一种信号设备功能测试系统方案的研究

2010-05-09李启翮

铁路通信信号工程技术 2010年4期

李启翮

（北京全路通信信号研究设计院，北京 100073）

1 概述

轨道交通领域作为高安全需求领域，其信号设备（如联锁、列控设备等）多为安全苛求设备，这些设备协同工作，共同保证列车安全运行。

为确保设备安全稳定工作，运营之前必须进行全面的测试。针对不同的设备以及测试的不同级别，需要设计并构建不同的测试系统。针对该问题，本文提出一种通用的设备功能自动化测试系统，针对事件驱动类型（如CTCS-2级列控系统的列控中心、CBTC系统的区域控制中心等）或周期处理类型（如计算机联锁）的设备，实现系统级别功能测试，只需针对具体的设备进行适配，就能以相同的测试原理测试不同的设备。

测试通常分为多个级别，如单元测试、针对设备各部件的子系统测试、针对单一设备的系统测试、多个系统设备之间的集成测试以及现场测试等。单元测试由开发人员自己完成；子系统测试是保证该部件能与其余部件相配合工作，组成完整的设备；系统测试则是针对单一设备，确保该设备的功能正常，从而为后续集成测试和现场测试中多个设备之间联调联试打下基础。

实际测试中，若缺陷在后面几级测试才被发现，其解决成本比在前几级测试中发现的解决成本高得多。统计表明，后一级的测试与前一级的测试相比，发现和修复一个缺陷的平均成本要提高10倍。因此子系统和系统级别的测试，尽量完整覆盖所需测试的功能，将尽量少的问题遗留到后面的联调联试中，从而极大降低故障定位、缺陷修复的成本。

本文所提出的测试系统，主要针对系统测试这一级别。由于子系统测试和系统测试相近，只需将被测的部件看作一个单一设备即可。因此，本测试系统也同样适用子系统级别的测试。

CTCS-2级列控系统已在提速线路和客运专线上成功运用，是当前主流的列控系统，列控中心（TCC）是其核心控车设备。本文将以TCC为例，对测试系统进行描述。

2 被测对象

系统测试的对象是一个正常运行设备的内部处理功能，以及该设备与其他设备的交互功能。以TCC为例，就是要测试TCC能否与其外接设备正常交互，并根据自身状态和外部输入实时做出正确反应。从本质上说，就是在确定设备自身状态后，对其实施激励，检测其反应是否正确。

TCC根据调度命令、进路状态、线路参数等产生进路以及临时限速等相关控车信息，通过有源应答器及轨道电路传送给列车。以既有线车站列控中心为例，在计算机联锁车站，他与调度集中（CTC）、计算机联锁（CB I）、地面电子单元（LEU）、集中监测（CSM）等设备相连[1][2]，其连接关系如图1所示。

3 测试方式

对被测对象的测试，采用根据功能场景、需求规范以及接口规范编制测试用例的方式进行。由于测试工作量巨大，人工手动测试难以满足实际需求，要求进行自动化测试，这就需要根据测试用例编写测试脚本以实现测试自动化。即先编写测试规范与用例，再根据用例编写脚本，在测试系统上运行测试脚本，观察并分析其运行结果，确认被测功能是否符合需求。

4 测试系统需求

对设备进行系统测试的目的是为了确认该设备是否符合功能需求，是否能够可靠地与其他设备协同工作，是否具有足够的鲁棒性，为下一级测试交付一个可用的设备。

一个单独的不与外部通信的设备是无法正常工作的。每一个设备都与不同数量、种类的其他设备相连，而各接口之间的交互功能往往包括多个步骤，许多测试场景还涉及多个接口之间的配合、协调，因此测试步骤比较复杂。以TCC为例，测试系统必须能够测试TCC与CBI、LEU、CTC、CSM的交互功能。

由于测试的复杂性，纯人工手动完成并不现实，因此测试系统应能进行自动化测试。此外，开发过程中，开发者会根据每一轮的测试结果发布新版本，需要对每一个版本进行迭代测试，为节约成本，测试系统应能提供自动化的迭代测试功能。最后，为了方便测试以及节约时间成本，该测试系统应易于构建，方便使用。

5 测试系统

5.1 测试系统原型

一个正常运行的设备需要与其他设备相连接以进行信息交互，而在对其进行较全面的测试之前又不适合与其他真实设备联调联试，即便能够，也无法满足系统鲁棒性测试的要求，因为真实设备难以方便地实现错误注入，因此需要采用外连各设备的仿真器来测试其功能。以TCC为例，为构建测试系统，需要开发CTC仿真器（CTCsim）、联锁仿真器（CBIsim）、LEU仿真器（LEU sim）、CSM仿真器（CSMsim）等。

为了实现自动化测试，需要将测试用例以某种语言编写为测试脚本。为了对测试脚本的运行进行管理并记录测试结果，还需要一个测试管理器（TM）。

根据以上分析，本文提出如图2所示的测试系统原型。

5.2 仿真器

为简化开发工作，测试系统采用接口仿真器。接口仿真器只具有与真实设备相同的接口，而不实现内部处理逻辑，所有需要逻辑处理的地方，均由人工编写命令脚本实现。这类仿真器制作简单，但如果被测设备与仿真器之间的交互信息无法准确确定时，将增大测试脚本的编写难度。由于信号设备多为安全苛求系统，当其自身的内部状态与外部输入被确定时，该设备的正确反应也随之确定。因此，接口仿真器完全能够满足测试的需要，即使有部分数据不能精确确定，也可以通过计算其取值范围，并在编制脚本时增加一些处理即可。

每一个接口仿真器应实现与真实设备相同的接口，其中应用数据层、链路层、安全层等应与真实接口完全相同，物理层可以通过接口转换器实现。此外，仿真器还应能根据用户的指定，实现错误注入，以测试被测设备的鲁棒性。最后，仿真器的安装使用应尽量简单。

以CTCsim为例，仿真器应实现的功能：（1）实现符合规范[3]的接口协议；（2）能接收用户命令；（3）能根据用户命令按正确格式发送CTC消息；（4）能根据用户要求发送有错误的消息，以实现错误注入；（5）能接收TCC所发送的消息，并将其以一定格式向用户显示；（6）能自动对TCC消息进行CRC校验，如出错，则向用户发送提示；（7）能自动向TCC发送打点时钟消息，且其频率能由用户指定；（8）能自动检测TCC“列控中心状态消息”的发送频率，若超出一个可配置的范围，能提示用户；（9）能根据用户命令与TCC建立或断开通信连接。

根据以上分析可知，CTCsim的功能并不复杂，主要分为与TCC的消息交互和与用户的消息交互两个部分。为了单独使用和便于调试，用户命令的接收和TCC消息的显示分别使用操作系统的标准输入和输出，如图3所示。测试人员可以直接输入命令让仿真器向TCC发送消息，并根据TCC回应的消息，判断TCC处理逻辑的正确与否。从便于安装使用的角度出发，仿真器实现为一个单独的应用程序使用时直接运行。其他仿真器也以类似方式实现。

由于与被测设备的物理接口多样化，例如RS-422串行异步接口、以太网接口等，对不同仿真器实现不同的物理层接口增加了复杂度。为能以一致的方式进行仿真器的开发，决定所有仿真器均采用以太网与外部接口，再根据需要使用接口转换器与之相连，以实现正确的物理层接口。

5.3 测试管理器

TM的基本功能是脚本解析与命令收发。根据输入测试脚本，TM依次将脚本中的各条命令向该命令所指定的接收对象转发。收到TM命令的仿真器会据此与被测设备进行相应的信息交互，并将被测设备的回应消息转发给TM，TM将该消息与测试脚本所规定的应收到的正确消息进行比较，以确定被测设备的功能是否正确；如否，则向测试人员报告错误所在。

TM实现为一个单独的程序，其功能包括：（1）脚本文件的读入与内容解析；（2）与仿真器建立通信连接；（3）根据脚本向仿真器发送消息；（4）接收仿真器转发的被测设备的消息或仿真器的提示信息，并与脚本的规定进行比较以判断正误；（5）记录并显示测试过程和结果。其中(1)和(5)只涉及文件操作和文本处理，(2)、(3)和(4)是核心功能。

考虑到TM要与测试脚本进行交互，采用同一种脚本语言实现TM和测试脚本（如可采用p er l、ruby等脚本语言），更有利于二者的交互。

如前所述，各仿真器以标准输入、输出与用户交互，而自动化测试时则需要与TM交互，这需要增加仿真器与TM间的通信接口。由于脚本语言的性能较低，此外，与TM交互的仿真器的数量、种类会随被测设备的不同而变化，为了达到模块化的设计，决定将消息分发功能独立出来，增加1个消息分发器（MD）。TM仅与MD相交互，由M D完成消息的分发。

为了不增加仿真器的复杂度，充分复用其已有的I/O接口，可利用U n ix系统的基于进程间通信（IPC）的管道I/O重定向功能。具体方法是启动MD后，首先由MD根据配置文件，通过fork()产生新的进程，以启动各个仿真器，再针对每一个仿真器创建两个管道，分别与其标准输入、输出相连，从而实现与仿真器的信息交互。针对每个仿真器，M D设定唯一的标识符，该标识符由配置文件指定，由脚本和MD在消息中加上该标识符，就可容易地实现消息分发。由上可知，M D的功能应包括：（1）读入配置文件，根据指定的配置，管理各仿真器的启动与关闭；（2）实现消息分发。M D实现也为一个单独的程序。

以上方案不仅能实现单一用例的自动化测试，再增加对多个测试案例批量处理的功能，就可以进行自动化迭代测试。这只需给TM增加第6个功能：脚本批量处理，即读取一个脚本文件名列表文件，根据该列表逐条读取脚本运行，当完成一个脚本运行后，继续读入下一个脚本进行测试。

5.4 测试脚本

由于所用仿真器只有接口而没有内部处理逻辑、线路数据，因此，这部分功能只能由测试脚本承担。将测试用例场景，转化为一个动作执行序列，按步骤将每一步应发送给TCC的消息以及应从TCC接收到的消息以一定格式编写到一个文件里，由TM读入并顺序执行，该文件即测试脚本。

脚本编写应简单明确，既适合测试人员编写、阅读，又便于TM进行解析，最终确定以rub y语言[4]编写，同时TM本身也以rub y编写实现，有利于二者交互。下面是一个简单的脚本示例。

ctcSim=ni l

ctcSim=CTC.new(name)

ctcSim.sendConnect()

ctcSim.waitConnected(expire_time)

ctcSim.sendTSRStatusReq()

ctcSim.waitAck(expire_time)

c t c Sim.wa i t TSRSt a t us(seqno,bmai n,cmd n o,t ime1,t ime2,s t a r t,e n d,t s r,lef t,whole,expire_time)

这是一个CTC sim与TCC交互的例子。首先建立仿真器实例，该函数会设置一些默认的初始化参数，如该仿真器的名字、系统时间等，然后与TCC相连接，随即发送状态请求消息并等待回应。示例中CTC为事先封装好的公共类，sendConnect()等均为已经编制好的类方法，可供任意脚本调用。函数括号内斜体所示为参数，实际脚本中应以正确的数据替换，如w aitTSRStatus()的参数分别为帧序号、主备机标志、限速命令号等消息数据，用于和所收到的消息比对以确定消息是否正确，参数expire_time是消息等待时间，如该时间内未收到消息，则报错。这样编写的脚本所反映的场景流程更加清晰，不会被处理细节所干扰。