列控中心产品功能测试技术研究与应用

2018-09-11朱耘燕

铁路通信信号工程技术 2018年8期

朱耘燕

(北京全路通信信号研究设计院集团有限公司，北京 100070)

1 概述

列控中心（Train Control Center，TCC）是CTCS-2和CTCS-3级列控系统的地面核心设备，列控中心根据其管辖范围内联锁进路、轨道占用状况（各列车位置）、以及临时限速状态等信息，向轨道电路发送编码信息，向有源应答器发送报文信息，向列车传输运行许可，从而实现列车控制系统的功能[1]。

随着我国铁路建设事业的高速发展，TCC作为客运专线和高速铁路列控系统地面信号控制的关键设施，为高速运行的列车提供了可靠的安全保证。在客运专线建设和既有线改造过程中，随着站场类型的日益复杂、业主需求的不断增加，既有的列控中心软件已无法通过车站配置数据修改满足全部需求，必须对软件的实现逻辑进行修改和添加。

在软件发布现场前，需要对列控中心进行严格的测试，包括产品功能测试（Product Function Test，PFT）、产品数据测试（Product Data Test，PDT）、系统测试（System Data Test，SDT）3个过程。PDT的侧重点在于配置数据正确性的验证，PFT的侧重点在于验证软件功能修改的正确性，PFT的实质是根据开发阶段的需求分析、详细设计以及代码结构，设计出全覆盖软件修改的测试用例，并按照测试用例驱动仿真/真实模拟测试环境中运行的列控软件，观察执行结果，分析可能出现的故障。通过代码走查、功能测试，能很好的验证列控软件修改的正确性。

2 产品功能测试技术概述

列控中心设备适用于客运专线上的联锁车站、中继站和线路所[1，2]，TCC接口配置如图1所示。

TCC的设备接口组成如图2所示。

列控软件由基础代码和配置数据共同编译生成，基础代码完成列控中心的基础功能，配置数据用于适配各站的特殊站型、设备数量。基础代码修改包括基础代码升级和工程变更，基础代码升级是定期维护并完善基础代码功能，不同站场的特殊需求由工程变更实现。产品功能测试针对基础代码修改，测试重点关注软件功能修改，满足以下要求：1）完成需求；2）不影响既有功能的实现；3）符合故障-安全原则。全覆盖的功能测试对于验证列控基础代码修改的正确性，提高列控中心应用软件的可靠性有着非常重要的意义。

目前，列控中心数据测试的标准站场的标准功能部分已通过测试序列生成的方法实现自动测试。列控中心产品功能测试由于每次软件功能修改不同的特殊性，由人工采用灰盒测试形成的一套验证基础代码修改正确性的行之有效的测试方法。灰盒测试即结合黑盒测试和白盒测试对列控中心软件修改功能进行验证。软件代码走查和功能测试是列控中心产品功能测试的两个重要组成部分。前者从代码实现角度直接分析软件修改的合理性，后者从功能实现角度间接验证软件修改的正确性和安全性。

列控中心产品功能测试不是一个线性工作流程，而是在上述工作中不断循环，直至寻找到所有可发现的缺陷，并回归测试验证缺陷修复的正确性，其执行流程如图3所示。

3 列控中心软件代码走查

白盒测试又称基于代码的测试。在TCC-PFT测试中的白盒测试主要对代码进行逻辑覆盖，针对不同的模块分别采用语句覆盖、判断覆盖和条件覆盖[3]。

代码走查，指开发测试人员针对软件输入，进行代码人工走读，从而发现缺陷的一种测试方法。代码走查能充分发挥开发测试人员的主观能动性，多方面综合各种输入，找到测试软件无法发现的缺陷。

开发测试人员在代码走查过程中，必须综合考虑列控项目实施说明书、列控系统集成设计输入审核单、列控软件修改详细设计等输入，判断走查的函数是否符合上述输入的要求。代码走查的特殊性，要求开发测试人员必须对《列控中心技术条件》和《信号安全系统C语言编写规范》等原则有充分的理解，并且具备对复杂输入进行分析、判断、运行的能力，这也是代码走查无法由软件自动完成的直接原因。

列控中心的代码走查，重点关注两方面的内容：1）代码符合语言编写标准，无逻辑漏洞；2）代码完成的功能符合设计输入，无安全问题。当然，如果代码走查的项目过多，会加重测试人员的工作负担，以致无法凸显代码走查的优势。为提高工作效率，在实际工作中不断对走查项目进行删减，最终形成的检查项如表1所示。

表1 列控中心软件走查检查项Tab.1 Terms of TCC software walkthrough

实践证明，运用表1的检查项进行代码走查，能有效发现列控中心软件修改导致的缺陷。而且，代码走查已成为最有效的缺陷发现方式。统计笔者一定工作时期内的缺陷发现量，代码走查的缺陷发现量占比高达67.7%，如表2所示。

4 列控中心软件功能测试

功能测试，指开发测试人员对修改后的列控中心软件进行功能验证，从而发现缺陷的一种测试方法。功能测试不仅局限于验证修改需求是否得到满足，更为重要的是确认软件修改没有引入新的问题，并且所做的软件修改都符合故障-安全原则。

表2 列控中心软件走查发现缺陷占比Tab.2 Percentage of defects detected by TCC software walkthrough

功能测试的测试环境包括列控中心仿真测试系统（Train Control Center Test，TCCT）[4]和真实设备。列控中心仿真测试系统是针对客专列控中心接口开发的基于PC及Windows操作系统的列控中心软件调试及测试平台，实现列控中心对外通信接口单元和外部通信设备逻辑，以及列控中心主机单元设备的仿真[5]。真实设备指列控中心真实双系主机，以及真实联锁、真实CTC、真实TSR等外部设备。

根据测试环境的搭建方法，列控中心软件功能测试分为仿真功能测试和真实设备功能测试两大类。两类功能测试之间没有明显的使用界限。功能测试工作开展过程中，一般根据实际情况，是否涉及双系、平台交互等修改，选择合适的测试方法。

4.1 测试方法概述

黑盒测试也称功能测试,列控中心软件黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法[6，7]。

当以上方法不能够全覆盖软件修改时，通过代码注入打桩，触发被测语句，通过灰盒测试实现代码修改的全覆盖。

4.1.1 划分等价类

常用的案例设计方法采用划分等价类。等价类是指某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据，取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。

例如区间改方相关功能测试。有效等价类有区间正方向、反方向和无方向的情况。无效等价类为各种组合条件不满足时改方不成功。

4.1.2 边界值分析

常用的边界值分析是通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。它是对等价类划分方法的补充。长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误[6-8]。

以临时限速覆盖标志测试为例。分别选择在临时限速管辖范围边界上、边界外1 m、边界内1 m的限速，验证跨边界限速只有在起点反向覆盖和终点正向覆盖是能够验证并执行成功。

4.1.3 错误推测法

常用的错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。

以网络通信中断案例为例。验证当TCC和CBI、CTC、相邻TCC、TSRS等外围设备单、双通道中断时，能够正确向集中监测输出报警。

综上，结合代码走查，通过划分等价类、边界值分析、错误推测法对列控中心软件修改进行验证测试。例如对条件覆盖，通过划分等价类对代码中的每一个条件语句进行功能覆盖测试。例如对判定覆盖，通过划分等价类对代码中的每一个判断语句进行覆盖测试，采用错误推测法对else的情况进行覆盖测试。