机载航电软件配置项测试

文/朱文钊

（中国直升机设计研究所 江西省景德镇市 333001）

1 引言

嵌入式软件具有“高实时性”、“开发和测试环境专门化”等特点，有别于运行于Windows上的软件，嵌入式软件在运行中对操作者是“不可见”的，由于嵌入式软件的这种特殊性，导致针对它的测试与普通的软件测试有着很大的不同。在测试过程中测试者要设法将软件运行的轨迹和动作以字符串的形式输出到系统之外，供测试者或者测试系统观测和分析[1]。传统上，嵌入式软件开发流程一般为需求分析、处理流程与数据流的分析、设计系统结构、定义软件间接口、软件设计与实现、单元测试、配置项测试、集成测试以及系统测试[2]。其中配置项测试主要针对软件功能的实现的测试和验证[3]。

软件配置项是一组能独立编译、运行和管理并能满足用户最终需求的软件集合，具有独立的功能、性能、接口和人机界面等软件特性[4]，因此在进行配置项测试时需选取多种测试类型进行验证。

2 航电软件特性

航电软件是直升机机载软件中负责显示飞机飞行状态、与超短波电台、导航等设备进行信息交互，与驾驶员进行交互并且驻留在任务机的软件。软件架构为嵌入式系统架构。要求实时性较高。对于飞机的飞行姿态、高度信息、设备情况等信息的显示要及时迅速可靠。航电软件按照功能的不同，基本分为多功能显示器显示软件和飞行操作软件两类，它们共同完成机载航电软件的工作任务。多功能显示器显示软件侧重于信息的显示，而飞行操作软件侧重于控制类功能的实现。在对这两个软件进行测试时，要着重注意它们之间的区别。

3 配置项测试

目前直升机机载软件一般为嵌入式软件，工作环境为VxWorks，对系统延时的要求高，与硬件平台结合紧密。在对其进行配置项测试时不仅需要考虑功能上的实现，还需要对其相关性能进行考察。

白盒测试在测试过程中测试者可以看到被测的源程序,根据其内部结构设计测试用例。而黑盒测试在测试过程中测试者完全不考虑程序内部结构和内部特征,根据需求规格说明来设计测试用例。配置项测试并不是完全的黑盒测试，需要结合接口协议等文档来完成测试用例的设计,配置项测试对白盒测试和黑盒测试进行了有效的结合，进行了所谓的“灰盒测试”，使得测试更为完善。

在配置项测试开始前，应对需求规格说明及其他相关文档进行文档审查工作,特别是项目时间较为紧急的情况下，文档中经常存在各文档间说法不一致等问题，在进行文档审查时需特别注意。测试项目负责人以需求规格说明为准绳，将整体软件需求分解。一般而言，可以将需求规格说明中的需求划分为数据控制相关、显示控制相关、性能测试等几部分。这样划分的好处是数据控制相关的需求与接口协议关系较为密切,而显示控制相关的需求则偏向于设备的画面切换等，这样测试人员在编写测试用例时就有了侧重点。划分后的测试项与需求中的每一项都要保一一对应关系,以满足测试需求的全覆蓋。

3.1 航电软件测试用例的设计

在软件测试的多个阶段，测试人员根据需求规格说明等文档设计出大量的测试用例来满足测试覆盖率的要求。在测试过程中会发现存在用例未覆盖到的需求，而且还需要对软件进行回归测试，软件测试用例集的规模变得越来越大。在编写测试用例时，并没有清晰明确的方法来指导测试人员对测试用例的编写。因此编写出的用例有时会不满足需求的100%覆盖，有时却会增加冗余的测试用例，导致时间和成本的浪费。在软件测试过程中，用户需求时有变更，在频繁的需求变更和软件回归测试过程中，也会产生大量的测试用例，很多的测试用例由于对需求点的理解不充分而导致冗余,影响测试执行的有效性。当用户的某些需求发生变更时，则需要对需求的变更进行影响性分析，编写新的测试用例，以替换受到影响的测试需求和对应用例。

测试用例编写者拿到测试计划后，找到由自己负责的那一部分需求，根据需求说明、软件的接口协议书等相关文档，编写测试用例。设计测试用例时要充分考虑每一条测试需求的输入、输出及二者间的关系,在测试用例中设计满足条件或不满足条件的测试输入，以验证软件的设计是否满足需求。

编写测试用例中的功能测试时要依据需求规格说明,并参照相关设备的接口协议，明确在实现相应功能时数据的发送和接收是否也保持一致。关于边界测试的用例编写,比如某类温度值区间为0°C ～100°C,画面的显示精度为0.1°C，那么对于0°处的测试用例,应当考虑-0.1°/0°/0.1 °这三个值进行测试。如果是接口中的数据，那么可以考虑使用边界值±一个LSB值（某个参数数据最低有效位的权值）来进行测试。

由于测试环境的不具备或处于对人员、设备安全等方面的考虑，某些测试用例可能无法执行，此时可以采用代码走查的方式进行验证。如果在设计测试用例时发现存在需求无法进行测试,那么需要提供对该需求的后续测试方法或处理意见。编写的测试用例达到需求全覆盖后也可以再次进行约减。很多直升机的型号是由军转民,若存在之前相似型号项目的经验,则可以考虑测试用例的复用，用以减少重复工作。

3.2 保证对需求的全覆盖

设计测试用例时,当需求表述为文字时可以采用提取关键词的办法。每条需求中都包含若干个关键字，每个关键词都有若干个状态,提取这些状态积的集合，即达成需求的全覆盖。若需求是公式的形式表述，则将公式中的每一个变量作为一个关键词。关键词的状态积见图1所示。W1、W2、W3为原始需求。其中W2和W3需求可以进一步拆解细化为W21、W22、W23和W31、W32、W33子需求。经过梳理，可以得到子需求列表W1-W21-W31、W1-W21-W32、W1-W21-W33、W1-W22-W32、W1-W23-W32，通过这5条子需求就能写出相应的测试用例，从而得到完整的需求追踪矩阵。原本复杂的需求经过状态积的拆解，分解成为若干个简易明了的需求状态积，此时可以按照拆解出的需求状态积进行测试。使得测试过程结构清晰，易于追踪。

如某型机的机裁软件需求规格说明中描述了电台和任务机的握手流程。驾驶员执行数据加载握手操作，任务机向超短波电台发送数据加载握手指令，超短波电台收到握手指令后回复是否准备好数据加载。从中可以提取“任务机向超短波电台发送数据加载指令”和"超短波电台回复是否淮备好"两个关键词句，其中第二句有两种形式分别为"电台回复已准备好”、“电台回复尚未淮备好”及“电台无应答''，由此可以编写出三个测试用例。

但是随着测试的深入，当遇到复杂任务流程时，分解得出的状态积也会膨胀，导致得出的测试用例集也随之膨胀，影响测试效果和效率。在这种情况下，测试人员应当适当的对拿到的需求状态积进行筛选，剔除一些不必要的选项，精化测试用例集，以便降低测试人员的工作强度。

表1：测试用例执行单表头

表2：配置项测试问题列表

图1：多个关键词的状态积

在拿到需求后对需求进行分解时可以使用思维导图来帮助测试人员设计测试用例，首先使用思维导图对需求进行拆解，形成条目化的需求，然后在每一条需求后面都设计相应的测试用例，这样形成的测试用例集就比较的完整清晰。在实际使用中，由于测试用例的格式较多，我们在实际操作中可以仅挑选其中关键的部分作为测试用例的描述来追踪相应的需求，这样后期使用自动化的工具可以直接将简略的思维导图格式的测试用例转化为测试用例集的形式，节约了测试人员的时间。注意到测试用例中关键条目为测试描述、测试步骤、预期结果。当我们在思维导图中每条需求后对应的测试用例都按照这些条目填入相应的内容后，即可使用工具将这些简略的测试用例转换为合乎规格的测试用例集。

3.3 编写测试用例执行单

随着测试工作经验的积累，测试人员会发现软件测试用例表在实际测试中实用度不高，在执行完测试用例后需要花费很长一部分时间用于填写测试用例表，因此在测试时可以考虑采取测试用例执行单的形式，将测试用例形成Excel表格，见表1，测试人员在测试用例执行单上设计测试用例时，主要填写测试说明、用例描述、测试步骤和预期结果四栏[5]。这样在编写测试用例时可以着重关注对需求的覆盖和如何设计用例以暴露问题，而不必将太多时间花在格式上，在全部的测试用例执行完成后，将其余栏目内容补全，再由自动化工具将用例执行单转换为测试用例表以存档和复用。表1为一般测试用例执行单的表头部分。

在测试用例的执行过程中，由于机载软件的特殊性，需要交替使用真实设备和仿真器来进行测试，这是由于很多机载设备的故障是无法通过真实设备来实现，只能在仿真器中作相应的设置来模拟故障信息，或者使用真实设备模拟某些状态的效费比不高。如果需要使用仿真软件，则需要额外说明仿真的输入和输出与真实设备具有同样的使用效果。当测试用例执行单设计完成后，测试人员应当确认测试环境已经准备充分。则可以按照测试用例执行单执行相应的测试用例，以开展测试工作。

3.4 填写配置项测试问题记录单

在测试过程中发现的问题记录在配置项测试问题列表上（表2）。在测试现场可以简略记录，待时间充裕时再行整理。当配置项测试用例执行工作完成时，存在未执行的用例，则需说明未执行的原因和处理意见。

在测试过程中发现的问题经由软件开发方的确认后将相应问题归零，如有对软件的改动则需要进行影响性分析，并编写回归测试用例，供回归测试时使用。

对于通过执行配置项测试发现的问题的处理方式，有下面的几种处理方式的分类。新建：一个问题由测试人员发现并提交，我们将状态标注为新建；开发人员接收了该问题，将问题的状态修改为已分配（Assigned）表示已认可；如果开发人员对于问题不认可，开发人员的解释得到我们的认可，那么我们将问题的状态标注为关闭；开发人员解决了该问题后，就将该问题的状态修改为解决，并发给测试人员进行回归测试；测试人员对问题进行回归测试后，如果问题已经解决，则问题的状态修改为关闭，否则的话则发给开发人员重新修改。如果以前版本已经关闭的问题，在新版本中重新出现，那么其状态应修改为重新打开。

3.5 编写测试计划、测试说明和测试报告

前面已经提到在配置项测试开始前需对照相应需求文档编写测试计划，整个测试过程根据测试计划来进行。测试计划是整个测试过程的策划，是需要在测试过程开展前完成的，而在测试策划前期，我们将需求分解得出需求追踪矩阵，按照整个需求追踪矩阵，编写出相应的测试用例，形成测试用例集，这些工作是需要在前期完成的，而测试计划文档的编写可以在测试工作完成后在测试追踪矩阵和测试用例集等证据的基础上补完，以避免在测试过程中有变动的地方导致文档反复修改。

测试报告用以整个测试过程进行总结，测试说明侧重于对测试用例的描述。在配置项测试结束后，统计编写的测试用例情况，汇总集结成测试用例集，并编写测试说明和测试报告文档，在整个测试过程中，可以优先完成测试说明和测试报告中重点注意的证据材料，待测试完成后在这些证据的基础上补充完成文档的编写工作。

4 结束语

经过以上测试流程后，即完成了机载软件的配置项测试的工作。根据笔者多个型号的软件测试项目的经验，在整个软件测试的几个阶段中，往往在配置项测试这一环节能够暴露被测软件的诸多问题。这反映了在机载软件的开发过程中，开发人员常常为了追赶项目进度，只追求软件功能的有和无，而对代码质量不够重视。而软件测试人员的工作就在于此，通过我们的测试，找出软件潜在的缺陷，提高软件质量，增强软件的可靠性。