在谈论Bug Bash之前需要先介绍下Bug Bash的来源和意义以及ZBB（零错误反弹）

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

　　2、ZBB（零错误反弹）：

　　Zero Bug Build：这一版本的构建把所有已知的bug都解决掉了、或者是目前活跃的BUG趋近于0、或者指在项目中的某一个点上，开发活动最终赶上了测试的步伐，当前已经不存在活跃错误。

　　Zero Bug Bounce：通常在一个Zero Bug Build之后，bug数目会以惊人的速度反弹，故称Bounce。系统要经历几次bounce，像阻尼震荡一样，bug的数目在弹了几次之后，最后固定在（或者无限逼近于）0。

　　Bug Bash注意事项：

　　Bug Bash是一个非常有意思、有挑战性的活动、但要组织好这样的活动并非易事。一般有以下要点：

　　（1）尽管这是一个测试活动，但参与者不能仅限于测试人员、建议是整个项目组成员都参加、包括项目经理，产品经理、开发人员。如果高层管理人员能参加就更好了，如同全民动员。目的是要集思广益。

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

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

　　进过上面的一番介绍对Bug Bash有了一定的了解、那么我们可以考虑下

　　起因：

　　1、产品准备要实测了、

　　2、或者是测试活动中已经2周没有BUG产出

　　3、再或者是BUG已经趋近于0了、也就是达到了ZBB（零错误反弹）的临界点了。

　　目的：

　　1、调动全组积极性，换一种思维和方式执行测试

　　2、市场和需求人员从用户的角度分析，会发现一些测试人员想不到的问题；

　　3、开发人员知道从代码、白盒的角度分析问题会发现测试人员想不到的问题；

　　4、提早发现bug，降低软件风险

　　5、长期的测试容易使得测试人员形成思维定式或疲惫，通过这个小活动增加软件测试的趣味性和新鲜感

　　风险：

　　1、大家的积极性都是被调动、奖励机制一定需要、而且也要强调这个活动的必要性和重要性

　　2、所有参与Bug Bash的人员的时间需要保证

　　3、产品版本的稳定性必须要保证

　　4、各个部门领导对Bug Bash的支持程度