探讨一下测试的主动权（和当时的讨论有关系，呵呵，特定环境）。

　　呵呵，怎么感觉测试和开发是对立的关系呢？不是东风压倒西风，就是西风压倒东风。但我个人不这么认为，当然，如果BUG数成了考核的内容，那当然就不同了。

　　不过我还是建议，把部门、角色间人的关系按照项目管理来管吧。所有的人情事故都放在桌面上管理，就是沟通吧。

　　今天讨论的第一个问题：测试的轮数。测试要几轮才算是结束呢。无限……当然，也是不可能的，所以公司可能就规定是3轮，5轮，第一轮做什么？第二轮……我觉得也没有问题，BUG是永远找不完的。公司规定的3轮可能是从公司的平均生产率上总结出来的。当投入产出比平衡时，测试就应该结束了。

　　做软件的也知道，计划永远赶不上变化，规定永远都会有特殊。这就是我们讨论的具体问题具体分析了。

　　首先，一般的情况下，不要把冒烟测试定义了一轮测试。也许你冒烟不通过，领导说测吧测试，测试总比不测试好。但实际上并不是这样，因为冒烟测试已经测试了产品的必须功能，这些是下面正式测试的基础。如果这些都不通过的话，后面可能大量的测试是无意义的。更不能采用其它特殊的方法勉强去完成测试，因为你临时调整的测试环境，换了旧的包之类的，都会导致这次测试并不真实，是可以尽早发现错误，但投入的测试资源和发现的BUG数远不成比例。 并且，你每次不可测试的版本都接收的话，那么，下一次、下下一次可能同样不合格的版本不停地提交过来。这样一来加大了测试人员的工作量；其次，测试人员发现BUG、记录BUG、开发修改还要通过BUG管理流程走一遍，其反工成本是大了几倍的。所以请把冒烟测试不通过的版本扔回去了。合格了再入来。

　　其次，每次的测试是应该根据计划来执行的，哪怕你的计划就是两行字。一旦计划有变更，象增加原来遗留BUG的返测。需要修改计划的。这里面有两个问题：1、你计划测试前，你应该考虑原来产品遗留的BUG是否需要返测。如果计划时没有考虑到这个风险，此时就比较被动了。 2、不得已的情况加入了，那计划一定要调整。不要把你有限的资源花在未计划的工作上，导致计划的工作不能完成。多做工作并不见得总是好事。完成目标才是第一位的。

　　第三，不要在测试过程中随意增加资源。原因：1、增加资源带来学习成本。2、增加资源在短期内是降低生产率的。即使你发现了更多的BUG。但发现BUG的成本远大于你投入的成本。假设你每测试人员每天发现10个BUG。你增加了两个测试人员，一天总共发现了18个，看视发现的BUG多了，实际上总的生产率是下降的。3.这也是计划的变更，增加了资源，就要增加下一轮的测试。不要就此结束，否则看起来，你原来的测试是有问题的，因为按照这样的理论下去，你增加10个8个人后，BUG就变成了7、80个了。4、可能你原来的测试真是有问题的，那么，继续吧。别停止。

　　第四，易用性的测试。易用性测试是开发关注最小，用户关注最多的。找两个方法吧：1、站在用户的角度上不停地向开发灌输易用性的重要。停止从开发的角度看BUG.  2、总结出易用性注意列表，提前给开发，让这些问题消灭到萌芽阶段。3、易用性注意列表不起作用怎么办？　那就是执行的方法问题了，不行的话用行政手段吧，呵呵。

　　第五，BUG的质量。可能100个问题出现1个质量有问题的BUG，可以不关注，但是写BUG的时候，要想想，开发是我们BUG的用户。站在他们的角度上考虑一下吧。BUG描述的不清楚，难以重现，属于重复……都会让我们的用户对我们有意见。当然要考虑BUG评审的投入产出比。但我们可以通过一些方式去改进。1、不停地强调BUG质量的重要性，测试人员在写BUG时就要特别注意。2、增加BUG审核，尤其到新的测试人员提交的BUG来说。3.增加客户满意度调查，哈哈，就是开发的反馈。

　　呵呵，写这么多吧。感觉和测试的轮数没有什么直接的关系。只是轮数如果限制了，各种各样的变化又发生了，结果导致测试很被动。

　　最后一句：如果你改变不了整个公司，就改变自己的部门吧；如果你改变不了自己的部门，就先改变一下自己吧。

版权声明：本文出自雪儿的51Testing软件测试博客：http://www.51testing.com/?1800

原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。