CN104239217A - 铁路信号软件测试的方法及系统 - Google Patents

Abstract

本发明公开了一种铁路信号软件测试的方法及系统，包括：测试处理器获取预设测试序列，并依据解析所述预设测试序列得到的解析结果构建测试模型；状态机在构建的测试模型中启动，所述测试处理器，状态机，主引擎，分引擎和测试机组依据所述状态机的状态执行相应操作；当所述状态机处于启动成功状态时，所述主引擎和所述分引擎按照预设执行顺序的测试脚本对铁路信号软件进行测试；所述测试处理器通过所述测试机组监控所述主引擎和所述分引擎的测试过程，直至所述预设测试序列完成后，统计所述测试脚本的测试结果，并生成相应的测试报告，实现了对铁路信号软件进行自动化测试，降低了测试执行人员的工作量和提高了铁路信号软件测试结果的稳定性。

Description

铁路信号软件测试的方法及系统

技术领域

本发明涉及软件测试技术领域，特别是涉及一种铁路信号软件测试的方法及系统。

背景技术

软件开发的关键过程通常包括需求、涉及、实现和测试四个阶段。针对应用于铁路上的铁路信号软件与普通的应用软件则有所不同，其要求在复杂的条件下具备高安全性，所以其测试过程在软件开发过程中占据极其重要的位置。

在实际应用中，虽然也有一些自动测试的方法，但大多数只是具有基本的模式和测试功能，功能较为单一，在现有技术中多半还是采用传统的依赖测试人员的手工测试方式进行软件测试。但是，铁路信号软件为了满足高安全性，通常要求在铁路信号软件的测试中模拟大量而且复杂的场景、配置大量的工程数据，当利用传统的手工测试方式对铁路通信信号软件进行测试时，测试执行人员的工作量很大，耗费的人力成本与时间成本都十分高。另一方面，由于传统测试依赖于测试执行人员的经验与操作，导致测试工作不规范，在测试过程中会出现因为操作失误而重复测试的情况，进而导致测试结果不稳定。

由上述可知，采用现有的手工测试方法对铁路软件进行测试，不仅工作量大，还容易出现操作失误等致使测试结果不稳定的问题。

发明内容

有鉴于此，本发明提供了一种铁路信号软件测试的方法及系统，以达到降低测试执行人员的工作量和提高测试结果稳定性的目的。

为解决上述技术问题，本发明提供一种铁路信号软件测试的方法，应用于铁路信号软件测试的系统，所述铁路信号软件测试的系统包括测试处理器，状态机，主引擎，分引擎和测试机组，该方法包括：

所述测试处理器获取预设测试序列，并依据解析所述预设测试序列得到的解析结果构建测试模型；其中，所述预设测试序列包括：预设执行顺序的测试脚本和测试部署模型图；所述测试部署模型图包括：所述分引擎的数目，各个所述分引擎的路径、命令行参数、配置信息及启动的顺序；

所述状态机在构建的所述测试模型中启动，所述测试处理器，所述状态机，所述主引擎，所述分引擎和所述测试机组依据所述状态机的状态执行相应操作；其中，所述状态机的状态包括初始状态，主引擎启动状态和启动成功状态；

当所述状态机处于启动成功状态时，所述主引擎和所述分引擎按照预设执行顺序的所述测试脚本对铁路信号软件进行测试；

所述测试处理器通过所述测试机组监控所述主引擎和所述分引擎的测试过程，直至所述预设测试序列完成后，统计所述测试脚本的测试结果，并生成相应的测试报告。

优选的，所述测试处理器获取预设测试序列，并依据解析所述预设测试序列得到的解析结果构建测试模型，包括：

获取预设测试序列；

解析所述预设测试序列中的测试部署模型图，获得所述主引擎和所述分引擎所需的资源信息，其中，所述测试资源为所述测试机组上能够参与测试的网络通信端口和文件；

与所述测试机组中待分配的各个测试机进行通信；

当所述测试机组上所述主引擎和所有所述分引擎所需的资源信息未被占用时，将所述主引擎或所述分引擎分配至对应的所述测试机；

确定所有所述主引擎和所述分引擎都分配至对应的所述测试机；

依据分配结果向同一台所述测试机传输测试配置数据，其中，所述测试配置数据包括：运行所述测试序列需要的可执行程序和数据配置文件；

接收各个所述测试机依据所述测试配置数据分配到相应测试路径的确认信息，并依据各个所述确认信息构建测试模型。

优选的，在存在大量预设测试序列待进行测试的情况下，所述测试处理器获取预设测试序列，并依据解析所述预设测试序列得到的解析结果构建测试模型，包括：

根据所述预设测试序列的相关信息对所有的预设测试序列进行排序，得到测试序列队列，其中，所述相关信息包括：提交的时间和/或重要程度；

按顺序依据所述测试序列队列中的预设测试序列执行构建测试模型步骤；

其中，所述构建测试模型步骤包括：

按顺序获取预设测试序列；

解析所述预设测试序列中的测试部署模型图，获得所述主引擎和所述分引擎所需的资源信息；其中，所述测试资源为所述测试机组上能够参与测试的网络通信端口和文件；

与所述测试机组中待分配的各个测试机进行通信；

当所述测试机组上所述主引擎和所有所述分引擎所需的资源信息未被占用时，将所述主引擎或分引擎分配至对应的所述测试机；

或，

当所述测试机组上所述主引擎和/或所述分引擎所需的资源信息被占用时，返回执行测试序列队列选择下一个预设测试序列执行所述构建测试模型步骤，直至所有预设测试序列执行完所述构建测试模型步骤；

或，

当所述测试机组上所述主引擎和/或所述分引擎所需的资源信息被占用时，所述测试序列在所述测试序列队列中排队等待至所述测试资源改变，则将所述主引擎或分引擎分配至对应的所述测试机，或，为所述主引擎和所述分引擎分配其它测试机组，直至所有预设测试序列执行完所述构建测试模型步骤；

其中，所述测试资源改变，包括：所述分引擎运行结束，所使用的端口和文件被释放，或，新加入若干台测试机。

优选的，所述状态机在构建的所述测试模型中启动，所述测试处理器，所述状态机，所述主引擎，所述分引擎和所述测试机组依据启动状态执行相应操作，包括：

所述状态机开启并进入初始状态；

所述测试处理器发送主引擎启动命令至分配给所述主引擎的测试机；

所述分配给所述主引擎的测试机接收所述主引擎启动命令并开启所述主引擎；

当所述主引擎输出启动完毕等待分引擎连接的消息时，所述分配给所述主引擎的测试机向所述测试处理器发送主引擎启动成功消息；

所述测试处理器接收所述主引擎启动成功消息并向所述状态机发送主引擎启动成功响应信息；

所述状态机进入主引擎启动状态；

所述测试处理器根据所述测试部署模型图中的启动顺序发送分引擎启动命令至分配给分引擎的测试机；

所述分配给分引擎的测试机接收所述分引擎启动命令并开启所述分引擎；

直至所有需要启动的分引擎都已开启，所述状态机进入启动成功状态。

优选的，所述状态机在构建的所述测试模型中启动，所述测试处理器，所述状态机，所述主引擎，所述分引擎和所述测试机组依据启动状态执行相应操作，包括：

所述测试机组和/或所述测试处理器获取第一异常事件并向所述状态机发送对应于所述第一异常事件的异常事件信息；

其中，所示第一异常事件包括：所述铁路信号软件测试的系统的通信网络出现故障和所述测试资源被占用；

所述状态机接收所述异常事件信息，并生成启动中止指令和对应于所述异常事件的异常事件提示指令；

所述状态机启动过程中止，及，根据异常事件提示指令在所述状态机界面显示所述异常事件信息。

优选的，所述测试处理器通过所述测试机组监控所述主引擎和所述分引擎的测试过程，包括：

所述测试处理器接收由所述分配给所述主引擎的测试机接收并转发的当所述主引擎解析和执行所述测试脚本过程中检测到当前要执行的是显示命令语句时发送的显示命令语句的行数和状态信息，并依据所述显示命令语句的行数和状态信息在监控界面显示所述测试脚本执行到的行数；

所述测试处理器接收并显示由所述分配给所述分引擎的测试机实时获取并发送的所述分引擎的log信息；

和/或，

所述测试处理器接收由所述分配给所述主引擎的测试机接收并转发的当所述主引擎执行所述测试脚本过程中检测到第二异常事件时发送的所述第二异常事件发生时所述测试脚本执行到的行数和状态信息，并依据所述测试脚本执行到的行数和状态信息在监控界面显示所述测试脚本执行到的行数，并用不同的背景色区分所述第二异常事件中不同的异常，且一种背景色仅对应一种异常；

其中，所述第二异常事件包括：匹配分引擎输出异常、主引擎异常分引擎发生异常或测试环境发生异常。

优选的，所述预设测试序列完成后，统计所述测试脚本的测试结果，并生成相应的测试报告，包括：

统计所述测试脚本的测试结果；

依据所述测试结果判断所述测试脚本是否通过测试，如果是，则标记所述测试脚本通过，得到判断标记结果，否则，则标记所述测试脚本未通过，并显示出错的测试语句行数和未通过原因，得到判断标记结果；

依据所述测试脚本的测试结果和所述判断标记结果生成相应的测试报告。

优选的，在所述测试处理器通过所述测试机守护程序监控测试过程，直至所述测试序列完成后，统计所述测试脚本的测试结果，并生成测试报告之后，还包括：

清除所述测试机组中本次测试所涉及的进程和释放本次测试所占用的资源。

优选的，还包括，在所述测试序列执行过程中，所述测试处理器收到异常消息后中止本次测试，并清除所述测试机组中本次测试所涉及的进程和释放本次测试所占用的资源。

一种铁路信号软件测试的系统，包括：

测试处理器，用于获取预设测试序列，解析所述预设测试序列得到的解析结果构建测试模型；及，通过所述测试机组监控所述主引擎和所述分引擎的测试过程，直至所述预设测试序列完成后，统计所述测试脚本的测试结果，并生成相应的测试报告；其中，所述预设测试序列包括：预设执行顺序的测试脚本和测试部署模型图；所述测试部署模型图包括：所述分引擎的数目，各个所述分引擎的路径、命令行参数、配置信息及启动的顺序；

状态机，用于在构建的所述测试模型中启动，所述测试处理器，状态机，主引擎，分引擎依据所述状态机的状态执行相应操作；

主引擎和分引擎，用于当所述状态机处于启动成功状态时，按照预设执行顺序的所述测试脚本对铁路信号软件进行测试；测试机组，用于提供测试环境，及，与所述测试处理器进行通信并配合所述测试处理器完成测试。

相较现有技术，本发明的有益效果为：

基于上述本发明提供的铁路信号软件测试的方法及系统，该方法通过测试处理器获取预设测试序列，并依据解析该预设测试序列得到的解析结果构建测试模型；所述状态机在构建的所述测试模型中启动，所述测试处理器，状态机，主引擎，分引擎和测试机组依据该状态机的状态执行相应操作；当状态机处于启动成功状态时，主引擎和分引擎按照预设执行顺序的所述测试脚本对铁路信号软件进行测试；并且，所述测试处理器通过所述测试机组监控所述主引擎和所述分引擎的测试过程，直至所述预设测试序列完成后，统计所述测试脚本的测试结果，并生成相应的测试报告。本发明通过自动构建测试模型，自动监控测试过程及自动生成相应的测试报告，实现了对铁路信号软件进行自动化测试，降低测试执行人员的工作量，提高测试工作的规范性，进而提高了铁路信号软件测试结果的稳定性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本发明实施例一提供的铁路信号软件测试的方法流程图；

图2为本发明实施例二提供的步骤100具体过程的方法流程图；

图3为本发明实施例四提供的步骤101具体过程的方法流程图；

图4为本发明实施例六提供的方法流程图；

图5为本发明实施例八提供的铁路软件测试的系统的示例图。

具体实施方式

为了引用和清楚起见，下文中使用的技术名词的说明、简写或缩写总结如下：

SDP：Signalling Software Development Platform信号系统设计开发平台；

RPC：Remote Procedure Call Protocol远程过程调用协议，用于通过网络向远程计算机请求服务；

测试机：通用计算机或者服务器，提供运行测试分引擎的环境；

测试机组：用局域网连接起来的一组测试机，具有统一的组名；

测试脚本：用脚本语言描述测试的逻辑，实现逻辑控制、发送消息、接收消息及相应等等；

测试部署模型图：表示测试运行所需信息的UML模型图，通过解析测试部署模型图可以得到：可执行程序的路径、分引擎启动的顺序、分引擎启动参数、配置文件、通信协议类型等；

测试序列：测试运行的基本单元，包含若干需要顺序执行的测试脚本和测试部署模型图；

主引擎：运行测试序列中的内容并控制整个测试的进程，解析测试脚本中的语句驱动分引擎完成测试任务；

分引擎：对真实环境中相对独立的功能单元进行模拟的软件模块，可以模拟被测试的目标系统，也可以模拟其他与目标系统有交互的功能单元；

测试处理器：解析测试序列中的测试部署模型图，根据测试部署模型图中的信息给测试序列分配测试机资源，将测试序列中需要的主引擎、分引擎部署到同一测试机组内的测试机上。存在多个测试序列时，测试管理器需要根据优先级对测试序列的执行顺序进行调度；

测试机守护程序：运行在测试机上，负责与测试管理器进行通信，接受部署、启动等命令。

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明的核心是提供一种铁路信号软件测试的方法及系统，以达到降低测试执行人员的工作量和提高测试结果稳定性的目的。

为了使本技术领域的人员更好地理解本发明方案，下面结合附图和具体实施方式对本发明作进一步的详细说明。

实施例一

请参考图1，图1为本发明实施例一提供的铁路信号软件测试的方法流程图，该方法应用于铁路信号软件测试的系统，所述铁路信号软件测试的系统包括测试处理器，状态机，主引擎，分引擎和测试机组，该方法包括：

步骤100、所述测试处理器获取预设测试序列，并依据解析所述预设测试序列得到的解析结果构建测试模型；其中，所述预设测试序列包括：预设执行顺序的测试脚本和测试部署模型图；所述测试部署模型图包括：所述分引擎的数目，各个所述分引擎的路径、命令行参数、配置信息及启动的顺序；

其中，所述预设测试序列为测试运行的基本单元；

其中，所述测试部署模型图具体为表示测试运行所需信息的UML模型图，是测试管理器获得测试环境信息的接口，在该测试部署模型图定义了分引擎的数目，各个分引擎的路径、命令行参数、配置信息及启动的顺序。举个例子，比如，每个分引擎在哪个测试机上，需要占用何种测试资源；在测试机上自动启动分引擎时，需要的命令行参数和配置文件的路径。

这里需要说的是，所述配置信息指的是除了分引擎的数目，各个分引擎的路径、命令行参数及启动的顺序以外的所有测试运行所需的信息，比如，通信协议等等其他信息，只要该测试部署模型图所提供的信息能保证测试的正常进行，并不影响本发明技术方案的实现。并且，本发明实施例一提供的测试部署模型图在通用UML模型基础上添加了描述分引擎属性的字段，以便更好地了解分引擎的状态。

步骤101、所述状态机在构建的所述测试模型中启动，所述测试处理器，所述状态机，所述主引擎，所述分引擎和所述测试机组依据所述状态机的状态执行相应操作；其中，所述状态机的状态包括初始状态，主引擎启动状态和启动成功状态；

其中，所述分引擎为对真实环境中相对独立的功能单元进行模拟的软件模块(可以理解为是可执行的exe程序)，可以模拟被测试的目标系统，也可以模拟其他与目标系统有交互的功能单元，也就是说，分引擎为铁路信号软件测试提供了与真实环境中可能会遇到的场景的模拟环境，以便能更好地测试出该铁路信号软件在实际应用中的真实性能品质。当然，当模拟所述真实环境中可能会遇到的场景涉及到配置大量的复杂的工程数据时，本发明实施例一提供的方法是利用所述分引擎来完成的，避免了现有技术中由手工测试方式带来的工作量大，时间成本高的问题；

所述测试机组，是由若干测试机通过局域网连接在一起形成的，这些测试机连接形成的测试机组具有统一的组名，其中，测试机通常为通用计算机或者服务器，当然，并不局限于哪一种，只要能实现为运行测试分引擎提供测试环境都可以采用。

步骤102、当所述状态机处于启动成功状态时，所述主引擎和所述分引擎按照预设执行顺序的所述测试脚本对铁路信号软件进行测试；

步骤103、所述测试处理器通过所述测试机组监控所述主引擎和所述分引擎的测试过程，直至所述预设测试序列完成后，统计所述测试脚本的测试结果，并生成相应的测试报告。

其中，所述测试报告支持文本格式和IRM Rational DOORS格式，如果测试报告是写入DOORS服务器的，还可以通过与测试案例的关联分析测试测试序列对测试案例的覆盖情况。

基于上述本发明实施例一所公开的方法，该方法通过测试处理器自动构建测试模型，自动监控铁路软件测试过程及自动生成相应的测试报告，实现了对铁路信号软件进行自动化测试，与传统测试依赖于测试执行人员的经验与操作相比，降低测试执行人员的工作量，提高测试工作的规范性，进而提高了铁路信号软件测试结果的稳定性。

实施例二

基于上述实施例一所公开的方法，其执行步骤100、所述测试处理器获取预设测试序列，并依据解析所述预设测试序列得到的解析结果构建测试模型的具体过程如图2所示，具体包括如下步骤：

步骤200、获取预设测试序列；

步骤201、解析所述预设测试序列中的测试部署模型图，获得所述主引擎和所述分引擎所需的资源信息，其中，所述测试资源为所述测试机组上能够参与测试的网络通信端口和文件；

其中，所述测试资源除了包括上述提及的网络通信端口和文件，也可以包括所述测试机组中能够参与测试的测试机的IP，当然，也不局限于这几种，只要能实现本实施例所要求的功能，其它资源也可算入其中，并不影响本发明的实现。

步骤202、与所述测试机组中待分配的各个测试机进行通信；

其中，优选的，测试处理器与测试机之间通过使用RPC协议(远程过程调用协议)进行通信，具体地，测试处理器是与运行在测试机上的测试机守护程序进行通信，也就是说，除非有特别说明，只要测试处理器与测试机进行收发数据的通信，都是与运行在该测试机上的测试机守护程序进行交互通信；

步骤203、当所述测试机组上所述主引擎和所有所述分引擎所需的资源信息未被占用时，将所述主引擎或所述分引擎分配至对应的所述测试机；

步骤204、确定所有所述主引擎和所述分引擎都分配至对应的所述测试机；

其中，只有主引擎和所有的分引擎都被成功分配至对应的测试机，才表明该预设测试序列可以在该测试机上执行，进而执行步骤205；

步骤205、依据分配结果向同一台所述测试机传输测试配置数据，其中，所述测试配置数据包括：运行所述测试序列需要的可执行程序和数据配置文件；

步骤206、接收各个所述测试机依据所述测试配置数据分配到相应测试路径的确认信息，并依据各个所述确认信息构建测试模型。

在步骤205中，优选的，测试管理器将所述测试配置数据压缩之后再发送，特别是当所述测试配置数据的数据量比较大的时候，有利于缩短传输所述测试配置数据所消耗的时间，进而缩短完成软件测试的时间；当然，在步骤206中，存在相应的对接收到的数据得解压缩步骤。本发明实施例二所提供的方法，执行步骤200至执行步骤204实现了对完成测试所需的测试资源的分配并得到分配结果，后续执行步骤依据所述分配结果完成对测试模型的构建，显然，整个过程都是自动化实现的，降低测试执行人员的工作量，提高测试工作的规范性。

实施例三

基于上述实施例一与实施例二所公开的方法，在存在大量预设测试序列待进行测试的情况下，其执行步骤100、所述测试处理器获取预设测试序列，并依据解析所述预设测试序列得到的解析结果构建测试模型的具体过程包括：

步骤300、根据所述预设测试序列的相关信息对所有的预设测试序列进行排序，得到测试序列队列，其中，所述相关信息包括：提交的时间和/或重要程度；

步骤301、按顺序依据所述测试序列队列中的预设测试序列执行构建测试模型步骤；

其中，所述构建测试模型步骤，具体包括如下步骤：

步骤302、按顺序获取预设测试序列；

步骤303、解析所述预设测试序列中的测试部署模型图，获得所述主引擎和所述分引擎所需的资源信息；其中，所述测试资源为所述测试机组上能够参与测试的网络通信端口和文件；

步骤304、与所述测试机组中待分配的各个测试机进行通信；

其中，所述测试处理器依据与所述测试机组中待分配的各个测试机进行通信的过程中获取到的各个测试机上资源信息被占用的情况，判断各个测试机上主引擎和所有分引擎所需的资源信息被占用的情况，如果所述测试机组上所述主引擎和所有所述分引擎所需的资源信息未被占用，则执行步骤305的内容，否则，执行步骤306或者步骤307；其中，对于执行步骤306还是步骤307，则可由本领域技术人员根据具体情况自行设定；

步骤305、当所述测试机组上所述主引擎和所有所述分引擎所需的资源信息未被占用时，将所述主引擎或分引擎分配至对应的所述测试机；

步骤306、当所述测试机组上所述主引擎和/或所述分引擎所需的资源信息被占用时，返回执行测试序列队列选择下一个预设测试序列执行所述构建测试模型步骤，直至所有预设测试序列执行完所述构建测试模型步骤；

步骤307、当所述测试机组上所述主引擎和/或所述分引擎所需的资源信息被占用时，所述测试序列在所述测试序列队列中排队等待至所述测试资源改变，则将所述主引擎或分引擎分配至对应的所述测试机，或，为所述主引擎和所述分引擎分配其它测试机组，直至所有预设测试序列执行完所述构建测试模型步骤；

具体地，为所述测试序列在所述测试序列队列中排队等待所述测试资源改变的时间预设值一个时间阈值，当所述测试序列在所述测试序列队列中排队等待的时间超过这个时间阈值时，执行为所述主引擎和所述分引擎分配其它测试机组，直至所有预设测试序列执行完所述构建测试模型步骤；

其中，所述测试资源改变，包括：所述分引擎运行结束，所使用的端口和文件被释放，或，新加入若干台测试机。

其中，所述分引擎运行结束，所使用的端口和文件被释放，即前一次被占用的测试资源处于空闲状态，具备可以分配给主引擎或分引擎的条件；新加入若干台测试机，即添加了未被使用的测试资源，同上，该测试资源处于空闲状态，具备可以分配给主引擎或分引擎的条件；

这里需要特别说明的是，步骤305、步骤306和步骤307在实际的软件测试过程中，根据当时测试机组上主引擎和所有分引擎所需的资源信息被占用的情况对应选择其中一个步骤执行，直至所有预设测试序列执行完构建测试模型步骤为止；也就是说，本实施例针对实际的软件测试过程中可能会遇到的不同种测试机组上主引擎和所有分引擎所需的资源信息被占用的情况提供了相应的应对措施，有利于本发明实施例所提供的方法在实际应用中有效利用测试资源，增强了该方法的实用性，提高了测试效率。

本实施例三与实施例二的不同之处在于在步骤300至步骤301中存在对预设测试序列进行调度的执行过程，即依据待测试的预设测试序列的提交时间和/重要程度等相关信息对这些预设测试序列进行排序，这也是本实施例的重点所在，相应地，依据经过排序得到的顺序进行后续的执行步骤。显然，通过以上合理的调度保证了先提交和优先级高的预设测试序列先执行，进而提高测试的效率。

实施例四

基于上述各实施例所公开的方法，其执行步骤101、所述状态机在构建的所述测试模型中启动，所述测试处理器，状态机，主引擎，分引擎和测试机组依据启动状态执行相应操作的具体过程如图3所示，具体包括如下步骤：

步骤400、所述状态机开启并进入初始状态；

步骤401、所述测试处理器发送主引擎启动命令至分配给所述主引擎的测试机；

步骤402、所述分配给所述主引擎的测试机接收所述主引擎启动命令并开启所述主引擎；

步骤403、当所述主引擎输出启动完毕等待分引擎连接的消息时，所述分配给所述主引擎的测试机向所述测试处理器发送主引擎启动成功消息；

步骤404、所述测试处理器接收所述主引擎启动成功消息并向所述状态机发送主引擎启动成功响应信息；

步骤405、所述状态机进入主引擎启动状态；

步骤406、所述测试处理器根据所述测试部署模型图中的启动顺序发送分引擎启动命令至分配给分引擎的测试机；

其中，只有在状态机进入主引擎启动状态，即意味着确定主引擎已经启动，才会执行步骤406的内容；

步骤407、所述分配给分引擎的测试机接收所述分引擎启动命令并开启所述分引擎，直至所有需要启动的分引擎都已开启，所述状态机进入启动成功状态。

优选的，步骤101、所述状态机在构建的所述测试模型中启动，所述测试处理器，状态机，主引擎，分引擎和测试机组依据启动状态执行相应操作，包括：

步骤500、所述测试机组和/或所述测试处理器获取第一异常事件并向所述状态机发送对应于所述第一异常事件的异常事件信息；

其中，所示第一异常事件包括：所述铁路信号软件测试的系统的通信网络出现故障和所述测试资源被占用；

当然，所述第一异常事件包括上述两种异常情况，仅仅只是针对实际的启动过程中经常出现的异常进行了举例，并不局限于哪一种，只要是测试过程中有可能会涉及到的异常都包括于所述第一异常事件中；

步骤501、所述状态机接收所述异常事件信息，并生成启动中止指令和对应于所述异常事件的异常事件提示指令；

步骤502、所述状态机启动过程中止，及，根据异常事件提示指令在所述状态机界面显示所述异常事件信息。

其中，当状态机接收异常事件信息时，不论此时状态机处于何种状态，都会立刻中止启动过程，并在界面提示异常信息，便于测试执行人员修正。

其中，优选的，可以在状态机界面显示异常事件信息的同时，发出异常提示音，对测试人员的听觉系统进行刺激以示提醒，相较只在界面上显示信息，提示音更有利于让测试人员发现测试过程中出现异常并采取应对措施。在实际应用中，可以采用蜂鸣器来发出异常提示音，当然该蜂鸣器肯定是与测试过程中异常事件相关联的，当然，也可以采用其它的提示器，这并不影响本发明的实现。这里需要说明的是，本发明其它实施例中，若涉及到在界面显示异常情况的操作，同样可以采用上述方法对该异常进行提示。

本实施例四所提供的方法，为了确保在主引擎启动成功之后启动各个分引擎，该方法采用状态机来描述主引擎和分引擎的启动状态，使复杂的启动过程更加清晰可控，在发生异常的情况下能及时停止测试并提示测试执行人员，保证了整个启动过程的有效性与实用性。

实施例五

基于上述各实施例所公开的方法，其步骤103中、所述测试处理器通过所述测试机组监控所述主引擎和所述分引擎的测试过程的具体过程，包括：

步骤600、所述测试处理器接收由所述分配给所述主引擎的测试机接收并转发的当所述主引擎解析和执行所述测试脚本过程中检测到当前要执行的是显示命令语句时发送的显示命令语句的行数和状态信息，并依据所述显示命令语句的行数和状态信息在监控界面显示所述测试脚本执行到的行数；

其中，所述测试脚本中添加了特殊的显示命令，当所述主引擎解析和执行所述测试脚本时检测到当前要执行的是该特殊的显示命令语句时发送这个特殊的显示命令语句的行数和状态信息；也可以理解为，当对这个特殊的显示命令语句的行数和状态信息进行显示时，也就意味着对测试脚本的执行直至上述特殊的显示命令语句都是正常通过的；

步骤601、所述测试处理器接收并显示由所述分配给所述分引擎的测试机实时获取并发送的所述分引擎的log信息。

其中，上文有提及到分引擎可理解为是可执行的exe程序，通常，在程序运行的过程中都会把一些重要信息记录到一个*.log文件里，这里的log是日志的意思，从这个log文件中可以获取许多关于该程序的重要信息，基于以上分析，所述分引擎的log信息即为该分引擎，也就是相应的可执行的exe程序在运行过程中记录的运行日志信息，有便于测试人员对分引擎的运行状况进行实时监测；

需要说明的是，所述分引擎的log信息的输出主要是通过运行在分配给该分引擎的测试机上的测试机守护程序实现的，测试机守护程序在启动分引擎时会重定向分引擎的标准输出并进行监控，一旦分引擎进行输出，该测试机守护程序就将输出的内容发送给测试管理器进行显示。

以上实施例五针对主引擎和分引擎，分别提供了一种监控测试进展情况的方式，包括在测试处理器上对应于测试脚本的监控界面显示脚本执行的情况和实时输出分引擎的log信息，特别是针对测试脚本运行的监控方式，可以直观动态显示测试脚本的执行状态，有便于测试人员对分引擎的运行状况进行实时监测。还需要说明的是，实际测试过程中，测试脚本是由主引擎执行的，所以对测试脚本的监控也就实现了对执行该测试脚本的主引擎进行了监控。

优选的，步骤103中、所述测试处理器通过所述测试机组监控所述主引擎和所述分引擎的测试过程，还包括：

所述测试处理器接收由所述分配给所述主引擎的测试机接收并转发的当所述主引擎执行所述测试脚本过程中检测到第二异常事件时发送的所述第二异常事件发生时所述测试脚本执行到的行数和状态信息，并依据所述测试脚本执行到的行数和状态信息在监控界面显示所述测试脚本执行到的行数，并用不同的背景色区分所述第二异常事件中不同的异常，且一种背景色仅对应一种异常；

其中，所述第二异常事件包括：匹配分引擎输出异常、主引擎异常分引擎发生异常或测试环境发生异常。

其中，所述第二异常事件包括上述四种异常，仅仅只是针对实际测试过程中经常出现的异常进行了举例，并不局限于这几种，只要是测试过程中有可能会涉及到的异常都包括于所述第二异常事件中；同样的，所述主引擎执行所述测试脚本过程中检测到第二异常事件，可以是检测到一种异常，也可以是多种，只要对这一种或多种的异常用不同的背景色以示区分即可；

以上实施例五所提供的方法，在对主引擎和分引擎运行情况进行监控的同时也针对测试过程中可能出现的异常进行监控，对正常通过和异常错误的测试语句进行了区分，使得测试执行人员尽早发现脚本中的错误，进而提高了铁路信号软件测试结果的稳定性。

实施例六

基于上述本发明提供的各实施例所公开的方法，步骤103中、所述预设测试序列完成后，统计所述测试脚本的测试结果，并生成相应的测试报告的具体过程如图4所示，具体包括如下步骤：

步骤700、统计所述测试脚本的测试结果；

步骤701、依据所述测试结果判断所述测试脚本是否通过测试，如果是，则进入步骤702，否则，则进入步骤703；

步骤702、标记所述测试脚本通过，得到判断标记结果，进入步骤704；

步骤703、标记所述测试脚本未通过，并显示出错的测试语句行数和未通过原因，得到判断标记结果，进入步骤704；

步骤704、依据所述测试脚本的测试结果和所述判断标记结果生成相应的测试报告。

本实施例六所公开的方法，在一个预设测试序列完成后，所述测试处理器会子自动统计该预设测试序列中包含的测试脚本的运行结果，然后自动生成相应的测试报告，显然，整个过程都是自动化进行的，与传统测试依赖于测试执行人员的经验与操作相比，显著降低测试执行人员的工作量和提高测试结果稳定性。

实施例七

基于上述各实施例所公开的方法，其步骤103、在所述测试处理器通过所述测试机守护程序监控测试过程，直至所述测试序列完成后，统计所述测试脚本的测试结果，并生成测试报告之后，还包括：

清除所述测试机组中本次测试所涉及的进程和释放本次测试所占用的资源。

针对以上内容举个例子，即杀死主引擎和分引擎进程、释放测试过程中所占用的资源等等，相应的具体实现过程如下：

测试管理器使用RPC协议向测试机发送杀死主引擎和分引擎的命令，测试机守护程序收到之后，立即开始杀死相关进程并且释放占用的资源，清理完成后向测试管理器报告清理完毕。测试结束之后的清理工作非常重要，进程被杀死、占用资源完全释放后，测试过程才真正结束，被占用的测试机才可以分配给下一个等待执行的测试序列。

同样，优选的，本发明上述各实施例所公开的方法中，还包括，在所述测试序列执行过程中，所述测试处理器收到异常消息后中止本次测试，并清除所述测试机组中本次测试所涉及的进程和释放本次测试所占用的资源。

其中，所述测试处理器收到的异常消息，通常是当网络连接出错、主引擎或分引擎异常、测试机操作系统崩溃等情况，测试管理器会接收到相应的异常消息并立刻中止测试，杀死相应的进程并清理被占用的资源。

需要说明的是，当测试人员主动中止测试序列时，也会进行同样的中止和清理工作。

实施例八

基于上述实施例一至实施例七所公开的铁路软件测试的方法，本发明实施例八对应该方法还提供了一种铁路信号软件测试的系统，该系统包括：

测试处理器，用于获取预设测试序列，解析所述预设测试序列得到的解析结果构建测试模型；及，通过所述测试机组监控所述主引擎和所述分引擎的测试过程，直至所述预设测试序列完成后，统计所述测试脚本的测试结果，并生成相应的测试报告；

其中，所述预设测试序列包括：预设执行顺序的测试脚本和测试部署模型图；所述测试部署模型图包括：所述分引擎的数目，各个所述分引擎的路径、命令行参数、配置信息及启动的顺序；

状态机，用于在构建的所述测试模型中启动，所述测试处理器，状态机，主引擎，分引擎依据所述状态机的状态执行相应操作；

主引擎和分引擎，用于当所述状态机处于启动成功状态时，按照预设执行顺序的所述测试脚本对铁路信号软件进行测试；测试机组，用于提供测试环境，及，与所述测试处理器进行通信并配合所述测试处理器完成测试。

为了方便本领域技术人员能更好地理解本发明实施例所所公开的铁路软件测试的系统，结合图5就该铁路软件测试的系统的实际应用举个例子：

测试人员在客户端SDP平台A上完成进行铁路软件测试的准备工作：完成分引擎D1和分引擎D2(统称分引擎D)对目标系统E的模拟，编辑预设测试序列(包括配置预设执行顺序的测试脚本和绘制测试部署模型图)；其中，客户端SDP平台A(信号系统设计开发平台)提供了测试人员与本实施例所公开的铁路信号软件测试的系统之间的人机交互的图形化界面，便于测试人员监控整个测试过程；

其中，配置预设执行顺序的测试脚本的过程中需要从测试管理器A中包含的分引擎库和测试数据库(统称数据库)中获取相应的数据信息；

测试处理器A从客户端SDP平台A获取所述预设测试序列，解析所述预设测试序列得到的解析结果构建测试模型；

状态机在构建的所述测试模型中启动，测试处理器A，所述状态机，主引擎C，分引擎D和测试机组依据所述状态机的状态执行相应操作；

当所述状态机处于启动成功状态时，主引擎C和分引擎D按照预设执行顺序的所述测试脚本对铁路信号软件进行测试；

测试处理器A通过所述测试机组监控主引擎C和分引擎D的测试过程，直至所述预设测试序列完成后，统计所述测试脚本的测试结果，并生成相应的测试报告。

其中，在整个对铁路信号软件进行测试的过程中，主引擎C、分引擎D与目标系统E之间实时进行相应的命令反馈，同时，主引擎D实时向测试处理器A反馈测试状态，该测试处理器又将所述测试状态及相应结果反馈至客户端SDP平台，由此实现对测试过程的监控；

其中，当所述预设测试序列完成后，统计所述测试脚本的测试结果，并生成相应的测试报告。

优选的，该铁路软件测试的系统包括测试序列编辑器，用于编辑所述预设测试序列。

优选的，所述测试处理器包括具有绘制测试部署模型图的辅助工具，用于图形化绘制所述预设测试序列中的测试部署模型图。

这里需要说明的是，上述各实施例提供的方法都能适用于该系统。

以上对本发明所提供的铁路软件测试的方法及系统进行了详细介绍。本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以对本发明进行若干改进和修饰，这些改进和修饰也落入本发明权利要求的保护范围内。

Claims (10)

1.一种铁路信号软件测试的方法，其特征在于，应用于铁路信号软件测试的系统，所述铁路信号软件测试的系统包括测试处理器，状态机，主引擎，分引擎和测试机组，该方法包括：

所述测试处理器获取预设测试序列，并依据解析所述预设测试序列得到的解析结果构建测试模型；其中，所述预设测试序列包括：预设执行顺序的测试脚本和测试部署模型图；所述测试部署模型图包括：所述分引擎的数目，各个所述分引擎的路径、命令行参数、配置信息及启动的顺序；

所述状态机在构建的所述测试模型中启动，所述测试处理器，所述状态机，所述主引擎，所述分引擎和所述测试机组依据所述状态机的状态执行相应操作；其中，所述状态机的状态包括初始状态，主引擎启动状态和启动成功状态；

当所述状态机处于启动成功状态时，所述主引擎和所述分引擎按照预设执行顺序的所述测试脚本对铁路信号软件进行测试；

所述测试处理器通过所述测试机组监控所述主引擎和所述分引擎的测试过程，直至所述预设测试序列完成后，统计所述测试脚本的测试结果，并生成相应的测试报告。

2.如权利要求1所述的方法，其特征在于，所述测试处理器获取预设测试序列，并依据解析所述预设测试序列得到的解析结果构建测试模型，包括：

获取预设测试序列；

解析所述预设测试序列中的测试部署模型图，获得所述主引擎和所述分引擎所需的资源信息，其中，所述测试资源为所述测试机组上能够参与测试的网络通信端口和文件；

与所述测试机组中待分配的各个测试机进行通信；

当所述测试机组上所述主引擎和所有所述分引擎所需的资源信息未被占用时，将所述主引擎或所述分引擎分配至对应的所述测试机；

确定所有所述主引擎和所述分引擎都分配至对应的所述测试机；

依据分配结果向同一台所述测试机传输测试配置数据，其中，所述测试配置数据包括：运行所述测试序列需要的可执行程序和数据配置文件；

接收各个所述测试机依据所述测试配置数据分配到相应测试路径的确认信息，并依据各个所述确认信息构建测试模型。

3.如权利要求2所述的方法，其特征在于，在存在大量预设测试序列待进行测试的情况下，所述测试处理器获取预设测试序列，并依据解析所述预设测试序列得到的解析结果构建测试模型，包括：

根据所述预设测试序列的相关信息对所有的预设测试序列进行排序，得到测试序列队列，其中，所述相关信息包括：提交的时间和/或重要程度；

按顺序依据所述测试序列队列中的预设测试序列执行构建测试模型步骤；

其中，所述构建测试模型步骤包括：

按顺序获取预设测试序列；

解析所述预设测试序列中的测试部署模型图，获得所述主引擎和所述分引擎所需的资源信息；其中，所述测试资源为所述测试机组上能够参与测试的网络通信端口和文件；

与所述测试机组中待分配的各个测试机进行通信；

当所述测试机组上所述主引擎和所有所述分引擎所需的资源信息未被占用时，将所述主引擎或分引擎分配至对应的所述测试机；

或，

当所述测试机组上所述主引擎和/或所述分引擎所需的资源信息被占用时，返回执行测试序列队列选择下一个预设测试序列执行所述构建测试模型步骤，直至所有预设测试序列执行完所述构建测试模型步骤；

或，

当所述测试机组上所述主引擎和/或所述分引擎所需的资源信息被占用时，所述测试序列在所述测试序列队列中排队等待至所述测试资源改变，则将所述主引擎或分引擎分配至对应的所述测试机，或，为所述主引擎和所述分引擎分配其它测试机组，直至所有预设测试序列执行完所述构建测试模型步骤；

其中，所述测试资源改变，包括：所述分引擎运行结束，所使用的端口和文件被释放，或，新加入若干台测试机。

4.如权利要求1所述的方法，其特征在于，所述状态机在构建的所述测试模型中启动，所述测试处理器，所述状态机，所述主引擎，所述分引擎和所述测试机组依据启动状态执行相应操作，包括：

所述状态机开启并进入初始状态；

所述测试处理器发送主引擎启动命令至分配给所述主引擎的测试机；

所述分配给所述主引擎的测试机接收所述主引擎启动命令并开启所述主引擎；

当所述主引擎输出启动完毕等待分引擎连接的消息时，所述分配给所述主引擎的测试机向所述测试处理器发送主引擎启动成功消息；

所述测试处理器接收所述主引擎启动成功消息并向所述状态机发送主引擎启动成功响应信息；

所述状态机进入主引擎启动状态；

所述测试处理器根据所述测试部署模型图中的启动顺序发送分引擎启动命令至分配给分引擎的测试机；

所述分配给分引擎的测试机接收所述分引擎启动命令并开启所述分引擎；

直至所有需要启动的分引擎都已开启，所述状态机进入启动成功状态。

5.如权利要求4所述的方法，其特征在于，所述状态机在构建的所述测试模型中启动，所述测试处理器，所述状态机，所述主引擎，所述分引擎和所述测试机组依据启动状态执行相应操作，包括：

所述测试机组和/或所述测试处理器获取第一异常事件并向所述状态机发送对应于所述第一异常事件的异常事件信息；

其中，所示第一异常事件包括：所述铁路信号软件测试的系统的通信网络出现故障和所述测试资源被占用；

所述状态机接收所述异常事件信息，并生成启动中止指令和对应于所述异常事件的异常事件提示指令；

所述状态机启动过程中止，及，根据异常事件提示指令在所述状态机界面显示所述异常事件信息。

6.如权利要求1所述的方法，其特征在于，所述测试处理器通过所述测试机组监控所述主引擎和所述分引擎的测试过程，包括：

所述测试处理器接收由所述分配给所述主引擎的测试机接收并转发的当所述主引擎解析和执行所述测试脚本过程中检测到当前要执行的是显示命令语句时发送的显示命令语句的行数和状态信息，并依据所述显示命令语句的行数和状态信息在监控界面显示所述测试脚本执行到的行数；

所述测试处理器接收并显示由所述分配给所述分引擎的测试机实时获取并发送的所述分引擎的log信息；

和/或，

所述测试处理器接收由所述分配给所述主引擎的测试机接收并转发的当所述主引擎执行所述测试脚本过程中检测到第二异常事件时发送的所述第二异常事件发生时所述测试脚本执行到的行数和状态信息，并依据所述测试脚本执行到的行数和状态信息在监控界面显示所述测试脚本执行到的行数，并用不同的背景色区分所述第二异常事件中不同的异常，且一种背景色仅对应一种异常；

其中，所述第二异常事件包括：匹配分引擎输出异常、主引擎异常分引擎发生异常或测试环境发生异常。

7.如权利要求1所述的方法，其特征在于，所述预设测试序列完成后，统计所述测试脚本的测试结果，并生成相应的测试报告，包括：

统计所述测试脚本的测试结果；

依据所述测试结果判断所述测试脚本是否通过测试，如果是，则标记所述测试脚本通过，得到判断标记结果，否则，则标记所述测试脚本未通过，并显示出错的测试语句行数和未通过原因，得到判断标记结果；

依据所述测试脚本的测试结果和所述判断标记结果生成相应的测试报告。

8.如权利要求1所述的方法，其特征在于，在所述测试处理器通过所述测试机守护程序监控测试过程，直至所述测试序列完成后，统计所述测试脚本的测试结果，并生成测试报告之后，还包括：

清除所述测试机组中本次测试所涉及的进程和释放本次测试所占用的资源。

9.如权利要求1～8任意一项所述的方法，其特征在于，还包括，在所述测试序列执行过程中，所述测试处理器收到异常消息后中止本次测试，并清除所述测试机组中本次测试所涉及的进程和释放本次测试所占用的资源。

10.一种铁路信号软件测试的系统，其特征在于，包括：

测试处理器，用于获取预设测试序列，解析所述预设测试序列得到的解析结果构建测试模型；及，通过所述测试机组监控所述主引擎和所述分引擎的测试过程，直至所述预设测试序列完成后，统计所述测试脚本的测试结果，并生成相应的测试报告；其中，所述预设测试序列包括：预设执行顺序的测试脚本和测试部署模型图；所述测试部署模型图包括：所述分引擎的数目，各个所述分引擎的路径、命令行参数、配置信息及启动的顺序；

状态机，用于在构建的所述测试模型中启动，所述测试处理器，状态机，主引擎，分引擎依据所述状态机的状态执行相应操作；

主引擎和分引擎，用于当所述状态机处于启动成功状态时，按照预设执行顺序的所述测试脚本对铁路信号软件进行测试；测试机组，用于提供测试环境，及，与所述测试处理器进行通信并配合所述测试处理器完成测试。