陈晓轩 乔艳茹

（卡斯柯信号有限公司上海测试部 上海市 200071）

1 引言

近年来，随着我国现代化铁路进程的推进，轨道交通逐渐而又深刻的改变着国民的出行方式，高效便捷的出行得益于列车运行控制系统的更新升级。所谓列车运行控系统，就是根据列车在线路上的客观运行条件、实际运行状况，通过列车车载和地面设备对列车进行实施控制、监督和调整，以保证行车安全，提高运输能力；目前，我国时速300 公里/时以上的高铁，主要采用CTCS-3 系统，这是基于无线通信、轨道电路和固定的移动闭塞开发的一套准移动闭塞技术的列车控制系统；未来的列车控制系统，或将取消轨道电路，基于移动闭塞、北斗导航和5G 通信技术，由无线闭塞中心和列控车载设备共同完成列车定位和完整性检查，实现虚拟移动闭塞和移动闭塞，形成“空天地一体化”网络系统，这将是我国高铁列控技术里程碑式的重大技术变革。

为了实现这一目标，国家投入大量的科研力量，然而列车控制系统庞大而复杂，需要与不同设备厂商的设备进行互联互通，软硬件之间的耦合度要低，软件的可配性要求很高，因此，大量的信息需要存储在配置文件中，生成高质量的配置文件也成为当下列车控制系统验证过程中亟需解决的问题。随着软件迭代周期缩短，频率提高，由人的过错或者失误导致的软件失效而造成巨大的经济损失，甚至危及人身安全的概率也与日俱增[1]；而软件测试是保障质量的重要手段和环节[5]，对软件测试的准确度和完备性要求也越来越高，尤其对性能测试提出了更高的要求和挑战。

一般传统的嵌入式计算机软件测试都是基于各种通用仪器或专用设备，采用各种仪器设备对被测系统的运行进行监测，这种测试凭条的开发周期长，成本高，复用性差[6]，无法在其他嵌入式系统中进行复用，而我们的测试方法采用主流的上位机、下位机模式[2]；上位机负责外围输入信息模拟，下位机即被测对象负责处理收到的信息和反馈，如图1所示。

其中，上位机测试平台是运行在Windows 操作系统上，主要功能是管理自动化测试工具和测试活动管理[7]；下位机被测试对象是由工控机，主板，显示器等组成，运行实时操作系统通过网络、RS232、RS422、RS485、CAN 等系统提供的IO 和总线进行被测设备与实时主机间进行数据通信接收、解析与执行测试主机的配置文件和脚本，进行实时通信，控制或采集数据[3]。

结合被测系统要适配多种硬件，外围设备，多种数据，可配性高的特点，将测试活动分为测试数据准备，测试环境搭建，测试执行和测试结果分析；于被测系统而言，编写配置文件的过程变成一项复杂而繁重的体力劳动，且配置出来的文件质量低下，导致上下位机调试不顺利，成为嵌入式软件性能测试的一道瓶颈，因此上下位机配置不匹配的问题亟待解决，以降低联调成本、提高测试效率，推动研发测试并进，保证项目进度的同时保障高质量交付。因此，本文提出并实现了基于Python 语言开发的性能测试配置生成工具软件；之所以选用Python 语言，是因为Python 拥有丰富的库文件和完备生态系统，具有良好的开放性和灵活性，适合快速开发。

2 框架设计

图1：嵌入式测试模型

图2：上位机配置文件生成过程

图3：改进配置生成过程

图4：数据关系图

现有项目所采用的配置生成流程图如图2所示。

其中，Input Files 是上层用户配置文件，需经过Offline Tool 处理生成相应的二进制下位机配置文件Output Files，该Output Files是被测系统能够正常启动的必须配置，要使上位机测试平台与下位机建立通讯，必须将下位机的相关信息配置到模拟器中，因此须根据下位机配置文件按照一定规则配置上位机配置文件；而该配置过程起初是由人工完成的，过程复杂且易错，当通信节点数量指数上升的时候，几乎成了不可能完成的任务，严重阻碍项目推进。更致命的是，节点数量不算庞大时，人工制作的配置文件也会因为一些疏漏导致上下位机联调进展不顺而使项目进度迟滞，这在当今形势下的软件迭代活动中是不可接受的，性能测试更成了纸上谈兵无法落地。

因此，笔者基于现状分析配置过程中的难点和要点，提取配置规则需求，设计和开发了性能测试配置生成工具，推动配置过程改进如图3所示。

其中，AutoGenTool 将人工配置过程完全转化为代码并且引入反馈机制，其在生成上位机配置文件过程中，发现下位机配置文件中存在未配置设备，或者下位机配置文件自身存在不匹配问题等会给予记录并反馈从而促进双方的提升和获益。

3 技术实现

笔者通过规则需求提取和方案设计，选用Python 的configparser 包作为开发工具包。ConfigParser 包是Python3 中用来解析ini 配置文件的解析器，具有强大的索引功能便于读取，但却大小写不敏感，而源目标文件是大小写混用，因此需要设计解决该问题。

以下将阐述遇到的问题及解决方案：

（1）信息分散于多个ini 源文件中而目标文件是提取多个文件的相应字段信息处理所得；

（2）源文件中option 字段大小写混用；

（3）目标文件option 字段需与源文件保持一致以使C 语言生成的.lib 库文件识别；

（4）协议本身配置规则如某些远端与本端字段需交换；

（5）上下位机约定规则（自定义规则）。针对每个问题的具体解决方案如下：

3.1 创建设备协议映射索引表

分析外部因子对配置生成工具的影响，提取关键字段作为Key值，创建键值对索引表，用于目标文件生成过程中根据源文件中SrcAddr 索引Equipment 和Protocol 中某些字段信息，以解决信息分散不便于提取的问题，数据关系图如图4所示。与此同时，该表也剔除了非主要信息对配置生成工具的影响，对Equipment.ini 和Protocol.ini 而言，不在设备协议映射索引表中的字段可以随时增加、删除、修改而对配置生成工具没有影响，从而降低了上下位机配置文件之间的耦合度，增加了二者的灵活度。

图5：创建option 字段映射表

图6：处理大小写和协议字段

图7：上下位机匹配规则

图8：自定义规则

如图4所示，下位机信息存储表（Protocol.ini 和Equipment.ini 文件）主要是存储网络相关信息和设备本身信息。Protocol 中包含两类子表，一类是记录本地网络信息的LocalNetInfomation，另一类是与系统相互通信的外部设备信息即RemoteNetInformation；LocalNetInfomation 包括本地IP，网关，端口名称以及串口信息；RemoteNetInformation 包括设备名，网络连接数，本地端口，本地使用IP 编号，远端使用端口。Equipment 文件中包含了与系统通信的所有设备节点，信息包括EquipmentName、EquipmentNode 以及各个层的参数信息，其中EquipmentName 在Equipment.ini 表中是主键，在Protocol.ini 中是外键，EquipmentNode 在具体协议配置（源文件）中是主键，在Equipement.ini 中是外键，利用这个条件，创建了EquipmentMapTable 和ProtocolMapTable，使得用户在生成目标文件时可以根据源文件的EquipmentNode 索引到EquipmentName的所有参数进而获取网络配置信息，一次生成与下位机匹配的配置信息，从而实现快速查询而不需要遍历多个源文件，节约了计算时间。

图9：人工时间成本曲面图

3.2 创建关键字段映射表

由于Python 是小写处理信息而源文件和目标文件option 字段是大小写混用的，因此需要创建section 中option 字段的映射表以解决混用问题，而此映射表在生成输出文件阶段也会用到以保障输出文件与源文件一致。源文件option 字段大小混用映射表的实现过程如图5所示。

3.3 协议配置规则

每个协议有自身的配置规则，远端与本端信息需要做交换处理，因此创建的交换字段Key-Value 索引表，当读取到源文件中需要做交换处理的字段时进入协议规则处理过程，同时，该字段若为大小写混用字段需要用图5 所创建的MAP 表中Value 值替换，以实现输出格式与源文件保持一致；其处理过程如图6所示。

3.4 上下位机约定规则

下位机配置文件在Protocol 中约定了与系统通信的所有设备使用的IP 和Port 信息，因此在生成上位机配置文件时需要从下位机配置表中查询该设备使用的网络配置信息，而InstanceProtocol 源文件中没有存储Protocol 与之对应的EquipmentName 字段，此时需要先查询设备协议映射表，通过InstanceProtocl 中的SourceAddr在EquipmentMapTable 中查找到对应的EquipmentName，从而利用EquipmentName 获取其在ProtocolMapTable 中所有网络配置索引信息，这也是创建设备协议索引表的重要作用所在。此外，在创建索引表过程中发现下位机配置文件本身的问题也会做相应的异常处理并记录反馈，其处理过程如图7所示。

3.5 自定义规则

在实际应用中，系统与外部通信设备不断增加且由于行业的特殊要求，同一设备需要热冗余以便当一系发生故障时，设备能够自动切换至另一系继续工作从而实现对外输出透明。体现在配置中就会出现多个EquipmentName 与同一个EquipmentNode 对应，此时上下位机配置匹配时需要按照系统设置的自身规则进行处理。目前的冗余规则是，当协议节点使用交叉互联模式时一个节点会有4 个EquipmentName 与对应，前两者默认为A 系，后两者为B 系；如果采用直连模式会有2 个EquipmentName 与对应，说明只有一系，则默认输出到A 系。下位机配置文件中允许同一类型协议直连和交叉互联模式同时存在，因此人工处理起来更为繁琐，而程序按照约定规则实现大大降低了出错率，未来用户也可以约定其他规则，只需要添加对应的规则处理函数即可。具体处理流程图如图8所示。

4 技术优点分析

本设计方案具有以下优点：

（1）松耦合：只须约定下位机配置文件格式而不限制内容，建立的相对稳定的索引表，从而实现不会因为下位机配置文件某些内容的修改、增删就必须更新配置生成工具，降低了两者之间的耦合度，给双方以更多的自由空间和灵活度。

（2）可扩展：如图4 数据关系图所示，采用3 层映射关系，增强了配置工具的可扩展性。随着系统支持的协议增加，InstanceProtocol 可以持续扩展，当有新的协议加入下位机配置文件中时用户只需要给定该协议的源文件格式（InstanceProtocol 源文件），下位机配置支持该协议，就可以放入配置生成工具中自动生成与源文件匹配的目标文件，而对其他协议没有影响。

（3）工程效应：大幅度提升工作效率，推动性能测试顺利开展。以项目实际应用为例，以系统支持的Y（Y＞500）个Protocol1类型节点，其中直连模式比例为X，交叉互联模式比例为（1-X），假设人工配置这样一个上位机配置文件，一个Connection 至少需要3 次人工索引，15 个字段修改，理想情况下修改一个Connection 需要30 秒时间，而且不能保障准确度，因为人随着重复度提高，疲劳程度加强，配置文件出错率也会越高；配置节点个数增加与直连模式比例的变动所需要的人工时间成本三维曲面图如图 9所示。

从图9 中可以看到，当节点数量剧增、直连比例降低时，人工耗时成本急剧增加。实际上，当人力配置一个文件超过20 分钟其质量已经堪忧，而系统支持超过100 个节点，人工配置已经是不可达状态；而采用配置生成工具生成上位机配置文件轻而易举，1 秒之内即有输出，大大提高了测试效率，推动了性能测试的工作和验证强度，节省了人力成本，工程效应显著。

5 结束语

随着软硬件本身的提升，系统可扩展性、灵活性以及性能不断加强，因此配置文件也越来越庞大而复杂，要对其性能进行完备的验收，性能测试成了软件测试过程中的重要环节和瓶颈。而完备的性能测试配置及测试数据是性能测试成功的必要条件，本文阐述的性能测试配置生成工具为配置完备的性能测试配置提供了有效途径，该设计方案易于二次开发，具有良好的扩展性和稳定性，有效提高性能测试平台的开发效率，推动性能测试的顺利开展。