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

核心提示：对于许多团队来说，单元测试现在是开发过程的一个主要部分；JUnit 之类的框架可以进行无损测试，Java 理论与实践: 平衡测试，第 1 部分：不要仅编写测试，还要编写 bug 检测器，尽管我们并不喜欢它，宁愿为某些 代码编写某些 测试，因为测试用例是专为每个组件和每个潜在错误模式设计的，所以只有编写足够多的单元测试才

对于许多团队来说，单元测试现在是开发过程的一个主要部分；JUnit 之类的框架可以进行无损测试，尽管我们并不喜欢它，宁愿为某些 代码编写某些 测试。单元测试运行效率很低，只能测试单个代码片段，并且，一般情况下，测试代码的重用性通常很也低 —— 昨天为组件 A 编写的测试不能很好地用于测试组件 B（示例代码除外）。

典型的单元测试场景

在发现 bug 时，要做的第一件事是什么？您可能只是想去修复它，但是，在长时间的运行中，这不是一个最有效的方法。在许多开发部门中，处理 bug 的过程如下：

针对 bug 编写测试用例

确保测试用例在遇到 bug 时运行失败

修复 bug

确保测试用例通过

确保其他测试套件仍能通过

检查修正和测试用例，形成版本控制

将修正记录在 bug 跟踪系统中

尽管此方法在短期内比仅修复 bug 要多做许多工作，但它提供了许多更有价值的东西：获得修复 bug 的更多信心，因为您已经对它进行了测试；获得 bug 将不会再出现的更多信心，因为测试用例是回归测试套件的一部分。在版本控制系统和 bug 跟踪系统之间，还可以获得一个记录，该记录描述了 bug 是什么以及如何修复它 —— 这是非常有用的信息，其他人会从中受益。

如果进取心较强，那么可以思考一下 bug 是怎样出现的，并在其他位置查找同一错误。如果在别处发现同一错误，那么可以对这些 bug 进行测试和修复。单元测试作为质量管理工具的主要弱点是每个测试用例只能测试一个代码片段。因为测试用例是专为每个组件和每个潜在错误模式设计的，所以只有编写足够多的单元测试才能测试大量的产品，这非常耗时并且代价高昂。

QA 经济