Java理论与实践:平衡测试，第1部分：不要仅编写测试，还要编写bug检测器 - 编程入门网

静态分析的主要作用是分析输出，并确定报告的条目是真的 bug 还是假警报 。编写的部分优秀分析工具或 bug 模式检测器会管理误报率；核心 FindBugs 包中的检测器已经进行了调优，目的是使误报率不超过 50 ％，这样分析输出时 不会有太多的烦麻。（将此阈值与针对 C 的 lint-like 工具进行比较，后者常 常发出许多假警报，使用时相当耗时。）

Java理论与实践:平衡测试，第1部分：不要仅编写测试，还要编写bug检测器(2)

将它提升一个级别

前面描述修复 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()，则会降低使用该库的应用程序的性能，开发人员 可能会感到很茫然，对性能会如此低下感动很奇怪。

编写

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!