代码质量：改进军用级应用的测试

　　很久很久以前，唯一的动态软件测试是系统功能测试。与不可靠软件的斗争完全是通过完整的系统测试进行的，其中应用程序的价值是通过参考一组需求、一组测试数据和预期结果来证明的。

　　虽然这仍然是验证和验证过程的重要组成部分，但大多数测试数据集仅执行代码的特定部分。不幸的是，正是这种不寻常的代码路径只有在发生异常情况时才会被调用，这可能导致现场灾难性的结果。一个例子可能是对除数的测试，以确保它在计算中使用之前不为零。它不应该发生 - 但如果它发生了，并且测试有缺陷怎么办？

　　为了防止这种可能性，最好也引入单元和集成测试。单元测试涉及围绕函数或过程编写包装器“工具”，向其传递数据，并确保生成的输出符合设计要求。集成测试通过采用类似的方法建立在这一成功的基础上，但允许函数调用调用树中的其他函数，从而证明这些单元按预期协同工作。

　　单元测试和集成测试可以填补系统测试和练习构造留下的空白，以防止这些意外事件，例如“除以零”。或者，我们可以“自下而上”地练习整个系统，首先证明最小的功能组件已经充分锻炼，然后证明它们一起工作。

　　无论哪种方式，尽管我们现在有办法执行所有代码，但我们怎么知道我们已经这样做了？好的测试工具提供结构覆盖指标，以定量分析在结构覆盖率分析期间执行了多少代码路径。DO-178等标准的使用已经证明，这种方法可以降低失败的风险。因此，这已成为大多数嵌入式军事标准的规范。

　　虽然此类标准不要求您使用工具来生成此信息，但手动演示覆盖范围的开销非常耗时（更不用说更容易出错），以至于大多数公司将工具视为显着降低开发成本的一种方式。测试工具使用经过验证的检测机制创建覆盖率数据，该机制由函数调用组成，以记录所采用的执行路径。创建内部实现所需的工作量与应用程序代码本身类似。

　　第三方工具也提供了独立性的衡量标准，证明测试是全面的，使用由没有既得利益的组织编写的机制。

　　故事到此结束，是吗？使用这些工具和技术，您可以杀死龙并证明所有陈述在功能上都是正确的并且已被执行。

　　好吧，也许吧。这取决于失败的影响。应用越关键，对标准的要求就越高。您生成的覆盖范围数据量是否反映了项目的关键性？代码是否已在目标或主机上执行？

　　审核编辑：郭婷