基于因果图法的CTCS-3级列控系统测试案例完备性验证方法

穆建成，辛　未，马连川,3，曹　源,3

(1.国家铁路局 科技与法制司，北京　100891；2.北京交通大学 电子信息工程学院，北京　100044；3.北京交通大学 轨道交通运行控制系统国家工程研究中心，北京　100044)

对列控系统进行测试是检验其是否符合功能需求的必要过程，而测试案例是这一过程的基础和标准[1]，并且测试案例的完备性是测试过程能够充分验证系统是否满足列控系统要求的关键。CTCS-3级列控系统的测试案例采用基于功能特征的方法生成[1-2]，对设计人员要求较高，如果对系统功能需求的理解不够深入，则可能导致测试案例设计错误或遗漏[3]。为确保测试能够覆盖全部系统需求规范，需要验证测试案例的完备性。

对CTCS-3级列控系统测试案例进行完备性验证，就是考察其对于《CTCS-3级列控系统需求规范(SRS)》[4]的覆盖程度。目前，针对测试案例的完备性验证主要采用静态或动态需求跟踪方法，通过建立需求跟踪关系确定[5]。

静态需求跟踪方法主要是利用需求跟踪矩阵[5]、需求管理工具(DOORS[6]和Rational Requistepro[7])等由人工手动建立需求跟踪关系。例如文献[1]利用DOORS人工关联SRS与测试案例，形成链接关系并输出需求跟踪报表，最终通过人工审核，验证CTCS-3级列控系统测试案例的完备性。但由于该方法对人工依赖程度较高，如果验证人员对SRS和测试案例的理解有偏差，则可能导致验证结果并不能说明测试案例的完备性。特别是对于规模较大的系统，应用静态需求跟踪方法存在着需求跟踪关系创建困难并且容易出错等问题[8-9]。

动态需求跟踪方法则主要是利用信息检索技术[10]、动态跟踪工具RETRO[11]等自动生成需求跟踪关系。但目前应用动态需求跟踪方法生成的需求跟踪关系一般会存在错误，并可能漏掉部分正确关系，导致验证过程存在精度问题，难以满足对安全性要求较高项目的验证需要。

此外，CTCS-3级列控系统的SRS和测试案例均用自然语言描述。由于自然语言本身具有的矛盾、二义性等问题[12]，造成SRS和测试案例间存在表述不一致、对应关系不明确的问题，不能满足准确验证测试案例完备性的要求。

针对列控系统测试案例完备性验证方法目前存在的问题，本文基于因果图法提出CTCS-3级列控系统测试案例完备性验证的新方法；并以CTCS-3级列控系统车载设备待机模式下的模式转换功能测试案例为例，通过对该案例完备性的验证，证明本文方法的有效性。

1　基本思路

对CTCS-3级列控系统测试案例进行完备性验证，需要解决以下3个主要问题。

(1)SRS与测试案例间的对应关系不明确、描述内容不统一；

(2)SRS和测试案例均采用自然语言描述，无法进行自动验证；

(3)缺少有效衡量测试案例完备性的依据。

因果图法[13-16]是一种通过描述系统的逻辑条件和相应动作，从而生成测试案例的方法。使用因果图可以形式化描述结构复杂、接口众多、安全苛求系统的SRS，确定复杂系统状态和外部输入信息间的依赖关系，然后利用回溯算法生成判定表，最终基于判定表设计测试案例。由于判定表能够强化系统逻辑描述的严密性，因而基于判定表生成的测试案例是全部功能测试方法中最严格的[17]。因此，本文基于因果图法研究能够解决以上3个主要问题的CTCS-3级列控系统测试案例完备性的验证方法。

本文方法的主要流程如图1所示。首先建立SRS因果图，然后使用改进的遍历式回溯算法生成SRS判定表；利用SRS判定表内的事件建立测试案例因果图，进而生成测试案例判定表；根据设计的测试充分性准则，通过SRS判定表导出测试覆盖域，确定完备性的衡量依据；最终，对测试覆盖域和测试案例判定表进行对比，从而验证CTCS-3级列控系统测试案例的完备性。

图1　基于因果图的测试案例完备性验证流程

2　基于因果图的验证方法

2.1　建立SRS因果图并生成SRS判定表

1)建立SRS因果图

基于《CTCS-3级列控系统需求规范(SRS)》和《CTCS-3级列控功能需求规范(FRS)》[18]的条文和说明，参照文献[15]建立CTCS-3级列控系统的SRS因果图。为了降低建立SRS因果图的复杂程度，可针对CTCS-3级列控系统的不同功能分别建立系统各功能的SRS因果图。在建模过程中，需要根据需求规范所描述的系统状态或外部输入信息的性质(原因或结果)，确定该系统状态或外部输入信息为原因事件或结果事件，并为每个事件定义唯一的标识。需要注意的是，某些结果事件同时又构成了其他系统功能需求的原因事件，在建模过程中需要对此类事件所具有的逻辑关系进行完整的描述[15]。此外，由于CTCS-3级列控系统的系统状态和外部输入信息间具有复杂的相关性，因此在建模过程中需要相应地利用约束关系[15]对相关性进行描述，以保证SRS因果图的正确性。

2)生成SRS判定表

建立SRS因果图后，再根据SRS因果图并应用启发式或遍历式回溯算法生成SRS判定表，从而将SRS中描述的系统功能需求转化为判定表内的事件组合，表中的每行，即每组事件组合描述1项系统功能需求。但是，在利用启发式回溯算法[15]生成SRS判定表的过程中可能会遗漏部分系统功能需求，从而无法满足完备描述SRS的要求；而用传统的遍历式回溯算法[13,15]生成SRS判定表，虽然可以保证对SRS描述的完备性，但在回溯完与当前结果事件存在依赖或约束关系的事件后，会对其他与当前结果事件不存在依赖和约束关系的事件进行统一的置值处理，从而导致对SRS的描述存在偏差，这不利于后续验证。因此，为了完备且准确地描述SRS，本文通过引入“未明确规定”概念，对遍历式回溯算法进行改进。

对于1个包含m个结果事件的因果图G0，定义：i为结果事件索引，且i=1，2，…，m；ei为索引i下的结果事件；Ri是与ei存在依赖关系的原因事件的集合；Si是与ei和Ri中事件存在约束关系的事件的集合；Pi是可以使ei发生的事件组合集合；pik∈Pi是导致ei发生的事件组合，其中k=1，2，…；Vi是其他与ei不存在依赖和约束关系的事件的集合。改进后的遍历式回溯算法步骤如下。

(1)初始化各变量，置i,k=1，构造空的SRS判定表D0；

(2)选定未被回溯的结果事件ei，将其状态设置为“真”，根据G0描述的依赖和约束关系，确定Ri和Si中各事件的状态，从而确定导致ei发生的全部事件组合，得到Pi；

(3)对Pi中的事件组合进行处理，选定未被处理的事件组合pik，将Vi中的全部事件视作SRS“未明确规定”，用“-”表示，并添加入pik中，然后再将pik补充到SRS判定表D0内的后序行中；

(4)执行k=k+1，循环执行步骤(3)，直至Pi中的全部事件组合均被加入D0内；

(5)执行i=i+1，循环执行步骤(2)、步骤(3)和步骤(4)，直至i>m；

(6)回溯完全部结果事件后算法结束，即可得到采用改进遍历式回溯算法生成的SRS判定表D0。

2.2　建立测试案例因果图并生成测试案例判定表

由《CTCS-3级列控测试案例》[19]可知，用自然语言描述的测试案例主要由5个部分构成，即测试的系统内部初始状态SC、接口初始状态SA、测试步骤Ts、系统内部结束状态EC和接口结束状态EA。其中，SC和EC分别描述了测试的初始和结束状态下系统的运行等级、运行模式、行车许可等内部状态；SA和EA分别描述了初始和结束状态下无线链接、人机交互界面等系统接口的具体状态；TS描述了测试过程中外部输入信息的具体内容，包括接收信息、接收报告、列车的位置变化以及司机的确认操作等。

由于上述5个部分表示的系统状态及外部输入信息均在SRS中有对应的描述。因此，可基于SRS判定表内的全部事件并参照文献[15]的方法建立测试案例因果图，并利用改进的遍历式回溯算法生成与SRS判定表对应的基于相同事件的测试案例判定表，从而统一SRS和测试案例的描述方式，以保证两者具有明确的对应关系。

在测试案例因果图中，原因事件应包括SC，SA和TS所描述的系统内部状态、接口状态以及外部输入信息；结果事件应包括EC和EA所描述的系统内部状态及接口状态。

对于给定的测试案例T0，定义：C和E分别为该测试案例的原因事件集合和结果事件集合，在初始状态下，上述两集合均为空集；CS为由SRS判定表D0内全部事件构成的集合。利用CS内的事件建立测试案例因果图的过程如下。

(1)构造初始测试案例的事件集合C和E；

(2)从测试案例T0中选定1个要描述的系统内部状态、接口状态或外部输入信息，进而从CS中查找与其对应的事件；

(3)根据该系统内部状态、接口状态或外部输入信息所对应事件的性质(原因事件或结果事件)，将其补充至C或E内；

反应堆压力容器算例模型如图5所示，因压力容器是对称的，取其1/4模型来分析法兰与压力容器之间的接触，该模型仅受螺栓预紧力的作用。材料参数为：弹性模量为200 GPa、泊松比为0.3。

(4)循环执行步骤(2)和步骤(3)，直至处理完测试案例T0中描述的全部系统内部状态、接口状态及外部输入信息。

(5)根据C和E内的事件以及测试案例描述的事件间依赖和约束关系，建立测试案例因果图。

根据完成的测试案例因果图，同样应用改进的遍历式回溯算法，即可得到测试案例判定表。

2.3　确定衡量测试案例完备性的依据

衡量测试案例完备性的依据是，基于对应测试目的的测试充分性准则及测试覆盖域[15]。根据列控系统的测试目的，设计测试充分性准则为：测试案例应覆盖SRS判定表内的全部事件组合。

基于测试充分性准则，利用SRS判定表导出测试覆盖域。在设计测试案例时，设计人员需要对某些系统功能需求进行延伸理解，以设计多种测试场景进行测试；但该延伸理解的差异性可能会导致在某些测试案例的描述中存在着与其对应的SRS判定表中未包含的其他SRS事件。因此，在利用SRS判定表导出测试覆盖域时，需先将SRS判定表中未包含的其他SRS事件全部补充至该SRS判定表内，并将其他SRS事件的状态视为“未明确规定”，在SRS判定表内用“-”表示。之后将SRS判定表内的每一行作为测试覆盖域中的1个元素，由此得出测试覆盖域。

2.4　测试案例完备性对比验证流程的设计

在确定测试覆盖域后，根据测试案例对测试覆盖域中所有元素的覆盖情况，可以得到测试案例完备性的验证结果。当测试覆盖域中的所有元素全部被覆盖，则可判定测试案例的设计满足测试充分性准则的要求，即测试案例是完备的。测试案例与测试覆盖域的对比验证流程如图2所示。

由图2可知，首先要根据列控系统的特点，将事件按重要程度分为关键事件、测试条件事件以及其他事件3个部分。然后，依次选定测试覆盖域中的元素，并与测试案例进行逐个事件的对比。当发现某关键事件错误时，则表示测试案例未能覆盖SRS规定的某项系统功能需求，应针对该功能需求补充设计测试案例。当发现某测试条件事件错误时，则表示该事件描述的测试条件与SRS的规定不相符，说明虽然测试案例覆盖了关键事件所对应的功能需求，但其测试条件的设计，例如接口所处状态、外部输入信息的内容等存在不足，应进行修改或完善。当发现其他事件不符时，表示测试案例包含了SRS中“未明确规定”的事件，其主要原因是设计人员对SRS中的规定进行了延伸理解，可利用文献[4,18]判定该延伸理解是否正确，根据判定结果对测试案例或SRS中的不明确内容进行修改或说明。

图2　测试案例与测试覆盖域的对比验证流程

3　实例验证

以CTCS-3级列控系统车载设备在待机模式(SB)下的模式转换功能为例，应用本文方法对其测试案例的完备性进行验证。

为了下面阐述的方便，首先定义事件的标识及其所描述的内容，见表1。

表1　SB模式下模式转换功能的事件内容

本文所使用因果图中的基本关系[15]包括蕴含关系、非关系、与关系和要求约束关系，如图3所示。其中，ca，cb，cc表示原因事件，ea表示结果事件。在因果图中，蕴含关系表示当ca为真时，则其对应的结果事件ea也为真；非关系表示当ca为真时，则其对应的结果事件ea为假；与关系表示当ca，cb和cc同时为真时，则其对应的结果事件ea为真，并用“∧”标识；另外当与关系中存在3个或3个以上的原因事件时，则在结果事件端再加入弧线表示，否则可不再加弧线；要求约束关系表示当ca为真时，则cb必为真，并且仅可将要求约束关系用于描述二元约束关系。

图3　本文因果图中使用的基本关系

3.1　建立SB模式下模式转换功能的SRS因果图及判定表

根据《CTCS-3级列控系统需求规范(SRS)》和《CTCS-3级列控功能需求规范(FRS)》中给出的SB模式下模式转换功能需求规范，建立该功能的SRS因果图。其中，对SB转换为IS，SB转换为CO以及SB转换至SH和SL的转换优先级建立的SRS因果图如图4所示。

在图4中，利用因果关系描述了列控系统车载设备由SB模式转换至其他工作模式时的转换条件，并利用约束关系描述了不同转换条件间具有的屏蔽和依赖关系。图中的m1—m6是为了便于建模而建立的中间结点，无实际含义。

图4　SB模式下模式转换功能的SRS因果图(部分)

根据得到的SB模式下各模式转换功能的SRS因果图，应用改进的遍历式回溯算法生成对应各模式转换功能的SRS判定表，并对所得到的全部SB模式下各模式转换功能SRS判定表进行整合，得到SB模式下模式转换功能的SRS判定表，见表2。在该表中，用“1”和“0”分别表示相应的事件为真和假，用“-”表示该事件在SRS中“未明确规定”。

表2　SB模式下模式转换功能的SRS判定表

3.2　建立SB模式下模式转换功能测试案例的因果图及判定表

基于SRS判定表内的全部事件和《CTCS-3级列控测试案例》[19]，建立SB模式下模式转换功能的测试案例因果图。其中，对CTCS-3级列控系统功能特征549的测试案例1以及功能特征558的测试案例1建立的因果图如图5所示。在图5中，m7—m10同样为中间结点。

对SB模式下模式转换功能的测试案例因果图进行回溯，并整合后得到其测试案例判定表，见表3。其中，事件c17，c18，c19，c20，c21和e8为不包含在SB模式下模式转换功能SRS判定表中的其他SRS事件。

图5　SB模式下模式转换功能的测试案例因果图(部分)

表3　SB模式下模式转换功能的测试案例判定表

3.3　确定SB模式下模式转换功能的测试覆盖域

根据测试充分性准则，利用SB模式下模式转换功能的SRS判定表确定其测试覆盖域。将SRS判定表内每一行，即每一组事件组合确定为测试覆盖域的1个元素，而将该SRS判定表内未涉及的全部其他SRS事件表示为“-”，得到SB模式下模式转换功能所包含19个元素的测试覆盖域，见表4。由于篇幅所限，在表4中仅列出了与本实例相关的事件状态。

表4　SB模式下模式转换功能的测试覆盖域

3.4　完备性验证结果及分析

选定运行模式，即c1和e1—e7为关键事件，c2—c16为测试条件事件，其余SRS事件(包括c17—c21和e8)全部为其他事件。利用作者编制的自动验证工具对测试覆盖域和测试案例判定表进行对比，输出验证结果见表5。

表5　SB模式下模式转换功能测试案例完备性验证结果

根据验证结果，对文献[4]和文献[19]中的相关内容进行对比分析，可以发现：

(1)未对SB模式转入TR模式设计相应的测试案例；

(2)未针对SB模式转入其他工作模式时的模式转换优先级功能设计测试案例；

(3)在SB模式转入SH模式和SL模式的测试案例中，存在着SRS中“未明确规定”的其他事件。利用文献[4,18]进行核对，该事件属于正确的人为扩充，应在测试案例中给出说明。

4　结束语

本文针对既有列控系统测试案例完备性验证方法存在的问题，基于因果图法设计了CTCS-3级列控系统测试案例完备性验证方法。为了确保SRS和测试案例两者描述方式统一、对应关系明确，并且便于自动验证的实现，本文通过引入“未明确规定”的概念对现有的遍历式回溯算法进行了改进，使其可以生成满足验证需求的判定表，并提出利用SRS判定表内的事件建立测试案例因果图；另外，为了明确测试案例完备性的衡量依据，还设计了基于SRS判定表的测试充分性准则，并据此提出了基于SRS判定表确定测试覆盖域。

以CTCS-3级列控系统车载设备在SB模式下的模式转换功能为例，对本文方法的有效性进行了检验。结果表明，现有测试案例基本实现了对SRS的覆盖，能够较好地验证系统的功能，但也发现一些缺失和不足，需要进行补充和改善；本文方法可以有效地对现有测试案例进行完备性验证，为进一步完善CTCS-3级列控系统测试案例、确保测试过程覆盖全部SRS提供了新的方法。

[1]季学胜,李开成,张勇,等.CTCS-3级列控系统测试案例生成方法的研究[J].铁道通信信号,2009,45(10):1-5.

(JI Xuesheng,LI Kaicheng,ZHANG Yong,et al.Test Case Producing Manner of CTCS Level 3 Train Control System[J]. Railway Signaling & Communication,2009,45(10):1-5.in Chinese)

[2]张勇,王超琦.CTCS-3级列控系统车载设备测试序列优化生成方法[J].中国铁道科学,2011,32(3):100-106.

(ZHANG Yong, WANG Chaoqi.The Method for the Optimal Generation of Test Sequence for CTCS-3 On-Board Equipment[J].China Railway Science,2011,32(3):100-106.in Chinese)

[3]谈敏.CTCS-3级车载设备测试平台研究[D].北京：北京交通大学,2008.

(TAN Min.Research on the Test Platform of CTCS-3 Onboard Equipment[D].Beijing:Beijing Jiaotong University, 2008.in Chinese)

[4]中华人民共和国铁道部. 科技运[2008]127号 CTCS-3级列控系统需求规范(SRS)[S].北京：中国铁道出版社,2008.

[5]李引,李娟,李明树. 动态需求跟踪方法及跟踪精度问题研究[J]. 软件学报,2009,20(2):177-192.

(LI Yin,LI Juan,LI Mingshu.Research on Dynamic Requirement Traceability Method and Traces Precision[J]. Journal of Software,2009,20(2):177-192.in Chinese)

[6]IBM.DOORS(Dynamic Object Oriented Requirements System) [DB/OL]. [2015-03-21]http://www.telelogic.com/index/cfm.

[7]IBM.Rational RequisitePro[DB/OL].[2015-03-21]http://www.306.ibm.com/software/awdtools/reqpro.

[8]HAYES J H, DEKHTYAR A, SUNDARAM S K,et al. Helping Analysts Trace Requirements:an Objective Look[C]//Proceedings of the 12thInternational Requirements Engineering Conference. Washington: IEEE Computer Society,2004:249-259.

[9]HAYES J H, DEKHTYAR A, SUNDARAM S K. Advancing Candidate Link Generation for Requirements Tracing: the Study of Methods[J]. IEEE Transaction on Software Engineering, 2006,32(1):4-19.

[10]ANTONIOL G,CANFORA G,CASAZZA G,et al. Recovering Traceability Links between Code and Documentation [J].IEEE Transaction on Software Engineering,2002,28(10): 970-983.

[11]HAYES J H,DEKHTYAR A,SUNDARAM S K,et al.Requirement Tracing on Target(RETRO): Improving Software Maintenance through Traceability Recovery [J]. Innovations System Software Engineering,2007,3(3):193-202.

[12]古天龙.软件开发的形式化方法[M].北京：高等教育出版社,2005.

[13]胡巍巍.CBTC车载系统测试案例设计及优化方法研究[D].北京：北京交通大学,2010.

(HU Weiwei.Research on the Method of Test Cases Generation and Optimization for CBTC Onboard System[D].Beijing：Beijing Jiaotong University，2010.in Chinese)

[14]刘畅,王轶辰,刘斌,等.软件边界组合测试的典型案例分析[J].计算机工程与应用,2009,20(2):74-77.

(LIU Chang,WANG Yichen,LIU Bin,et al.Analysis of Representative Case in Software Boundary Combination Testing[J]. Computer Engineering and Applications, 2009,20(2):74-77.in Chinese)

[15]MATHUR A P.Foundations of Software Testing[M]. New Jersey:Addison-Wesley Professional,2008.

[16]李文波,杨颖. 因果图测试法在地铁网络应用软件合格性测试中的应用[J].机车电传动,2013 (3): 43-45,48.

(LI Wenbo,YANG Ying.Application of Causality Diagram Test Method for Metro Network Application Software Approval Test[J].Electric Drive for Locomotive，2013 (3): 43-45,48.in Chinese)

[17]JORGENSEN P C.Software Testing:A Craftsman’s Approach[M].Boca Raton:CRC Press,2001.

[18]中华人民共和国铁道部.科技运[2008]113号 CTCS-3级列控功能需求规范(FRS)[S].北京：中国铁道出版社,2008.

[19]中华人民共和国铁道部.科技运[2009]59号 CTCS-3级列控测试案例[S].北京：中国铁道出版社,2009.