基于共性需求的软件通用自动化测试设计研究

左万娟，虞砺琨，王小丽，董 燕

(1.北京控制工程研究所，北京 100190；2.北京轩宇信息技术有限公司，北京 100190)

0 引 言

随着中国航天事业的高速发展，航天发射任务越来越密集，航天软件测试强度不断增大，作为软件质量和可靠性的重要保证手段，如何在提高测试效率的同时确保软件测试的充分性和有效性，成为航天软件测试的新课题。

自动化测试已经成为当前软件测试发展的趋势，可以有效地缩短测试时间和减少成本，同时也可减少手动产生的失误[1]。

测试用例设计是软件测试的核心、关键要素。测试用例自动生成是自动化测试的关键环节，也是当前的研究热点。目前，自动生成测试用例的设计方法主要有两种[2]：基于代码的测试用例设计方法和基于需求的测试用例设计方法。其中，基于代码的测试用例设计，其实质是基于路径覆盖或基于MC/DC覆盖，常用算法有遗传算法[3-4]、粒子群算法[5]、蚁群算法[6-7]、果蝇算法[8]等，但是，采用该方法生成的测试用例，只能判定代码是否被执行，至于软件实现是否满足需求是无法度量的[9]。而设计测试用例的关键在于准确理解客户的需求，只有围绕测试需求设计出来的测试用例才能真正地测试出该软件是否合格[10-11]。基于需求的测试，其实质是基于模型的测试[12-14]，首先需要对需求建模[15]、验证模型的正确性[16]，其方法本身对模型的要求很高，在航天软件有限的测试时间内，很难完成繁琐的建模工作，建模被认为是基于模型测试技术难以推广的最大障碍[17]。而且，基于需求建模的测试用例自动生成，很容易产生测试集爆炸的问题。

为了在提高测试效率的同时确保测试质量，通过对大量航天软件测试实践的研究，提出了一种基于共性需求的软件通用自动化测试方案，针对航天软件中的共性需求，开展通用自动化测试设计，并在航天软件测试实践中推广应用，从而为基于需求的自动化测试提供一条可持续发展的研究路线。

1 名词解释

对文中用到的名词解释如下：

测试设计：通过需求分析，设计和得到测试用例的过程，称为测试设计。

CAN：Controller Area Network，控制器局域网络。

仲裁场：CAN总线通讯格式中的特定字段，一般为数据帧的第一字节。

控制场：CAN总线通讯格式中的特定字段，一般为数据帧的第二字节。

帧序号：CAN总线通讯格式中的特定字段，一般为多帧数据帧的第三字节。

DLC长度：CAN总线通讯格式中的控制场的低4位。

2 通用测试设计方案

2.1 方案概述

通用测试设计方案分为两个阶段：前期一次性研发阶段、后期重复性测试应用阶段，如图1所示。

其中，前期研发阶段承担了90%以上的工作量，且这部分工作投入是一次性的。后期测试应用阶段仅需要完成简单的个性化配置，即可使用。

2.2 前期研发

(a)共性需求分析。

研究航天嵌入式软件需求，从众多软件需求中提炼出通用性强、适用范围广的共性需求，开展需求分析，确保需求分析的全面性、有效性。典型的航天嵌入式软件共性需求包括CAN总线通讯、1553通讯、AD采集、自检、三取二等等。

图1 通用测试设计方案

(b)通用测试设计。

针对共性需求分析，开展测试设计研究，形成通用性强、适用范围广、覆盖充分的通用测试设计。

(c)自动化测试工具研发需求。

针对通用测试设计，开展自动化测试工具研究，提出工具研发需求，利用工具实现测试用例和测试脚本的自动生成，支持一键测试。

(d)专家评审。

针对共性需求分析、通用测试设计、自动化测试工具研发需求，开展专家评审，根据评审意见完善前期研究成果，形成最优的共性需求分析、通用测试设计、工具研发需求。

(e)自动化测试工具研发。

根据自动化测试工具研发需求，开展自动化测试工具研发。

(f)自动化测试工具验收。

针对自动化测试工具，组织验收。通过验收的工具，方可提交后期测试应用。

2.3 测试应用

(a)工具配置。

在自动化测试工具默认配置的基础上，通过少量的手工配置，使其与特定被测件相匹配。

(b)一键测试。

一键生成测试用例、测试脚本，并支持一键测试。

3 通用测试设计说明

下面，以航天嵌入式软件常见的CAN总线通讯接口测试为例，对通用测试设计方案中的重点环节予以说明。

3.1 共性需求分析

3.1.1 选取分析

CAN总线是航天嵌入式软件常用总线之一，作为嵌入式软件对外输入输出的门户，其相关接口设计的正确性对航天器正常在轨运行起着至关重要的作用，因此，对CAN总线通讯接口测试提出了更高的要求。

根据各个航天器所承载任务的不同，CAN总线接口输入流种类繁多、通讯格式各有不同，导致CAN总线通讯接口设计分支复杂，进而导致CAN总线通讯接口测试需要涵盖的测试点多、测试复杂、测试脚本编辑量大，耗费工期较长。

通过对大量CAN总线通讯接口测试的研究发现，针对不同软件而言，尽管其CAN总线接口设计各有不同，但是，CAN总线通讯接口的测试方法、测试内容是基本相同的。然而，截至目前为止，针对CAN总线通讯接口测试，始终缺乏一定的测试规范。测试人员仅仅是依靠一些已经达成的共识或凭借个人经验开展测试需求分析和测试设计，导致测试设计过于依赖测试人员的经验，测试缺乏统一的规范和标准，时有人为错误的发生，使得测试有效性和全面性得不到有效的保证。

综合上述分析，将CAN总线通讯接口测试作为共性需求，通过通用测试设计的研究，加强其测试规范性，从而确保测试有效性，是非常必要的。

3.1.2 需求分析

通过对大量航天嵌入式软件的CAN总线接口设计的研究，CAN总线通讯接口的通用测试需求主要包含以下三个方面：

(a)合法/非法输入的校验与处理。

TR-JK-001：接收并校验CAN总线数据帧。校验内容包括：仲裁场、控制场、帧序号(针对多帧输入流，帧序号应从0开始连续计数)、LENGTH、TITLE、校验和。软件仅处理合法数据帧，非法数据帧不予处理。

(b)CANA、CANB总线的输入与处理。

TR-JK-002：针对CANA、CANB总线输入，软件均应按照TR-JK-001进行处理。

(c)应答输出的总线选取原则。

TR-JK-003：针对需要应答的输入，如果是CANA总线输入，则软件应从CANA总线输出应答；如果是CANB总线输入，则软件应从CANB总线输出应答。

3.2 通用测试设计

通过对大量航天嵌入式软件的CAN总线通讯接口测试的研究，CAN总线通讯接口测试的核心内容是确认总线上的数据传输是否符合接口控制文档(interface control document，ICD)的规定，对符合规定的合法输入流应予以正确的响应及处理，对不符合规定的非法输入流应予以屏蔽。因此，CAN总线通讯接口的通用测试设计应覆盖如下情况：

3.2.1 合法输入流的覆盖性测试

测试应覆盖所有的合法输入流，并将不同长度的输入流均作为独立的输入流，予以覆盖。

以数据块为例，输入流包含15、25、35三种不同长度的数据块，则测试应覆盖三种长度的数据块，而不能仅覆盖其中一种长度的数据块，从而确保测试覆盖性。

3.2.2 非法输入流的覆盖性测试

测试应覆盖所有的非法输入流，即，覆盖每个输入流的所有异常情况。

典型的非法输入情况包括：仲裁场错、控制场错、帧序号错、LENGTH错、TITLE错、校验和错。

3.2.3 多帧输入流的非法情况测试

相比单帧输入流，多帧输入流有一些特殊情况，需要在测试设计时，予以特别的关注。

(a)针对多帧输入流的仲裁场错、控制场错、帧序号错，应分别考虑首帧、尾帧、中间帧错误的故障模式。

(b)针对多帧输入流，应考虑多帧接收不完整的故障模式，包括未收到首帧、未收到中间帧、未收到尾帧、未收到后N帧(N<多帧的总帧数)的情况。并在该故障多帧输入流之后分别输入正确的单帧、多帧输入流，以考察该故障多帧对后续正确输入的影响。针对故障多帧，软件应不予处理；针对其后的正确的单帧或多帧输入，软件应正确处理。即，当前故障输入流，不能影响后续正确输入流的接收与处理。

(c)针对多帧输入流，应考虑首帧、尾帧、中间帧的DLC长度小于实际长度的情况。

3.2.4 合法、非法输入穿插测试

测试过程中，设置非法输入，执行格式非法指令测试，首先是为了验证软件对非法输入的屏蔽情况，即，软件不应响应非法输入；其次是为了验证软件对非法输入的处理是否会影响其后续对合法输入的正常响应处理。因此，应进行合法与非法输入的穿插测试。

3.2.5 CANA、CANB总线测试

针对CANA、CANB总线应分别设计并执行两套用例。

3.3 自动化测试工具研发需求

共性需求分析和通用测试设计研究，为CAN总线通讯接口通用测试奠定了夯实的基础，有效保证了CAN总线通讯接口测试的有效性和全面性。

为进一步提升效率，减轻测试人员工作量，避免因人为因素而引入的测试不充分问题，针对通用测试开展自动化测试工具研发，充分利用工具的高效性、固定性，是非常有必要的。

3.3.1 需求概述

通过少量的手工配置操作，使基于共性需求分析的通用测试设计与具体被测件相匹配，实现一键生成全部测试用例、测试脚本，支持一键测试，同时实现测试结果的自动比对。

3.3.2 具体需求

工具应支持如下配置：

(a)硬件屏蔽码。

硬件屏蔽码，用于CAN总线接口芯片自动屏蔽非法输入，由被测软件在CAN总线初始化时设置。设置内容示例如表1所示。

表1 CAN总线硬件屏蔽码初始化设置示例

该项配置，在工具自动生成非法输入时需使用，避免工具产生的非法输入被硬件屏蔽掉而导致软件中的合法性判断设计未经测试验证，从而确保软件中的判断分支可以执行，软件设计得到充分的验证。

(b)合法输入流。

工具支持测试人员编写或导入所有的合法输入流。输入流格式示例如表2和表3所示。

表2 单帧输入流格式示例

表3 多帧输入流格式示例

格式说明如下：

固定数字：相应合法输入流的相应字段，始终是固定值。

XX：相应输入流的相应字段，可以是随机值。

SUM：相应输入流的相应字段，为校验和，由工具根据指定的校验规则自动生成，默认为TITLE和“XX”字段的字节累加和。工具支持可配置修改。

INDEX：帧序号。

(c)非法输入流。

非法输入流由工具在合法输入流基础上，按照配置覆盖的非法输入情况，自动生成。其中，所有默认配置，均支持手工修改。

针对所有输入流，默认非法情况包括：仲裁场错、控制场错、帧序号错、LENGTH错、TITLE错、校验和错。

针对所有字节均为固定数字的单帧输入流，默认非法情况包括：任意字节错误。

针对多帧输入流的仲裁场错、控制场错、帧序号错，默认非法情况包括：首帧、中间帧、尾帧错误。(即，仲裁场错可配置出3种非法输入，控制场错、帧序号错也一样)

针对多帧输入流的丢帧错误，默认非法情况包括：首帧丢失、中间帧丢失、尾帧丢失、后续帧丢失。

针对多帧输入流的DLC错，默认非法情况包括：首帧、尾帧、中间帧的DLC长度小于实际长度的情况。

(d)错误值生成原则。

针对仲裁场错，工具自动生成的错误值应能通过硬件屏蔽(即，确保该故障输入不被硬件自动屏蔽掉)、且不能与所有输入流的合法仲裁场值相同。

针对其余字节错，无特殊限制。

(e)输入间隔。

可由测试人员配置输入间隔，默认间隔5 s。

(f)用例生成原则。

用例生成时，自动实现合法/非法输入流的穿插。

3.3.3 自动比对需求

针对固定搭配的输入与应答，工具提供可配置接口，并在测试执行时，自动进行结果比对。

另外，输入与输出总线的匹配性，由工具进行自动比对确认。

3.4 专家评审

为确保前期一次性研发工作的有效性，需要组织专家集体评审，重点对以下环节予以确认：

(a)共性需求的通用性。

共性需求的通用性，是通用测试设计可以推广使用的前提条件。通用性不足，将导致后期无法推广使用，从而导致前期研发投入的浪费。

(b)需求分析的充分性和正确性。

需求分析的充分性和正确性，是确保软件测试充分性和有效性的前提。通过专家评审的方式，修正不合理的需求、补充不完善的需求，是很有必要的。

(c)用例设计的全面性和有效性。

用例设计的全面性和有效性，是确保软件测试充分性和有效性的核心。通用测试设计不到位，将引发批次性的不良后果。

(d)工具需求的完备性和易用性。

工具需求的完备性和易用性，是软件测试充分性和高效性的有力保障。

4 应用分析

文中所提出的基于共性需求的航天嵌入式软件通用测试方案，已在空间飞行器软件检测站全面推广应用。

4.1 应用前后的工作量对比分析

应用前和应用后的测试人员承担工作的对比分析如表4所示。

表4 应用前后测试工作量对比分析

注：“-”表示测试人员无需承担相应的工作。

可见，通用测试方案应用后，测试人员承担工作量得到了大幅减少。

4.2 应用后的优势分析

通用测试方案应用后，有如下优势：

(a)实现了共性需求测试的规范化、标准化，解决了部分测试人员经验不足的问题，有效提升并保证了全员的测试质量。

(b)通过工具自动化，有效避免人为原因带来的各种不确定因素，减少人为因素导致的测试缺陷，确保测试有效性。

(c)测试人员工作量大幅减少，有效提升了测试效率，缩短测试周期，降低测试成本。

(d)测试设计经过专家评审，相比完全自动化的测试设计，其有效性和全面性得以更好地保证，有利于充分暴露软件潜在设计缺陷，且测试覆盖率得以保证。

(e)实现了基于需求的测试自动化，相比面向路径覆盖的测试自动化，测试效果更佳。

(f)通过共性需求提取和通用测试设计，满足不同航天器的测试要求，推动航天软件测试向着通用化和标准化的方向发展。

4.3 应用效果说明

基于共性需求分析的通用测试方案推广应用后，以CAN总线通讯接口测试为例，取得了如下成效：

(a)CAN总线通讯接口测试的耗时由之前的1～2周缩短至1～2天。

(b)CAN总线通讯接口设计的测试覆盖率达到95%以上。

(c)CAN总线通讯接口正常/异常处理相关缺陷，均能有效检出。

5 结束语

自动化测试是软件测试未来的发展方向[18-19]，航天软件的自动化测试，更是势在必行。从工程实践的角度，基于需求的自动化测试，对软件的验证更加充分，建议作为优选方案。

文中的研究成果，为基于需求的自动化测试提供了一条可持续发展的研究路线。通过共性需求提取、分析以及针对共性需求的通用测试设计，逐步推动航天软件测试向着通用化和标准化的方向发展，再辅以工具自动化手段，最终实现测试质量和测试效率的双赢。该方案可作为共性化需求的测试优选方案。

针对基于需求建模的测试用例自动生成，应着力加强对需求建模工具的研究。只有解决了需求建模的便利性问题，才能真正推动该项技术在工程实践中的应用。该方案可作为个性化需求的测试优选方案。

另外，在测试结果自动判读方面，尤其是通用化的基于智能判读算法的复杂判断[20]，也应加强研究投入。

总之，针对航天嵌入式软件的自动化测试，不应拘泥于某一种方案，应该结合软件自身特点，综合各种方案的优点，通过优势互补、取长补短，实现测试质量和效率的共同提升。