自动化测试技术在FADEC控制软件中的应用

熊 波,柏 晗,郝小蕾

(中国航发控制系统研究所，江苏 无锡 214063)

0 引 言

航空发动机控制系统是航空发动机的重要组成部分。随着科学技术的进步，航空发动机的控制系统从传统的液压机械控制系统发展到目前的全权限数字电子式控制(FADEC)系统。FADEC软件级别依据系统安全评估过程中所确定的潜在失效状态定义为A级(Level A)，它对可靠性的要求比普通软件高，这就要求对FADEC软件进行严格的测试，以提高产品的可靠性。发动机控制软件(发控软件)在国内面临以下几个挑战：研制周期长、频繁的需求变更且进度紧迫。如何保证发控软件能够应对挑战，重要的一点是每次变更带来的回归测试要完整、全面。本文主要探讨针对发控软件的系统测试自动化平台的设计，来满足发控软件的安全性需求。

1 自动化测试平台架构设计

DO-178C[1]是国际公认的机载软件开发指南，其目的是为航空软件的生产提供指导，使软件达到相应等级的安全性。DO-178C中的6.4节给出了一条说明软件测试充分、完整的途径，它的测试理念[2]是回溯测试的本源，基于需求进行用例设计，最后通过对需求的覆盖率和代码的结构覆盖率来评判测试的充分性。基于需求的硬件/软件综合测试(DO-178C 6.4.3.a)作为重要一环，本地化后对应为发控软件的系统测试，它的目标是确保目标机中的软件满足高层需求，它所关注的输入输出均为和外部接口相关的，直接影响发动机控制，一旦不能完整验证，将存在很大的泄漏风险。

在发控软件的全生命周期过程中，都会进行很多次的软件升级，需要进行回归测试。目前通常采取的是手工执行的方式，受限于时间节点，手工执行只能采取增量测试，即对变更的内容进行测试，而发控软件是一个非常复杂的软件，其实现发动机控制的80%以上功能，数据和控制耦合交叉影响，任何更改都可能带来非预期的更改，针对变更的增量测试也难于保证测试的全面性。通过分析某所近年外场暴露的软件缺陷，多个国家重点项目均出现关联更改带来的软件缺陷，比如某项目因为更改消喘功能下的点火影响到起动功能时的点火，从而导致发动机起动失败。

自动化测试是针对手工测试效率低，覆盖面不全等问题产生的。自动化测试框架就是用计算机按照特定流程或业务逻辑来模拟用户执行的操作，比较软件执行结果与预期的差别，将执行结果记录到日志文件中去的过程。由于计算机能够做到执行重复的操作，并且每一次操作都是无差异性的，从而弥补了手工测试对单一重复操作的不足。自动化测试是测试行业智能化中很重要的一个体现，这个转变大大提高了工作效率[3-12]。

自动化测试技术按照成熟度趋势划分，经历了以下几个阶段：

1)录制和回放技术。把手工测试过程捕获下来，形成线性脚本，利用回放功能，重复执行录制的软件操作。由于录制的脚本和对象及测试数据完全耦合，当对象、测试数据改变时必须重新录制，给脚本维护带来极大的不便。

2)基于数据驱动的测试。从数据文件中读取输入数据，将数据与测试脚本分离，从而可以在不修改测试脚本的情况下通过更新测试数据完成对测试用例的增加、更改和删除，适应于对相同流程进行大数据量测试且测试结果可被预期的情况，但是未提供良好机制适应被测程序的变动。

3)基于关键字驱动的测试。主要思想是把传统测试脚本中变化的与不变的信息进行了分离，使得分工更加明确，并且避免了它们相互之间的影响。它需要将具体测试和自动化工具以及应用程序本身的变化完全隔离开。但是这种投资是一次性的，一旦开发结束并投入使用，它给人们带来的效益是巨大的，是自动化测试框架中最容易维护和使用的，而且可以反复运用于各种应用中，长期发挥作用。

目前，大多数测试工具处于数据驱动到关键字驱动之间的阶段，其中支持数据驱动的主流测试工具包括WebKing、Rational Robot、WinRunner、QTP等，支持关键字驱动的主流测试工具包括SAFS、FitNesse、Certify、UTP、QTP等。

自动化测试框架工具虽然有多种且各有侧重，如针对GUI、Web等自动化测试，但是对于发动机控制软件系统测试的特殊性，需要构建嵌入式系统的自动化测试框架，将主流测试工具进行本地化改造的工程量巨大，尚未有成功的应用实践。本文结合关键字驱动的技术，研究一种以满足DO-178C需求的覆盖率目标为基础，构建测试用例自动化执行、结果自动化分析、基于需求追溯的测试覆盖率自动化显形，在回归测试时可以快速自动执行，并最终达到MC/DC覆盖率要求，解决以往航空发控软件系统回归测试过程中验证不完整的问题。最终形成的平台架构设计如图1所示，拓扑结构如图2所示。

图1 自动化测试框架

图2 自动化测试平台环境拓扑结构

自动化测试框架的运行操作步骤如下：

1)测试人员编写测试用例文件；

2)根据测试平台定义的规则软件解析测试用例文件，形成测试执行脚本；

3)测试平台软件按测试执行脚本中的操作步骤，通过网络通讯向地检软件和上位机软件发送对应的指令；

4)地检软件根据接收到的操作步骤指令，设置控制器的输入信号，获取控制器的输出信号；

5)上位机软件保存来自控制器的数据，并根据操作步骤指令与控制器进行数据交互；

6)所有用例执行完成后，数据分析软件对所有用例对应的数据文件进行分析，最终输出测试结果报表，并最终显形测试的需求覆盖情况。

2 系统测试自动化实践

将自动化测试操作运用到实际型号项目中，最终形成的测试流程如图3所示。

图3 系统测试自动化整体流程图

2.1 测试设计

基于Doors中的需求开展需求分析，并将所有的需求标识存放到工作环境中，需求的标识存放形式如图4所示。

图4 需求标识全集

项目基于标准工作项，通过工具自动化产生测试设计的工作目录，如图5所示。

图5 标准工作目录

基于标准工作目录分配任务，不同的测试人员在统一的工作目录下开展测试规程设计并更新上传到配置管理服务器SVN，测试规程规格如图6所示，同时在测试规程中定义了其所追溯的需求。

至此，测试用例的设计工作基本完成。

图6 测试规程的设计

2.2 执行脚本开发和执行

原测试执行模式是基于单个需求场景设计输入步骤，然后从对应的数据文件中寻找验证点所在的片段进行数据比对，带来的一个问题就是“忽略”了数据文件中的其他片段，也不关注其他场景下产生的数据是否符合本场景下的验证点，降低了随机扫描发现问题的概率；再一个就是这种模式下人工处理环节造成的效率提升困难。因此将原测试规程中的执行和分析进行剥离，最后产出每个被测对象的操作场景和分析算法。通过部署执行和分析解耦，可以提高回归测试执行的效率和测试数据分析的充分性，更好地抑制软件关联更改引入的缺陷，同时也能弥补人工分析不足的问题。

首先基于测试执行部分开展脚本设计，脚本通过和测试规程名称的一致性来保证追溯性。执行脚本设计完后在测试执行软件下进行自动执行，产生测试数据。为了更好地提升脚本设计效率和提高可读性、可维护性，采取关键字驱动的设计技术[13-16]，将常见操作进行封装，测试人员可以采取类自然语言的方式编写脚本，如图7所示。

图7 执行脚本

每个测试用例运行前，系统都需要重置以保证系统的初始状态，如图7中的进入待机状态，该关键字含重启模型的机制，如图8所示。当测试用例出现异常，比如模型死机、抛出异常等，会导致该用例执行不通过，测试人员可以从执行记录中分析异常。

图8 初始化系统状态

在执行的过程基于Jenkins打通远程部署和分布式执行，执行完成后产生测试数据，并自动推送到数据服务器存储，如图9所示。

图9 测试数据

产生的测试数据需要自动按照用例名存放到特定的目录，以实现分析的自动化。自动存储的设计如图10所示。

图10 设定自动化存储测试数据

2.3 分析脚本开发和执行

在开发执行脚本并执行的同时，可以基于测试规程开展分析脚本的开发。分析脚本的设计[17-19]如图11所示。

图11 分析脚本的设计

分析脚本库函数的设计如图12所示。

图12 分析脚本库函数的设计

定义追溯链路并规格化，才能工具化。分析脚本中和需求的追溯关系规格定义如图13所示。

图13 分析脚本中定义和需求及验证对象的跟踪关系

测试数据产生后，利用分析脚本进行测试结果的自动化分析，分析脚本的使用模式如图14所示。

图14 分析脚本的使用模式

通过测试数据和分析脚本的“交叉式”分析，可以极大地提升分析的效率，这是人工分析难于达成的，比如图14中，未将执行和分析解藕，则只能分析将A、B执行脚本产生数据分别用分析脚本A、B分析，执行2次分析，而解耦后的分析脚本是基于全场景下的对象来设计的，可以分析任一场景下该对象的预期符合性，因此A、B执行脚本产生数据均可以用分析脚本A、B分析，执行了4次分析，随着执行和分析脚本的增加，分析的数量呈指数级增长。

通过构建基于Jenkins的分布式数据分析平台，实现不同区域的分析脚本和数据服务器中的测试数据进行联合分析。

分布式数据自动分析批处理命令如图15所示。

图15 分布式数据自动分析批处理命令

2.4 测试记录和覆盖状态生成

分析完成后通过自动化工具，产生测试的执行记录，如图16所示。

图16 测试记录

最后，对所有的测试记录，结合需求标识全集、测试规程、测试执行脚本、分析脚本等通过工具化可以分析得到每条需求的设计和执行覆盖状态，如图17和图18所示。

图17 需求的设计覆盖

图18 需求的执行覆盖

同时也可以直观显形统计出覆盖率，最终回答DO-178C中需求百分百覆盖的目标，如图19所示。

图19 需求的设计覆盖率和执行覆盖率

2.5 应用成效

使用本文基于需求覆盖的系统测试自动化技术和方法，对某所重点型号项目控制软件进行自动化测试部署，通过实施表明，在人工基于增量测试的基础上通过自动化测试帮助项目发现了不少关键的缺陷，这些问题都是原先的测试模式所不能发现的，有效地提升了产品质量，应用成效如图20、图21和表1所示。发现的问题主要有2类：1)在有限的时间内可以做更多的分析，即通过交叉式分析可以达到比原模式指数级增加的分析量，从而发现人工未识别到的异常数据；2)在有限的时间内可以设置更多的场景，即针对变更人工设计的用例未覆盖全，具有自动化后可以将原有的用例快速执行从而发现不足。

图20 自动化测试对缺陷抑制的作用

图21 自动化测试对测试执行效率的提升

表1 自动化测试对测试分析量的提升

3 结束语

本文基于适航DO-178C要求的需求完全覆盖的目标，针对FADEC软件的特点，从如何在软件全生命周期的过程中快速有效地完整验证，抑制问题泄漏为目的，研究自动化测试的相关技术，并设计整套测试流程。通过规格化测试规程和标准工作环境，提升协调工作能力；通过自动化执行技术的突破，提升执行的可重复性，从而保障回归测试的完整性；通过执行和分析的流程设计以及测试分析技术应用，极大地提升分析的全面性；通过建立需求到测试规程、测试规程到测试执行脚本、测试规程到测试分析脚本之间的层层追溯，通过工具化显形需求的覆盖状态。通过在发控软件项目上的应用也表明极大地提高了验证的完整性，具有很强的推广性和应用前景。