基于Tornado的嵌入式软件单元测试

王 泉

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

0 引 言

随着软件工程化的不断推进和用户对软件质量要求的日趋严格，软件测试作为软件质量保证的关键环节，正受到越来越多的重视。目前国内已产生通过GJB2725A资质认可的军用软件测评实验室，借助各自的测试技术和方法，开展各种级别的测试工作，发现并摒除软件缺陷，提升军用软件质量。

嵌入式软件通常为嵌入式系统中的关键部件，具有实时性强、开发工具昂贵、软硬件联系紧密、CPU种类繁多等特性。嵌入式软件的特性决定了嵌入式软件测试是软件测试的难点和重点，引发了众多测评机构对其进行研究［1－2］。软件单元测试是验证软件正确性的最基本测试类型，但针对嵌入式软件的单元测试，各软件开发单位或测评机构方法各异［3－5］，未形成一种统一规范的测评方法。

本文作者以某计算机系统嵌入式软件测试为原型项目，在以往单元测试方法的基础上，提出了一种基于Tornado开发环境的嵌入式软件单元测试方法。该方法借助Testbed自动测试工具及Tbconfig，基于Tornado编译环境进行动态单元测试，消除了测试环境造成的差异性；采用黑/白盒结合的隔离单元测试技术；使用TbrunReporter辅助工具定制测试报告模板，大幅提高了测试效率。该方法最终作为一种通用且规范性的嵌入式软件单元测试方法在所在测评机构加以推广使用。

1 单元测试基本理论

单元测试作为系统开发过程中要进行的最低级别的测试活动，集中对源代码实现的每一个程序单元进行测试，检查各程序单元是否正确实现了软件详细设计文档规定的功能、性能、接口和其他设计约束要求，发现函数单元可能存在的错误［6］。进行单元测试的必要性在于：①单元级测试易于发现程序错误与缺陷；②易于达到完全代码覆盖率；③减少软件测试费用与开发时间。

1.1 单元测试基本方法

单元测试的两种主要方法是黑盒测试和白盒测试。黑盒测试又称为数据驱动的测试，测试目标与程序内部机制和结构完全无关，而是将重点放在发现程序不按其规范正确运行的环境条件；白盒测试称为逻辑驱动的测试，它依赖于对程序细节的严密检验，针对特定条件设计测试用例，对程序的逻辑结构进行检查［7］。黑、白盒测试各有优缺点，在软件测试时需把两者结合起来应用。

1.2 单元测试模型

单元函数不能独立运行，需构造一个运行环境才能完成测试。单元测试模型如图1所示，由驱动函数、被测试单元函数和桩函数组成。

图1 单元测试环境组成框架

驱动函数是一个主函数，代替该单元的上级模块，其作用是将测试用例数据传送给被测单元、引导被测单元运行并保存运行结果；桩函数是一个构造子函数，是用来替代被测单元调用的子函数，模拟从属模块与被测单元的函数调用或消息交互功能。

2 基于Tornado开发环境的嵌入式软件单元测试方法

某嵌入式软件测试项目，硬件采用PowerPC755处理器，开发环境为Tornado2.2，软硬件联系紧密、软件单元众多、数据结构复杂，测试工作量巨大，时间节点要求紧。根据测试项目估算结果，如果按照通常的做法，很难在给定时间内完成测试。为能在保证测试工作质量的基础上按时完成测试项目，必须要统一规范测试流程，简化测试过程，采用成熟的测试用例设计技术，提高测试工作的效率。笔者结合嵌入式软件特点，提出了一种借助测试工具的规范化测试方法，优化了测试流程、采用了与开发环境和运行环境一致的编译和运行环境，大大的提高了单元测试工作效率，保证了测试项目在规定时间内完成，且发现了不少软件问题。

2.1 测试工具选择

为节省单元测试过程中人工编写测试驱动和桩模块的时间、使测试更加准确高效、并取得满意的覆盖率测试效果，需借助专业的测试工具。目前各测评机构使用不同的成熟测试工具（如CuttleITE［8］和Attol等）进行测试，同时也在积极探索开发自主测试工具［9－10］。本文选择了成熟的Testbed/Tbrun专业测试工具。该工具主要特性如下：

（1）分析软件内部程序流程和结构，帮助制定覆盖策略及设计测试用例；

（2）自动与被测软件的编译器相结合，对被测软件实施自动插装，并自动收集这些插装信息；

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

（4）自动完成测试过程，实时显示测试覆盖率，根据搜集的插装信息计算覆盖率，帮助测试人员找到未被覆盖的软件部位，提供调整测试方案和优化软件测试的必要信息。

借助Testbed测试工具，测试人员可将精力放在设计测试用例上，保证测试用例的完善性，进而提高测试质量和效率。

2.2 测试流程

基于Tornado开发环境的嵌入式软件单元测试方法测试流程为：利用等价类划分和边界值分析技术，采取黑/白盒结合的测试方法，依据设计文档和程序结构设计单元测试用例，在Tornado环境下对被测软件进行静态分析和源程序自动插装；生成、编译、执行测试驱动程序；分析预期输出与实际输出的一致性；获得被测单元执行完所有测试用例后的总覆盖率文件；根据测试用例执行结果确定测试是否满足预期及软件结构覆盖率情况，有效地发现软件缺陷，并最终编写单元测试报告。该测试方法流程图如图2所示。

2.3 测试特点

基于Tornado的嵌入式软件单元测试方法具有以下特点：

（1）有效利用已有的Tornado开发环境资源，减少了测试环境构造工作时间，同时消除了测试环境的差异性。

借助Testbed的单元测试中，测试人员为使用和调试的熟练便捷，通常会使用Testbed支持的基于主机的编译环境（如VC＋＋6.0）进行，这需耗费大量的时间对嵌入式软件被测单元源代码进行移植，使其在主机环境下顺利编译和运行，同时由于运行环境与目标环境存在差异，如某些数据类型定义不相同，会造成测试过程中产生非程序原因的错误。为保证测试结果的正确性，测试人员需在测试报告中分析测试环境的差异及其造成的影响。而基于Tornado的嵌入式软件单元测试方法借助Tbconfig辅助工具完成编译环境配置，使嵌入式软件单元测试的编译环境与软件开发环境完全一致，消除了运行环境差异造成的测试影响。

图2 基于Tornado开发环境的单元测试流程

（2）结合黑/白盒结合测试方法，大幅提高测试效率。

一般的单元测试仅采用白盒测试方法，根据程序的内部结构进行测试，侧重逻辑的路径，造成测试不充分和完善，而黑盒测试仅将重点放在发现程序不按其规范正确运行的环境条件。两种方法各有优缺点，基于Tornado的嵌入式软件单元测试方法选取将二者结合的测试方法，同时兼顾软件文档和程序内部结构，可使测试更加充分完善，获得较好的测试覆盖率。

同时，由于某嵌入式软件每个c文件包括大量程序单元，以往的单元测试常以函数单元为单位，进行代码编译和必要修改［11］后进行测试，产生众多冗余工作量。而基于Tornado的嵌入式软件单元测试以c文件为单位进行编译和代码的必要修改，减少了冗余工作量。

（3）借助辅助工具来完成测试文档编制工作，保证了测试报告的规范和客观，提升了测试质量和效率。

软件测试需要采集测试用例数据作为测试报告的附件，包括测试用例设计者、用例标识、测试目的、测试类型、测试输入和预期输出等信息，见表1。传统单元测试中往往使用手工的方式完成填写，当测试单元结构较复杂时，输入输出参数数量众多、结构繁杂，填写过程会耗费大量的人力和时间，且容易造成填写错误和因个人填写风格不统一造成的不规范。基于Tornado的嵌入式软件单元测试方法借助辅助工具，根据测试人员执行测试后记录测试信息的tcf文件，提取相关测试用例数据，自动生成单元测试报告附件，从而消除传统手工生成测试报告造成的不规范性、易错性和耗时性。

表1 单元测试用例一览表

2.4 测试关键步骤及实现

2.4.1 基于Tornado编译、运行环境的相关配置

要使用与实际开发环境相同的Tornado2.2编译环境顺利编译、执行嵌入式软件测试驱动程序，进行动态单元测试，需完成以下几个关键步骤：

（1）借助Tbconfig辅助工具完成编译环境配置。测试人员在安装完Tornado2.2编译环境的前提下运行Tbconfig软件，完成Testbed和Tornado的安装位置信息、主机信息，选择插装模板等基本配置。

（2）根据Tornado开发环境中工程的具体编译信息更改编译命令。直接Tornado默认的编译命令进行测试驱动程序的编译，会出现许多编译错误，需使用编辑工具更改TBrun for Workbench的编译命令文件vxsim＿build.bat，根据情况完成必要修改，定制适合于该嵌入式软件的编译指令使其完成正确编译。如去除－ansi使编译识别以“//”表示的单行注释、去除－wall使编译只保留错误信息、在编译命令结束处加入pause命令，以便编译完成后测试人员在暂停的编译界面窗口中查找编译错误。

（3）正确使用Tornado2.2的仿真模拟器。单元测试过程中无法及时提供测试运行所需的真正目标机及其操作系统，必须正确配置并开启仿真模拟器并将其作为虚拟目标机，将Testbed经过Tornado2.2编译链接后生成的测试驱动程序下载到仿真模拟器中运行，即相当于在真实的目标机及其操作系统中运行应用测试程序、产生测试结果。

2.4.2 黑/白盒结合的单元隔离测试方法

为使测试更加充分完善，本文采取黑/白盒结合的单元隔离测试方法，其实现方法为：

（1）采用黑/白盒结合的测试方法。测试人员需结合软件需求文档和程序内部结构信息两方面，设计测试用例，设置相关输入变量、桩函数、输出变量及其预期值，尽可能完成软件需求和设计文档中所有功能点的用例设计，设计完成后运行测试用例，获取测试结果和软件结构覆盖率信息。使用此方法弥补了黑盒或白盒单一测试方法的不足，在充分根据需求设计测试用例的同时获得较好的测试覆盖率信息。

（2）函数单元隔离测试，保证各单元测试独立性。函数单元隔离的原理为：在测试人员以c文件为单位完成静态分析、插装代码进入Tbrun、为该文件创建新的测试序列时，测试界面会列出隶属于该c文件的所有函数单元，同时Testbed会为该c文件下每个函数单元自动创建一个宏定义号（如单元宏定义号1、单元宏定义号2…单元宏定义号n），并在插装后的c文件代码中的每个函数单元前自动生成条件判断语句”＃if defined（单元宏定义n）”，但暂不定义这些宏定义号。只有在针对某个单元n进行单元测试，为该单元创建测试用例时，针对单元n的测试驱动程序才会立刻定义单元n的宏定义号“单元宏定义号n”。此方法使得针对单元n的测试驱动程序中，仅单元n前的条件判断语句为真，其余函数单元前的条件判断语句为假，即开放了需测试的函数单元n的源代码、屏蔽掉其余函数单元源代码。隔离软件单元界面如图3所示，被隔离的函数单元会被标记上“X”实现自动隔离。执行该c文件其它单元测试时，不需再进行代码静态分析和插装，只需针对其它单元新建测试序列完成测试即可。

图3 TBRUN的文件窗口

黑/白盒结合的单元隔离测试方法在充分结合程序和文档设计测试用例的同时，保证了每个单元测试的独立性，消除了各单元测试间的互扰，大幅提高了测试效率。

2.4.3 文档自动生成

本文采用一种自动化、规范化的方法来自动生成测试用例描述和测试报告，借助辅助工具TbrunReporter，其实现方法为：

（1）定制单元测试报告模板。由于不同的测评机构或项目要求采集的测试数据不同，报告模板也风格迥异。本文作者根据所在测评中心体系要求，裁剪所需采集的测试用例信息数据，更改和编制了表格布局和风格，最终完成了测试报告附件模板定制，其单页如图4所示。模板中内嵌的编程代码为TbrunReporter从包含测试信息的tcf文件中导出数据的设置代码，测试人员不可更改。

（2）完成测试信息的导入和自动化文档生成。测试人员在TBrunReporter主界面中设置作者姓名、选择Group批量导入测试用例执行信息文件（tcf文件）；在TCF设置界面中设置测试用例的起始编号、编号格式宽度，过程（函数）的起始编号、编号格式宽度等，TBrunReporter设置页面见图5。设置成功后，TBrunReporter可结合设置信息及从tcf文件中提取到的测试输入变量、输入初始化代码、桩函数设置、预期输出结果、实际测试结果等测试数据，按定制的测试报告模板自动化生成测试报告附件。

使用TBrunReporter和定制的测试报告模板自动生成测试报告，不仅大大提高单元测试报告文档编写的时间效率，也提高了文档编写的规范性和准确性。

3 测试效果分析

使用基于Tornado 2.2编译环境、黑/白盒结合的单元隔离测试方法和测试报告自动生成的嵌入式软件单元测试技术，既消除了测试编译环境不同造成的差异，又规范了测试流程和测试文档的生成。本文从各项测试工作分配比例和千行代码测试工作耗时两方面，将以往嵌入式软件未经规范的单元测试方法同基于Tornado开发环境的嵌入式软件单元测试方法进行了横向比较，比较结果如图6和图7所示。

由图6和图7可看出，基于开发环境的规范化单元测试方法已将测试重心转移到设计和执行测试用例上，使测试用例的设计更充分和完善，有效减少了代码移植和手动测试报告生成等冗余工作量。从测试效率方面分析，使千行代码的测试时间节省了22小时，测试效率提高了约23%。

4 结束语

专业的Testbed测试工具为嵌入式软件的单元测试提供了有力支持，合理使用测试工具和针对嵌入式软件的基于开发环境，形成规范化的嵌入式软件单元测试方法，是笔者在机载嵌入式软件测试的一次成功尝试。测试结果表明使用该方法极大提高了软件测试的规范性和高效性，使嵌入式软件单元设计和编码过程中的问题和缺陷得以暴露。该方法已作为本测评中心针对嵌入式软件进行单元测试的规范性方法加以培训和推广，旨在进一步提高测试技术能力和规范测试流程，更好地保障软件质量。

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

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

［3］HU Dan，DU Xin－hua.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.］

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

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

［6］飞思科技产品研发中心.Practical software testing method and application［M］.Beijing：Publishing House of Electronics Industry，2003：20－21（in Chinese）.［飞思科技产品研发中心.实用软件测试方法与应用［M］.北京：电子工业出版社，2003：20－21.］

［7］Glenford J Myers.The Art of Software Testing［M］.WANG Feng，CHEN Jie，transl.Beijing：（in Chinese）.［梅尔斯.软件测试的艺术［M］.王峰，陈杰，译.北京：机械工业出版社，2006：5－6.］

［8］YANG Jun，ZHANG Qian，LIN Yi－gang.An approach to the code coverage of embedded software［J］.Command Information System and Technology，2010，1（1）：24－26（in Chinese）.［杨俊，张倩，林依刚.一种嵌入式软件覆盖测试方法［J］.指挥信息系统与技术，2010，1（1）：24－26.］

［9］QIAO Wen－jun，WAN Xiao－dong.Research of coverage test tool on embedded software［J］.Computer Measurement ＆Control，2007，15（9）：1238－1240（in Chinese）.［乔文军，万晓冬.嵌入式软件覆盖测试工具的研究［J］.计算机测量与控制，2007，15（9）：1238－1240.］

［10］ZHANG Xiu－qiong.The research and implementation of an automated software unit test tool in ATC system［D］.Chengdu：Sichuan University，2006（in Chinese）.［张秀琼.ATC系统软件自动化单元测试工具的研究与实现［D］.成都：四川大学，2006.］

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