绩效是产出的评价而不是产出本身
我们遇到的一个很鲜明的例子就是把测试用例的数量作为绩效考核之一。实际上如果你的测试流程中没有严格的测试用例评审环节，请边缘化这个纯工作量的指标，因为你对它没有评价。把它作为一个重要指标并不会提升你的测试同事们的用例水平，只会引导他们进一步减小用例的颗粒度。
倘若你的目标就是通过绩效来提升用例水平呢？如果是加入评价，用例评审后的问题数量占比，用例的遗漏情况等等这些评价后的结果作为绩效我们暂时称之为有效的。工程师们会加大检查自己用例的力度，去换取用例质量的提升，这里的提升主要是覆盖情况和用例的正确性，可执行性。
换句话说，我们通过绩效提升了测试用例的质量，但是它不会直接去提升用例设计水平(之所以用直接，是因为长期稳定的绩效还会延伸出学习的引导性，工程师们知道这方面重要，他自己通过学习提升这方面的水平)。提升用例水平的方式需要结合培和训。
这个例子用来简单说明，测试绩效是用来评价结果的，并且它具有引导性，它是一种制度上提升产物结果的东西，所以我们设置绩效考核注意关注这个产物结果。
测试过程包括了用例，执行，需求评审，提bug，回归bug等等，这期间包含了很多产物。测试结果包含了什么？验收结果和线上质量情况。
绩效可以提升产物结果，那么整体上最关注什么？测试结果。所以测试组的整体绩效需要直接挂钩于产品线的质量情况(根据实际情况考虑测试报告中已经提出的风险点，进度和质量的妥协在各个公司会有不同)。测试组内部各人的绩效同样如此，首先挂钩于测试结果，而后再涉及测试过程。
测试过程的评价仍然是各个产物结果评价的综合。例如我们不需要每个人的bug数量作为绩效，需要的是每个人有效的bug数量以及有效bug数量占总bug数量的比例作为绩效，前者是评价有效后的有效工作量，后者则是评价一个测试工程师的测试问题反馈效率，无效问题毕竟降低了项目组的效率。如果细化还可以拆解有效严重问题的数量和占比，早期发现问题(评价问题的发现时间)的占比等等。
谈完客观绩效组成，我们还会遇到主观绩效。以前文章所述测试人员核心能力之一是推进能力，这个能完全通过数据评价吗？也许很难。所以绩效中会需要主观绩效的存在，而如何减少因为喜好带来的主观绩效偏失，则是测试管理本身的问题之一。尽管如此，在绩效组成中，让客观绩效作为主体，主观绩效作为修正不失为一个很好的解决方案。
