城市轨道交通车辆运行参数监测系统软件单元测试方法研究

秦 昊，肖曼琳，王振宇，杨 霄，蔡烨玲

（上海工程技术大学城市轨道交通学院，上海 200000）

随着中国城市化进程的加快以及基础设施建设的发展，城市轨道交通客运里程以及客运量不断增加，保证城市轨道列车的安全运行成为相关行业和社会越来越关注的任务。

目前，国内大部分列车均搭载基于MVB 标准的网络控制系统，即实时采集列车运行情况，并将这些信息通过MVB 网络数据显示出来，并加以分析和处理，从而完成对车辆运行系统的参数监测，并且最后通过上位机软件，即车辆运行参数监测系统软件，动态显示以告知司机列车当前的各种状态。车辆运行系统参数监测系统工作流程如图1 所示。

图1 车辆运行参数监测系统工作流程示意图

本文介绍了车辆运行参数监测系统软件单元测试的方法以及研究过程，但是由于该软件的功能单元数量巨大，并且每个单元中设计的函数运算数量庞大、逻辑复杂，软件工作时输入信号多变，所以设计合理的软件单元测试方法，完整并高效地完成功能单元测试，具有很强的软件工程实践意义。本文主要研究了车辆运行参数监测系统软件单元测试的方法以及过程，其具体内容安排如下：第1 节叙述了单元测试的背景，第2 节介绍了单元测试原理以及测试方法，第3节分析了轨道交通车辆信号软件单元测试的基本要求并设计了测试步骤，第4 节展示了车辆运行参数监测系统软件单元测试流程及测试结果，第5 节总结。

1 单元测试背景

对自己书写代码的检测往往会被工程师忽视，且代码检测存在粗略、不规范等诸多特点，如文献[1]仅仅介绍了计算机软件的黑盒测试这一种方法。在文献[2]中采用了C++test 动态测试来测试软件函数运行中存在的问题，用函数覆盖率体现，具体点就是通过函数调用的检测来快速准确找到具体的问题函数，却无法确定整体函数的运行模式等，即不完整的动态测试。文献[3]是从单元测试中动态测试方法与规范方面引入，是一篇理论指导方面的论文，侧重于动态测试的阐述与分析，缺少在动态情况下函数调用独立运行、静态测试等在软件测试中的问题解决方法与实际操作。文献[4]采用底层模拟技术优化了打桩技术，因为大部分轨道运行的软件都是嵌入式的，与电脑的操作系统不同，有着独立的无法识别的函数，这个时候就需用打桩技术来解决，但又不是所有的函数都需要进行，所以不具有普遍性。对比以上文献中所提到的测试方法，本文所包含的测试方法更加全面，而对于检测工具的合理使用也使测试效率大幅提升，也能更加直观地发现未被覆盖的代码，便于测试人员以及开发人员后续修改和检测。现在还不存在一套对各类软件都通用的测试方法和流程，所以本文旨在保证被测软件正常运行，研究和设计一套测试方法和测试流程，并完成对该软件的单元代码全面和严格的测试，保证软件良好运行。

2 软件单元测试

2.1 单元测试原理

单元是由人指定要测试的最小的功能模块。单元测试是软件开发过程中最低层次的测试活动。独立的软件单元将与程序的其他部分分开进行测试。根据软件源代码程序和软件设计说明书，了解输入输出范围的功能限制和代码逻辑原理，测试分析软件编码是否正确，并确定软件界面和单元功能是否满足软件设计规范的要求。

2.2 单元测试方法

2.2.1 静态测试

静态测试指不需要软件代码运行即可进行的测试[5]。可用来检测软件代码的基本质量，检测是否存在简单错误，包括定义的冲突或歧义，它进一步测试的前提，可以为之后的测试排除基础错误，也可以检测软件代码的完整性以及是否一致，代码编写是否符合规范[6]。

2.2.2 白盒测试

白盒测试又名逻辑驱动测试，是一种对代码结构的测试，运用白盒测试前需要了解代码的逻辑以及代码如何运作，白盒法是穷举路径测试。

2.2.3 黑盒测试

黑盒测试是一种关注软件外部结构的测试，是将软件代码看做一个无法打开的黑盒子，不需要考虑内部结构，是一种主要面对软件界面以及软件功能的测试。

3 轨道交通车辆信号软件单元测试

3.1 轨道交通车辆信号软件单元测试基本要求

目前，轨道交通信号软件测试的标准规范主要为ISO 29119-3《软件测试国际标准》和MISRA-C：2004《Guidelines for the use of the C language in critical systems》等文件。

轨道交通信号软件单元测试一般应满足以下要求：首先，要保证软件的行为和性能满足对应测试规格的要求，软件测试应遵循先静态再动态的测试原则；其次，测试用例应包含输入、输出2 部分，能验证函数的正确性，测试通过准则为BUG 数等于0，对于错误较多的函数，应进行多次测试；最后，组合条件覆盖率应达到100%，特殊情况下，组合覆盖率不能达到100%，应经过人工验证代码，并给出合理解释和说明[7]。

根据认证标准以及行业规范总结了以上要求，并以此作为测试规范。

3.2 轨道交通车辆信号软件单元测试方法步骤

根据软件测试的易错性和单一性，笔者们选择C++Test 9.5 以及Keil uVision5 作为单元测试的工具。C++Test 是面向C 语言的单元测试工具，该软件能够自动进行白盒测试、黑盒测试和回归测试。因此，该软件可以高效完成对软件的底层测试，能够有效降低软件错误率，提升软件运行稳定性。Keli uVsion5 主要用于嵌入式单片机编程。

4 车辆运行参数监测系统软件单元测试过程

4.1 测试流程研究

设计针对被测软件的测试方法和测试流程，并完成对被测软件的具体测试。基本的软件测试大致流程如图2 所示。

图2 软件测试基本流程示意图

代码质量测量、控制流、数据流和编码规则检查是通过C++测试、结合工具和手动检查完成的。采用人工方法分析编码规范的一致性以及编码与详细设计的一致性。流程如下：首先对被测代码进行解读，根据代码的运行流程与复杂程度从而制定相应的检查单，分为软件分析与人工走查2 类，分别进行测试，再将软件测试中出现错误的代码进行人工走查，人为修改约束条件，进行针对性测试。

4.2 测试过程及结果

第一阶段为基于C++Test 的软件静态分析。代码质量度量、控制流、数据流和编码规则检查是通过C++测试来执行的。检查内容为MISRA-C：2004 规则、度量指标规则、最优化规则等规则，规则搭建方法如图3所示，目的是找出欠缺和可疑之处，测试流程如图4所示。结果将展示被测代码中有多少行代码违反了何种规则，测试结果如图5 所示，并将静态分析中产生的错误整理出来，包括错误代码发生的位置及内容。

图3 静态测试规则搭建

图4 静态测试流程

图5 静态测试结果

单元测试菜单如图6 所示，在C++Test 任务栏里发现，有30 行代码违反了规则，其中25 行代码违反了MISRA-C： 2004 规则，3 行代码违反了度量指标规则，2 行代码违反了最优化规则。

图6 单元测试菜单

第二阶段为基于覆盖率分析的白盒测试。通过分析测试系统软件模块内部的路径执行和逻辑分支，选择覆盖分析的方法，使软件的4 个覆盖率达到100%。具体测试流程如下：建立单元测试、建立桩函数、收集桩函数信息、运行单元测试。以上流程均由图7 所示菜单完成，由测试结果可以得出被测代码的各种覆盖率。由此可以对代码的质量进行分析，并判断该代码是否需要进行人工走查。

图7 单元测试结果（被测软件覆盖率）

第三阶段为基于等价类和边界值的黑盒测试。通过4 步完成黑盒测试：①明确函数代码结构中所包含的输入、输出变量，以及输入输出边界值，如图8 所示，分析输入输出判断是否为无效等价类数据；②建立测试用例，需在测试工具中建立外部数据库，手动建立测试用例库；③添加测试用例数据，同时，对函数内部调用的其他函数进行打桩处理，生成桩函数；④对桩函数输入值进行修改，以满足软件运行需求，在桩函数与测试用例都无误后，进行测试。

图8 函数代码的输入输出值

5 结束语

目前，在软件测试领域，单元测试的重要性正在被逐渐发现，但往往由于项目时间短、资金缺乏等原因导致了软件单元测试工作难以开展，测试质量不能被保证。因此了解单元测试的优点，并研究一种高效准确的测试方法有着重要的意义。本文在理论方法的研究和实际软件测试的基础上，对轨道交通车辆信号软件单元测试方法进行了研究，并对系统中重要组成部分进行测试与分析，能够高效地找出软件开发过程中存在的缺陷，并提醒开发人员及时纠正，确保轨道交通车辆信号软件的稳定性和可靠性，进一步提高信号系统的安全性。