测试的招数:ZBB

团队要有把Bug都搞定的执行力。ZBB=Zero BugBuild，即这一版本的构建把所有已知的Bug都解决掉了。Zero Bug Bounce:通常在一个ZBB之后，Bug数目会以惊人的速度反弹，故称Bounce。系统要经历几次反
弹，像阻尼振荡一样，Bug的数目在反弹了几次之后，最后固定在(或者无限逼近于)0。要注意必须要保证Bug的数量到0，以防止一些问题拖而未决，有些Bug长期拖而未决，有可能掩盖了深层次的设计问题，要尽早把这些问题暴露出来，而且划定一个时间期限，一定要解决。下图是一个60人团队的"预想ZBB进军图"。每个小组的Bug数量累加起来，就是团队的Bug总量。下图中的黑线表示已修复的Bug总量。

小飞:我注意到这一条预想变化线(到11/11为0)不是一条直线，好像中间断断续续有一些平缓的阶段。
阿超:看起来是每星期的周末，理论上周末两天没有人上班，因此团队也没有期望周末Bug数量会自动下降。
小飞:还是比较人性化。
大牛:我有一个问题，测试人员每天都有新的Bug要报告，开发人员修复一个缺陷需要走一天左右的流程，等到第二天，又会有新的Bug产生，所以这个"零"只是一个瞬间的状态，或者根本不能实现?
阿超:这里有一个技术细节，大部分的团队都是这样定义的:在这一时刻，我们系统内没有N天以前创建并且正在处理的Bug。N一般是2天。用移山项目的例子来说，就是:项目ZBB=此次构建中所有两天(48小时)以前报告的缺陷都已经处理。移山公司的例子:第一个ZBB达到了，同时产生了一个ZBB的构建，由于这个构建质量很好因此测试团队铆足了劲把各个部分都测试了一遍。同时也测试了复杂的场景，进行了效能和压力测试。结果报出不少新问题。因此ZBB之后的Bounce就跳得特别高。第二次ZBB后，由于各个模块质量的提高，这一次的反弹就低很多，随着每次ZBB过程中质量的加强，Bug的数目会越来越少。同时也有几个功能被砍掉，这些功能的Bug也就不计入总数。下面ZBB的趋势图显示了Bug经过几次反弹，逐渐到0的情况。