铁路信号产品自动化测试探讨
2020-10-09宋西欣郁文斌
宋西欣，郁文斌
(北京全路通信信号研究设计院集团有限公司，北京 100070)
1 概述
近年来，国内高铁快速发展，路网规模占世界高铁60%以上。截止2019年底，国内高铁运营总里程达到3.1万km，这是一项非常了不起的成就。列车运行控制系统是高速铁路的“大脑和神经”，旨在确保列车运行安全。CTCS-3级列控系统[1]作为中国高速铁路安全运行的核心系统，测试是保障其安全可靠的其中一个重要环节。
北京全路通信信号研究设计院集团有限公司（简称通号院）作为高铁信号设备供应商，为中国高铁列控系统的安全可靠运营做出了很大贡献。笔者参与高铁信号设备测试工作多年，深刻体会了测试技术的发展、测试质量的提升对于高铁快速并且安全可靠的发展具有重要意义。上万公里的高铁线路，如何保障每一公里测试的充分性、正确性，一直是业内测试技术发展的动力所在。如此庞大的工程数据量，带来的测试工作也是巨大的。因此，自动化测试在铁路行业领域发挥着举足轻重的作用。
以通用的自动化测试技术作为分析起点，结合铁路行业的特点，展开高铁列控系统自动化测试的论述；针对高铁信号为特点的自动化测试发展所面临的问题，提出可行的解决方案并推出一套行之有效的自动化测试框架，力求对于高铁列控系统各类型设备的自动化测试实现有一定的理论指导意义。
2 自动化测试
自动化测试是每一个测试项目的终极目标。对于自动化测试，虽然各行业不同，但具有通用的理念、理论及技术应用。
2.1 业内情况
国内自武广高铁开始应用CTCS-3级列控系统，目前铁路信号领域的列控系统设备面临数据量大、枢纽工程数据复杂、变更频繁等诸多问题，与其他行业自动化测试技术相比：1）铁路信号领域的自动化测试技术相对落后；2）铁路信号领域的自动化测试覆盖率较低，尤其是枢纽工程，有些产品甚至仍旧依赖人工测试。
以通号院的CTCS-3级列控系统产品举例，联锁产品[2]、列控中心产品[3]的自动化测试目前主要使用早期自主开发的系统，无线闭塞中心[4]和车载设备[5]采用引进的国外设备自动化测试框架，临时限速服务器[6]自动化测试则起步较晚。早期自主开发及引进的自动化测试工具，普遍具有更新慢、维护难、对复杂的枢纽线路支持不足等问题，导致无法进一步提高自动化测试覆盖率；业内的同行企业，很多是在与其合作的外方公司自动化测试框架基础上进行引进消化吸收的再次开发，选用的方式主要是通过验证测试完成后的日志记录分步执行，严格意义上不属于自动化测试。
以上现象说明，目前通用自动化测试技术在铁路信号领域的应用有较大程度滞后，因此需要深入分析铁路信号领域的特殊需求，针对运营里程快速增长引起的庞大工程数据量，以及工程枢纽改造带来的复杂性、既有线与新建线频繁改造接入等特点，开发适用于铁路信号的通用自动化测试技术。
2.2 业外情况
行业外的自动化测试则是另外一番景象。自动化测试技术和理念不断升级更新，新的自动化测试框架频繁提出，自动化测试工具更是层出不穷。目前流行的JUnit、TestNG、Selenium+WebDriver、Appium、STAF+STAX、Robot Framework等，尤其是Robot Framework具有丰富的生态系统，发布了各种通用的测试库、扩展库、拆件、工具，可充分满足用户的二次开发需求。尤其是其强大的数据驱动功能，可以支持excel、XML等各种格式的外部数据，对于铁路信号工程领域的测试具有极大的优势。
自动化测试的优势，笔者认同文献[7-8]的观点，这些优点同时也适用于铁路信号领域：
1) 节省测试时间、进行全面的回归测试；
2) 增强对于系统质量的信心，其又可以反馈到对系统的改进；
3) 节省人力资源，测试人员可以将精力投入到新功能等其他测试领域；
4) 其工作输出的成果（工具、脚本框架、自动化用例）都是可以长期重复使用的，是“实在”的、“可见”的成果；
5) 自动化在质量守护和问题快速反馈上起了决定性的作用：大部分需要长期更新维护的软件，都需要自动化能力帮助防止质量劣化、支持重构；
6) 自动化几乎是测试活动的终极形式：当某一类测试内容已经被研究透彻，形成了一定的规律和模式，那就可以进一步实现自动化测试。因而自动化也是团队技术进步的标志之一。
基于上述优势，通过引入这些框架，构建符合铁路信号自身需要的自动化测试仍不容易。
首先，市场上流行的测试框架对于支持web、mobile、UI等易于实现。由于行业的差异，对于支持铁路信号软件还有一定距离。但是，其通用的理念、理论可以借鉴以实现适于铁路信号的测试框架实现。
根据ThoughtWorks公司的评估，任何一种自动化测试的分层都可以映射到如图1所示。
图1 自动化测试分层图示Fig.1 Layers of an automatic test
铁路领域信号产品的人工测试目前都是基于交互式的人机界面，由此可以考虑基于图1的基本概念，引进市场上流行的自动化测试技术，解决铁路信号领域自动化测试面临的问题，从而开发出适应于铁路信号领域的交互式自动化测试产品,以提升测试效率与质量。
3 面临问题
高铁信号领域的工程特点与传统的测试定义差异极大，但面临的问题具有很大的相似性。“测试是不能穷尽的”这一基本法则表明，测试是成本与质量的矛盾体，有限资源下的测试穷尽涉及的测试数量是巨大的，因此经常会遇到测试驱动的数据源爆炸、测试序列爆炸、组合条件爆炸、测试路径爆炸、测试场景分类爆炸等各种无法完成的测试需求或任务，尤其是频繁更新的高铁信号领域，由于信号产品面临各工程场景之间条件的复杂性，导致软件内部涉及业务功能的条件判断、软件外部版本管理的分支化，由此产生后续一系列的工程数据配置迭代回归频繁、测试配置分支化等问题。
依据铁路信号工程测试特点，目前自动化测试框架的构建面临以下几个问题：
1) 测试数据源处理；
2) 测试框架方案选择与构建；
3) 测试工具对于框架的适配开发。
因此高铁信号产品的自动化测试的实现主要围绕上述问题解决进行阐述。
3.1 测试数据源处理
无论选择哪种测试框架，最终的测试都需要落实到案例的执行。首先遇到的问题就是测试数据的驱动方式。进行测试数据驱动，首先需要有数据来源。高铁信号产品由于工程数据源的标准化颗粒度差异性导致了数据源采集时的不确定性，而后续测试工作开展的基础是工程数据采集结果，涉及到两方面的工作：
1) 脚本驱动的数据源构建；
蓝宝石最大的特点是颜色不均，可见平行六方柱面排列的，深浅不同的平直色带和生长纹。那么什么是色带，蓝宝石为什么会有色带呢？蓝宝石色带是指宝石内部可见的120度夹角,由颜色深浅变化的蓝色组成的天然纹路。理解色带的成因之前，我们必须要了解，蓝宝石是结晶形成的。结晶是蓝宝石，红宝石，祖母绿，帕拉伊巴这些单晶体宝石的生长方式，原理就和冰糖结晶一样，从小小的一粒逐渐长大。
2) 脚本结果匹配的期待数据构建。
高铁信号产品的自动化测试首先需要解决数据源的标准化。自2018年起，行业内开始推进铁路信号工程领域工程数据表的标准化工作[9]，并对各产品间接口数据表进行规范，解决由于接口数据表描述不统一导致的信号软件接口兼容性问题。由此，数据源标准化前进了一大步，但是仍旧遗留诸多问题：
1) 虽然标准化了工程数据表格模板，但是模板内部的关键字未明确规定；
2) 接口表内部的关键字虽然规范化，但是设备商根据自身信号产品的实现方式，需要二次加工的信息由于各设备厂商产品的差异性无法完成统一规范化；
3) 高铁线路的频繁变更、改造导致的枢纽站的数据变更无法标准化；
4) 有些输入源的数据表由于历史原因等尚未做到标准化。比如联锁产品，电子联锁表是联锁产品自动化测试的前提，只有提供了标准格式的电子联锁表，才具备自动测试的必要条件。目前联锁设备供应商仅可获得非电子化的纸质版本联锁表，极大影响了联锁产品自动化测试的发展，需要行业主管部门大力推进解决。
3.2 测试框架方案
虽然上文提到一些测试框架及工具，根据高铁信号产品特点，直接在其基础上构建基本是行不通的，需要进行大量的接口实现和适配等二次开发后才能构建起来。如何选择适合高铁信号产品的测试框架方案，也是制约自动化测试的一大问题。
自动化测试框架是骨架结构，支撑自动化测试的执行环境的构建，其包含数据集合方式、流程、脚本编码标准、概念、项目层次化、实现。一旦确定了框架，则自动化测试奠定了构建的基础，如图 2所示。
图2 自动化测试框架图示Fig.2 A test automation framework
目前流行的测试框架基本是针对测试脚本语言实现方式进行分类：
2) 函数型、单领域语言型、多领域语言型、富文档型。
根据高铁信号测试从业人员的整体水平评估以及长期的业内经验总结，数据驱动、关键字驱动、富文档型是比较容易在业内推行的测试案例脚本化方式，且选用语言语法越简单易懂，越有利于普及推广。
构建了测试框架，自动化测试的开发即可展开，针对高铁信号产品，自动化测试开发主要集中在：
1) 测试数据的采集及处理；
2) 脚本的数据驱动处理；
3) 脚本以操作命令模式、业务场景模式的关键字驱动；
4) 测试数据驱动的信息在被测设备与外部接口模拟设备的交互；
5) 测试数据驱动的信息在测试驱动组件与外部接口模拟设备的交互；
6) 测试案例预期结果数据的计算；
7) 测试结果的匹配及正确性判断；
8) 其他辅助性信息处理。
因此，适用于高铁信号地面产品的自动化测试开发，即是在测试框架下的自动化测试引擎开发。其可以选择在目前流行的功能和扩展库强大的自动化测试框架产品上开发（例如Robot Framework有丰富的扩展库，可以广泛支持通信、进程调度、队列、事件等），也可以借鉴其先进的理念进行自主开发。无论如何，这也是制约高铁信号产品自动化测试的又一个问题。
3.3 测试工具
铁路信号系统是一个庞大的系统集成系统，尤其是CTCS-3级列车运行控制系统，采用国内现行最先进的信号系统技术，该系统包括地面设备和车载设备。其中联锁、无线闭塞中心、列控中心、临时限速服务器等地面设备，都需要配置大量的工程数据。
工程数据测试是对具体设备所承载配置数据的测试，检测其是否正确。目前国内高铁列控系统的工程数据主要是由地面设备进行配置和计算，因此工程数据测试集中在地面设备的测试。每种地面设备均与其他设备实现信息交互，共同完成整体系统的计算功能，保证高铁系统的安全可靠。地面设备的工程数据测试涉及的测试数据量非常可观，需要遍历车站的所有进路信息、区间的闭塞分区信息等，因此其测试结果即是验证被测设备通过交互的输入信息执行计算后，其向外部接口设备输出信息或显示信息是否正确。每种设备的测试工具则主要是外部设备的接口模拟工具。如果进行自动化测试，需要驱动接口模拟设备按测试案例的数据驱动模式进行数据交互。
信号设备的测试工具开发主要集中在：
1) 数据驱动后的信息处理；
2) 以关键字驱动的业务场景操作处理；
3) 信息按驱动执行与被测设备的交互功能；
4) 信息按驱动执行与测试驱动组件的交互功能；
5) 其他日志等辅助信息处理。
以合作过的某外国公司信号设备商自动化测试框架为例，有如下缺点：
1) 工具部署异构，接口较多；
2) 存在大量的人工辅助工作；
3) 缺少模块扩展接口，未考虑维护简易化；
4) 由于信号产品测试是判断被测设备输出信息的正确性，因此脚本化语言选用了匹配自然语言的脚本编程语言，属于小众化脚本语言，推广困难；
5) 未开源且技术未转让。
4 解决方案
通过详细分析并总结从业多年的经验积累，笔者认为解决上述问题的思路是在引进目前流行的自动化测试技术前提下，构建符合高铁信号产品自身特点的自动化测试框架，从而自主开发适应高铁信号产品特点的自动化测试平台，也就是测试引擎。这样既可以保持技术的先进性，又可以把核心技术掌握在自己手中，摒弃受制于外来公司技术的瓶颈限制，在测试环节实现和实践为国内高铁技术发展安全可靠性的保障。
4.1 测试数据源处理
依据本文3.1节提出的问题，首先需要从数据源上进行分析。当前各设备供应商地面信号设备的处理方式均为数据导入后进行内部标准化，以提供给用户统一的数据提取接口。其使用的常见技术为数据库技术，即从数据源直接到数据库的处理方式。为了解决3.1节的问题，可以采用中间适配技术，在数据源和目标之间实现一层适配，适配的技术可以引进目前流行的技术：
人工智能：CTCS-3级列控系统涉及的地面产品（列控中心、无线闭塞中心、临时限速服务器等）工程数据配置的来源是工程数据表。3.1节已经提到，虽然目前规范了格式的标准化，但是由于各种客观原因，仍旧存在无法标准化的内容。例如表头名称的定义、公里标数据的字符串格式等。针对这些问题，可以引入AI的“基于概率的推论”，技术推理最有可能的匹配结果进行分析后确定数据的处理方式，“专家系统”的技术对未识别出的内容进行学习扩展。利用AI的机器学习和算法生成最优测试案例或者制定测试策略则是另一个课题，不在本文中讨论。
关键字模糊匹配：模糊匹配的算法和实现的技术也可以用于解决本节的数据源处理问题，而且跨平台跨语言提供了丰富的开源库可以使用。最为熟知的是搜索引擎的模糊匹配处理算法，对于常用的字符串处理，极大程度上适用于工程数据表中关键字的模糊匹配。例如错别字匹配、近义词匹配、长尾词扩展匹配等技术可以借鉴后引进，在工程数据表数据导入时用于解决遇到的各种问题。
4.2 测试框架
前面已经提到，没有流行的测试框架是针对高铁信号领域提出的，也没有测试框架可以直接应用于高铁信号产品设备的自动化测试框架构建。
针对本文3.2节提出的问题，可以借鉴2.2节中的自动化测试框架技术，针对高铁信号产品承载功能的数据特点进行考虑：
1) 具有勘查设计属性，例如地面设备线路数据的里程标系、坡度、速度勘查数据；
2) 具有范围或距离属性，例如无线闭塞中心的管辖范围、移动授权距离；
3) 具有静态和动态属性，例如地面设备实时输出的给定条件下经过计算的安全信息，自身固有配置信息；
4) 具有接口信息属性，例如联锁设备的进路状态信息、信号开放信息；
5) 具有信息交互属性，所有的高铁设备工作模式是通过自身已知的信息计算输出用于其他外围设备安全控制的协议信息。例如列控中心、无线闭塞中心向列车输出移动授权范围内的线路信息；车载人机界面DMI输出列车的警示、速度、设备状态、距离等关键信息以向司机反映当前车载运行控制信息。
首先需要解决脚本语言的问题，在此基础上确定测试框架方案。目前流行的脚本语言有python、perl、ruby、javaScript、VBScript、tcl等，根据设计单位提供的工程数据表特性，目前流行的python、ruby有丰富的数据库支持设计单位提供的数据格式的采集、处理、构建和输出，而且其语言语法简单易懂，对于构建基于数据驱动、关键字驱动的脚本测试案例具有很大的优势。
本文针对高铁信号产品提出一种DRT框架模型，驱动(Driver)/资源(Resource)/任务(Task)框架的逻辑结构，如图3所示。
图3 DRT框架结构图示Fig.3 DRT framework
1) 驱动服务提供一切自动化测试需要运行的程序单元，包括基础数据处理驱动、测试数据生成驱动、测试数据与测试动作结合驱动、脚本生成和运行控制驱动、被测对象与外围设备的交互信息定制、获取、验证驱动等，是本自动化测试框架运行的工作基础。所有的驱动组件以函数接口的方式进行组织实现，以方便用户扩展。驱动服务以测试引擎的方式运行，可以采用分布式进行管理。
2) 资源由测试对象、测试数据、测试脚本、运行列表构成。测试对象是识别测试元素的集合，例如临时限速服务器产品的限速拆分、无线闭塞中心的坡度速度信息生成、联锁设备的进路状态信息输出等；测试数据是测试脚本运行所使用的数据载体；测试脚本则是测试对象、测试数据按照测试业务流程组合在一起的运行载体。
3) 任务是用于实现一个、一组测试行为的操作集合。例如信息发送、信息获取、信息匹配、信息验证、信息响应等。
还有一些辅助性的内容，例如脚本运行结果记录、统计信息等，也可纳入到本模型中。
本模型可以涵盖目前高铁信号产品自动化测试的基本需求集，满足一般性的自动化测试实现。在测试脚本的设计中，可采用数据驱动和关键字驱动结合的方式进行，在本文4.1节提供的数据源的基础上，使用基础数据驱动和测试数据生成驱动组件构建符合脚本语言使用的数据组织形式，可以是数据库、excel以及其他富文档类型的数据组织形式，而要做到真正的数据驱动，必须有控制测试的业务流，由任务列表中的关键字驱动结合实现，测试数据和测试操作结合驱动根据任务列表预先设定的任务关键字选取相应的流程函数，根据用户的数据定制需求生成测试案例。测试脚本是最终测试案例执行的“驱动”。
4.3 测试工具
任何自动化测试框架下实现自动化测试，必须对被测对象进行驱动。例如web的自动化测试必须使用驱动浏览器的工具库。因此，高铁信号各产品的自动化测试需要驱动被测产品与外围设备的交互，外围设备模拟即为驱动被测对象的测试工具。
根据DRT模型，测试工具以被驱动的方式接入测试框架，根据高铁信号产品特点，测试工具与被测设备的交互均在测试框架内以测试驱动服务实现，即测试工具作为代理在驱动服务组件与被测设备之间进行数据交互。由此，与自动化测试相关的功能尽量在测试驱动内实现，测试工具仅适配测试驱动程序按其驱动指令完成与被测设备的数据交互，如图4所示，实现方案如下。
1) 被测设备与外围模拟建立内部通信连接，用于测试驱动的接口实现。
2) 测试驱动接口的收发两个方向，以不同队列作为数据交互的数据结构。
3) 脚本中的任务流控制测试数据与测试驱动接口的交互。
4) 测试驱动接口与被测设备的数据交互采用触发方式，有数据则触发。
5) 在1）中，被测设备与每个外围设备模拟间维护独立的驱动接口，即分布式管理。当然，也可以采用轮询算法进行单线程调度管理。
6) 上述1～4进行分布式处理，其通过2）中的队列作为进程或线程的通信方式。
图4 测试工具图示Fig.4 Block diagram of test tools
测试工具能够完成测试案例脚本中业务关键字指定的数据驱动功能，按其指令完成数据在测试工具与测试驱动组件或被测设备的信息交互。
5 总结
本文针对铁路信号产品自动化测试现状进行汇总分析，总结了高铁信号产品自动化测试发展的问题。在参考和借鉴其他行业自动化测试框架的流行技术的基础上，针对这些问题提出一种符合高铁信号产品自动化测试的DRT框架模型，并在此框架下提出一系列具体实现的技术和理念，对高铁信号产品工程测试的自动化实现提供一种方案参考。
后续在本文的基础上，针对某一信号产品开发实现一个通用的自动化测试平台，验证其可行性并推广到其他产品，是本方案进一步的展望和规划。
