移山 - 软件测试讨论(6)

　　1.14 Bug Bash

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

　　答：简而言之，就是大家一起来找小强的活动 – 小强大扫除。一般是安排出一段时间(一天)，所有测试人员(有时也加入其他角色)放下手里的事情，专心找某种类型的小强。然后结束时，统计并奖励找得最多的，和最厉害的小强的员工。这种活动，如果运用得好，有下面的作用：

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

　　鼓励测试队伍学习并应用新的测试方法，例如在做完“软件安全性测试”培训后，立马做一个针对“安全性”的小强大扫除.

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

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

　　扰乱正常的测试工作

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

　　两个细节是：

　　1.一定要让“小强大扫除”有明确的目标，明了的技术支持。

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

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

　　2总结和思考

　　2.1十八般兵器

　　阿毛：超总, 我的脑袋好像装不下了!? 听了这么多，我感觉像是身上扛着十八般兵器，累得半死，但是不知道什么时候，对哪一种敌人用哪一种兵器，能不能总结一下!

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

　　远景和计划阶段：

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

　　开发阶段：

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

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

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

　　稳定阶段：

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

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

　　发布阶段：

　　测试队伍要把尽可能多的测试用例自动化，并为下一个版本的测试工作做好准备。

　　2.2构建的质量

　　1.编译失败

　　2.可测/不可测

　　3.可用/不可用

　　2.3问题

　　2.3.1 如果连续几天都不能产生“可测”版本，怎么办?

　　提示：可以在下一个构建版本中限制签入的数量，只接受那些高等级的修改，在一般的做法中，导致“不可测”的小强的严重性是1，必须在下一个构建开始的时候得到改正。

原文转自：http://www.ltesting.net