最近我们确定了一系列考评开发工作质量的指标，比如初级Bug率，Bug关闭时间等等，不知不觉开发团队的压力大了很多，因此有开发人员来问：怎么都是考评开发的啊，测试工作的好坏怎么考评呢？今天我们就来讨论一下这个问题。
1、测试遗漏Bug数
这是绝大多数测试团队都会使用的重要指标，淘宝测试也在用。用这个指标的目的也非常明确：经过测试团队的验证，就应该把软件中的大部分Bug都找出来。如果我们测完了，产品也发布了，结果又出现了一些既严重，又明显的Bug，那无论如何都说不过去了。
测试遗漏Bug可以分为“故障”和“普通Bug”两类，故障最好是一个都别有，普通Bug么，一般都会有一些，但数量也不能超过一个上限，具体的数字可以根据产品的特点，团队的现状，讨论后决定。
问题：虽然我遗漏的Bug比他多一点，但是我每个月测试的功能比他多多了，做的多就错的多啊，这样公平么？
这样肯定不公平。所以只考评遗漏Bug数，是很片面的，这里必须引入另一个指标，与遗漏Bug来制衡，这个指标就叫做：
2、测试工作产能
测试产能简单来说就是单位时间内，团队或者个人所测试完成的功能的数量。在最近的季度总结会上，我们统计了一下各个测试团队完成的项目和日常（淘宝术语，相当于微型的项目）的数量，以此来分析产能的高低。
问题：有的项目做半年，有的只做一个月，日常也有大小之分，这样统计出来，不太靠谱吧？
确实不靠谱，只统计到项目、日常的个数，太不精确了。我们必须要找到一个科学的“一般等价物”，用来标识一个项目或者日常的规模。值得庆幸的是，软件工程学科里已经有了一个标准的模型以及算法，它叫做：
功能点！
有了功能点计算的标准，我们再根据互联网软件的特点做一些调整，就能拿出一个解决方案，对每个项目和日常的功能点进行计算，比如A项目500个功能点，B日常20个功能点。有了这些数字，很多信息就一目了然了。我们其实没必要对测试用例数、Bug数做度量，因为我们比的不是谁的用例写的多，谁的Bug提的多，而是比谁测得又快又好。把每个项目的用例都写得近乎标准和完美，产能反而会下降。
问题：开发只修改了一个功能点，但是我必须测试很多用例才能保证功能没问题，这样算，那我的产能不是很低了，这样公平么？
这个问题我们先不回答，并且要反问这样一个问题：开发改了一个地方，我们是不是真的有必要把上面的功能全部回归测试一遍呢？汽车换了一个轮子，有必要把发动机也拆开测试一下么？
这里有一个观点要澄清一下，测试人员不仅要熟悉需求业务，也要对产品的程序结构有所了解。这样一旦开发人员修改了程序的某个功能，我们测试就可以分析出来，哪些功能被影响了，需要重点测试；而没有被影响的部分，少测或者不测。
如果开发修改的是底层的代码，那么用单元测试就可以很好的覆盖，web应用层只需要测试关键的功能点即可。如果web应用层也有自动化脚本可以覆盖，那就更爽了。这也就是淘宝测试正在推行的“珠联璧合”的精髓所在。（珠联璧合：一种多种测试策略混合的测试模型）。
所以，在珠联璧合的模式下，我们不是比谁写的脚本多，也不是比谁写的脚本快，比的是，谁能灵活运用各种脚本，让验证功能点的速度达到极致。因此，只要我们能把珠联璧合运用自如，上面那个问题也就自然消失了。
还有一个重点需要指出，测试环境的稳定性，对于测试产能来说非常重要。测试环境要是三天两头挂，大把的时间用来等待和调试，产能是根本上不去的。每个团队的manager都要想办法保证环境稳定。
说了这么多，我们可以推理出这样一个结论，如果一个测试团队的产能很高，并且遗漏的Bug也很少，那我们就可以肯定，这个测试团队做的很出色。因为这两个指标，几乎体现了优秀团队的所有品质：无间的合作、流畅的沟通、综合的技术、强烈的责任感等等，只要其中一环出了问题，团队成绩都会出现明显的下降。
