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

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

对于许多团队来说，单元测试现在是开发过程的一个主要部分；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 模式检测器，并将它们包装为插件，所以 如果一组标准的检测器不能按您的需要执行，那么您可以很容易地编写自已的

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