对于许多团队来说，单元测试现在是开发过程的一个主要部分；JUnit 之类的框架可以进行无损测试，尽管我们并不喜欢它，宁愿为某些 代码编写某些 测试。单元测试运行效率很低，只能测试单个代码片段，并且，一般情况下，测试代码的重用性通常很也低 —— 昨天为组件 A 编写的测试不能很好地用于测试组件 B（示例代码除外）。
典型的单元测试场景
在发现 bug 时，要做的第一件事是什么？您可能只是想去修复它，但是，在长时间的运行中，这不是一个最有效的方法。在许多开发部门中，处理 bug 的过程如下：
针对 bug 编写测试用例
确保测试用例在遇到 bug 时运行失败
修复 bug
确保测试用例通过
确保其他测试套件仍能通过
检查修正和测试用例，形成版本控制
将修正记录在 bug 跟踪系统中
尽管此方法在短期内比仅修复 bug 要多做许多工作，但它提供了许多更有价值的东西：获得修复 bug 的更多信心，因为您已经对它进行了测试；获得 bug 将不会再出现的更多信心，因为测试用例是回归测试套件的一部分。在版本控制系统和 bug 跟踪系统之间，还可以获得一个记录，该记录描述了 bug 是什么以及如何修复它 —— 这是非常有用的信息，其他人会从中受益。
如果进取心较强，那么可以思考一下 bug 是怎样出现的，并在其他位置查找同一错误。如果在别处发现同一错误，那么可以对这些 bug 进行测试和修复。单元测试作为质量管理工具的主要弱点是每个测试用例只能测试一个代码片段。因为测试用例是专为每个组件和每个潜在错误模式设计的，所以只有编写足够多的单元测试才能测试大量的产品，这非常耗时并且代价高昂。
QA 经济
测试是一种基本的质量管理工具，我们知道仅有多组测试用例还不足以找出复杂软件片段中的所有 bug。事实上，对于任何优秀程序而言，“查找所有 bug” 是不可能实现的目标。据估计，NASA 向每个开发人员提供了 20 个测试程序（大大超过任何商业实体）来负责质量评价 (QA) —— 但软件仍有缺陷。因此，质量评价的目标不应是查找所有的 bug，因为这是不可能的。相反，质量评价的目标应该是提高代码运行良好的信心，从而最大程度地提供可用资源。
要高效运行质量评估量 (QA)，则需要对可用 QA 方法中的可用资源做预算，这样才能最大限度地提高信心。覆盖范围大的测试套件可以提高我们对代码使用的信心，因为它进行了一次彻底的代码审查。执行两次比执行一次较果好，因为每次都会发现另一次可能错过的错误。两次同样遵循收益递减规则，所以测试价值为 X 美元和代码审查价值为 Y 的 QA 计划要比价值为 X+Y 的任何一次测试或代码审查的效果好。
添加静态分析
静态分析是在不运行代码的情况下对其进行分析的过程，它与进行前面的代码审查时我们执行的操作非常相似，或者与标记可疑结构时 IDE 执行的操作非常相似。静态分析是添加到 QA 混合（QA mix）中的一项优良技术，因为它擅长查找其他方法（如测试和代码审查）可能错过的错误。静态分析相对比较容易一些，不像单元测试那样必须为要测试的每个类重新编写测试，您可以在任何代码上运行静态分析工具。
FindBugs 是一种开放源码的静态分析工具，它包含用于许多常见 bug 模式的 bug 模式检测器，令人惊讶的是，即使在测试良好的软件中，FindBugs 也常常会发现一些 “沉默” 的 bug，但是单元测试和专业代码审查都可能错过这些 bug。FindBugs 还允许编写新的 bug 模式检测器，并将它们包装为插件，所以如果一组标准的检测器不能按您的需要执行，那么您可以很容易地编写自已的检测器。此扩展性使 FindBugs 成为非常强大的质量管理工具，因为当发现新类型的错误时，可以针对该错误编写检测器，并在整个代码基址中搜索该错误。
静态分析的主要作用是分析输出，并确定报告的条目是真的 bug 还是假警报。编写的部分优秀分析工具或 bug 模式检测器会管理误报率；核心 FindBugs 包中的检测器已经进行了调优，目的是使误报率不超过 50 ％，这样分析输出时不会有太多的烦麻。（将此阈值与针对 C 的 lint-like 工具进行比较，后者常常发出许多假警报，使用时相当耗时。）
文章来源于领测软件测试网 https://www.ltesting.net/