有一款正常工作的软件。那么可以说正常工作的软件都是好软件吗？在漫威的《黑豹》电影中有一个场景我深深地看过。
<图 1> 电影《黑豹》的场景
就算做的好，也有进步的空间!
我认为好的软件也是如此。 即使它可以工作并且没有问题，但总是有改进的空间，并且可能存在尚未发现的错误。
在本文中，我们想讨论动态测试无法捕获的错误、静态分析的必要性以及为什么需要修复缺陷。
动态测试不能发现的BUG
有哪些方法可以找到动态测试都没有发现的bug？
首先，让我们谈谈为什么会出现错误。 产生错误的原因有无数种，但大致可分为以下 4 类。
- 未考虑的案例（缺失需求）
- 意外行为（需求被误解）
- 异常输入（缺少异常处理）
4.由于简单的编码错误导致的Bug
动态测试可以在一定程度上覆盖第1点和第2点。 通过组织良好的需求、100% 的覆盖率和 QA 流程，可以找出大多数bug。 需要我们考虑的是第 3 点和第 4 点，它们很容易被忽略。
异常输入（缺少异常处理）
为什么动态测试不能捕捉到异常输入？
异常输入不能很好地作为动态测试的案例。 如果将其作为动态测试用例，则不会有错误，因为它是预期的输入。
最简单的例子是除以零或缓冲区溢出等错误。 这类 bug 最大的问题是它们大多发生在软件发布之后。
单纯由代码编写导致的bug
动态测试没有检测到哪些编码错误？
一个典型的例子是内存泄漏。 通常，只有当程序运行时间较长，才会发现内存泄漏。
动态测试中发现内存泄漏并不容易，需要在开发阶段快速检查结果。 此外，在内存泄漏的情况下，即使找到了相应的错误，也很难找出泄漏发生的代码位置。
由于异常输入或编码错误，通常出现在软件运行中，而不是在开发中。 为了便于解释，我们将这些错误统称为运行错误。
接下来，我们来谈谈如何避免运行错误。
[如何避免运行错误]
让我们看看需要哪些步骤来防止运行错误。
最好的方法是获得大量的实践或经验。 经验丰富的开发人员通过大量的编码经验提前考虑运行错误。那么，经验和实践有限的开发人员是否需要针对运行错误进行无防御的开发？
通常，在开发过程中会执行结对编码、mob 编码和代码评审等过程，以提前预防这些 bug。 但是，如果项目日程紧迫，并且需要将产品快速推向市场，那么实际上并没有太多时间来进行这些活动。 此外，由于经验丰富的开发人员的时间成本很高，因此代码评审、结对编码和mob编码等活动对公司或团队来说效率不高。
静态分析(Static Analysis)必要的原因
除了经验丰富的开发人员的活动之外，还有一种低成本的替代方案，那就是静态分析。
通过执行静态分析，可以毫不费力地避免诸如运行错误之类的错误。静态分析根据经验丰富的开发人员的专业知识或现场已经发生的许多运行错误的案例来创建规则。然后，使用创建的规则对源代码进行分析。源代码静态分析会检查异常输入、程序的流程或在审查中遗漏的代码。这意味着您找到动态测试或代码审查等活动无法发现的bug。
静态分析不需要执行代码。因为即使在未完成的代码上也可以进行分析，所以可以比动态测试更早地发现错误。与动态测试相比，它还具有在相对较短的时间内发现错误的优势。
下图是SureSofttech的代表性静态分析解决方案CodeScroll STATIC的执行界面。
随着在任务关键域中检查编码规则和运行错误（Runtime Error）的重要性增加，该项目规模开始加大。导致静态分析时间和通信成本的增加，使得修复缺陷变得困难。 STATIC 就是为了解决这些问题而开发的解决方案，通过提供一组丰富的编码规则，从而使项目能够高效的进行。
<图 2> CODESCROLL STATIC memory leak BUG检出结果画面
<图 3> CODESCROLL STATIC Buffer Overrun 检出画面
让我们看看我们需要静态分析的其他原因。
正如本文开头所提到的，即使是运行良好的软件也有改进的空间。静态分析不仅能发现bug，还能发现有改进空间的代码。
静态分析还提供有关编码风格的规则和代码质量度量。
编码风格规则检查是否按照编程语言提供的规则或公司设置的规则进行编程。由于这些规则是考虑到代码的维护和可读性而制定的，因此强烈建议遵循它们。
代码质量度量提供代码的复杂性、可扩展性和可移植性的数字表示。我们可以通过使用质量指标来量化不可见代码的质量，为了定量化数值，我们可以控制我们的工作。如果质量度量管理没有在开发早期应用，成本可能会增加并最终放弃改进。如果您从开发的早期阶段管理质量指标，您可以发布具有低技术债务的产品。
<图4> CODESCROLL STATIC Metric 画面
动态测试 VS 静态测试
动态测试是最昂贵的测试方法之一。 随着源代码的增加和越来越复杂，需要维护的测试代码的数量也在增加。 另外，由于测试代码也是一个编码过程，自然会出现错误，测试代码中的错误极大地影响了产品的质量。
当然，动态和静态测试发现的 bug 的类型和性质略有不同。 最好同时进行这两项活动，但是… . 如果您必须以相同的时间和成本在两个测试之间进行选择，我会毫不犹豫地推荐静态分析。
尽可能修改
我们经常看到进行静态分析而源代码没有进行相应修改的情况。在某些情况下，它会被跳过，因为它是微不足道的部分，或者因为它是与程序运行无关的缺陷。虽然考虑修复的时间和成本很重要，但尽可能修复代码以减少所有故障。
经验丰富的开发人员犯的错误更少。因为经验与习惯有关，而习惯来自于重复。不断修复错误代码对产品有好处，但也有助于开发者人员的编码习惯。我认为有经验的开发者都是有良好习惯的开发者。让我们假设静态分析不是一项繁琐的任务，而是帮助开发人员提高技能并推进他们的职业生涯。如果有一天，我第一次在静态分析器上运行代码，它的缺陷为零，那不是很好吗？静态分析和缺陷修复对开发人员比对正在发布的软件更有利。
即使制作精良，仍有改进的余地。
我期待着有一天我可以尽可能地改进它，并使我的经验成为一个不需要静态分析的优秀开发人员。
