Java理论与实践:平衡测试，第2部分：编写和优化bug检测器(5)

优化检测器

使用静态分析的最大消耗是处理假警报。静态分析不一定精确，其目标不是 发现 bug，而是只发现那些可能是 bug 的构造，这意味着有时会标记正确的代 码出错。如果代码审核工具产生 95％ 的假警报，那么任何人都不太可能想再次 使用它；第一次发现报告新 bug 的假警报真的很痛苦。所以对于一个有效的 bug 模式检测器，它必须最小化假警报数量，最好使假情报不超过 50％。

优化检测器的最佳方法是在 JDK 类库 (rt.jar)、Eclipse 或 JBoss 之类的 大型代码基址上运行它。所以在编写 bug 检测器后，应该试着在新的项目和示 例上运行它，以查看它们是真实的 bug，还是假警报。对于非凡的检测器（比如 这里开发的检测器），第一次体验常常有点让人失望—— 假警报比预期的多。

优化检测器的过程包括查找假警报和细化 bug 模式，以消除某些假警报，同 时不要将太多的真实 bug 排除在外。为细化模式，可以执行的操作之一是消除 以下情况：存在零或 try 块中抛出已经过检查的异常；在这些情况下，捕获 Exception 不可能导致尝试合并多个捕获块，而会导致反映对捕获未经检查的异 常的真实愿望。此修改对假警报率有很大的影响。

优化检测器通常包括 “得分” 算法的使用，以确定是否将匹配报告为 bug 。通过使用几个因素可执行其他调优，以增加或减少对给定实例的 “信心得分 ”。某些方面（如不存在任何已检查的异常）可以减少候选匹配的得分；其他方 面，比如捕获异常失效方面（在捕获块中不使用），可以增加候选匹配的得分。清单 7 显示了对此检测器进行优化后形成的得分算法；它将优先级用作得分， 因为在某一阈值上具有优先权的 bug 被 bug 报告的框架忽略（较高优先级的值 指示的实际 bug 的严重性较低）。

清单 7. 优化后 RuntimeException 捕获检测器使用的得分算法

if　(!rteCaught)　{ 　　 int　priority　=　LOW_PRIORITY　+　1; 　　 if　(range　>　300)　priority--; 　　 else　if　(range　<　30)　priority++; 　　 if　(catchClauses　>　1)　priority++; 　　 if　(thrownSet.size()　>　1)　priority--; 　　 if　(caughtException.dead)　priority--; 　　 bugReporter.reportBug(new　BugInstance(this, 　"REC_CATCH_EXCEPTION", 　　　　　　 priority) 　　　　　　 .addClassAndMethod(this) 　　　　　　 .addSourceLine(this,　caughtException.sourcePC)); }

结束语

为静态代码分析工具（如 FindBugs）编写自定义 bug 检测器可以显著提高 代码质量，并且有许多乐趣。尽管编写和优化 bug 检测器非常困难（优化它们 对确保其能够使用非常重要），用检测器捕获 bug 模式的信息要付出高昂的代 价，但是，使用这些信息能够花费少量工作来扫描任何项目中的 bug 模式，从 而使您对最愚蠢的 bug 查找方式感到惊讶。

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