Bug Bash的来源与意义

要做好这样的活动，首先我们必须明白这项活动的意义。

Bug bash（Bug大扫除）来源于微软，通常发生在项目开发各阶段（微软叫里程碑）的末期，比如Beta版发布前，划出一个专门的时间段（通常1-3天），在这期间所有参与项目的人员，集中全部精力，运用各方面的知识，尽全部智慧来搜寻项目的Bug。

这是一个非常有意思的活动，但要组织好这样的活动并非易事。一般有以下要点：

（1）尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益；

（2）要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug；

（3）为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。

（4）可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。

（5）as usual we'll have pizza and other fun food. Sometimes there's prizes for most bugs kept, most heinous bug, etc.

ZBB（零错误反弹）--软件稳定的指示器

为什么要做Bug bash，其实与另一个测试方法有密切联系。在此之前，先说说错误收敛。

错误收敛(Bug Convergence)

错误收敛是指项目组在减少活跃错误数量上取得了重大进步的一个转折点。在错误收敛这一转折点上，解决错误的速度超过了发现错误的速度；因此实际的活跃错误数量开始减少。下图给出了错误收敛的图示。

即使错误数量从整体上开始减少，但具体数量还会出现升降变化，因此错误收敛通常来讲只代表一种趋势，而不是一个固定的时间点。在错误收敛之后，错误的数量将持续减少直到零错误反弹。

零错误反弹

Zero Bug Build：这一版本的构建把所有已知的bug都解决掉了。

Zero Bug Bounce：通常在一个Zero Bug Build之后，bug数目会反弹，故称Bounce。系统要经历几次bounce，像阻尼震荡一样，bug的数目在弹了几次之后，最后固定在（或者无限逼近于） 0。要注意必须保证bug的数量要到0，以防止一些问题拖而未决。

零错误反弹是指在项目中的某一点上，开发活动最终赶上了测试的步伐，当前已经不存在活跃错误。在零错误反弹之后，错误数量的峰值将显著减小，并且错误数量会持续减少直到产品足够稳定，进而构建出第一个候选发布版（RC,release candidate）。取得零错误反弹是项目组逐渐接近稳定的候选发布版的明确标志。

注意，在到达这一里程碑之后，必定还会发现新的错误。但是，它却标志着项目组能够第一次诚实地报告已经不存在活跃错误了，虽然这只是针对当前情况。而且它可以让项目组集中力量保持在这一点上。

事实上，正是通过bug bash的方式，来达到ZBB的效果。