下面讲一下模型的用法。一般的软件测试过程，都有3个阶段，从上面的图中能清楚的看出来。
阶段1：测试组对系统开始进行全面测试，打开bug的速度明显高于关闭bug的速度，活动bug数急速上升，当完成了全部测试用例的执行时，活动bug数达到最大；
阶段2：开发组全力修复bug，测试组一边验证bug，一边小范围的回归测试，验证bug的周边功能。这时，关闭bug的速度高于打开 bug的速度，活动bug数回落。当活动bug数刚开始回落的时候，称为“bug收敛”。最终，活动bug会降到一个很低的位置，有时，会达到“零bug ”，不过，这并不说明项目可以发布。
阶段3：测试组再次对软件系统进行一次完整的回归测试。在这个过程，还会打开一些bug，但是，数量很少，这称为“零bug反弹”。完成了这一轮回归之后，软件才真正稳定下来，进入发布候选过程。
所以，我们可以通过这两个模型，来检查项目的测试进展是否正常，软件的质量是否稳定，检查方法如下：
* 如果第二阶段已经开始，但是活动bug仍在继续上升，没有回落，说明打开bug速度仍很高，可能是第一阶段用例执行还没有完成，或者开发组修复bug速度较低；
* 如果第二阶段结束，活动bug没有回落到低水平，说明大量的bug还需要修复，软件质量低；
* 如果第三阶段，打开、关闭bug的次数很多，说明bug活动频繁，系统稳定性差。
因此，正常的项目测试应该是，活动bug先上扬，再回落，最后在低位小幅振荡，并且打开关闭次数很少。有了这两个分析模型，我们对项目进度得控制，就更有把握了。
推荐阅读：
