测试什么 - 嵌入式软件测试基础概述

　　测试什么

　　因为没有一个实际的测试集可以证明一个程式是正确的，因此关键问题变成了哪个测试子集最有可能检测到最多的错误。选择合适的测试例程的问题被称为测试例程设计。虽然存在数十种测试案例的设计方法，但它们通常可归为两种截然不同的方法：功能测试和覆盖测试。

　　功能测试（也称为黑盒子测试）选择可评估实现与需求规格符合程度的测试。覆盖测试（也称为白盒子测试）选择可执行程式码某些部份的测试例程。（过后，将详细讨论这两种方法。）

　　这两种测试都是对嵌入式设计进行严格测试所必须的。其中，覆盖测试表示程式码的稳定性，所以这种测试是用于已经完成或将近完成的产品的。另一方面，可在编写要求文件时，同时编写功能测试。

　　事实上，从功能测试开始入手，可以大幅地降低重复劳动和重写测试案例的工作。因此，在我看来，要先考虑功能测试。

　　每个人都同意先编写功能测试这个观点，有人认为，功能测试在系统整合阶段（而不是在单元测试时）最有用。以下是整合功能测试和覆盖测试方法的一个简单处理流程：

　　1．找出哪些功能未被功能测试完全覆盖。

　　2．找出每个功能的哪些部份没被执行。

　　3．找出需要哪些额外的覆盖测试。

　　4．执行新增的额外测试。

　　5．重复以上步骤。

　　何时停止测试？

　　最通用的停止标準（按可靠性排序）如下：

　　1．老板命令停止测试

　　2．新的测试週期找到的新缺陷少于X个

　　3．在没有发现任何新缺陷的情况下已经满足了某个覆盖阀限

　　无论你多么彻底地测试了程式，都无法保证找出所有缺陷。这引发了另一个有趣的问题：你可容忍多少缺陷？假设在极端软体压力测试过程中，你发现系统每进行大约20小时的测试就会锁定。你仔细地检查程式，但是仍无法找出这个错误的根源。这个时候你应该提供产品吗？

　　多少测试才‘足够好’？这个我说不好。但遵循一些久经时间考验的规则总是好的：“如果方法Z预估Y行程式码中的缺陷少于X个，那么就可放心地发佈程式了。”也许有一天会出现这种标準。编程产业仍然相对年轻，还达不到类似建筑业那样的成熟度。

　　许多厚厚的建筑手册和大本规格是多年经验的结晶，它们可为建筑师、土木工程师和结构工程师提供按工期在预算内、建造一栋安全建筑所需的全部资讯。偶尔虽仍会有建筑倒塌，但毕竟很少见。在编程产业制订出类似标準前，“多少测试才足够？”就是个主观判断问题。