代码质量：动态和静态分析相结合使工程师和审核员满意

在过去美好的时光里，在编写软件成为“软件工程”之前，代码开发是一门黑艺术，由刚从大学毕业的奇怪书孩子实践。对他们来说，编码绝不是一门结构化的学科。如果你设法让他们沟通，他们可能会告诉你，他们正在一起破解代码，并使用临时测试数据来查看它是否做了他们执行它时应该做的事情。

无论他们是否知道，他们都在通过系统功能测试进行动态分析。与静态分析不同，动态分析涉及代码执行的定义。

但是，除了显示基本功能对于任何基本的测试数据大致正确之外，这还做了什么？虽然总比没有好，但可能不超过一半的代码被执行。行业软件专家、Ganssle Group首席顾问兼行业编辑Jack Ganssle对此表示赞同：“研究证实，如果不使用代码覆盖率分析，测试通常只执行50%的代码。给定典型的错误率，这意味着程序中的 100K 行代码将附带 2500 到 5000 个错误。这些错误会导致许多系统故障。

为什么？因为无论测试多么富有想象力，现实生活中都有可能抛出一些曲线球来尝试未经测试的路径。如果执行某些内容未经测试，您可能会遇到一些意外和潜在的灾难性故障。

快进 30 或 40 年。虽然这种朴素的方法并不能与复杂的军事嵌入式应用相提并论，但功能测试仍然是动态测试的核心。精心挑选的测试数据表明，源代码中的分支和语句是按照规范执行的，不仅使我们能够证明系统在功能上是正确的，而且我们已经执行了所有这些功能。当与静态分析结合使用时，动态分析提供了所需的支持证据，以证明我们所有其他良好的工作和最佳实践产生了安全、可靠和高质量的最终产品。

与多年前的黑客攻击不同，今天的自动化测试工具通过使用仪器探针等技术精确地跟踪执行路线。这些探测器本质上是附加的函数调用，从源代码中的战略点生成“我来过这里”消息，并允许整理覆盖率数据。它们允许动态测试生成有关其全面程度的反馈，以便我们可以在每组结果的基础上连续构建，直到达到所需的覆盖水平。

反过来，这为我们一次执行多少代码提供了灵活性。可以对整个系统进行动态分析，但总有一些通过代码的路由，我们的系统在正常运行期间无法执行这些路由——例如防御性代码;也许是除以零的支票。

在这种情况下，最好也使用“单元测试”。单元测试封装了系统的一个子集，并允许传递参数，以便执行示例中的防御机制代码。我们甚至可以选择完全基于单元测试进行应用程序动态分析，在每个模块开发时整理代码覆盖率数据，并消除等待完整系统的任何要求。

当今的军事应用需要支持 ARINC 653 或FACE等架构标准，以提高代码的可移植性和可重用性。通过动态分析提供全面的覆盖数据提供了证据，证明即使移植到不同的应用程序，代码仍然是可维护的、安全的，特别是当与有效的静态分析制度结合使用时。

审核编辑：郭婷