杜孝平，张 禄，李 晔

DU Xiaoping,ZHANG Lu,LI Ye

北京航空航天大学 软件学院，北京100191

College of Software,Beihang University,Beijing 100191,China

1 引言

AFC（Automatic Fare Collection）系统又称为自动售检票系统，是城市公共交通中的一项重要技术[1]，为城市轨道交通带来了诸多益处。改革开放以来，北京城市公共交通尤其是城市轨道交通基础设施和运营管理得到了较快发展，AFC 作为城市轨道交通运营不可缺少的核心组成系统，为运营的科学管理提供依据[2]。北京市AFC 系统在投入运营前需要进行常规连接测试、异常连接测试、功能测试、专项测试、集成测试等测试工作。异常连接测试的任务是测试AFC 系统中被测车站设备和系统对异常数据的处理是否符合《北京轨道交通AFC系统设计及实施规范》（简称“实施规范”）中的相关要求，它是检测AFC 系统容错性的重要手段。

文献[3-5]讨论了在平台搭建基础上对AFC 功能和接口进行测试的问题；文献[6-7]在讨论模拟测试工具的设计实现基础上，介绍了对AFC 系统的功能与接口测试。现有文献尚未看到对异常连接测试的相关测试工具研究的介绍。

负责北京市AFC 系统检测的北京市轨道交通指挥中心现在针对异常数据处理的测试方式是利用一个辅助测试工具，通过熟悉AFC 系统的人员对照实施规范中的数据结构，手动构造测试数据，并按测试用例逐步发送/接收数据，人工对比接收到的数据和测试用例中的预期数据是否一致，来判断被测对象是否满足要求。其测试方式对人员素质要求较高，且编制数据与控制数据收发过程效率低下，易于出错。本文对设计实现一个异常连接测试工具用于完成上述测试任务进行讨论。该工具可自动生成测试数据，自动控制数据收发流程，降低测试人员对系统业务了解的要求，提高测试效率。

2 问题描述与分析

AFC 系统一般采用5 层架构体系：清算中心（AFC Clearing Center，ACC）、线路中心（Line Center，LC）/多线路中心（Multiple Line Center，MLC）、车站计算机系统（Station Computer，SC）、车站终端设备（Station Level Equipment，SLE）和车票层[8-11]，如图1 所示。异常连接测试的任务是测试MLC、SC 与SLE 之间对异常数据的处理是否符合实施规范的要求。异常连接测试工具需要具备仿真上述某一层系统或设备同其他被测系统或设备（简称被测对象）建立连接，向被测对象发送消息并检查应答的功能，具体包含仿真MLC 测试SC、仿真SC 测试MLC与SLE以及仿真SLE测试SC四部分。其开发原理是基于AFC 系统各层次的通信接口协议，由仿真工具模拟生成各层次系统或设备的测试数据，与被测对象进行通信，验证测试数据能否符合实施规范的要求[12]。

图1 AFC 系统层次图

3 测试工具设计

3.1 总体设计

异常连接测试的一般流程为先准备测试数据，再与被测对象建立连接，最后按测试用例收发数据，若收发数据的顺序和内容都与测试用例一致，则该测试用例通过，否则中断测试用例的执行，对错误进行记录。工具设计以尽力降低系统耦合度，实现数据共享，加强功能函数复用为原则。基于此原则，本工具的总体架构设计为界面层、支撑层、数据层三层。界面层为直接面向用户的功能层，包含测试数据准备、实现与被测对象的连接以及执行测试功能；支撑层为工具的运行提供公用的功能函数，为界面层的各个功能提供有效支持；数据层为整个工具的运行提供数据支撑，用于存储自动生成的测试数据、测试日志以及测试数据结构数据和测试用例结构数据。测试工具的总体结构如图2 所示。

图2 测试工具的总体架构

为实现本工具的各功能，使其能替代大部分人工测试工作，需要解决两个关键问题：测试数据的自动生成和测试用例的自动执行，下面为这两个问题提供解决思路。

3.2 关键问题的解决

3.2.1 自动生成测试数据

为了能够自动生成测试数据，首先需要根据测试数据的特征将其进行分类，再利用这些分类数据根据需要灵活生成满足测试需求的测试数据。自动生成的测试数据是否正确依据实施规范规定的内容来判断。

实施规范中规定的测试相关数据由大量数据字段构成。基于自动生成测试数据时每个字段被处理的方式的不同，可将这些数据字段归纳为六类：

（1）固定内容字段。包含由实施规范规定的数据起始、结束标识等字段。这类字段长度与内容都在实施规范中有明确的定义，其值固定不变。

（2）随本工具模拟的设备不同而变化的字段。包含设备ID、设备IP、设备群组号等设备的基本信息字段。这类字段长度固定，内容随设备而变。

（3）随时间变化的字段。包含描述数据发送时间、交易生成时间等与时间相关的字段。这类字段长度不变，内容随时间变化，且其值来自于数据产生时的系统时间。

（4）随测试用例变化的字段。这类字段用于描述由本工具向被测对象发送的消息错误应答中的错误码，其值由测试用例中规定的错误类型确定。这类字段长度不变，内容随具体测试用例而变。

（5）描述数据包长度的字段。这类字段长度不变，其值随数据包的大小不同而不同。

（6）需要人工参与填写数据值的字段。包含请求指定包数目、状态数量数据等。这类字段长度不变，其值在实施规范和测试用例中都没有规定，需要测试者按实际情况填写，该类数据字段很少，仅在少量测试数据中出现，对自动生成测试数据的影响不大。

自动生成测试数据时，每个测试数据由多个前述数据字段构成，单个数据字段的长度和结构不变，但整个测试数据的长度和结构随测试的不同而不同。

测试数据属于半结构化数据，利用关系型数据库存储管理较为困难。可扩展标记语言（XML）是半结构化数据的一个特例[13]，XML 数据模型能很好地实现对半结构化数据的管理以及不同程序或模块对半结构化数据的共享[14]。本文以XML 作为测试数据结构数据和测试用例结构数据的存储语言。

为实现自动生成测试数据的功能，可将每个数据的具体结构和固定内容按一定规则用XML 存储于配置文件中，通过自动生成测试数据函数（在4.2 节介绍）解析配置文件来生成测试数据。配置文件中测试数据的结构如图3 所示。

图3 测试数据存储结构

图中第2～4 行分别用于描述实施规范中数据的一级分类（如控制数据）、子分类（如控制数据中的命令数据）与数据的具体名称（如设备运行控制命令）。

第5～10 行用于表示一个数据字段，其中第10 行中的property 属性用于标识该字段属于六个数据字段分类中的哪一类。

第11～20 行用于表示一个特殊的数据片段的结构，该数据片段可以在一个测试数据中重复多次。

自动生成测试数据函数在解析测试数据结构后，根据测试数据结构中每个数据字段的分类来做出相应的处理，生成预期的测试数据。自动生成测试数据函数对各类字段的处理方法如下：

对于第一类字段，直接取其固定值写入。

对于第二类字段，通过提取本工具模拟设备时填写的设备相关信息来写入。

对于第三类字段，取生成该字段时的系统时间填入数据字段。该类字段描述的是数据发送时间、交易生成时间等，属于即时内容。

对于第四类字段，其数据内容需要在自动执行测试用例时实时填入，即通过读取测试用例中的相应数值来填入。该类字段的值是在测试用例中规定的，同一类数据在不同的测试用例中该值都可能不同，需要在执行测试用例时实时填入。

对于第五类字段，在数据包生成完成后通过计算数据包长度填入。其值来自于将测试数据中每个字段的字节长度相加的结果。

对于第六类字段，自动生成测试数据函数生成默认的固定值，这些默认值可能并不符合实际情况，但在大部分测试用例中并不影响测试结果，若用户不想使用默认值，则可以自己修改该类数据字段的值。

3.2.2 自动执行测试用例

执行测试用例时，是由测试人员逐条执行测试用例的每个步骤，观察实际操作结果与测试用例的描述结果是否相同。其中每个步骤的操作内容可以分为两类：向被测对象发送数据和对比来自被测对象的数据与测试用例描述数据是否相同。自动执行测试用例的功能，可以通过取出以XML 文件组织的测试用例，根据解析的结果调用相应的功能函数并获取相应的测试数据来实现[15]。测试用例按一定规则用XML 存储在配置文件中，测试用例的每个步骤作为一个节点，每个节点中存储数据名称，并区分该数据是“发送”还是“接收”。在自动执行测试用例时，自动执行测试用例函数解析配置文件，当节点中的数据标记为“发送”时，则调用自动生成测试数据函数生成相应测试数据或直接获取已经存在的测试数据并发送，然后继续读取下一个节点；当节点中的数据标记为“接收”时，则调用数据解析函数（在4.2节介绍）解析接收到的数据，对比接收到的数据特征与节点中存储的数据特征是否相同，若相同则继续读取下一个节点；若不同则中止测试用例的执行，提示用户测试用例执行出错。用例执行过程中收发的数据和提示信息都会记录于日志文件中。

4 测试工具实现

本测试工具的界面层按用户行为主要分为三部分：与被测对象连接、数据准备和执行测试。

与被测对象连接部分需要实现配置测试工具的连接信息来与被测对象建立连接，并向被测对象发送测试数据以及接收来自被测对象的数据的功能。

数据准备部分需要实现自动生成测试数据，解析显示测试数据的功能。

执行测试部分需要实现自动执行测试用例，执行过程中自动生成测试数据，解析来自被测对象的数据的功能。

4.1 与被测对象连接的实现

异常连接测试中要求传输的数据利用基于TCP/IP的SOCKET 协议进行传输。根据实际测试需求，本工具可模拟测试对象主动连接实际的被测对象（如利用本工具模拟SC 测试MLC 以及模拟SLE 测试SC 时，由本工具向被测对象MLC 和SC 发出连接请求）；或作为模拟的测试对象等待实体被测对象主动连接（如利用本工具模拟MLC测试SC以及模拟SC测试SLE时，本工具被动等待来自实测对象SC 与SLE 的连接请求）。主动请求连接的一方称为客户端，等待连接请求的一方称为服务端。建立连接时，由服务端监听某个端口，客户端根据服务端的IP 地址和其监听的端口号与服务端建立连接。

与被测对象建立连接、发送接收数据通过C#的socket库实现。建立连接的过程如图4 所示。

图4 建立连接过程

4.2 数据准备的实现

该部分由自动生成测试数据函数和数据解析函数来实现。为方便对自动生成测试数据函数的原理进行说明，将图3 所示的XML 文件抽象为图5（a）所示的树状结构，将实际测试数据（一个二进制文件）内容抽象为图5（b）所示的结构。自动生成测试数据函数首先解析如图3 所示的XML 文件，找出要生成的测试数据节点（如DataType_2），然后遍历该节点下的每个子节点Row1,Row2,…，每个子节点即一个数据字段，函数判断该数据字段属于六个数据字段分类中的哪一类，按3.2.1小节中对相应数据字段的处理方法生成数据内容，并将数据内容填入图5（b）所示的相应片段中。若某个Row节点下存在children 子节点（如Row2，其生成的数据内容设为x），则需要为children 节点的子节点Row′1,Row′2,…生成数据内容，并插入到Row2节点的数据内容之后，且需要循环生成x遍children 节点的子节点内容。当Row节点遍历完成，则测试数据也生成完毕。

数据解析函数用于解析一个已经存在的数据包，通过取二进制数据中的特定位置的字节与实施规范中的定义比对，以此判断该数据的具体名称，并由该具体名称从图3 的XML 文件中获取相应数据结构，然后将该数据包按该结构分解展示给用户查看和修改，方便用户对数据包的理解和维护。

图5 抽象结构

图6 为本工具的自动生成测试数据的界面。图中A区域表示数据分类结构树，由图3 的XML 文件生成；B区域表示自动生成的测试数据。

图6 自动生成数据界面

4.3 执行测试的实现

该部分由自动生成测试数据函数、自动执行测试用例函数和数据解析函数来实现。执行测试时调用自动执行测试用例函数，发送数据时调用自动生成测试数据函数生成相应数据并发送，接收数据后调用数据解析函数解析数据，并对比接收到的数据特征与测试用例中存储的数据特征是否相同。

自动执行测试用例函数读取存储有测试用例结构的XML 文件，存储结构如图7 所示。

图7 测试用例存储结构

图8 测试用例自动执行结果

当函数读取到SendData 节点时会发送相应的数据。SendData 节点中存储需要发送的数据名称，根据该名称函数会调用自动生成测试数据函数来生成相应的数据。filledByTester属性用于标识该数据中是否有需要测试人员填写的数据，如果其值为true，则测试者可以选择本地已有的存储数据的文件作为发送数据，防止每次发送相同的数据时都需要测试者自己填写数据内容。如果发送的数据需要构造某些异常，则需要errorType属性。自动执行测试用例函数会根据errorType 属性的不同来更改发送数据的相应字段，以构造相应的异常数据。当发送的数据是消息错误应答，该反馈中需要填写错误类型代码时，则填入errorCode属性值。

测试用例自动执行结果如图8 所示。

5 结束语

本文通过分析当前北京AFC 系统异常连接测试过程中存在的问题，找出了影响测试效率的瓶颈。通过总结归纳测试数据和测试流程步骤，将测试数据分为六类，测试流程步骤分为两类，并将这些特点信息存储于XML 文件中，由异常连接测试工具自动解析处理，开发实现了具有自动生成测试数据、自动执行测试用例功能的异常连接测试工具，为测试提供了一种可选的新手段。数据结构和测试用例步骤的可定制性，以及界面的友好性将是下一步工作的重点。

[1] Ampelas A.Automatic fare collection[C]//Proceedings of Intelligent Transportation Systems，2001：1164-1166.

[2] 赵菁.试论城市轨道交通（AFC）系统运营数据分析与运营管理[J].城市建设，2010（11）：128-129.

[3] 陈伟欣，杨俊辉，肖力扬.基于Web 的城市轨道AFC 仿真测试平台设计[C]//第十届中国科协年会论文集（一），郑州，2008：284-287.

[4] 黄钟.自动售检票通用测试平台的构建[J].城市轨道交通研究，2006，9（12）：32-35.

[5] 徐高峻.自动售检票系统模拟测试平台的组建与应用[C]//2010 城市轨道交通关键技术论坛论文集，上海，2010：503-506.

[6] 张志敏.针对AFC 系统的自动化测试工具研究与实现[D].长沙：湖南大学，2010.

[7] 叶皑.自动售检票软件测试方法及其工具应用研究[D].上海：东华大学，2010.

[8] 徐炜炜，徐骏善，叶飞.自动售检票系统中车站信息管理系统的研究与设计[J].城市轨道交通研究，2012（5）：53-56.

[9] 潘颖芳.城市轨道交通AFC 系统体系结构分析与研究[J].信息技术，2012（2）：166-168.

[10] 裴顺鑫，张宁.地铁自动售检票系统的互联标准[J].都市快轨交通，2007（5）：38-41.

[11] 陈鹏辉.城市轨道交通自动售检票系统的现状与发展趋势[J].城市轨道交通研究，2009（5）：10-12.

[12] 蔡佳妮.自动售检票系统检测中心检测理念与实施策略[J].城市轨道交通研究，2011（1）：24-28.

[13] 邬晶亮.基于XML 的半结构化数据存储和查询的研究与实现[D].上海：上海交通大学，2006.

[14] Bertolino A，Gao J，Marchetti E，et al.Automatic test data generation for XML schema-based partition testing[C]//Proceedings of the 2nd International Workshop on Automation of Software Test.[S.l.]：IEEE Computer Society，2007.

[15] 朱菊，王志坚，杨雪.基于数据驱动的软件自动化测试框架[J].计算机技术与发展，2006（5）：68-70.