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 工具进行比较，后者常常发出许多假警报，使用时相当耗时。)

　　将它提升一个级别

 

　　前面描述修复 bug 的方法(首先编写测试用例，然后检查修复和测试用例)反映了

 

这样一个愿望：不仅要修复 bug，还要提高修复它的信心，并记录如何修复它，以及何

 

时修复它。此方法比仅修复 bug 要多做许多工作，但是它给我们提供了更多的信心，我们

 

的代码在经过多个开发人员的不断修改后可以继续使用。不过，仅为所发现的 bug 编写测
试用例是一种消极方法。在代码失败之前，我们希望尽可能以最佳实践分析代码。

 

　　清单 1 

 

通过 BigDecimal 

 

类说明了常见的 bug。BigDecimal 是固定不变的，所以算

术方法(  

如 add())

 

会返回一个新的 BigDecimal 作为其结果，而不修改调用它们的对象。清

 

单 1 中的代码显然被假定为有条件地将运输费用添加到总体订购价格中，但是，实际上

 

不能随意添加任何内容，因为 add() 的返回值被丢弃了：