将它提升一个级别
前面描述修复 bug 的方法（首先编写测试用例，然后检查修复和测试用例）反映了这样一个愿望：不仅要修复 bug，还要提高修复它的信心，并记录如何修复它，以及何时修复它。此方法比仅修复 bug 要多做许多工作，但是它给我们提供了更多的信心，我们的代码在经过多个开发人员的不断修改后可以继续使用。不过，仅为所发现的 bug 编写测试用例是一种消极方法。在代码失败之前，我们希望尽可能以最佳实践分析代码。
清单 1 通过 BigDecimal 类说明了常见的 bug。BigDecimal 是固定不变的，所以算术方法（如 add()）会返回一个新的 BigDecimal 作为其结果，而不修改调用它们的对象。清单 1 中的代码显然被假定为有条件地将运输费用添加到总体订购价格中，但是，实际上不能随意添加任何内容，因为 add() 的返回值被丢弃了：
清单 1. 典型的 bug 模式 —— 使用 mutator 方法配置 factory 方法
public class ShoppingCart {
private BigDecimal totalCost;
private boolean qualifiesForFreeShipping() { ... }
private BigDecimal getShippingCost() { ... }
public void checkout() {
...
if (!qualifiesForFreeShipping())
totalCost.add(getShippingCost()); //WRONG!
}
}
清单 1 中的错误是一种常见的错误，它忘记了对象是不可变的，从而将 factory 方法误认为 mutator 方法。如果在代码中查找此类错误，就会发现存在同一错误多次发生的情况，因为它来源于对特定库类工作方式的误解。对于查找此 bug，负责任的开发人员可能会搜索整个代码基址来查找对 BigDecimal.add()、subtract() 等方法的调用，并寻找忽略返回值的其他实例。
此策略是一个好的开头，但我们可以做得更好。在这里识别 bug 模式是非常容易的 —— 忽略不可变对象上的求值方法（value-bearing method）的结果。识别出该模式后，构建识别此模式的检测器是相对简单的一件事件。（FindBugs 在核心检测器集中有这样一个检测器。） 此技术不仅可以应用于 BigDecimal，还可以应用于其他不可变类（如 BigInteger、String 或 Color）中。
花费一点时间为 bug 模式创建一个 bug 检测器，它会为您带来可观的收益。不仅可以用比手工操作更少的工作和更高的信心来审核整个项目，从中寻找 bug，而且还可以在现在和将来将同一检测器应用到其他项目中。您已针对不断恢复、随时可能出现的 bug 类型建立了防御机制，而不是在逐个实例的基础上解决 bug。
示例 bug 检测器
为说明编写 FindBugs 检测器的过程，我们编写了一个简单的检测器，它可以查找对 System.gc() 的调用。（下载此示例检测器代码的 源代码。） 虽然调用的 System.gc() 不一定是 bug，但在实践中，它会带来更多的问题（多于它解决的问题 ）。尤其是，如果错误地调用了库中隐藏的 System.gc()，则会降低使用该库的应用程序的性能，开发人员可能会感到很茫然，对性能会如此低下感动很奇怪。
编写 bug 检测器的第一步是识别被检测的 bug 模式。在本例中，该模式非常简单，只需调用 System.gc() 即可。要编写识别字节码中此模式的检测器，则需要知道对应于 bug 模式的字节码是什么。了解此问题的最好方法是编写一个包含 bug 的小程序，对它进行编译，并使用 javap -c 解开 .class 文件。清单 2 显示了一个展示该 bug 的类：
文章来源于领测软件测试网 https://www.ltesting.net/
