“小强”大扫荡（Bug Bash）

　　问：我们已经讲了太多的测试了，好像微软还有一个叫“Bug Bash”的活动，是啥意思？

　　答：Bug Bash，或者叫Bug Hunt，简而言之，就是大家一起来找小强的活动——小强大扫荡。一般是安排出一段时间（一天），所有测试人员（有时也加入其他角色）放下手里的事情，专心找某种类型的小强。然后结束时，统计并奖励找得最多和最厉害的小强的员工。

　　问：这是不是可以看做是“全体动员Ad hoc”？

　　答：一般情况下是的，但是并不是全体人员用键盘鼠标一通乱敲乱点就可以搞定，大扫荡的内容也应该事先安排好。

　　这种活动，如果运用得好，会带来这样的功效：

　　◆  鼓励大家做探索试的测试，开阔思路；

　　◆  鼓励测试队伍学习并应用新的测试方法，例如在做完“软件安全性测试”培训后，立马做一个针对“安全性”的小强大扫荡，或者为“全球化/本地化测试”做一个小强大扫荡也是很常见的；

　　◆  找到很多小强，让开发人员忙一阵子。

　　当然，小强大扫荡也有一些副作用：

　　◆  扰乱正常的测试工作；

　　◆  如果过分重视奖励，会导致一些数量至上，滥竽充数的做法。

　　因此，两个需要提醒的细节是：

　　（1）一定要让“小强大扫荡”有明确的目标、明了的技术支持。

　　（2）一定要让表现突出的人介绍经验，让别人学习。

　　要记住，最好的测试，是能够防止小强的出现。

　　讨论

　　1、十八般兵器

　　阿毛：超总，我的脑袋好像装不下了！听了这么多，我感觉像是身上扛着十八般兵器，它们互相碰撞，叮叮当当。我累得半死，但是不知道什么时候，对哪一种敌人用哪一种兵器，能不能总结一下！

　　阿超：好，我们用软件开发的生命周期来说明一下不同的测试在不同阶段的使用。

　　1）远景和计划阶段

　　此时，测试只是处于计划阶段，我们要讨论测试计划和测试设计说明书，同时要收集用户对于软件非功能性的需求，如效能、可用性、国际化等。一些“小强大扫荡”的类型也可以在这个时候初步安排。

　　2）开发阶段。

　　开发人员要写单元测试，测试人员要写BVT。

　　对于每一个成功的构建，测试人员要运行功能测试/场景测试，同时建立回归测试基准以便开始回归测试。各类测试人员要进行探索式测试以求尽早发现问题。

　　随着软件功能的逐步完善，测试人员要进行集成测试。这时，团队可以开展对程序非功能性特性的测试，如效能/压力测试、国际化/本地化测试、安全性测试、可用性、适用性测试等。在这个时候，可以考虑分析各个模块的代码覆盖率，以增加测试的有效性。根据计划，各种类型的“小强大扫荡”会以适当的频率发生。