CN103049379B - 一种系统测试的方法 - Google Patents

Abstract

本发明公开了一种系统测试的方法，包括：监测系统各个接口，若一接口的报文数据能触发一测试案例，则判定该报文数据与该测试案例的触发条件匹配成功，且当触发条件匹配成功后该测试案例进入执行队列；获取测试案例的执行结果，并根据该测试案例的标识判断是否为正向测试；若是，则将执行结果与预定的执行结果进行匹配，否则执行失败；当测试案例为正向测试时，若所述执行结果与预定的执行结果匹配成功，则案例执行成功，否则执行失败。通过采用本发明公开的方法提高了测试案例的执行效率，改善了测试质量，减少了测试的依赖性，节省了人力物力资源。

Description

一种系统测试的方法

技术领域

本发明涉及中国列车运行控制系统，尤其涉及一种系统测试的方法。

背景技术

随着计算机技术的飞速发展，自动化测试技术也越来越趋于成熟。针对软件的测试已普遍采用了自动测试技术，并且已取得了显著的成就。

目前，我国采用的CTCS-3级列控系统，其结构和功能都十分复杂，对正式投入运营的设备安全性要求十分苛刻。所以，在正式投入使用前需进行完整的功能测试。而针对CTCS-3级列控系统的测试，大多采用传统的人工测试的方式，问题产生后，需要人工去查找问题产生的原因，耗时耗力且效率不高。针对有些偶然发生的故障，若没及时捕捉到，事后很难再复现当时的场景，给工作带来了很大的困扰。而且无论是现场测试还是实验室测试，最终均依靠用户根据经验判断结果，导致对系统的测试没有一个衡量的标准，同时也会引入由人为因素引起的判断结果不稳定等问题，严重影响测试质量。

现有技术中，对CTCS-3级列控系统进行测试有如下几种方法：

（1）通过从存储测试数据的数据库中查询对CTCS列控子系统进行测试的测试序列中的测试变量的信息，来显示CTCS列控车载子系统的运行情况。但是该方法仅是针对列控车载子系统进行测试，无法应用到整个列控系统，而且仅对列车运行状态进行显示，对于产生问题的原因还是需要用户进行分析判断，没有一个标准的衡量方法，并且采用预先编写测试序列的方式，只能针对固定的线路进行测试，检查系统是否按照已有的序列正常响应，并且若要对全新的线路进行测试，仍需要先编写测试序列，因此，降低了系统的可移植性。

（2）通过对测试案例进行分类及对应，得到与互联互通相关的测试案例集合，并按照特定方法串联成测试序列，生成测试序列期望结果数据库；利用测试平台对被测设备进行测试，记录测试中传输的全部数据，将测试序列执行结果与期望结果进行比对分析，以统计结果方式生成缺陷数据库。但是从该方法生成的缺陷数据库中无法判断缺陷产生的原因，还需要用户进行分析判断；并且该方案为预先组织测试序列，然而若造成遗漏现象，将导致测试不全面。

发明内容

本发明的目的是提供一种系统测试的方法，提高了测试案例的执行效率，改善了测试质量，减少了测试的依赖性，节省了人力物力资源。

一种系统测试的方法，包括：

监测系统各个接口，若一接口的报文数据能触发一测试案例，则判定该报文数据与该测试案例的触发条件匹配成功，且当触发条件匹配成功后该测试案例进入执行队列；

获取测试案例的执行结果，并根据该测试案例的标识判断是否为正向测试；若是，则将执行结果与预定的执行结果进行匹配，否则执行失败；

当测试案例为正向测试时，若所述执行结果与预定的执行结果匹配成功，则案例执行成功，否则执行失败。

由上述本发明提供的技术方案可以看出，通过触发条件对测试案例进行全面搜索匹配，提高了测试案例的执行效率及系统的可移植性，并减少了系统的依赖性，提高了测试质量。

附图说明

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

图1为本发明实施例一提供的一种系统测试的方法的流程图；

图2为本发明实施例二提供的又一种系统测试的方法的流程图。

具体实施方式

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

实施例一

图1为本发明实施例所提供的一种系统测试的方法，该方法可以包括如下步骤：

步骤101、监测系统各个接口，若一接口的报文数据能触发一测试案例，则判定该报文数据与该测试案例的触发条件匹配成功，且当触发条件匹配成功后该测试案例进入执行队列。

其中，该报文数据可以是测试数据也可以是实际数据。换言之，本发明可以用于实验室测验（例如，对特定功能进行测试），也可用于实际工作中对系统运行状态进行检测。

对于接收到的报文数据是否能够触发测试案例主要判断报文数据是否能够搜索到匹配的触发条件。触发条件一般包括：记录单元（JRU）消息、无线闭塞中心RBC消息、车载设备人机界面DMI消息、其它相关信息包和/或相关变量。解析所述接收到的报文数据，确定消息类型、对应的消息编号、信息包编号和相关变量；将所述消息编号作为该消息的取值，从知识库中筛选出与该取值对应的S（S为大于1的自然数）个测试案例；从所述S个测试案例中查找出与该消息的信息包编号及相关变量相匹配的测试案例。

步骤102、获取测试案例的执行结果，并根据该测试案例的标识判断是否为正向测试；若是，执行步骤103，否则执行步骤105。

大多数的测试案例均为正向测试，但某些案例正向测试很难进行，为保证测试的准确性则进行反向测试，即在规定的时间或距离内发生某事件则认为案例执行失败。

步骤103、当测试案例为正向测试时，若所述执行结果与预定的执行结果匹配成功，则转入步骤104；否则，转入步骤104。

步骤104、测试案例执行成功。

当测试案例执行成功后，生成测试案例执行结果数据库，并根据需要可对案例测试结果进行分类统计。

步骤105、测试案例执行失败。通过上述内容可知，测试案例执行失败可能有多种情况：反向测试时，即在规定的时间或距离内发生某事件；正向测试时，执行结果与预定的结果匹配失败。此时，通过包含测试案例执行失败的各种原因的推理机对执行结果进行故障分析，生成对应的测试报告，并存储该分析结果。

本发明实施例通过触发条件对测试案例进行全面搜索匹配，提高了测试案例的执行效率及系统的可移植性，并减少了系统的依赖性，提高了测试质量。

实施例二

为了更具体的介绍本发明，下面结合附图2对本发明做进一步描述。如图2所示，包括以下步骤：

步骤201、建立知识库。本实施例以用于中国列车运行控制系统CTCS-3级列控系统的测试为例做介绍，因此，需建立与其对应的知识库。

该知识库的主要目的是用于验证系统是否满足CTCS-3级列控系统总体技术方案和系统需求规范，即验证系统功能是否完善，设备之间是否已达到互联互通的要求，因此最终判定的依据是系统功能需求规范。

《CTCS-3级列控系统测试案例》依据《CTCS-3级列控系统系统需求规范（SRS）》和《CTCS-3级列控系统总体技术方案》进行编制，是CTCS-3级列控系统实验室仿真测试、现场试验及联调联试的基础性文件，因此本实施例的知识库的主要来源于《CTCS-3级列控系统测试案例》。即将《CTCS-3级列控系统测试案例》中的测试案例进行整理，生成程序所能识别的描述语言，并将测试案例提取出关键字段，整理成表格形式，其中主要字段有，案例编号、触发条件和预定的执行结果。触发条件为触发一个测试案例的先决条件，预定的执行结果作为判断测试案例是否执行成功的依据。其中，复杂的案例可划分为若干个子案例，前一个案例作为后一个案例的关联案例，只有关联案例执行成功后才能执行此案例，当案例执行失败时，便于查找问题的根源。

通过上述内容可以得知，知识库中包含了若干的测试案例，而为了提供系统的可移植性以及针对测试情况不同，需要设计测试案例的组织方式。

（1）当需要针对某些特定的功能进行测试时，可以直接将对应的测试案例提取并按照某种特定的顺序串联在一起，形成测试序列。该测试序列的设计和执行都是按照步骤来执行的，测试序列以步骤形式将所有测试案例关联起来，只有当上一个测试案例执行成功后才会执行下一个测试案例。并且所设定的测试序列需覆盖所有的测试案例，以便能够针对所有功能特征进行测试。

（2）当需要对系统的运行状态进行检测时，则可以检测系统的各个接口，从接口获取报文数据来触发测试案例。而通过接口传输的报文数据用户无法预先得知与其对应的测试案例，因此，需对知识库中的测试案例进行全面搜索。优选的，为了实现测试案例的快速匹配，可在存储测试案例时将案例分类进行存储，然后根据收到的数据，搜索特定案例的分支子树，提高搜索的效率。

步骤202、监测系统各个接口，若一接口的报文数据能触发一测试案例，则判定该报文数据与该测试案例的触发条件匹配成功，且当触发条件匹配成功后该测试案例进入执行队列。本步骤主要针对上述第2种测试案例的组织方式进行介绍。

在对CTCS-3级列控系统的测试时，可以在现有接口上进行，从接口获得数据后，搜索对列控系统进行测试的知识库中每条测试案例的信息。

接口一般分为两大类：（1）与无线闭塞中心RBC相关的接口：包括RBC本地操作终端（含MMI和记录器），RBC与RBC接口、RBC与车站联锁设备接口、RBC与调度集中CTC接口、RBC与临时限速服务器接口、RBC与GSM-R网络之间的接口、RBC与集中监测系统的接口。（2）与车载设备相关的接口：包括车载设备与人机界面（DMI）、车载设备与记录单元接口（JRU）、车载设备与GSM-R接口（RTM）、车载设备与动车组接口（TIU）、车载设备与应答器接口（BTM）、车载设备与轨道电路接口（TCR）。

监测系统各个接口（例如JRU、TIU及DMI等），当接收到数据后，进入测试案例的搜索匹配过程，下述以接收到JRU接口的数据为例进行介绍：

JRU接口接收到的数据是行车过程中交互的主要信息，其数据是以固定格式打包的信息帧，系统通过车载设备接收JRU报文数据，并根据协议解析数据帧，得到关键信息，从而确定消息类型；由DMI显示行车过程中的模式、等级和速度等一些辅助信息，再通过模式识别软件（PR），摄取DMI的图像信息，提取有用数据；然后查询知识库，搜索该数据能够触发的测试案例。具体的：本实施例中JRU报文数据包括车到地消息（RBC消息）、地到车消息（RBC消息）、应答器报文（JRU消息）与司机操作（JRU消息）等，将该报文解析后若得知该报文为车到地消息或地到车消息，则可确定该报文为RBC消息，随即对该消息进行解析，得到RBC编号、信息包编号和相关变量，将该编号作为该RBC消息的取值，从知识库中筛选出与该取值对应的S个测试案例；从所述S（S为大于1的自然数）个测试案例中查找出与该消息的信息包编号及相关变量相匹配的测试案例。若对报文数据解析后得知该报文为应答器报文或司机操作，则为JRU消息，其查找测试案例的过程与上述查找过程类似。并且，系统的其他接口（例如，TIU及DMI）接收到数据后的处理过程与上述处理过程类似，因此，不再赘述。

进一步的，为了能够更好的对测试结果进行分析，本发明还实现了对测试结果进行回放的功能，从接口接收数据的同时，将数据存储成特定格式的文件，在测试结束后，读取文件数据，即可实现系统的回放功能。

步骤203、获取测试案例的执行结果，并根据该测试案例的标识判断是否为正向测试；若是，执行步骤204，否则执行步骤206。

大多数的测试案例均为正向测试，但某些案例正向测试很难进行，为保证测试的准确性则进行反向测试，即在规定的时间或距离内发生某事件则认为案例执行失败。

步骤204、当测试案例为正向测试时，若所述执行结果与预定的执行结果匹配成功，则转入步骤205；否则，转入步骤206。测试案例执行结果的匹配相对于触发条件的匹配而言较为简单，如步骤203所述，反向测试则不需要进行执行结果的匹配，即满足触发条件匹配即可；而正向测试需要匹配执行结果，当执行结果与当前测试案例的预定的执行结果一致时，则表示案例执行成功。

存在以下几种情况：1对1，即在某一时间点上满足测试案例的触发条件，且执行结果与预定的执行结果匹配成功，则案例执行成功，否则案例执行失败。

1对多，即某一段时间均满足测试案例的触发条件，此时需先确定该测试案例的起止时间，若在该起止时间内匹配到对应的预定的执行结果则案例执行成功，否则案例执行失败。例如，超速防护（测试案例）：当速度超过允许速度时，满足触发条件；此时应确定该测试案例的起止时间，当司机在该段时间内降速或采用最大常用制动或紧急制动时，使得速度小于允许速度，则案例执行成功，否则案例执行失败。

优选的，为避免测试案例的重复搜索比对，或由于触发条件的重复判断造成一段时间内系统的开销量增大，影响测试效率。因此，在对于1对1的情况时，即在某一时间点上满足触发条件，但在匹配到对应的预定的执行结果之前，又接收到包含该触发条件的报文数据时，则当前测试案例执行失败。例如，当前测试案例为请求MA，但是在收到MA之前，又接受到包含该测试案例触发条件的报文数据时，则判定当前测试案例执行失败。在1对多的情况下，即在某一时间段内满足触发条件，则判断该触发条件对应的测试案例是否已经进入预定的执行结果匹配阶段，若处于预定的执行结果匹配阶段，则在预设的时间结束前，不再对该测试案例的触发条件进行匹配。

显然，通过上述介绍可知，知识库中的测试案例处于两种状态：就绪状态与执行状态。就绪状态的测试案例一旦触发条件满足即进入预定的执行结果匹配队列；而执行状态的案例则存在两种情况：允许重复的，即测试案例允许重复执行，以1对1的情况居多，但若重复次数超出预设值（例如，1、2），并且当前案例还未执行成功，则认为案例执行失败；不允许重复的，只有当测试案例再次变为就绪状态才能进行触发条件的匹配。

步骤205、测试案例执行成功。当前案例执行成功，则可生成测试案例执行结果数据库，并根据需要可对案例测试结果进行分类统计，具体的：将测试案例的执行结果以图形化方式显示，可按案例的执行时间组织，显示案例的起始时间、结束时间以及整个执行时长，方便查找特定时间发生的案例；如若想要查看案例的统计信息，可以生成测试报告，其中包括案例的分类统计信息以及条形图显示，清晰直观。

步骤206、测试案例执行失败。当测试案例执行失败时，通过包含测试案例执行失败的各种原因的推理机分析其可能导致失败的原因后，存入结果数据库，作为下次产生相同故障时的分析依据。

推理机可以模拟人类专家进行推理和判断，但需要长期积累和学习的阶段。在测试案例整理初期，需要具有专门知识的用户给出可能导致测试案例执行失败的原因，作为一个初始推理依据。测试结束后，分析执行失败的测试案例，分析不同情况下执行失败的原因，分析结果存入推理机，丰富推理机的知识储备，通过这样不断的学习积累、充实推理机，使其具有丰富的案例故障分析的经验，能够自动分析案例执行结果、判断故障起因等。

本发明实施例通过触发条件对测试案例进行全面搜索匹配，提高了测试案例的执行效率及系统的可移植性；同时，通过推理机进行故障分析，减少了人为因素引起的判断结果不稳定等问题，并减少了系统的依赖性，提高了测试质量。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例可以通过软件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，上述实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质（可以是CD-ROM，U盘，移动硬盘等）中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述的方法。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明披露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求书的保护范围为准。

Claims (6)

1.一种系统测试的方法，其特征在于，包括：

监测系统各个接口，若一接口的报文数据能触发一测试案例，则判定该报文数据与该测试案例的触发条件匹配成功，且当触发条件匹配成功后该测试案例进入执行队列；

获取测试案例的执行结果，并根据该测试案例的标识判断是否为正向测试；若是，则将执行结果与预定的执行结果进行匹配，否则执行失败；

当测试案例为正向测试时，若所述执行结果与预定的执行结果匹配成功，则案例执行成功，否则执行失败；其包括：

若某一时间点上满足测试案例的触发条件，且执行结果与预定的执行结果匹配成功，则测试案例执行成功，否则，则测试案例执行失败；或，若在某一时间段内满足测试案例的触发条件，则先确定该测试案例的起止时间，在该起止时间内匹配到对应的预定的执行结果，则测试案例执行成功，否则执行失败；

若在某一时间点上满足测试案例的触发条件，但在匹配到对应的预定的执行结果之前，又接收到包含该触发条件的报文数据时，则当前测试案例执行失败；或，若在某一时间段内满足测试案例的触发条件，则判断该触发条件对应的测试案例是否已经进入预定的执行结果匹配阶段，若处于预定的执行结果匹配阶段，则直至当前测试案例执行完毕前，忽略接收到包含该触发条件的数据。

2.根据权利要求1所述的方法，其特征在于，该方法还包括：

预先建立包括若干所述测试案例的知识库，每一个测试案例设置有对应的触发条件及预定的执行结果。

3.根据权利要求1或2所述的方法，其特征在于，所述触发条件包括：

记录单元JRU消息、无线闭塞中心RBC消息、车载设备人机界面DMI消息、信息包和/或相关变量；其中，所述相关变量为记录单元JRU消息、无线闭塞中心RBC消息、车载设备人机界面DMI消息和/或信息包中的变量。

4.根据权利要求3所述的方法，其特征在于，确定所述一接口的报文数据能触发一测试案例的步骤包括：

解析接收到的报文数据，确定消息类型、对应的消息编号、信息包编号和相关变量；

将所述消息编号作为该消息的取值，从知识库中筛选出与该取值对应的S个测试案例；

从所述S个测试案例中查找出与该消息的信息包编号及相关变量相匹配的测试案例，其中S为大于1的自然数。

5.根据权利要求1所述的方法，其特征在于，当测试案例执行失败后包括：

通过包含测试案例执行失败原因的推理机进行故障分析；根据执行的结果判断故障的起因，生成对应的测试报告，并存储该分析结果。

6.根据权利要求1所述的方法，其特征在于，该方法还包括：将测试案例进行串联，构成测试序列；该测试序列中相邻的两个测试案例存在因果关系，当上一个测试案例执行成功后则执行下一个测试案例。