专项测试工具在铁路信号软件测试中的试用与结果分析

2013-05-09北京全路通信信号研究设计院有限公司北京100073

铁路通信信号工程技术 2013年1期

高强（北京全路通信信号研究设计院有限公司，北京 100073）

1 铁路信号软件测试的背景

铁路信号软件与普通的应用软件不同，最大的特点是在复杂的条件下要求具备高安全性，所以铁路信号软件开发过程中很大一部分精力要用于对产品测试。传统的铁路信号软件主要采用手工测试的方式，但由于测试仿真器和测试案例的数目比较多、测试的可操作性比较低，所以测试过程需要花费很大的人力与时间，而且测试结果的可靠性、规范性都不足。

信号系统设计开发平台（SDP）提供了用于铁路信号软件自动化测试的专项测试工具，能够支持执行完整的子系统功能测试，包括测试数据的准备、测试环境的准备、测试的自动执行和测试结果的统计等功能。专项测试工具使用脚本描述测试的过程，使用测试机进行自动测试执行，提高了软件测试的规范性和可靠性，降低了多轮次回归测试中人力的消耗，能够有效提高铁路信号软件的质量。SDP专项测试工具原理示意如图1所示。

高强，男，硕士毕业于清华大学，助理工程师，软件开发工程师。主要研究方向包括信号系统设计开发辅助工具，曾参与信号系统设计开发平台项目。

2 区域控制器（ZC）

本文以SDP专项测试工具在ZC子系统测试中的应用为例，进行试用与结果分析。ZC具备铁路信号产品的典型特点，是基于通信的列车自动控制系统（CBTC）的地面核心设备，根据所控列车的状态、其控制范围内的走行位置、联锁进路信息、临时限速命令等信息，实时生成列车行车许可，并通过无线通信系统传输给列车自动防护子系统（A TP），保证其管辖内的所有列车的运行安全，并实现移动闭塞。

ZC子系统功能复杂，所以测试的规模很大，体现在测试分引擎、测试案例、测试脚本的数目都比较大。在实际的测试中，分引擎的数目在9个左右，测试案例和测试脚本的数目都在数百的量级，如果采用手工测试则耗时耗力，而且测试的效果也不能得到保证，所以在ZC子系统测试中使用SDP专项测试工具。

3 专项测试工具和手工测试的结果统计

ZC子系统测试中使用SDP专项测试工具，进行了多轮次自动测试，测试的时间、人力以及测试效果的统计如表1所示。在每轮回归测试之外，ZC测试人员还使用SDP专项测试工具进行日常开发过程中的功能测试，效果如表2所示。

ZC子系统测试中同样使用手工方式进行了测试，用于日常开发过程中的调试与验证。ZC手工测试的情况如表3所示。

表1 ZC子系统测试使用SDP平台专项测试工具的情况统计

表2 测试轮次之外使用SDP专项测试工具的情况统计

4 试用结果的对比与分析

4.1 测试案例覆盖率的分析

测试方法对测试案例的覆盖率是十分重要指标之一，只有测试案例覆盖率较高的测试方法才是安全和可靠的。除了部分不具备测试环境的案例（例如ZC能控制30个车的测试案例），专项测试工具能够覆盖绝大部分案例。与此对比，手工测试对案例的覆盖率很低，存在大量的测试案例只能使用专项测试工具进行测试。手工测试未能覆盖的案例主要有以下3种原因。

1）耗时很长的案例：这类案例需要测试人员长时间操作和观察测试进程，对人力资源的需求量很大。

2）不能人工测试的案例：这类测试案例是人工测试难以复现或者不可实现的。例如各种边界条件下的案例就是难以复现的，需要测试人员多次重复。反案例用人工测试也比较困难，因为人工测试使用的仿真器全是按照正常逻辑来实现的；又如很多正面案例手工测试也无法完成，比如说车地通信时间戳的校准，10周期校准一次，人工测试不可能实现。如果要将这些案例变为人工可测的，需要对仿真器本身进行修改以增加功能，需要的人力远远大于编写脚本通过专项工具进行测试。人工不可测的原因统计如表4所示。

3）容易出错的测试案例：这类测试案例在人为因素的影响下容易出错，导致需要重复测试，浪费测试人员的时间。

表4 人工不可测的原因统计

正是因为人工测试不可能做到覆盖测试案例，在ZC子系统测试中人工测试更多用于调试错误和进行结果验证。

根据测试案例覆盖率的结果，可以对专项测试工具和手工测试两种方式对测试案例的覆盖率进行对比，分别为图2和图3所示。

从图2和图3中可以看出，SDP专项测试工具对案例的覆盖率很高。除了部分案例，其余绝大部分案例都能使用专项测试工具进行测试。手工测试随着案例难度和数目的增加，覆盖率逐渐下降，而且没有覆盖的案例很大部分都是手工测试根本无法进行的。在实际的测试过程中，几乎没有手工测试可以进行而专项测试工具无法测试的案例。因此如果要求尽可能多地覆盖测试案例，达到良好而完全的测试效果，则必须选用专项测试工具。

4.2 发现bug的情况

因为覆盖率与人力消耗的问题，ZC测试中已经不采用手工测试，只是在调试中使用人工测试，所以人工测试发现bug数为0。使用专项测试工具，能够在每轮测试中发现ZC软件中存在的b u g，如表1中所示。

更为重要的是，专项测试工具执行所需要的时间远远低于手工测试，而且不占用人力资源，所以专项测试工具可以用于开发过程中的快速迭代，以提高软件质量。快速迭代的流程如图4所示。

图4中可以看出，在修改b u g之后，使用专项测试工具可以进行快速迭代，验证b ug是否修改正确和是否引入新的bug。因为专项测试工具可以利用空闲的测试机或者闲暇时间，不消耗人力；而且根据表1，修改bug之后进行一轮完整覆盖测试案例的自动测试只需要2.5 h，完全满足快速迭代开发的时间需求，而这两个优点是人工测试无法做到的。表2中给出了开发过程中使用专项测试工具进行自动测试的情况。可以看出完全有充足的时间与人力进行多次测试，也发现了很多潜在的bug，在固定的测试轮次之前进行了修改。由此可知利用专项测试工具进行快速迭代，可以提高修改b u g的质量，避免引入新的b u g，尽早发现未知b u g，可以显著提高软件的质量。

4.3 测试准备阶段人力花费的对比

不论专项测试工具还是手工测试，每轮测试开始之前都需要进行测试环境的准备工作。SDP专项测试工具需要开发仿真器、编写和评审脚本。手工测试同样需要开发仿真器，以及为覆盖更多的案例而修改仿真器。将表1、表3和表4中的用于测试环境准备阶段的人力进行汇总，如图5所示。

从图5中可以看出，SDP专项测试工具和手工测试都需要花费很大的人力在第一轮测试之前开发仿真器。随着测试案例的增加和测试范围的扩大，SDP专项测试工具和手工测试都需要对测试环境进行修改。但专项测试工具与手工测试所用仿真器有较大的区别：SDP专项测试工具中与被测对象进行交互的逻辑是在测试脚本中实现的，只需要花费人力编写和评审脚本；手工测试中与被测对象进行交互的逻辑是在仿真器中实现的，所以需要花费人力对仿真器进行修改和调试。因为专项测试工具覆盖的案例比较完全，所以脚本的数目很多，前几轮测试中编写和评审脚本的人力花费比较大，而手工测试覆盖的案例较少，所以修改仿真器的工作量不大，花费的人力不多。

值得注意的是，开发脚本比修改仿真器容易。测试人员经验的增加，以及已有脚本也可以在新案例对应的脚本中复用，导致开发脚本的时间逐渐降低。另一方面，频繁修改仿真器很可能带来新的b ug，导致仿真器本身不稳定，在测试过程中如果发现了问题，还需要花人力确认是被测系统的b ug还是修改仿真器带来的问题，因此修改仿真器的时间并不会减少。根据实际测试中的统计，每轮测试中用于修改仿真器的人力消耗一直都没有减少，而开发脚本的人力则迅速下降，到第四轮测试时，SDP专项测试工具和人工测试用于测试环境准备的人力消耗已相差无几。

4.4 测试执行阶段人力花费的对比

将表1、3和表4中用于测试执行的人力进行汇总，得到图6。因为手工测试对测试案例的覆盖率很低，为便于比较，对手工测试的人力花费进行了修正，简单地用实际测试花费的人力资源除以测试案例的覆盖率，以表示手工测试完全覆盖测试案例所需要的人力资源，得到图7。

测试执行的人力消耗则是SDP专项测试工具的优势所在。从图6中已经看出手工测试所需要的人力要远远大于SDP专项测试工具。图7中按照完全覆盖测试案例进行修正后，手工测试所需要的人力是专项测试工具十倍乃至上百倍。此外，专项测试工具可以在空闲的测试机或测试人员的闲暇时间进行自动测试，只占用测试机的资源，人力消耗几乎为0，这是手工测试根本不可能实现的。

4.5 不同轮次耗时与人力的对比

为了清晰地反映出SDP平台专项测试工具和手工测试在测试执行中的情况，分析了每轮测试花费的时间图（如图8所示）和需要的人力图（如图10所示）。同样，根据对测试案例的覆盖情况，简单对时间和人力进行了修正，得到了图9和图11。

从图8和图9测试案例的覆盖情况可以看出，尽管手工测试没有编写和评审脚本的时间，但随着每轮测试规模的逐渐增大，需要的总时间也逐渐上升。相比较之下，在测试脚本和分引擎逐渐稳定之后，专项测试工具花费的时间大幅度下降，甚至仅仅包含测试机自动执行测试的时间。

图10和图11从人力使用的角度反映了类似的效果。手工测试花费的人力比较稳定，而且随着测试案例的增加，为完全覆盖测试案例需要的人力会逐渐增加。专项测试工具则在前若干轮需要花费人力进行测试环境的准备工作，测试环境稳定之后花费的人力逐渐下降，最后几乎只占用测试机的资源。

同之前分析的类似，手工测试中未测试的测试案例包括很多耗时长或者无法人工测试的案例，因此手工测试完全覆盖测试案例时所需的时间和人力远远大于图9和图11中的结果。

4.6 多轮次回归测试人力需求分析

SDP专项测试工具的优势在于多轮次的回归测试中耗时短并且节省人力。为说明这一优势，可以依据已有的数据，预测进行多轮测试时人力的消耗情况。

根据目前已有的四轮测试数据，假设第5轮测试有约600个测试案例，到第10轮测试时线性增长到约800个测试案例，之后趋于稳定。这样从第10轮至第20轮就没有测试准备的人力，只有测试执行的人力。预测时按照实际第3、4轮测试的增量数据进行计算，并认为手工测试按照比例完全覆盖测试案例。因为SDP专项测试工具只占用测试机资源，人力消耗几乎为0。经过分析与计算，可以得到表5。

表5 多轮次测试使用人力资源的分析与预测

从图12中可以看出，在前几轮测试中，因为测试案例在逐渐丰富，所以SDP专项测试工具和手工测试的多轮次累计人力需求都在快速增长。在测试案例稳定之后，测试准备环节不再消耗人力，人力需求的增长来源于测试执行环节。手工测试每轮次都要花费相当的人力，而专项测试工具只占用测试机资源，几乎没有人力资源需求。所以从图12可以看出，测试案例稳定后，人工测试的累计人力需求仍然持续增长，而SDP专项测试工具的累计人力需求保持恒定。到第20轮测试之后，人工测试的累计人力消耗远远大于SDP专项测试工具。

图13从多轮次测试中每轮平均人力需求的角度同样得到了类似的结论。在测试案例稳定之后，SDP专项测试工具的平均人力需求逐渐下降而趋于0，但手工测试的平均人力需求则保持恒定，甚至略有增长。

根据多轮次测试的人力资源需求情况的预测，很明显可以得到结论：SDP专项测试工具有利于多轮次的回归测试，特别是测试案例稳定之后，使用SDP专项测试工具可以显著降低人力资源的消耗，节省测试执行的时间。

4.7 SDP专项测试工具脚本开发学习效率分析

使用专项测试工具时，需要花费时间学习熟悉两个方面的知识：一是被测对象的需求和功能，知道测试的范围；二是脚本开发技术及测试方法，知道该如何测试被测系统，第一方面知识在手工测试中也必须学习。在ZC第一轮测试之前很大一部分时间用于学习这两个方面的知识。在熟悉一段时间之后，开发脚本的效率迅速提高，花费的时间与人力有了明显的下降，如表6和图14所示。