嵌入式软件机内测试的设计与测试

Vol.35 No.17 Computer Engineering ·软件技术与数据库·

文章编号：1000—3428(2009)17—0034—03

文献标识码：A

2009年9月

September 2009

中图分类号：TP311

嵌入式软件机内测试的设计与测试

王轶辰，徐 萍

(北京航空航天大学工程系统工程系，北京 100083)

摘 要：针对嵌入式软件中广泛开展的软件机内测试(BIT)设计，分析通用嵌入式系统结构，提出3种软件BIT的结构模式，结合实例对每种模式的算法设计进行描述。以故障模式的概念为核心提出一种基于故障注入的软件BIT测试方法，阐述方法中的需求分析、故障注入、测试设计和结果分析4个关键步骤。

关键词：嵌入式软件；软件测试性；软件机内测试；故障注入；软件测试

Build-In-Test Design and Test for Embedded Software

WANG Yi-chen, XU Ping

(Department of Project System Engineering, Beijing University of Aeronautics and Astronautics, Beijing 100083)

【Abstract】Software Build-In-Test(BIT) is now used widely in embedded area.This paper analyses the general architecture of the embeddedsystem, introduces three types of BIT structure pattern. For each pattern, the arithmetic design is described with real practice. It presents a new BITapproach based on fault injection. Four important phrases in this approach: test requirement analysis, fault injection, test design and result analysisare described thoroughly.

【Key words】embedded software; software testability; software Build-In-Test(BIT); fault injection; software test

1 概述 国内开展测试性/机内测试(Build- In-Test, BIT)的研究与推广应用比国外晚，但近年来进步较快，尤其在国防领域内的重要系统和设备研制中提出了明确的测试性要求，开展了测试性/BIT设计分析工作，制定了一系列相关的国家军用标准。航空航天及武器装备的BIT设计的越来越受到重视，应用也越来越多。然而，目前的测试性和BIT研究绝大多数还在硬件设计领域，对软件测试性的研究不够充分，研究成果较少，应用范围十分有限。 BIT[1]是指为了给故障诊断提供最大的方便，提高测试性水平，系统和设备内部设置了用于状态监控、故障检测与隔离的硬件和软件或自检装置等，使系统本身就能检查工作是否正常或确定什么地方发生了故障。BIT是系统或设备内提供的检测和隔离故障的自动测试能力。按工作方式和时段不同，常见的BIT分为：(1)连续BIT：连续不间断地监测系统工作状态；(2)周期BIT：以某一频率执行测试；(3)启动BIT：在外部事件(如操作者启动)发生后才执行监测；(4)维修BIT：在系统完成任务后(如飞机着陆后)执行维修检查测试。它可以启动运行系统所具有的任何一种BIT。 由于系统中愈来愈多的功能转由软件实现，因此与软件运行相关的硬件数量也不断增多，这类硬件设备的自检测只能通过软件来实现。目前，由软件实现的BIT尚处于软件测试性研究的初级阶段，仍然是硬件测试性设计的一种扩展，即利用计算机软件实现对其所依赖的硬件运行环境的检测功能，与软件BIST(Build-In-Self-Test)[2]的概念略有不同。 故障注入提出于20世纪70年代初期，之后一直被用于对容错系统的设计进行验证。20世纪80年代中期，故障注入技术逐渐开始被高校和研究部门所采用。进入90年代后，该技术越来越引起研究人员和工程设计者的重视，对故障注 —34—

入的研究与应用也随之深入和广泛。故障注入技术在实际应用中有多种方法，可按多种方式对故障注入进行分类[3]。 本文主要描述嵌入式软件的结构模式和算法模式，提出基于故障注入的软件BIT测试方法，给出对软件BIT测试结果的评价。 2 软件BIT设计 2.1 软件BIT的结构模式 嵌入式软件的BIT主要利用软件算法实现对嵌入式系统及交联系统硬件故障的监测、隔离和报警功能[4]。 嵌入式软件所运行的硬件环境如图1所示。 物理环境嵌入式系统嵌嵌入入式式RAMNVM输入/输出电源供应传感器环境特定界面动作器模数转换数模转换处理单元和其他系统的接口 图1 典型嵌入式系统结构 硬件系统分为3个层次： (1)板上器件级，包括处理器、RAM、NVM及定时器等； (2)系统内接口，包括各类输入/输出接口、各种传感器、作者简介：王轶辰(1977－)，男，博士，主研方向：嵌入式软件测试理论，软件测试性，测试方法，测试环境；徐 萍，博士 收稿日期：2009-02-05 E-mail：wangyichen@buaa.edu.cn

动作器以及特定的图形界面； (3)外部环境，包括与嵌入式系统通过外部总线或各种接口相关联的物理环境及设备。 嵌入式软件BIT是通过软件算法实现的对嵌入式系统硬件的自测试，BIT体系结构见图2。按照图1中的嵌入式系统层次结构，嵌入式软件BIT可以分为3种类型： (1)板上器件BIT：软件实现的对板上器件，包括处理器、各类存储器以及定时器等进行的自检测； (2)系统内接口BIT：软件实现的对系统内各种输入/输出接口板硬件进行的自检测； (3)系统间BIT：软件实现的对与系统连接的交联设备进行的自检测。 <<结构>>板上器件BIT嵌入式软件<<结构>>系统内BIT<<结构>>系统间BIT(2)系统内接口BIT的算法设计 系统内接口是被测试软件与外部设备和环境进行数据交换的桥梁，是系统对外体现功能和性能的关键部件，从故障模式入手进行分析，系统内接口的软件BIT设计主要侧重 2个方面：接口硬件是否连接正确；接口数据是否收发正常。以嵌入式系统常见的422总线BIT设计为例，首先通过初始化硬件以及向422总线发送和接收1帧数据，检测硬件的链接是否正常，通过比较2帧数据的一致性判断数据传输是否正确，最后记录检测结果或转入故障处理流程。 一个典型的422总线自测试算法如下： {… Set_BIT_lock; /*设置BIT联锁*/ init(); /*初始化422接口状态*/ write (BIT data frame1); send(BIT data frame1 ) to 422bus; /*将数据帧写入422总线 接口*/ receive(BIT data frame2); /*接收422总线数据*/ read(BIT data frame2); /*读出BIT测试数据帧*/ if (BIT data frame1 != BIT data frame2) send_fault_info(); /*报告422接口自检故障*/ else <<接口>>器件级接口<<接口>>系统内接口嵌入式硬件<<接口>>系统间接口 图2 嵌入式软件BIT体系结构模式 返回BIT的接口检测结果; …} 2.2 软件BIT的算法模式 (1)板上器件BIT的算法设计 板上器件对软件运行的影响最大，CPU、RAM和定时器等器件发生故障会导致软件无法运行或出现致命问题。但是软件运行对板上器件的依赖性又决定了软件BIT对板上器件的检测能力是十分有限的。 软件BIT的设计原则主要依据硬件故障模式，软件功能的实现是根据故障模式设计算法检验故障是否发生，并设计故障处理机制进行故障报警。以RAM存储器为例，嵌入式软件对存储器的依赖性很大，需要针对写入和读出能力全面地检测系统中各类存储器(RAM, ROM, NVRAM等)。而RAM的常见故障模式无法向某个存储单元写入数据及无法正确读出数据，因此，一个典型的RAM自检测算法如下： { … int N1 = 0xAAAA; write N1; read N1; int N2 = 0x5555; write N2; read N2; int N = N1 + N2; if(N != 0) Else …} send_fault_info(); /*报告RAM自检故障*/ (3)系统间BIT的算法设计 系统间BIT实质上是对交联设备工作状态的一类检测，一般是在系统内接口完成检测之后进行。通常由被测系统通过固定总线接口向需要检测的交联设备发送一个预先定义的信号或一帧数据，然后等待对方自检测结束后返回自检结果，根据返回值确定交联设备的状态是否正常，记录检测结果或者进入故障处理流程。 一个典型的系统间BIT算法如下： {… write (BIT data frame); send(BIT data frame ) to equip; /*将数据帧发送到设备A总线接口*/ receive(BIT data result)from equpA; /*接收设备A总线数据*/ read(BIT data result); /*读出BIT测试结果数据帧*/ if (BIT data frame1 != BIT data frame2) send_fault_info(); /*报告交联设备A发生故障*/ else 返回BIT的系统检测结果; …} 3 基于故障注入的BIT测试方法 通过上文对软件BIT的结构模式和算法模式的分析与总结，并结合软件BIT的功能需求，可以看出应该将嵌入式软件BIT的测试与验证重点放在考察软件发现故障和处理故障这2种能力上： (1)验证软件BIT设计得是否合理、充分，是否可以检测出嵌入式系统各个层次上的硬件故障； (2)测试软件BIT是否具备良好的故障处理流程，可以将正确检测到的硬件故障通知用户或者上层调用者。 为了满足以上2个测试需求并结合软件BIT的设计特性，本文提出一种基于故障注入的嵌入式软件BIT测试方法。该方法通过模拟嵌入式系统的硬件故障实现对软件BIT 2种主要能力的测试与验证。其中，模拟硬件故障的方式又分为软件故障注入和硬件故障注入2种。 —35—

上述算法首先向存储器中写入固定数据，验证写入能力，然后读出这个固定数据，验证读出能力，最后通过2个固定数据的求和验证数据的正确性。有些对存储数据安全性要求很高的系统，在设计算法时为了保证每个存储单元都是良好的，还需要在上述算法中加入循环机制，逐一考察存储单元。另外，对于其他特殊类型的存储器(如非易失存储器)还要设计算法检查特殊性。

基于故障注入的测试方法的核心是明确系统的硬件故障模式，并据此制定测试需求，进行测试设计并完成测试。如图3所示，基于故障注入的软件BIT测试方法分为4个主要步骤。 BIT设计的检测能力系统的故障模式软件BIT需求软件BIT设计利用因果图表示故障间关系分析故障模式明确测试需求确定故障的引入位置(层次定位)和触发方式确定故障注入机制确定故障的引入位置(层次定位)和触发方式设计测试用例确定输入/输出以各种形式保存观察到的测试结果运行测试用例获得结果数据根据故障模拟、故障注入以及测试结果评价BIT测试的可信性写入数据>。如果通过硬件故障注入方式实现，则需要破坏物理内存的管脚。显而易见，由于测试具有破坏性，因此硬件故障注入虽然真实但却很难在实际工程中得到广泛应用。 2)软件故障注入 软件故障注入是通过修改被测试软件的代码模拟硬件故障的一种测试手段。软件注入是一种易于操作且比较有效的故障模拟方式，根据软件测试需求中的故障模式并结合对具体BIT算法的分析，确定故障注入的位置和方式，即确定在程序的什么地方插入或修改什么样的代码语句。 相比硬件故障注入，采用软件故障注入方式时需要特别分析以下2点： ①测试充分性。软件BIT的主要功能是发现硬件故障并及时处理或报警，而通过修改软件方式所模拟的故障模式对于发现故障这个功能的测试是不充分的，根据软件故障注入的不同位置测试的充分性会有所不同，具体测试过程中需要对此作出分析与判断。 评价测试结果给出测试 图3 基于故障注入的软件BIT测试方法 (1)确定软件测试需求 根据软件BIT的功能需求及设计模式，一个全面的BIT测试需求应该包括2个方面： 1)软件BIT是否能够全面而正确地检测到系统硬件可能出现的所有故障模式 能够正确地检测出系统硬件发生的各类故障并进行相应处理是软件BIT设计的最终目标，也是BIT软件测试的主要内容。在确定软件测试需求的过程中需要对硬件可能出现的各种故障进行分析，而主要依据来自软件BIT的设计需求及经过分析总结的硬件故障模式库。确定故障模式后还要对BIT的处理过程进行分析，给出不同故障模式导致的软件系统状态，为后续的测试设计中确定测试预期结果奠定基础。 以上述内存自检测程序为例，可以对故障模式进行如下分析：根据软件BIT对内存检测的设计需求可以得到<无法正确向内存中写入数据>和<无法正确读出内存中数据>2个主要故障模式，同时考虑实践中积累的故障模式，根据所检测内存类型可以得到不同的故障模式：<非易失存储器(NVRAM)丧失非易失特性>，<可擦除存储器无法进行数据擦除>等。结合软件需求就可得到故障与系统状态之间的关系。 2)软件BIT是否误报了没有发生的硬件故障 BIT误报了没有发生的故障，即虚警，是软件测试性研究领域的一个重要概念。本文介绍的方法中不涉及针对该类需求的测试。 (2)确定故障注入机制 从软件BIT的设计需求与测试需求可以看出，硬件故障模式是其中的一个关键因素。在设计阶段收集故障模式是决定软件BIT是否充分准确的重要前提，在测试阶段模拟故障模式则是实现充分和准确测试软件BIT的重要手段。 确定软件测试需求后，要根据测试条件选择每一种故障模式的注入机制，即故障模拟的方式。根据软件测试中对故障模拟方式的不同可分为软件故障注入和硬件故障注入2种。 1)硬件故障注入 硬件故障注入是一种更接近软件实际使用环境的测试手段，根据软件测试需求中的故障模式真实地将故障在硬件设备上实现，例如上文提到的内存故障模式<无法正确向内存中 —36—

②测试可信性。故障注入方法的本质是一种仿真测试，软件故障注入方式的可信性分析要从2个方面考虑：软件故障注入的位置和程序中插装的语句对满足测试需求中硬件故障的仿真逼真度；被测试软件插装的程序代码对被测软件实际运行方式和状态的影响。 (3)设计测试用例 测试需求确定了要测试的目标和内容，故障注入机制提供了测试采用的主要手段，的测试用例设计将描述具体的测试操作步骤。软件BIT的测试用例中需要明确以下4点： 1)用例说明，即测试用例所实现的测试需求，对测试所要模拟的硬件故障模式进行描述。 2)测试条件，即采用的故障注入机制以及故障注入的位置和方式。 3)测试输入，这是软件测试用例的关键部分，需要详细列出测试用例的执行步骤，包括故障注入的具体操作及相应的数据输入或软件操作步骤。 4)预期结果，这是判断测试用例是否通过、软件是否存在缺陷的评判依据，需要根据测试输入和所依据的软件需求列出对应于每个输入的软件表现行为或数据特征。 测试用例其他信息如图4所示。 编制人： 用例说明 用例标识 测试条件 审定人： 测试用例的唯一标识 采用的故障注入机制，故障注入位置和方式 编制时间： 测试需求内容，测试模拟的故障模式 测试输入： 描述测试下表用例所必需的测试输入的一般情况。可包括： 输入说明：每个测试输入的名称和某些特殊情况的说明 输入来源及特征：测试输入的来源(如测试程序产生、磁盘文件、通过网络接收、人工键盘输入等)及特征(模拟还是真实) 输入步骤：一般情况下测试输入的时间或事件顺序及具体操作 预期输出：根据软件需求写出对应于上述测试输入的输出结果 终止条件 评估准则 说明测试用例的正常和异常终止条件 给出判断用例是否通过的判断标准 图4 基于故障注入的测试用例 (4)分析测试结果 设计的测试用例需要在合适的测试环境中得到执行，并且能够收集到测试执行数据，测试用例的执行过程及执行结果应该在测试过程记录中详细描述。根据测试结果数据及测试用例的预期输出可以得到测试用例是否通过的结论，基于 （下转第39页） 责创建数字签名算法(DSA)签名，DSASignatureDeformatter负责验证数字签名算法(DSA)。 (2)发送方关键代码 1)获取散列值 获取散列值是本方案中频繁使用的方法，同时计算出来的散列值会作为封装数据包的一部分发给接收方，所以选择了运算速度快、散列值长度较小的MD5算法。关键代码如下： HashAlgorithm MD5 = HashAlgorithm.Create(\"MD5\"); //创建一个哈希算法实例，指定MD5算法 hi = MD5.ComputeHash(pi); //计算数据包散列值 Provider(); DSA.ImportParameters(false); DSASignatureDeformatter DSADeformatter = new DSASignature Deformatter(DSA); DSADeformatter.SetHashAlgorithm(\" MD5 \"); DSADeformatter.VerifySignature(h14, SignedH14); 5 结束语 本文研究并分析了用树型散列的方法对IP组播的数据源进行认证的过程，包括数据包如何划分、散列值获取以及数字签名的认证过程，并给出了该方法的具体实现过程。该方法对提高IP组播源认证的工作效率有一定的参考价值。 参考文献 [1] 姚 烨, 徐学洲. 一种基于Internet的组多播通信协议[J]. 计算

机工程, 2005, 31(1): 130-132.

[2] 王 晖, 沙基昌. 大型视频组播系统整体效用层次化建模与求

解[J]. 计算机学报, 2007, 30(12): 2116-2120.

[3] 李 磊, 王怀民, 史殿习. 一种高性能的全序组播算法[J]. 计算

机研究与发展, 2007, 44(9): 1450-145.

[4] 何永忠, 冯登国. 一个组播源认证方案的安全分析[J]. 计算机工

程, 2006, 32(18): 12-13.

[5] 周贤伟, 戴昕昱, 刘蕴络. IP组播源认证方案研究[J]. 计算机工

程, 2007, 33(16): 131-132.

[6] 章 洋. 一种UC匿名的移动自组网概率组播策略[J]. 软件学报,

2008, 19(9): 2403-2412.

[7] Merkle R C. A Certified Digital Signature[C]//Proc. on Advances in

Cryptology. New York, USA: Springer-Verlag, 19: 218-238. [8] 王治海, 杨冬梅. 基于IP组播的网络电视播放技术[J]. 计算机工

程, 2008, 34(18): 123-124.

[9] Tian Ruixiong, Zhang Qian. Robust and Efficient Path Diversity in

Application Layer Multicast for Video Streaming[J]. IEEE Transactions in Circuits and Systems for Video Technology, 2005, 15(8): 961-972.

[10] Rivest R L, Shamir A, Adleman A L. A Method for Obtaining

Digital Signature and Public-key Crypto System[J]. Communica- tions of the ACM, 1978, 21(2): 120-126.

2)对块散列值签名 [10]=在综合考虑签名算法的安全性和高效性上，签名部分采用了DSA签名算法。首先创建一个负责签名服务的对象，并指定类型、算法，为哈希散列值签名，关键代码如下： DSACryptoServiceProvider DSA new DSACryptoService Provider(); DSA.ImportParameters(true); DSASignatureFormatter DSAFormatter new DSASignature Formatter(DSA); DSAFormatter.SetHashAlgorithm(\"MD5\"); SignedH14 = DSAFormatter.CreateSignature(h14); 3)组播设置 申请一个组播地址和一个端口号，创建套接字，绑定之后便可以向该端口上组播数据，需要注意的是，该套接字需要设置一个大于1的TTL值。方法如下： SetSocketOption(SocketOptionLevel.IP, SocketOptionName.Multi =castTimeToLive, 50); (3)接收方关键代码 1)验证散列值 由于Hash算法不可逆，因此验证散列值唯一的方法是，用计算出的新散列值同收到的散列值进行比较，相同则信息是正确的，否则是错误的。 2)验证签名 验证签名同数字签名的过程类似。首先创建一个负责验证签名服务的对象，并指定类型、算法、验证散列值和已签名数据，关键代码如下： DSACryptoServiceProvider DSA new DSACryptoService 编辑 任吉慧 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ （上接第36页） 要的软件缺陷。 故障注入的软件BIT测试属于仿真测试范畴，所以，在测试结果分析中应根据故障的模拟方式和注入位置进行分析， 参考文献 4 结束语 测试性是衡量软件质量的一个重要属性，而内建自测试是软件测试性体现最直接的一个特征。本文对目前软件中常见的BIT设计模式进行分析与总结，继而提出了针对BIT的软件测试方法，这种方法可以比较全面地对软件BIT功能进行分析与测试。 目前，基于故障注入的BIT测试方法已经在笔者主持参与的多个武器装备软件测试项目中得到应用，并发现了诸如“非易失存储器缺少非易失特性的自检测”等大量关键和重 [1] 田 仲, 石君友. 系统测试性设计分析与验证[M]. 北京: 北京

航空航天大学出版社, 2003.

[2] 孙峻朝, 王建莹, 杨孝宗. 故障注入方法与工具的研究现状[J].

宇航学报, 2001, 22(1): 99-103.

[3] 李 文, 徐拾义, 毕洪山. 软件内建自测试中测试点的设置及个

数的研究[J]. 计算机工程, 2005, 31(13): 96-98.

[4] 贾荣珍, 刘 丽, 王行仁, 等. 仿真系统的校核与验证的自测试

软件[J]. 系统仿真学报, 2000, 12(6): 617-620.

编辑 张正兴 —39—