嵌入式系统的系统测试和可靠性评估

引言

随着嵌入式系统硬件体系结构的变化，嵌入式系统的发展趋势向嵌入式系统高端，即嵌入式软件系统转移，具体体现在嵌入式操作系统趋于多样和应用软件日渐复杂。由于嵌入式系统软硬件功能界限模糊，研究如何进行系统测试和进行质量评估来保证嵌入式系统的产品质量具有重要意义。

首先，这里明确嵌入式系统的系统测试定义，是将开发的软件系统（包括嵌入式操作系统和嵌入式应用软件）、硬件系统和其它相关因素（如人员的操作、数据的获取等）综合起来，对整个产品进行的全面测试。嵌入式系统的系统测试比PC系统软件测试要困难得多，主要体现如下：
①测试软件功能依赖不需编码的硬件功能，快速定位软硬件错误困难；
②强壮性测试、可知性测试很难编码实现；
③交叉测试平台的测试用例、测试结果上载困难；
④基于消息系统测试的复杂性，包括线程、任务、子系统之间的交互，并发、容错和对时间的要求；
⑤性能测试、确定性能瓶颈困难；
⑥实施测试自动化技术困难。

1 测试方法

根据Goodenough和Gerhart提出的软件测试充分性准则可知，软件测试具有非复合性的特点，也就是说，即使以软件所有成分都进行了充分的测试，也并不意味着整个软件的测试已经充分。所以，即使通过了需求测试、设计测试、编码测试，并不意味着已经完全了充分的测试，还要进行软硬件全面测试，即系统测试。正确的系统测试方法能设计出良好的测试事例，而良好的测试事例是测试成功的关键。测试事例质量特性主要有以下几点。

*检验性：检测软件缺陷的有效性，是否能发现缺陷或至少可能发现缺陷。
*可仿效性：可以支持测试多项内容，减少测试事例的数量。
*开销：测试事例的执行、分析和调试是否经济。
*修改性：每次软件修改后对测试事例的维护成本。

测试方法不仅要保证测试事例具有发现缺陷的高可移植性，而且还要保证测试事例设计的经济有效。因此，在实际测试工作中，将嵌入式系统的测试方法分类如下：根据测试是否动态运行被测程序分为静态测试方法和动态测试方法；根据测试阶段分为需求测试方法、设计测试方法、编码测试（单元测试、集成测试）方法及系统测试方法；根据测试目的分为功能测试、性能测试、可靠性测试（容错性、可恢复性、成熟度测试*及信息安全保护等测试。参看表1嵌入式软件测试方法对照。其中“√”代表相关性。所有这些方法的具体定义这里不一一介绍。由于不同的嵌入式系统面向的应用不同，测试方法的侧重也很不相同。本文后面将对一个具体的便携式信息处理嵌入式系统（PDA、便携式翰林电子书）的系统测试方法详细说明。

表1 嵌入式软件测试方法及阶段对照表

测试方法分类		需求测试	设计测试	编码测试	系统测试
静态测试方式；	基本思想
Yourdon的结构化走通	结构化审阅	√	√		√
Fagan检查测试	检查并评估	√	√		√
动态测试方法；	基本思想
控制流测试	语句测试		√	√
路径测试			√
条件测试			√
数据流测试	数据定义引用			√	√
分域测试	划分子域测试	√	√		√
功能测试	划分功能测试			√	√
随机测试	不限定范围

2 可靠性评估

可靠性是嵌入式系统最重要的质量指标。ISO9000国示质量标准（ISO/IEC 9126-1991）规定，软件产品的可靠性含义是：在规定的一段时间和条件下，软件能维持其性能水平的能力有关的一组属性，可用成熟性、容错性、易恢复性三个基本子特性来度量。根据我们在评估嵌入式系统中的成功经验，一般采取以下简单有效的评估方法（可以采用百分制或十分制）。

（1）成熟性度量

①错误发现率DDP（Defect Detection Percentage）。在测试中查找出来的错误越多，实际应用中出错的机会就越小，软件也就越成熟。
DDP=测试发现的错误数量/已知的全部错误数量
已知的全部错误数量是测试已发现的错误数量加上可能会发现的错误数量之和。

②测试覆盖率度量。测试的覆盖率，可以用测试项目的数量和内容进行度量。除此之外，如果测试软件的数量较大，还要考虑数据量。测试的覆盖率，可以根据表2所示在测试指标进行评价。通过检查这些指标达到的程度，就可以度量出测试内容的覆盖程度。

表2 测试覆盖程度表

测试覆盖项	测试覆盖率指标测试描述	测试结果
界面覆盖	符合需求（所有界面图标、信息区、状态区）
静态功能覆盖	功能满足需求
动态功能覆盖	所有功能的转换功能正确
正常测试覆盖	所有硬件软件正常时处理
异常测试覆盖	硬件或软件异常时处理（不允许的操作）	测试结束判断

表3 可信度测试表

测试功能	甲	乙	丙	丁	平均	最大值-最小值
功能1
功能2
功能3
功能4
功能5

     　     　     　     　     　
注意，对于最大值与最小值的差值超过5的情况，应该重新测试响应功能。[page]

（2）容错性评估

容错性评估分为控制容错性评估、数据容错性评估、硬件故障恢复容错性评估：
容错性=以下各条款评分之和÷条款数

控制容错性度量
①对并发处理的控制能力；
②错误的可修正性和处理可继续进行能力。
数据容错性度量
①非法输入数据的容错；
②对相互冲突的要求和非法组合容错；
③输出数据是否合理容错。

硬件故障中恢复容错性度量
故障后恢复能力容错。

（3）易恢复性度量

与易恢复性紧密相关的测试是强度测试和健壮测试。强度测试又称为力度测或极限测试，主要测试系统对空间强度和时间强度的容忍极限；健壮测试又称异常测试，是很重要的可靠性测试项目。通过易恢复性测试，一方面使系统具有异常情况的抵抗能力，另一方面使系统测试质量可控制。

易恢复性=以下各条款评分之和÷条款数
①空间强度可恢复；
②时间强度可恢复；
③数据强度可恢复；
④异常通信可恢复；
⑤数据破坏可恢复；
⑥电池极限可恢复。

（4）测试可信度评估

测试可信度是对测试质量的有效评估，是保证质量的必要步骤。目前虽然很难有量化的指标，但我们采取积分的方式显示可信度。例如，请4个人员（甲、乙、丙、丁）对系统5个功能打一个从0（不信任）到10（完全信任）之间的分数，那么，可信度度量可以用表3进行计算。

3 测试实例

（1）电流测试

电流测试是嵌入式系统的系统测试中首先要进行的重要测试，也是最容易被忽视的测试。主要是测试系统的工作电流、待机电流。人们一般把它当成与系统测试无关的硬件测试。但是对于嵌入式系统，软件与硬件不可能清晰地划分，硬件的性能直接影响软件的运行。实例1说明了电流测试对系统运行的影响及不可替代的作用。

测试现象描述：进行同一厂商PDA系统测试，有几台PDA在名片子系统、行程子程序的操作过程中随机死机。

我们当时的错误分析定位是：①怀疑操作系统中断处理错误；②怀疑内存泄漏，堆栈溢出；③怀疑应用程序错误。

在软件开发人员为解决这个问题检查软件时，硬件开发人员提出应首先测试一下这几台机器的工作电流。结果发现，PDA的工作电流低于正常工作电流。加电容调整后随机死机问题消失。

由此例还可以看出，嵌入式系统测试的软硬件测试不可分性。绝对的将硬件测试和软件测试区分开来的测试思想是不正确的。我们在系统测试时的电流测试设计如表4。

表4 电流测试

测试电流项目	测试结果（不同的产品对电流要求不同）		备  注
预期值	实测值
待机电流/mA			关机后电流测试
启动电流/mA			开机瞬间电流测试
工作电流/mA			正常工作电流测试

（2）兼容性测试

考虑到嵌放式系统软硬件的开发成本高于通用PC系统，因此，提高软件对硬件的兼容及软件升级版本的兼容性极为重要。表5是便携林翰林电子书升级版本兼容性测试实例。

表5 兼容性测试

兼容性测试分类	硬件兼容性	操作系统兼容性	应用软件兼容性	PC制书软件兼容性
BIOS兼容测试
BIOSV1.0
BIOSV2.0
操作系统兼容测试
VOLF V.1.0
VOLF V.2.0
应用软件兼容测试
READER V.1.0
READER V.2.0
PC制书软件兼容测试
PCREADRE V1.
PCREADER V2.

   　     　     　
实例2：现在的嵌入式系统的层次结构一般分为硬件层、BIOS层、操作系统层、应用系统层。有的还需要通用PC应用软件支持。因此，嵌入式系统的兼容性测试要考虑硬件兼容性、BIOS兼容性、操作系统兼容性，还需考虑与相应PC应用软件的兼容性。

结语

本文的测试方法和评估方法在具体的嵌入式系统测试中，获得很好的效果。这是一项很有意义的工作，不仅要求嵌入式系统的测试人员具有很全面的软硬件知识，还需结合测试理论、统计方法，面对不同的系统进行测试方法、工具、过程评价及质量评估。随着嵌入式系统的多样性和复杂性发展，嵌入式系统的系统测试研究将继续深入。

参考文献

   1. Pressman Roger S Software Engineering A Practitioner' s Approach 2001
   2. 朱鸿.金凌紫 软件质量保障和测试 1997
   3. Satzinger Jone W.Jackson Robert B.Burd Stephen D Systems Analysis   
       and Design in a Changing word 2001
   4. 万建成.卢雷 软件体系结构的原理、组成与应用 2002
   5. Wayne Wolf 嵌入式计算系统设计原理 2002
   6. ISO9000国际质量标准.内部资料
   7. ISO9001:1994标准.内部资料
   8. ISO9000-3:1993标准.内部资料
   9. GB/T16260-1996.信息技术 软件产品评价 质量特性及其使用指南 1996
  10. GB/T17544-1998.信息技术 软件包 质量要求和测试 1999