原来，石头他爹手指不灵活，在按鼠标的时候鼠标的位置会稍稍移动，导致程序无法捕捉鼠标双击事件。问题是在小飞设计的游戏中，鼠标单击、双击都可以，而且是不同的功能。

　　同时，有些功能还只能够通过右键弹出菜单来执行。

　　石头他爹看起来很迷惑。这时，小飞说：左键/右键/单击/双击都可以。

　　从此之后，石头他爹对每一个操作都问：是按左键还是按右键？是按一下还是两下？

　　小飞露出了“faint”的表情。

　　半个小时后，大家送走了石头他爹，同时送他一个鼠标垫作为礼物。

　　阿超：（目送石头他爹的背影）幸好……

　　小飞：幸好啥？

　　阿超：幸好你还没有介绍你那超级功能，要按住Ctrl键，同时拖动鼠标才能使用。否则我们还要花半个小时陪石头他爹一起学习玩这个游戏。
　　“小强”大扫荡（Bug Bash）

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

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

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

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

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

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

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

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

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

　　◆  扰乱正常的测试工作；

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

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

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

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

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

　　讨论

　　1、十八般兵器

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

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

　　1）远景和计划阶段

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

　　2）开发阶段。

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

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

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

　　到了一个开发阶段的尾声，这时测试团队可以依据以前制定的验收标准，对软件逐项进行验收测试。按照测试计划，各个方面的测试都会宣布“测试完成”——所有想到的测试都做了，所有问题都发现了。在此阶段，团队也可以把软件发布给外部进行Alpha/Beta测试。

　　这时，伙伴测试会用于保证新代码签入前能得到足够的检测。

　　一般情况下，测试队伍要把迄今为止发现的所有小强都重新试一遍，确保它们都在后的版本中被清除了，没有一个“回归”出现。