覆盖测试 - 嵌入式软件测试基础概述

　　2．覆盖测试

　　功能测试的缺点是其很少执行全部程式码。覆盖测试则试图规避这个缺点，它採用的方法是（理想地）确保每一条程式码语句、判定点或者判定路径都至少被测试一次。覆盖测试还可以显示已经存取的数据空间大小。

　　覆盖测试也称为白盒子测试或玻璃盒子测试，这类测试的设计需要全面了解软体的实现方式，也就是说，它要‘看到盒子裡面’。白盒子测试利用了塬始程式码所能提供的方便。

　　白盒子测试充分借力了程式员对程式API、内部控制结构的知识，分享了程式员的异常处理能力。由于白盒子测试取决于具体的实现决策，因此要到应用程式码完成后，才能动手设计这类测试。

　　从嵌入式系统的角度来看，覆盖测试是最重要的测试，这是因为只要你把握已在多大程度上对程式码进行了测试，你就可很好地预警出现未发现缺陷的风险。白盒子测试的示例包括：

　　语句覆盖：选择的测试案例可以至少将程式中的每一条语句执行一次。

　　判定或分支覆盖：选择的测试例程可以使每一个分支（条件为真和假的路径）至少执行一次。

　　条件覆盖：选择的测试例程可以强制判定中的每一个条件（项）都包含所有可能的逻辑值。

　　理论上，白盒子测试可以利用或控制所需的任何对象来执行其测试。因此，白盒子测试可能使用JTAG介面强制设定特定的记忆体值作为测试的一部份。实践上，白盒子测试可以分析逻辑分析仪报告的执行路径。

　　3．灰盒子测试

　　由于白盒子测试可以深入程式码内部，因此与黑盒子测试相较，这类测试的维护成本更高。只要要求和I/O关係保持稳定，黑盒子测试就会一直有效；但每次修改程式码后，可能都需要重新进行白盒子测试。因此成本效益最高的白盒子测试一般是那些在不深入编程细节的情况下利用实现知识进行的测试。

　　较少涉及程式码细节的测试有时也称为灰盒子测试。当与‘错误推测’配合使用时，灰盒子测试非常有效。如果你知道（或者至少猜到）程式码中的弱点在哪裡，那么你就可以设计出对这些弱点‘施压’的测试案例。

　　因为这些测试覆盖了程式码的特定部份，因此这些测试是灰盒子测试；因为这些测试是根据可能会出现哪些错误的猜测而选择的，因此这些测试是错误推测测试。

　　在整合新功能与稳定的旧程式码库时，这种测试策略非常有用。由于程式码库已经过全面的测试，因此将测试重点集中在新、旧程式码交集处可以起到事半功倍的效果。