Java 编程: 平衡测试（一）

典型的单元测试场景

 

　　在发现 bug 时，要做的第一件事是什么?您可能只是想去修复它，但是，在长时

 

间的运行中，这不是一个最有效的方法。在许多开发部门中，处理 bug 的过程如下：

 

　　针对 bug 编写测试用例

 

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

 

　　修复 bug

　　确保测试用例通过

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

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

 

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

 

　　尽管此方法在短期内比仅修复 bug 要多做许多工作，但它提供了许多更有价值

 

的东西：获得修复 bug 的更多信心，因为您已经对它进行了测试;

 

获得 bug 将不会再出现

 

的更多信心，因为测试用例是回归测试套件的一部分。在版本控制系统和 bug 跟踪系统之

 

间，还可以获得一个记录，该记录描述了 bug 

 —— 

是什么以及如何修复它

这是非常有用

的信息，其他人会从中受益。

 

　　如果进取心较强，那么可以思考一下 bug 是怎样出现的，并在其他位置查找同

 

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

　　QA 经济

　　测试是一种基本的质量管理工具，我们知道仅有多组测试用例还不足以找出复

 

杂软件片段中的所有 bug

“

 

。事实上，对于任何优秀程序而言， 查找所有 bug” 是不可能实

现的目标。据估计，NASA 

 

向每个开发人员提供了 20 个测试程序(大大超过任何商业实体)

 

来负责质量评价 (QA) —— 但软件仍有缺陷。因此，质量评价的目标不应是查找所有的