15.11 向ZBB进军
啥是ZBB？即：
Zero Bug Build：这一版本的构建把所有已知的bug都解决掉了。
Zero Bug Bounce：通常在一个Zero Bug Build之后，bug数目会以惊人的速度反弹，故称Bounce。系统要经历几次bounce，像阻尼震荡一样，bug的数目在弹了几次之后，最后固定在（或者无限逼近于） 0。
要注意必须保证bug的数量要到0，以防止一些问题拖而未决。
图15-8是一个60人的团队的“预想ZBB 进军图”。每个小组的bug数量累加起来，就是团队的bug总量。图中的黑线表明修复的bug总量。
图15-8ZBB计划图
小飞：我注意到这一条预想变化线（到11/11为0）不是一条直线，好像中间断断续续有一些平的阶段。
阿超：看起来是每星期的周末，理论上周末两天没有人上班，因此团队也没有期望在周末的时候bug 数量会自动下降。
小飞：还是比较人性化。
阿亨：我有一个问题，测试人员每天都有新的bug 要报告，开发人员修复一个缺陷需要走大约一天左右的流程，等到第二天的时候，又会有新的bug 产生，所以这个“零”只是一个一瞬间的状态，或者根本不能实现？
阿超：这里有一个技术细节，大部分的团队，都是这样定义的：在这一时刻，我们系统内没有N天以前创建同时又是Active 的bug。N 一般是2天。用移山项目的例子来说，就是：
Stone项目ZBB =此次构建中所有2天以前报告的缺陷都已经处理。
移山公司的例子：
第一个ZBB，划了线，达到了。同时产生了一个ZBB 的构建，由于这个构建质量很好，因此测试团队铆足了劲把各个部分都测试了一遍。同时也测试了复杂的场景，进行了效能和压力测试。结果报告出来不少新问题。因此ZBB 中的Bounce就跳得特别高。第二次ZBB 后，由于各个模块质量的提高，这一次的反弹就低很多，随着每次ZBB过程中质量的加强，bug 的数目会越来越少。同时也有几个功能被砍掉，这些功能的bug 也就不计入总数。因此ZBB 的趋势图显示了bug 经过几次反弹，逐渐到0的情况（如图15-9所示）。
图15-9bug ZBB趋势图，横坐标是构建的版本号
15.11.1最后回归测试
在临近项目结束的时候，所有人员（开发、管理、测试）都要回归测试所有的bug。每个人都要帮助团队确保这些bug 的确是被修复了。而且别的更改没有导致功能的“回归”。从便于管理考虑，我们可以再加入一个新的字段标记某bug已经被回归测试过。
15.11.2冻结
随着程序功能的完善，我们要让程序的各个方面有次序地“冻结”，这样才能把稳定的软件交付给用户。一般来说，程序的人机交互界面最先开始“冻结”，不能再随意修改，因为很多项目的文字信息要被本地化成多种语言，当人机界面所用的文字和排版（layout） 固定后，我们才能把这些文字交给负责本地化的部门。随着时间的推移，一些功能也可以“冻结”，这些功能都经过全面测试，所有的bug 都解决了，功能进入稳定状态。在下一个版本前不要再碰和此功能相关的代码。
15.11.3侵官之害甚于寒
昔者韩昭候醉而寝，典冠者见君之寒也，故加衣于君之上，觉寝而说，问左右曰：“谁加衣者？”左右对曰：“典冠。”君因兼罪典衣与典冠。其罪典衣，以为失其事也；其罪典冠，以为越其职也。非不恶寒也，以为侵官之害甚于寒。
——《韩非子·二柄第七》
九条：（来找阿超）我最近新建了不少bug，今天发现它们都变成了closed，本来要测试的bug 都变成了关闭状态，我还用测试么？
阿超：是别的测试人员替你测试了么？
九条：没有，从记录上看是果冻修改了这些缺陷，然后把状态变成resolved，过了两天他又把状态变成 closed，但是我还没有运行验证测试呢。
他们把果冻找来了。
果冻：我是看着我的bug 老是没有关闭，心里很着急，然后昨天我就认真地把所有bug 验证了一遍，确信没有问题后，就把它们顺手关闭了。
九条：是不是你的领导在统计你的bug 数目了？呵呵。
阿超：不同的角色在开发过程中有相互合作，相互制约的作用，不能替代。测试人员在做验证测试时，需要做多方面、多平台的测试，这些工作量，也许远远超过了开发人员的能力范围。因此，必须要由测试人员来验证并处理已经修理好的bug。
侵官之害甚于寒——我们不是不鼓励开发人员主动帮助测试，我们是要避免导致职责不清的越界行为。
