一些不成熟的公司会沿用缺陷数量作为测试工程师的kpi，说实话，这是不客观的。
缺陷数量只能在一定程度上反映软件测试工程师的能力，如果没有从缺陷质量上着手，那也失去了软件质量的意义。
比如并不只是看简单易见的缺陷，还有测试的覆盖率等。
只是一味重视软件缺陷的数量，可能会出现测试工程师只追求缺陷数量，而不是为缺陷的深度和复杂性做考虑。甚至深度的缺陷容易被遗漏，没有记录下来。当然，数量也是需要追求的，只是核心逻辑是控制数量与质量的平衡，这样才具有全面性。
还有个问题，不同的项目复杂度以及规模都不一样。将缺陷数量作为考核标准的话并不公平。一些项目较为简单，测试用例数量少，发现的缺陷自然就少，而用例比较复杂的核心项目缺陷自然就多。难道因为项目复杂就算绩效高吗？
如果公司一定要对测试定制一个绩效规则的话，除了刚才提到的缺陷深度和覆盖率以外，应该再结合多维度来考察：
硬指标比如缺陷严重程度，测试效率，质量评估等。
软指标包括团队协作能力，自我学习能力等。这里也只是部分，笔者也不能保证囊括了所有。
另外，这还有一个很大的弊端就是：
测试工程师为了绩效更好看一些，原本可以不算缺陷的小问题都可以当做缺陷问题提出来。
笔者以前就遇到过：
有同事和另一个系统的同行同时发现了一个问题。另一个系统的同行为了增加缺陷数量，将一样的缺陷名称后面增加一个ios系统，这样单独作为一个缺陷提交到缺陷管理系统中……但当时给测试组的指标就是缺陷数量，无奈。
而且让人诟病的是，这样的评估方式，测试为了提缺陷而提缺陷，开发一看缺陷数量成倍的增加，可能会激起测试与开发的矛盾，不利于团队发展。
下面说说要怎么评估更加合理呢？
1、在刚刚提到的绩效评估的基础上，绩效标准一定要准确，量化，不要有含糊的地方。
2、评估的时效性。绩效评估的时效是周期性，而非一次性，一次性的评估很具有盲目性。定期进行评估，才能使问题充分暴露出来。
3、如有必要，对数据进行验证和审查。为什么要这么做呢？这只是为了保证数据的可信和准确性。当然，一般出于特殊情形或人才会采用此种措施，防止数据造假。
4、自我评价体系。这是容易忽视的，但是建议采取的方式，鼓励测试人员进行自我评价，发现自己的优点和进步，更有动力工作。如果实际工作中的结果如果与自己的自我评价有较大差异，也可以认识到自己的不足，及时进行修正。