CN109710513B - 一种用于cbtc系统自动化测试的引擎 - Google Patents

Abstract

本发明属于列车控制技术领域，涉及一种用于CBTC系统自动化测试的引擎，包括测试主引擎和测试分引擎两部分；测试主引擎为中央控制单元，提供测试脚本的解析，测试流程的控制，测试任务的分配，各测试执行器的同步与协调，从测试分引擎中搜集订阅的测试数据，以及测试脚本的终止、暂停、重载和测试动作的取消、恢复；测试分引擎，是测试脚本的真正执行者，根据主引擎下发的测试动作，依次向STP仿真测试平台发送消息，并且接收STP仿真测试平台上传的消息。本发明自动化测试引擎可分布式部署，并发执行测试案例。测试分引擎的应用层由STP仿真平台的相关模块集成实现，可花费极小的开销，将其分布在不同的机器上并行执行，极大的提高了测试执行的效率。

Description

一种用于CBTC系统自动化测试的引擎

技术领域

本发明属于列车控制技术领域，具体涉及一种用于CBTC系统自动化测试的引擎。

背景技术

随着计算机技术以及通信技术的快速发展，基于通信的列车控制技术CBTC(Communication Based Train Control)已经发展为城市轨道交通中主流的信号制式。当前，CBTC系统产品的的规模越来越大，其业务和实现的复杂度也越来越高。这样大规模和高复杂度的控制软件给测试工作带来了很大的困扰，并且传统的人工测试易出错、效率低、成本高，因此软件自动化测试势在必行。

1.自动化测试方法介绍

常用的自动化测试方法主要有简单的录制/回放、数据驱动和关键字驱动，很多的自动化测试框架都基于这三种方法设计。

1)简单的录制/回放：由测试工具录制并记录测试人员操作过程和数据，并将其转化为脚本，通过回放来重复人工操作的过程。在这种模式下，数据和脚本混在一起，几乎一个测试案例对应一个测试脚本，维护成本很高，脚本复用率很低。

2)数据驱动的自动化测试：从数据文件或数据库读取输入数据，通过变量的参数化，将测试数据传入测试脚本，不同的数据文件对应不同的测试案例。在这种模式下，数据和脚本分离，脚本的利用率、可维护性大大提高，但是这种方法仍然在较大程度上受到测试软件变化的影响。

3)关键字驱动的自动化测试：它是数据驱动测试的一种改进类型，它将测试逻辑按照关键字进行分解，形成数据文件，关键字对应封装的业务逻辑。主要关键字包括三类：被操作对象(Item)、操作(Operation)和值(Value)。这种方法使得脚本与数据分离、测试描述与具体实现细节分离，极大地增加了平台的可拓展性。

2.自动化测试工具介绍

从测试类别上自动化测试工具可分为白盒测试工具和黑盒测试工具，黑盒测试工具一般是针对被测对象的源程序进行测试，测试故障精确到代码级。而黑盒测试工具则是主要针对被测对象的功能进行测试，不需考虑软件内部的实现。目前市场上已经有一些成熟的测试工具。

1)Silk Test软件功能测试工具

Silk Test International是适用于当今全球企业级应用的一种先进的、基于标准的测试平台。它可以使用户通过执行单一的测试脚本同时测试跨多种语言、平台和Web浏览器的应用。Silk Test自动化测试工具提供测试的计划和管理、直接的数据库访问及校验、内置全天恢复系统等功能。

2)Test Partner

Test Partner是一个自动化的功能测试工具，它专为测试基于微软、Java和Web技术的复杂应用而设计。测试人员和开发人员都可以使用可视的脚本编制和自动向导来生成可重复的测试，没有编程知识的测试人员都能操作，使用可视化的导航器快速创建测试并执行。并且通过可视化的导航器录制并回放测试，每一个测试都将被展现为树状结构，以清除地展现测试通过应用的路径。

3)Silk Performer

Silk Performer是企业级负载和强度测试解决方案，用于对关键任务应用的质量进行优化。它使用可视化脚本生成技术和对存在成千上万的并发用户的多个应用环境进行测试的能力，以便能够在企业应用部署前，就对其可靠性、性能和可伸缩性进行彻底的测试，而无需考虑其规模大小和复杂程度。并且，Silk Performer拥有的诊断工具和报告管理能够帮助快速做出决定，从而很大程度上缩短了测试周期。

4)Load Runner

Load Runner是一款非常全面的性能测试工具。它可以对软件产品进行负载和压力测试，以防止产品硬件或架构设计等因素带来的各种性能瓶颈。它通过模拟成千上万的虚拟用户以及对性能指标的实时监测来进行测试，测试人员最终通过对测试报告的分析和诊断，找到优化系统的最佳方案。

上述介绍的自动化测试工具适用的范围都比较小，可扩展性差，都是一些专用型的自动化测试系统，比如Silk Test和Test Partner是针对功能测试的自动化测试工具，Silk Performer和Load Runner是针对性能测试的自动化测试工具。并且，这些自动化测试工具并不适用于轨道交通信号系统的测试。

发明内容

(一)要解决的技术问题

本发明要解决的技术问题是：大规模和高复杂度的控制软件给测试工作带来了很大的困扰，并且传统的人工测试易出错、效率低、成本高。

(二)技术方案

为解决上述技术问题，本发明提供一种用于CBTC系统自动化测试的引擎，包括测试主引擎和测试分引擎两部分；

测试主引擎为中央控制单元，提供测试脚本的解析，测试流程的控制，测试任务的分配，各测试执行器的同步与协调，从测试分引擎中搜集订阅的测试数据，以及测试脚本的终止、暂停、重载和测试动作的取消、恢复；

测试分引擎，是测试脚本的真正执行者，根据主引擎下发的测试动作，依次向STP仿真测试平台发送消息，并且接收STP仿真测试平台上传的消息。

进一步，测试分引擎在STP仿真测试平台的分布式对象中，与模型或代理的交互属于本地函数调用，并且只向测试主引擎发送订阅的消息。

进一步，测试主引擎作包含四个功能模块：测试脚本解析器、测试任务分配管理器、测试数据管理器和测试引擎管理器；

测试脚本解析器：根据预定义的测试动作库来解析测试脚本，从而生成可执行的测试事件链；

测试任务分配管理器：根据测试事件链中元素的具体含义，将之按照一定的规则拆分为若干可以并行执行的测试分支，并根据当前各分布式处理机与测试分支的相匹配度，将各任务进行下发；

测试数据管理器：负责收集所有测试关心的数据，汇总，以便测试结束后进行评价和分析；

测试引擎管理器：负责监控各分布式处理机的繁忙度，同时负责各任务执行器所需的任何配置工作，协调工作。

进一步，测试脚本解析器预编译所有的静态信息并剥离动态信息。

进一步，与测试监控管理子系统、测试分引擎等外部模块的接口由测试引擎管理器负责。

测试主引擎和测试分引擎之间通过集中监控模块来进行通信，测试主引擎将测试消息发送给集中监控模块，集中监控模块会根据消息中的地址将消息对应的转发给各测试分引擎。并且，集中监控模块会接收各测试分引擎返回的测试结果，将测试结果返回给测试主引擎。

进一步，测试主引擎和测试分引擎之间通过集中监控模块来进行通信，测试主引擎将测试消息发送给集中监控模块，集中监控模块会根据消息中的地址将消息对应的转发给各测试分引擎；集中监控模块会接收各测试分引擎返回的测试结果，将测试结果返回给测试主引擎。

(三)有益效果

与现有技术相比较，本发明具备如下有益效果：

本发明自动化测试引擎可分布式部署，并发执行测试案例，大大提高测试效率。测试分引擎的应用层由STP仿真平台的相关模块集成实现，可花费极小的开销，将其分布在不同的机器上并行执行，极大的提高了测试执行的效率。

本发明自动化测试引擎用于CBTC系统的自动化测试，可用于其系统功能测试和性能测试，产品专项级测试和系统级测试。由于CBTC系统软件极为复杂，且安全性要求较高，并且测试周期较于一般的系统软件要长的多，因此对于软件测试需要投入极大的人力和物力，此自动化测试引擎的设计将会极大的改善这一现状，在较大的程序上提高测试效率，缩短测试周期，减少人力和物力的投入。虽然此自动化测试引擎是专用于CBTC系统软件自动化测试的，但它在CBTC系统软件测试中却有着很好的通用性，可用于功能测试和性能测试，产品专项级测试和系统级测试。

附图说明

图1为测试引擎结构图。

图2为测试引擎执行流程图。

图3为网络服务系统流程图

图4为Petri网图。

具体实施方式

为使本发明的目的、内容、和优点更加清楚，下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。

实施例1

测试引擎作为自动化测试平台的核心，承担着测试脚本的解析执行和结果判定的工作，它驱动STP仿真测试平台完成测试所需的规定动作，并记录测试数据以待分析，同时，为测试人员在测试过程中人工干预测试过程提供支持。

本发明自动化测试引擎包括测试主引擎和测试分引擎两部分。测试主引擎为中央控制单元，提供测试脚本的解析，测试流程的控制，测试任务的分配，各测试执行器的同步与协调，从测试分引擎中搜集订阅的测试数据，以及测试脚本的终止、暂停、重载和测试动作的取消、恢复等功能。测试分引擎(即分布式测试执行器)，是测试脚本的真正执行者，它不再具有复杂的控制流程，只是根据主引擎下发的测试动作，依次向STP仿真测试平台发送消息，并且接收STP仿真测试平台上传的消息。测试分引擎在STP仿真测试平台的分布式对象中，与模型或代理的交互属于本地函数调用，并且只向测试主引擎发送订阅的消息。

测试引擎的总体结构如图1所示，测试引擎由测试主引擎和测试分引擎组成，其中测试主引擎作为中央控制单元，控制着整个测试流程，它包含四个主要的功能模块——测试脚本解析器、测试任务分配管理器、测试数据管理器、测试引擎管理器。

1)测试脚本解析器

根据预定义的测试动作库来解析测试脚本，从而生成可执行的测试事件链。其最主要的功能不但在于解释各种动作，组合成为事件链，而且，脚本解析器还要预编译所有的静态信息并剥离动态信息。此外，解析器还要标注所有动态信息的来源及获取方式，使得分引擎在执行测试任务时，可以跳过解读测试脚本的阶段，直接获取所需要的动态信息。

2)测试任务分配管理器

根据测试事件链中元素的具体含义，将之按照一定的规则拆分为若干可以并行执行的测试分支，并根据当前各分布式处理机与测试分支的相匹配度，将各任务进行下发。

3)测试数据管理器

负责收集所有测试关心的数据，汇总，以便测试结束后进行评价和分析。同时，记录测试进行的过程，为测试过程的重现奠定基础。此外，记录测试任务中对测试环境所做出的改变，以便在测试结束时，为迅速恢复现场提供数据上的参考和依据。

4)测试引擎管理器

在测试的整个过程中，测试引擎管理器负责监控各分布式处理机的繁忙度，同时负责各任务执行器所需的任何配置工作，协调工作。此外，与测试监控管理子系统、测试分引擎等外部模块的接口也由测试引擎管理器来负责。

而测试分引擎作为测试脚本真正的执行者，则不再具有复杂的控制流程，只是负责向STP仿真平台发送测试消息，并接收STP仿真平台返回的消息，经过判定之后返回给测试主引擎，因此结果判定是测试分引擎唯一具有一定计算逻辑的模块。

测试主引擎和测试分引擎之间通过集中监控模块来进行通信，测试主引擎将测试消息发送给集中监控模块，集中监控模块会根据消息中的地址将消息对应的转发给各测试分引擎。并且，集中监控模块会接收各测试分引擎返回的测试结果，将测试结果返回给测试主引擎。

执行流程如图2所示：

1)测试监控管理子系统向测试主引擎下发脚本信息、重载脚本命令、测试启动命令、测试终止命令等；

2)测试主引擎接收到脚本之后进行加载操作，然后当接收到执行命令后，由脚本解析器对脚本进行解析，生成带有测试动作的测试事件链；

3)测试主引擎的测试任务管理器会根据脚本将其分成若干个并行执行的测试分支，每个测试分支依次执行测试事件链上的测试动作；

4)测试主引擎根据测试动作类型，由测试引擎管理器将测试数据发送给集中监控模块(OCManager)，并等待测试结果返回；

5)测试主引擎在进行各项工作时，测试数据管理器会实时记录每一步的执行数据；

6)集中监控模块(OCManager)接收到测试主引擎的数据之后，会提取其中的地址信息，通过地址信息将测试数据发送给模块名为此地址的测试分引擎；

7)测试分引擎收到测试数据，经处理之后发送给STP仿真平台，并等待反馈结果；

8)测试分引擎接收到反馈结果之后，进行结果判定，将判定通过的订阅消息返回给测试主引擎，如果判定不通过则不返回任何消息；

9)测试主引擎如果在规定的时间内收到测试分引擎返回的测试结果，则判定通过，如果超时未收到测试分引擎返回的消息，则判定失败；

10)测试主引擎将执行成功或失败的消息返回给测试监控管理子系统；

11)在这测试过程中如果测试主引擎收到测试监控空管理子系统发来的测试终止命令，则向测试分引擎发送终止测试消息，并停止所有的执行线程，返回执行失败。

为了实现自动测试引擎的设计，本发明引用3个关键技术——网络服务注册技术、Petri网技术和结果判定技术。其中，网络服务注册技术主要为测试引擎内部之间通信以及和外部模块之间通信而设计，对IP和端口统一管理分配，减少手工配置的繁复，而且避免IP和端口出现冲突。Petri网技术主要用于测试主引擎的设计，是测试主引擎的设计原理，为测试事件链的执行提供重要的理论依据。结果判定技术主要用于测试分引擎，是测试分引擎的核心功能，帮助测试分引擎在执行测试之后对测试结果进行判定，为测试案例通过与否提供依据。

1)网络服务注册技术

从图1的测试引擎结构可以看出，它有许多的网络接口，测试主引擎与测试监控管理子系统、测试主引擎与测试分引擎之间均通过TCP连接通信，并且测试主引擎与测试分引擎通过集中监控模块(OCManager)进行间接通信，监控模块(OCManager)将测试主引擎的数据转发给各个测试分引擎，并且收集各个测试分引擎的消息，返回给测试主引擎，如果采用传统的通信方式，测试监控管理子系统、测试主引擎、监控模块(OCManager)、各个测试分引擎均需配置位移的IP和Port，这样则需要维护一张地址信息配置表，每当增加一个测试分引擎则需在表中增加一个配置，维护起来很是繁琐，并且容易出错。因此我们这里设计了一个网络服务系统，当模块启动时，便会向网络服务模块NetServer注册自己的地址，并分配端口号Port。当某一模块作为客户端向另一模块(服务端)请求数据时，便会从网络服务中查询服务端IP和Port，然后进行连接以及数据传输。

具体流程如图3所示：

NetServer建立服务器端，等待连接；

一般模块(测试监控管理子系统、测试主引擎)启动，向NetServer注册，并查询要连接的其它模块地址；

集中监控模(OCManager)块启动，向NetServer注册；

测试分引擎(OC)启动，向NetServer注册；

NetServer收到来自模块的注册信息，首先判断其模块类型，若它是集中监控模块(OCManager)，便会向其发送所有监控代理的IP和Port；否则，便会判断注册模块是否带有查询IP的指令。

如果模块带有查询指令，则会在NetServer中查询其它模块已注册的IP地址，否则，将为其分配端口号，模块收到端口号之后，便作为服务器进行监听。

带有查询指令的模块向NetServer查询已经注册的其它模块IP，若查到则返回其它模块IP和Port；否则，将为其分配端口号，模块收到端口号之后，便作为服务器进行监听。

2)Petri网技术

测试主引擎作为自动测试平台的核心模块，是中央控制单元，具有复杂的控制逻辑，要实现测试事件链的生成以及执行，并依次反馈测试结果，这一系列的操作具有联锁关系，因此我们在这里基于petri网技术理论来实现测试主引擎软件设计。一个测试脚本往往由多个测试步骤构成，每个测试步骤对应一个测试事件，测试事件对应有测试动作，测试事件的发生即对应测试动作的执行；前后测试事件有依赖关系，所有的测试事件隶属于当前脚本的测试流程中的某个节点，测试事件的依次发生实际是该事件激活的节点状态满足条件，即节点状态的变迁导致了测试事件的依次发生，在人工测试时，节点状态变化是测试人员测试执行步骤引起，自动测试时，需要测试主引擎驱动。在测试主引擎设计实现中，可以将一个测试脚本对应为一个测试事件链，一个测试事件链上包括测试事件链节点，每个测试链节点被关联多个测试动作；测试脚本的执行转变为测试事件链流程的进行，在测试流程执行过程中，需要设计实现petri网中的令牌以驱动流程的遍历执行。

petri网是简单的过程模型，如图4所示，由两种节点：库所(对应测试事件链节点)和变迁(对应测试事件链节点之间的路径，包含两种路径——离开路径和跳过路径)，有向弧，以及令牌(对应测试事件链节点中的测试动作)等元素组成的。

Petri网的元素：

库所(Place)圆形节点；

变迁(Transition)方形节点；

有向弧(Connection)是库所和变迁之间的有向弧；

令牌(Token)是库所中的动态对象，可以从一个库所移动到另一个库所。

规则：

有向弧是有方向的；

两个库所或变迁之间不允许有弧；

库所可以拥有任意数量的令牌。

行为：

如果一个变迁的每个输入库所(input place)都拥有令牌，该变迁即为被允许(enable)。一个变迁被允许时，变迁将发生(fire)，输入库所(input place)的令牌被消耗，同时为输出库所(output place)产生令牌。

变迁的发生是完整的，也就是说，没有一个变迁只发生了一半的可能性。

有两个或多个变迁都被允许的可能，但是一次只能发生一个变迁。这种情况下变迁发生的顺序没有定义。

如果出现一个变迁，其输入库所的个数与输出库所的个数不相等，令牌的个数将发生变化，也就是说，令牌数目不守恒。

Petri网络是静态的，也就是说，不存在发生了一个变迁之后忽然冒出另一个变迁或者库所，从而改变Petri网结构的可能。

Petri网的状态由令牌在库所的分布决定。也就是说，变迁发生完毕、下一个变迁等待发生的时候才有确定的状态，正在发生变迁的时候是没有一个确定的状态的。

两个变迁争夺一个令牌的情形被称之为冲突。当发生冲突的时候，由于Petri网的时序是不确定的，因此具体哪个变迁得以发生也是不确定的。实际应用中，往往需要避免这种情形。用于描述现象的Petri网也可能自然出现冲突，这表明我们对于变迁发生的条件没有完全了解。

多个弧连接两个节点的情况。在输入库所和变迁之间的弧的个数决定了该变迁变为被允许需要的令牌的个数。弧的个数决定了消耗/产生的令牌的个数。

3)结果判定技术

有效的测试结果判定是完整的自动化测试系统重要的组成部分，本系统实现的自动测试平台具备测试结果的自动判定功能。

结果判定由测试分引擎实现。

测试脚本规范中制定测试期望值的脚本定义，含测试期望值的测试动作定义，测试期望值的类型(单个或多个变量、变量类型)，测试结果判定标准(何种情况测试反馈数据与测试期望值一致，如单个变量完全一致或在某个阈值范围内一致，多个变量完全一致或部分一致，每个周期一致或部分周期一致等)，超时判断定义(何种情况下超时表示测试反馈数据与测试期望值不一致；何种情况下超时表示不能确定测试反馈数据与测试期望值不一致，只表示测试正常进行中)等。

测试分引擎将测试执行的结果与测试主引擎下发的测试期望动作与数据进行匹配判定，将判定通过的数据放回给测试主引擎。

Claims (3)

1.一种用于CBTC系统自动化测试的引擎，其特征在于，包括测试主引擎和测试分引擎两部分；

测试主引擎为中央控制单元，提供测试脚本的解析，测试流程的控制，测试任务的分配，各测试执行器的同步与协调，从测试分引擎中搜集订阅的测试数据，以及测试脚本的终止、暂停、重载和测试动作的取消、恢复；

测试分引擎，是测试脚本的真正执行者，根据主引擎下发的测试动作，依次向STP仿真测试平台发送消息，并且接收STP仿真测试平台上传的消息；

测试主引擎作包含四个功能模块：测试脚本解析器、测试任务分配管理器、测试数据管理器和测试引擎管理器；

测试脚本解析器：根据预定义的测试动作库来解析测试脚本，从而生成可执行的测试事件链；

测试任务分配管理器：根据测试事件链中元素的具体含义，将之按照一定的规则拆分为若干可以并行执行的测试分支，并根据当前各分布式处理机与测试分支的相匹配度，将各任务进行下发；

测试数据管理器：负责收集所有测试关心的数据，汇总，以便测试结束后进行评价和分析；

测试引擎管理器：负责监控各分布式处理机的繁忙度，同时负责各任务执行器所需的任何配置工作，协调工作；

测试脚本解析器预编译所有的静态信息并剥离动态信息；

与测试监控管理子系统、测试分引擎等外部模块的接口由测试引擎管理器负责；

测试主引擎和测试分引擎之间通过集中监控模块来进行通信，测试主引擎将测试消息发送给集中监控模块，集中监控模块会根据消息中的地址将消息对应的转发给各测试分引擎；并且，集中监控模块会接收各测试分引擎返回的测试结果，将测试结果返回给测试主引擎；

CBTC系统自动化的引擎中采用网络服务注册技术用于内部之间通信以及和外部模块之间通信，对IP和端口统一管理分配；

网络服务注册技术实现的具体流程为：

NetServer建立服务器端，等待连接；

测试主引外部测试监控管理子系统启动，向NetServer注册，并查询要连接的其它模块地址；

集中监控模块启动，向NetServer注册；

测试分引擎启动，向NetServer注册；

NetServer收到来自模块的注册信息，首先判断模块类型，若它是集中监控模块，便会向其发送所有监控代理的IP和Port；否则，便会判断注册模块是否带有查询IP的指令；

如果模块带有查询指令，则会在NetServer中查询其它模块已注册的IP地址，否则，将为其分配端口号，模块收到端口号之后，便作为服务器进行监听；

带有查询指令的模块向NetServer查询已经注册的其它模块IP，若查到则返回其它模块IP和Port；否则，将为其分配端口号，模块收到端口号之后，便作为服务器进行监听。

2.根据权利要求1所述用于CBTC系统自动化测试的引擎，其特征在于，测试分引擎在STP仿真测试平台的分布式对象中，与模型或代理的交互属于本地函数调用，并且只向测试主引擎发送订阅的消息。

3.根据权利要求1所述用于CBTC系统自动化测试的引擎，其特征在于，测试主引擎和测试分引擎之间通过集中监控模块来进行通信，测试主引擎将测试消息发送给集中监控模块，集中监控模块会根据消息中的地址将消息对应的转发给各测试分引擎；集中监控模块会接收各测试分引擎返回的测试结果，将测试结果返回给测试主引擎。

Images