Bug bash、ZBB与软件质量

jwjilove

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，其实与另一个测试方法有密切联系。在此之前，先说说错误收敛。

错误收敛

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



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

零错误反弹

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

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



        上图是一个60人的团队的“预想ZBB 进军图”。每个小组的bug数量累加起来，就是团队的bug总量。图中的黑线表明修复的bug总量。

fishy

。。。这个貌似是51Testing网站上的。。。。不用这么转来转去吧。。。