规范化嵌入式软件自测试方法

王 泉

（中国航空西安软件测评中心，陕西 西安710068）

0 引 言

随着嵌入式软件工程化要求的日趋严格，嵌入式软件测试工作日益受到重视，引发了众多测评机构对其进行研究［1－4］。但在嵌入式软件自测试方面，由于各单位本身对测试级别和测试类型的要求差异，尚未形成一种完全规范的覆盖全部测试级别的自测试流程和方法，尤其是在静态分析和部件测试方面要求和方法各异。限于多数嵌入式型号软件测试周期较紧的情况，大多采用相对简单的静态分析和一次集成的部件测试方法。本文作者旨在提出一种包括文档审查、静态分析、代码审查、动态单元测试、部件测试和配置项测试的规范化自测试方法，使嵌入式软件自测试阶段能及早并尽可能多的发现并消除软件问题，提高嵌入式软件质量。

1 嵌入式软件特点及测试要求

本文从单位嵌入式软件的开发现行特点出发，建立一种满足型号自测试要求、级别全面的自测试模型，尽可能在不同阶段发现并消除软件缺陷。某嵌入式软件包含系统软件、通信软件等二十余个软件配置项，软件具有以下特点：

（1）软件文档编制种类不统一、文档内容不够精准：型号总体单位要求所有的软件相关文档均要遵循GJB438B文档编写要求，但由于本单位软件配置项众多，不同的开发人员对军标的理解、文档编写的侧重点、编写粒度均不同，同时部分软件配置项还包含多个模块，除软件配置项应出具的文档外、各模块出具的配套文档种类繁多，类型和数量不统一。

（2）开发环境多样化：软件配置项有二十余个，涉及的嵌入式开发环境多样化，如Tornado2.2、Tornado2.2.1、WorkBench2.6、Xilinx EDK9.1等。

其次，该嵌入式软件自测试工作含以下测试要求：①软件需满足型号编码规则要求：型号总体单位制订了软件编码规范，要求各开发单位的编码均要符合该规范要求；②测试级别要求全面：某型号软件二十余个配置项的关键性等级均为B级，必须开展单元级、部件级、配置项级的测试，且单元测试需涵盖静态分析、代码审查、动态单元测试。

针对软件特点及测试要求，为提高软件自测试效率及质量，本文提出了一种集软件文档审查、静态分析和编码规则检查、代码审查、动态单元测试、部件测试、配置项测试在内的规范化自测试模型，力求分阶段发现软件问题，提高自测试质量及效率。规范化自测试模型图见图1。

图1 规范化自测试模型

该模型具有以下特点：

测试前期审查严格：为提高自测试准确性和高效性，测试方严把入口关，首先对软件文档进行工程化审查，为满足定型测评要求，明确了审查范围为型号总体规定的全套文档。对于部分配置项存在多个模块且模块级需提交的文档未规定的问题，考虑到软件研制任务书、软件需求规格说明、软件概要设计说明和软件详细设计说明文档的质量与软件开发及测试质量息息相关，上层文档存在的错误会导致错误的不断传递与放大，造成测试过程的代价大幅提升，如图2所示。故文档工程化审查人员统一了模块级别的提交文档为软件测试的最小集，即软件研制任务书、软件需求规格说明、软件概要设计、软件详细设计；针对文档编制不够细致精准、对军标理解不一致、文档编写侧重点不一致的特性，给出了上述四类文档的通用模板；针对这四类文档进行了多轮重点审查，以保证软件自测试必需的文档描述和依据全面、准确、无误，尽量减少因文档的不完善造成测试无法正常进行或增加测试迭代的次数。

同时，测试人员对程序是否符合型号编码规则和是否满足型号软件工程化大纲要求等方面进行了静态分析，最终生成静态分析报告，详细报告了软件不符合编码规则和圈复杂度、注释率、行数、扇出数等不符合型号软件工程化大纲要求的问题，便于开发人员及早对此类问题进行修改。

2 测试关键技术

2.1 可定制编码规则的静态分析

程序静态分析是指在不运行代码的方式下，通过词法分析、语法分析、控制流分析等技术对程序代码进行扫描，验证代码是否满足规范性、安全性、可靠性、可维护性等指标的一种代码分析，作为动态测试的补充在程序运行前尽可能多地发现其中隐含的错误，提高程序的可靠性和健壮性。静态分析作为软件工程的一个热点，已有众多的研究和产品，如Parasoft、LDRA等。

某型号软件自测试静态分析需完成三方面工作：一是进行软件的基本静态分析、复杂度分析、静态数据流分析、交叉索引分析、信息流分析和数据对象分析等，消除软件的大量低级错误；二是验证软件是否满足型号工程化大纲中对软件编码的代码行数、注释率、圈复杂度、模块扇出数等要求，三是验证软件是否满足型号编码规范的要求。故本项目必须选择具有检查代码规范性功能的静态分析工具，同时工具支持对规范的定制和补充。

LDRA TestBed作为常用静态分析工具之一，满足上述要求［5］，尤其是其在编码规则的修改和定制功能恰好能最优满足本项目要求。测试者使用LDRA TestBed测试工具，对成熟的软件GJB5369编程规则进行裁减、定制和补充，建立最终编码规则集，其组成关系如图3所示 （首先定制92条型号强制规则与TestBed支持GJB5369的所有138条规则中完全相同的规则，然后加入TestBed测试工具根据型号编码标准定制的若干补充规则，形成最终编码规则集），通过自动化逐行扫描程序代码，从中查找是否存在与事先构建好的规则模式相匹配的代码，如果发现相匹配的代码，则报告相应错误并判断代码是否违反所制定的编码规则，最终以文本报告的方式详细报告编码规则，定位代码中违反编码规范的地方。

该静态分析方法无需依赖程序的开发编译环境，结合了词法分析、语法分析和语义分析，对软件进行了全代码覆盖的分析，验证了软件与编码规则的符合程度，消除了软件的大量低级错误，且大幅度降低了测试后续阶段消除软件瑕疵的成本。

图3 最终编码规则集组成

2.2 基于宿主机的动态单元测试

单元测试主要检查各程序单元是否正确实现了软件详细设计文档规定的功能、性能、接口和其他设计约束要求，发现函数单元可能存在的错误。针对嵌入式软件的单元测试，各软件开发单位或测评机构方法各异［6－8］。

动态单元测试主要依据软件的设计文档，借助商用软件测试工具，利用等价类划分和边界值分析技术，设计完全覆盖软件设计需求的单元测试用例，对软件的每个单元进行测试，根据测试用例执行结果是否满足预期及软件结构覆盖率情况，发现类似设计遗漏、功能未实现、冗余代码等软件缺陷。

目前专业的测试工具很多，如Compuware公司的Dev－Partner、Rational公司的Purify、C＋＋ Test、CuttleITE和 Attol、IBM Rational Test RealTime［9］等。本文仍使用TestBed／Tbrun专业测试工具。该工具具有以下两大优势［10］：

（1）实时显示测试覆盖率，提供调整测试方案和优化软件测试的必要信息；

（2）自动生成单元／模块测试驱动、桩模块，提高软件测试效率与可靠性；

嵌入式软件测试环境分为基于目标机的测试环境和基于宿主机的测试环境。对于开发环境多样化的嵌入式软件，需选择基于宿主机的单元测试环境，重点对程序逻辑进行测试、尽量消除与硬件的相关性。在宿主机环境中的测试消耗时间通常相对较少，用调试工具可以很快地完成调试和辅助完成测试任务，而与定时、时序、中断、硬件接口等相关的测试重点在配置项测试验证。

使用TestBed／Tbrun的基于宿主机的动态单元测试流程如图4所示。

图4 基于宿主机环境的动态单元测试流程

测试人员设计好测试用例，完成代码的静态分析、代码插装和动态分析后，使用宿主机环境对测试用例及插装后的代码进行编译链接和执行，生成测试结果文件和代码覆盖率文件，最终再经过TestBed形成单元级别的测试报告文件。宿主机环境应尽可能与开发环境相同，主流的开发环境如Tornado2.0、Tornado2.2、WorkBench均可通过TestBed自带的测试配置工具Tbconfig完成不同开发环境的配置，某些特殊的开发环境在不影响单元逻辑测试要求和测试结果的前提下，将其移植到可配置的开发环境下完成单元测试。借助TestBed测试工具，测试人员可着重设计测试用例、提高测试用例质量，从而更有效的发现软件缺陷。

2.3 部分增量的部件测试

部件测试的目的是把已通过单元测试的单元集合起来，构造一个在概要设计中所描述的程序部件，通过测试发现与接口有关的程序结构、模块调用、模块接口方面的问题。部件测试策略一般分为增量式和非增量式两种［11］，二者的优缺点对比如表1所示。

表1 增量式与非增量式部件测试策略对比

对比表明，增量式部件具有较好的测试效果，但相对测试过程较复杂，耗时较长。以往的针对嵌入式软件的集成测试虽有一定的研究［12，13］，但尚未形成统一规范的测试方法。针对嵌入式软件最底层调用的大量函数为硬件读写、访问、打印语句等系统函数的特点，本文采取了一种部分增量的部件测试方法，其具体策略为：首先分析每个部件的入口函数与所有调用函数之间的调用层次关系；然后将调用层次关系树中从最底层叶子节点开始向上延伸三层（含最底层叶子节点）的所有函数单元一次组装进行子部件测试，然后采用自底向上的方法逐层向上组装直至到达整个部件的根结点的下一层，若从最底层叶子节点到根结点的下一层少于3层，则按实际层数一次组装进行测试；对整个模块进行部件测试时，如果各子部件之间有数据依赖关系，则按照部件真实调用子部件的顺序，采用子部件增量递加的方法逐个集成各子部件。图5给出了根据某部件层次调用关系划分的子部件和增量递加部件的示例图，其中A调用B、C、D的先后顺序为调用B→调用C→调用D。

图5 基于部分增量方法的部件划分

使用部分增量的部件测试方法首先由于将底三层函数单元一次集成，因底层程序调用关系较简单、不易发生错误，选用该方法可简化部件测试过程、减少部分测试时间；其次整体部件的第一、二层采用子部件增量递加的方法，便于发现部件按顺序依次调用时隐藏的影响程序结构或接口的错误。

2.4 基于故障注入的配置项测试

配置项测试依据软件需求规格文档进行测试需求分析、测试设计、测试实现和测试执行，完成软件的功能、性能、接口、强度、余量等测试，并重点关注了软件在异常状态和边界状态下的响应和处理，以及用于提高软件可靠性和安全性的措施的有效性。针对嵌入式软件特性，配置项测试主要采用了故障注入技术：

（1）硬件故障：通过下电、拔除等方式注入部分硬件模块故障，验证软件的相关自检及处理是否正确；

（2）程序插装法模拟注入硬件故障：对于CPU、NVRAM等硬件设备的计算故障或设备故障，由于无法直接造成硬件故障，而相关的故障检测及上报又为嵌入式软件的重要功能，故采用程序插装方法模拟注入此类故障，验证软件的故障检测及上报功能的正确性；

（3）数据故障：某型号软件配置项数量大，涉及的外部接口种类和数量众多，在接口测试中除正常接口通信验证外，重点通过模拟接口数据的包头、校验位、数据长度等数据故障来验证软件的接口处理是否正确。

3 测试效果分析

由于测试前期文档工程化审查、编码规则符合性、静态分析的有效开展，提高了文档编制的准确性，细化了需求颗粒度，便于配置项测试的开展，极大减少了后期测试工作时与开发方的冗余沟通时间，大幅提高了测试效率。传统自测试流程与本文自测试流程的测试各项工作比例对比见图6。

由于测试过程涵盖了静态分析、代码审查、动态单元测试、部件测试、配置项测试等多个测试级别及其不同测试方法，便于在不同的级别测试中发现不同的软件缺陷，不同阶段发现软件问题数目的比例图见图7。

由图7可看出，大量的不符合编程规范或程序低级错误均在静态分析或代码审查中发现，动态单元测试、部件测试及配置项测试的问题缺陷比例已相对较小，符合测试尽可能早的发现问题的初衷。

图6 传统自测试流程与本文自测试流程各项工作比例对比

图7 不同测试阶段发现软件缺陷比例

4 结束语

某型号项目自测试工作采用规范化的流程与适当的方法，有效发现了软件缺陷，提高了软件质量。在测试过程中，本文作者针对测试工作中仍存在的可改进部分及今后的型号软件自测试工作如何更有效的开展进行了深入的思考和总结，主要包括以下几方面内容：

由于不同型号编码规则不完全相同，目前任何成熟的软件静态分析工具都无法提供能够包含全部编码规则的编码规则全集，如何进一步扩展静态分析工具的功能使之能定制出可不断添加新规则的通用编码规则集，并获得军用软件权威部门的认可，仍是软件静态分析拭待解决的问题。

本文中基于宿主机的动态单元环境可对主流的嵌入式软件开发环境进行相关测试配置，但随着嵌入式软件计算机语言的种类增多，如何开发出适用各种开发环境的通用单元测试宿主机环境，是单元测试研究的重要方向。

测试前期软件文档工程化审查工作的有效开展，大幅提升了测试效率，后续的型号软件开发与研制过程中，一方面应在项目开展早期及时开展需求评审，使测试人员真正有效的参与需求评审，减少文档错误造成开发过程中错误的不断传递放大，另一方面应切实有效的做好软件文档工程化审查工作，提高文档编制的准确性和一致性，提高测试效率。

［1］LV Quanhe.Embedded software measurement ［J］.Software Guide，2010 （9）：40－41 （in Chinese）.［吕全和.嵌入式软件测试 ［J］.软件导刊，2010 （9）：40－41.］

［2］QIN Chunyan，YAO Zhuting.Study on embedded system software measurement ［J］.Mechanical Management and Development，2008，23 （3）：183－184 （in Chinese）.［秦春燕，姚竹.嵌入式系统软件测试的研究 ［J］.机械管理开发，2008，23（3）：183－184.］

［3］ZHAO Xiaolan.Analysis of standard software test process ［J］.Aerospace Control，2010 （1）：98－100［赵晓岚.规范化软件测试过程浅析 ［J］.航天控制，2010 （1）：98－100.］

［4］HU Rongxiang.Embedded software testing ［J］.CHINA Computer＆Communicaton，2010 （7）：79 （in Chinese）.［胡 荣祥.试论嵌入式软件测试 ［J］.信息与电脑，2010（7）：79.］

［5］JI Peigang.Research of program static analysis ［D］.Lanzhou：Lanzhou University，2006 （in Chinese）.［冀佩刚.程序静态分析研究 ［D］.兰州：兰州大学，2006.］

［6］HU Dan，DU Xinhua.Methods and practice of embedded software unit testing on a target machine ［J］.Electronic Measurement Technology，2006 （2）：33－35 （in Chinese）.［胡丹，杜新华.基于目标机的嵌入式软件单元测试 ［J］.电子测量技术，2006 （2）：33－35.］

［7］CAO Xiaoyong，LIU Xi.Application of coverage testing tool in embedded software testing ［J］.Electronics Quality，2009（12）：21－23 （in Chinese）.［曹晓勇，刘希.嵌入式软件覆盖测试的研究与应用 ［J］.电子质量，2009 （12）：21－23.］

［8］CHEN Lirong，XIONG Guangze.The covering test of embedded software ［J］.Microcontroller ＆ Embedded System，2007（7）：8－11 （in Chinese）.［陈丽蓉，熊光泽.嵌入式软件的覆盖测试 ［J］.单片机与嵌入式系统应用，2007 （7）：8－11.］

［9］JIANG Long，WANG Dongxing.Using IBM rational test Real－Time to realize embedded software test ［J］.Computer Study，2010 （3）：139－140 （in Chinese）.［姜龙，王冬星.使用IBM Rational Test Realtime进行嵌入式软件测试 ［J］.电脑学习，2010 （3）：139－140.］

［10］WANG Yu，HE Yongjun，Testbed／Tbrun used in embedded software unit testing ［J］.Acoustics and Electronics Engineering，2006 （4）：36－37 （in Chinese）.［王煜，何永军.Testbed／Tbrun应用于嵌入式软件单元测试 ［J］.声学与电子工程，2006 （4）：36－37.］

［11］The Art of software TESTING ［M］.2nd ed.Beijing：China Machine Press，2006 （in Chinese）.［机械工业出版社.软件测试的艺术 ［M］.北京：机械工业出版社，2006.］

［12］ZHANG Yanmei，JIANG Shujuan.An approach for class integration testing based on dynamic dependency relations ［J］.Chinese Journal of Computers，2011，34 （6）：1075－1089 （in Chinese）.［张艳梅，姜淑娟.一种基于动态依赖关系的类集成测试方法 ［J］.计算机学报，2011，34 （6）：1075－1089.］

［13］GAO Jing，LAN Yuqing.Approach to choose integration testing combination for foundational software platform ［J］.Journal of Beijing University of Aeronautics and Astronautics，2010（3）：16－20 （in Chinese）.［高静，兰雨晴.基础软件平台集成测试组合选择方法 ［J］.北京航空航天大学学报，2010（3）：16－20.］