软件开发过程中的测试管理[3]

        但是光进行测试案例的执行、按照事先设计好的使用步骤来测试软件的使用状况，只能达到上面所讲的第一个目的，却无法满足第二个目的。原因是，当你的软件在众多的使用者手中被使用时，用户们不见得一定会按照你所设计好的、或所期望的步骤来使用软件，而是任意地使用的。这个时候软件就有可能由于设计得不当或内部的缺陷而发生各种不同严重程度的问题。这一类的问题光用测试案例的执行不见得可以找得出来、而且通常往往是找不出来的。所以与执行测试案例的执行相并列的，还需要进行一系列的与正常的使用方案并不一样、甚至毫无关系的测试。这一类的测试是尽量找出在非正常或随意任意使用的情况下可能出现的Bug。

        对这样的测试目的，我们采用两种手段来达到：第一种手段是由测试团队设计并执行各种非正常性的测试，包括边界测试、压力测试、安全测试、以及进行一定数量的随机任意性测试（这些测试种类的详细定义见书中的解释）。这样的一些测试可以找出很多在正常使用情况下无法发现的缺陷。但是光靠测试团队的有限人力和资源，还是无法照顾到大量的随机任意性状态下可能发生的出错情况。所以你还得想办法“动员群众”来达到最好效果。微软的企业文化在这方面有两个很有意思的传统，值得国内业界的借鉴：

        第一个叫“抓虫大扫除”（Bug Bash）：在某一个版本的发行里程碑到达之后，在发行之前项目经理向全体开发组织发出通知，告诉大家哪一天的某个时间是Bug Bash的时间，到时候全体成员，包括开发、测试、文档等团队、甚至市场部门的员工，全都放下手中的工作，在规定的那一个或几个小时的时间里，每个人把自己当作是用户一样来使用这个未成品的软件，并且进行竞赛，看谁能找到最多的Bug。这样做的目的是，不是按照测试方案的顺序来检查软件，而是通过像真正的用户那样来使用软件，即完全是任意性的、无规则的顺序，看看在这样的使用条件下，还有没有仍旧没有被发现的严重的Bug。 我们往往采用谁找到最严重的Bug 就得奖的方法来鼓励大家尽力找出Bug。抓虫大扫除一结束，项目经理马上进行新呈交的Bug数量的统计，然后向开发组织中的全体员工公布。得奖的小有免费的咖啡、午餐、电影票等，大有各种礼物。所以每次Bug Bash 大家都踊跃参加，找到很多测试案例执行时没找到的问题。

        抓虫大扫除对任意性的手动式的测试很有效，但对任意性的自动测试则效率有限。所以我们又采用第二个手段：“分享大家的计算机”（Machine Share）：当我们在测试服务器产品时，需要模拟成千上万的使用者同时使用服务器的情况、或是需要模拟大量的黑客攻击的情况。这时候测试团队的机器往往不够用，还需要大量额外的机器加入到这样模拟中来。这时测试团队就会去逐个请求其他员工、 请他们在下班后不使用计算机的时候，在他们的机器上运行模拟大量使用或攻击的程序。谁的机器上的程序造成了服务器的崩溃或造成攻击成功，这个机器的主人就会得到一个免费的冰淇淋。有个人的机器连续三次攻击成功，测试团队还制作了一个巨大的冰淇淋画像挂在他办公室门前的走廊上，第二天上班大家都看到、并昵称他为黑客大王。

        总结以上综述，完善的测试是保证软件质量的关键手段，而要做到测试的完善，需要制定完善的测试计划，同时还需要开发团队为达到两种测试的目的进行带创意的各种执行手段来找出各种缺陷和差错 。

        这里对测试计划的管理理念以及TDD等概念作了一个简单的介绍。有关测试计划的细节、测试方法的种类等，你可以进一步参阅《软件开发项目管理》一书。在后面的连载文章里，我会再来阐述和讨论采用敏捷模式进行开发的一些实践指南。你要是对如何进一步提高你的软件质量有兴趣或有责任负责推动项目管理的改革，可以通过网络进一步了解业界在这方面的发展以及最新的动态。

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