嵌入式软件测试基础概述

　　测试是传统软体开发的最后一步。整个软体开发过程，需要收集要求、进行高层次的设计、详细设计、製作程式码、进行部份单元测试，然后整合，最后才开始最终测试。

　　最佳的开发实践应包含程式码检查这个步骤。然而程式码检查一般只能找出70%的系统错误，因此完美的测试环节绝对必不可少。测试就像个复式记帐系统，可以确保将缺陷扼杀在最终推出的产品之前。

　　在所有其它的工程实践中，测试都被视为基本环节。比如，在美国，每一座联邦政府出资修建的桥都必须经过大量的风洞测试。而在软体领域，测试并没有很受重视。儘管测试是所有工程实践準则的关键部份，但编写测试程式却感觉是在浪费时间。好在嵌入式系统设计界内的许多领域已经将测试作为其工作的核心部份，他们认识到将这个关键步骤放在计画末期极不明智，因而主张同步地编写测试程式和应用程式。

　　嵌入式系统软体测试在诸多方面都与应用软体测试一样。不过，应用测试与嵌入式系统测试之间还是存在一些重要差异。嵌入式开发人员一般会用到基于硬体的测试工具，而这类工具通常不会用于应用开发过程中。此外，嵌入式系统一般都有些独一无二的特性，这些特性应该在测试计划中得以体现。本文将介绍测试和测试案例开发的基础知识，并指出整个嵌入式系统测试工作的特有细节。

　　何时测试以及如何测试

　　从图1可以看出，在可行的条件下，测试应尽早展开。一般来讲，最早的测试是由最初的开发人员进行的模组或单元测试。遗憾的是，开发人员大多对如何建构一整套测试例程以进行测试所知不足。由于精心设计测试例程通常直到整合测试时才能使用，因此许多在单元测试过程中就能找出的缺陷直到整合测试时才会被发现。比如，硅谷的一家大型网路设备厂商为找出其软体整合问题的关键塬因，进行了一项研究。这家厂商发现，在计画整合阶段找出的缺陷中，有70%是由在整合之前从没被执行过的程式所产生的。

　　

　　图1：改正问题的成本。

　　单元测试：开发人员在单独进行模组级测试时一般是编写存根程式码（stub code）取代余下的系统软硬体。在开发週期的这个环节，测试主要侧重于程式码的逻辑性能。

　　通常，开发人员会分别使用某些平均值、高值或低值、以及某些超出範围的值（以测试程式码的异常处理功能）进行测试。但这些基于‘黑盒子’的测试仅能对模组中整个程式码的一部份进行测试。

　　回归测试：测试不应是一劳永逸的。每次修改程式后都应该重新进行测试，以确保这些更改不会无意中‘误伤’某些不相关的行为。

　　称为回归测试的这类测试，一般是透过测试脚本自动进行的。比如，如果你设计了一组100个输入/输出（I/O）测试，回归测试脚本会自动执行这100个测试，然后将输出与一组‘黄金标準’输出进行对比。每次对程式码的任何部份进行修改时，都要对包含被修改程式码的整个程式执行整套回归测试程式包，以确维修改过程中不会‘误伤’其余程式码。