最简单直接暴力——发现缺陷数

测试覆盖度，个人贡献度来作为绩效更好吧。之前看过一篇文章。
等我翻翻找到了再给你回复。

哈哈，好有耐心，好同志

是要评估整个测试部门的绩效，还是想了解测试团队每个人的绩效应该如何考量？
如果是团队的话，建议看看这个帖子：
https://testerhome.com/articles/17888

个人经验：做绩效考评首先第一点是明确目标、第二个是找到数据的量化点，尽量把目标能通过数据量化出来；比如目标可以是某某需求达到完美上线标准、完美上线标准要尽量量化出来：比如上线后 3 级 BUG 反馈少于 5 个；无 1、2 级 BUG

仅凭 bug 数肯定是不行的，怕是会为报 bug 而报 bug。测试文档输出、上线后反馈、bug 数、产品建议这些都得综合起来看吧

感谢分享，很有用，不知道我的理解对不对，我举一个脑补的测试部门的 OKR 实例大家帮忙看看：

本周关注的任务：
P1: 上月所有版本问题回溯分析
P1: 本周版本回归
P1: xx 工具分享

OKR 当前状态：
目标：提高发版质量
关键结果：线上资损率 25%（2500/10000）
关键结果：月均缺陷率
关键结果：持续改进措施覆盖率（版本覆盖率：37/50，资损覆盖率：1900/2500）
关键结果：人员技能提升（新工具推广 3/12 团队）

未来四周计划：
推动所有团队的版本回溯
工具推广应用
检查预防措施执行情况

状态指标：
缺陷率持续下降
人员单位产出增加

看了你们半天了 没说到点子上，绩效考评， 一句话 “会哭的孩子有奶吃” ；

年初时候公司也要求出类似的文档，经过搜集百度上的文档加上结合公司实际情况思考出以下维度：

可以量化的有以下：
考勤情况，简单的来说就是禅道或考勤系统的活跃天数
测试用例的个数与规范，即总共编写的用例个数以及规范情况，通过百分比方式进行加减分，如前 20% 加一分，后 20% 减一分
测试用例的有效率，即通过评审的用例个数与总个数的比例，这样可以控制不去为了写用例而写用例，通过百分比方式进行加减分，如前 20% 加一分，后 20% 减一分
BUG 的个数与规范，即总共提交的用例个数以及规范情况，通过百分比方式进行加减分，如前 20% 加一分，后 20% 减一分
BUG 的有效率，同理用例有效率，通过百分比方式进行加减分，如前 20% 加一分，后 20% 减一分
历史 BUG 的个数，即超过多长时间未处理的 BUG 数，可检查人员对 BUG 的跟踪情况，一个减多少分，多少个是上限
因为公司测试还需对产品进行维护，所以特地加了一个对于维护方面工作的加分

主观的就和网上差不多了，如：行为规范，工作规范，文档规范，执行力，责任心，沟通，工作的完成情况，工作的质量

绩效需要有主观和客观指标

一个版本分成 N 个小需求，然后分配到个人，最后统计个人的总需求量，以及其中发现 bug 的需求量。

这个要根据你们公司的情况来定吧，不同公司情况不一样，关键是测试部门目前的主要职责是什么、你通过绩效评价做到什么。

如果主要的工作是发现缺陷，那可以从需求和缺陷的发现比率来评估，做到大家多发现缺陷。
如果主要的工作是预防缺陷，那可以从平均需求发现缺陷数量降低的速率来评估，做到缺陷少出现。

我觉得测试最重要的还是对你要测的产品有所提升，无论是产品的质量，还是开发组的效率，其实都可以靠测试的

1. 产品 release 周期多少，能不能继续缩短？自动化 release 吗？
2. 测试对 feature 的覆盖度？或者测试对生产环境的覆盖度？
3. 测试要跑多久？能不能再提高？

不清楚你们产品和测试的规模，所以也很难继续想更多的细节

拍马屁的绩效为 S，非常听话的绩效为 A，一般听话但产出还可以的为 B+，一般听话但产出不好的为 B，不听话但产出还可以的为 B，不听话且产出不好的为 C。