第一、绝对不要把 BUG 和用例数作为绩效指标
第二、绝对不要满眼的都是量化两个字
第三、可以考虑版本交付质量和交付效率方面，也可以考虑特殊贡献、效率提升等方面的产出

bug 和用例都不是确定测试绩效的。而是用例漏测数，有预发环境的 bug 也可以算漏测；线上 bug，线上质量；客户体验；对团队的帮助如业务或技能；完成需求的量，比喻说这个人测的快测的多，负责的模块重；如果非要算上 bug 数，可以在版本中找个中位数来判断，但是需要和用例数结合来制定；测试误提的 bug 可以算，建议占比特别少；业务测试之外的，如自动化完成率；那测试制定了绩效，开发必须也要定，开发很重要的就是版本的总 bug 数和 P0 漏测数，这个测试要推动制定给他们，其他绩效就开发自己定。

这样搞，我一个 bug 可以拆成 10 个场景来提，又是充实的一天，除了骂骂咧咧的开发

每个月任务完成进度，有没有重大事故

哈哈 我司都反着来。

1. 无论说什么，第一反应是能不能量化
2. 如果不好量化，就想方设法用多维度指标去量化（现在团队一百多个指标/月）
3. BUG 和用例数只是指标之一
4. 考虑了交付质量和效率，无脑整了一大堆指标。
5. 什么特殊贡献、效率提升，那是你应该做的。

WTF！

笑死，我们团队自从量化 bug 数量，以前一个问题如接口返回报文字段缺失，就报一个 bug。现在演化成了缺了多少个字段就报多少个 bug

用 bug 数量化测试是挺傻的，只会造成对立， 后面会很难沟通。
实际上 bug 数量最终代表的不就是产品质量么，看线上反馈，看主客观漏测，工作对接态度，这个才比较重要吧。

你猜我为啥强调这句话，不同的公司，相同的 **
我现在看到听到想到这两个字就头疼

漏测率，就是多少线上缺陷，还有交付时间是否有延迟，最后一个：贡献度，贡献度就是指对团队部门的贡献，比如专利啊，一些改善流程提高效率的实施啊，技能分享啊等等

我们这些指标已经出现很多奇葩的事了，比如代码注释率卷到了 80%，2 行代码，8 行注释。程序员直接化身 AI 文员。

肯定是谁加班多谁绩效最好呀

我们以前也用量化，后来觉得会造成对立就不用了。由于公司会定期评 CMMI5 资质，所以在使用敏捷开发的模式下，有公式会去计算成果，要结合 sprint 内的故事点、用例数来看，想了解的可以自己去查相关资料。
不过实际工作中，我们最终还是把加班时长占绩效的 40% 来评，剩余的 60% 则是产品业绩 + 团队领导对你能力的主观意见。

测试的绩效是写了多少用例，提了多少 bug。开发的绩效是写了多少行代码和千行代码 bug 率多少。所以开发和测试反正有一个绩效不行

宇宙厂就是偷偷用 bug 数、case 数、工时这些给外包排名的，后来外包发现了，就开始拆分 bug、拆分用例、增加工时了，甚至出现一个月 21 个工作日，登记工作 30 多天的情况，但是没人在意，只需要淘汰排名靠后的即可，大领导也借此完成降本增效的 OKR。

简单说，在脑力活动占主导的工作中用指标打绩效，大部分场景最后对整体的收益都是负向的。坚持这么做的原因无外乎两种情况：

1. 领导能力和手段都非常有限，没有更好的办法激活员工的主观能动性。
2. 领导也清楚不合理，但是他别有用心，或者不在乎。

看谁爽就给 a 看谁不爽就给 D 这就是现实 不论 什么公司都存在好友感梯度排行，自己人 肯定给的好 不是自己人干嘛给你 好 重大贡献除外，但是就 一个测试能有多大贡献，说白了就是 牛马我给钱，你做牛做马。。