以下参考网络，有一定的参考价值：

产品测试方面的关键绩效指标 KPI 可分为两类：
一类是测试质量类指标，反映测试工作的质量，可促进提升测试能力的水平。
另一类是测试效率类的指标，用于促进提升测试的工作效率。常见的产品测试质量类的 KPI 如下：

1、产品设计缺陷率：产品经过测试、小批量试制验证以后，在批量生产和用户使用过程中发现的产品设计缺陷次数，与已生产、发运的产品台数之比，单位是次/台（或次/台.季度）理想情况下，已通过了测试和验证的量产产品应该没有设计缺陷，但是实际测试工作中不可能发现全部设计缺陷。计算本指标时，可以扣除那些测试已发现、但设计部门未予以修改的设计缺陷。本指标属于测试质量类指标，用于促进提升测试能力和水平。

2、产品缺陷漏测率：类似的指标还有因设计缺陷导致的产品（和部件）返修率、产品漏测率。所谓产品漏测率，是指产品在生产、用户使用等环节发现的漏测问题数与产品问题总数之比。

3、测试覆盖率：测试项目、测试用例对产品需求规格的覆盖率，或者对产品硬件设计的功能点覆盖率，或者对软件代码的覆盖率等等，这类指标用于衡量测试的充分性。

常见的产品测试效率类指标如下：

1、 人均发现问题数：每名测试工程师每天（或每月）在测试工作中发现的产品问题或缺陷个数的平均值。本指标可用于评估测试工程师数量是否合理。

2、 自动化测试比例：能够实施自动化测试的测试项目（或测试用例）个数与总测试项目（或测试用例）个数之比。本指标用于促进提升自动化测试水平。

3、 测试项目（或测试用例）的问题发现效率：单个测试项目（或测试用例）发现的问题数量的评均值。本指标用于促进提升测试项目（或测试用例）的有效性。

这几天也是一直在思考这个问题，希望有一些可以落地的内容。

好久的帖子，看到 KPI 忍不住想要留个言，说一下我个人的经历。三年前团队初建的时候，准确的来说是一个思想上"新老交替"的时期,我是极力想要推出一些更简易的考核机制的，想要放弃之前工作传承下来的 KPI 机制.当时也刚刚开始搞管理，接触到 OKR，公司还专门找了创新工场的人来讲 OKR。起初是觉得 OKR 是一个好的机会，可以摆脱 KPI 的条条框框,刚开始大刀阔斧 (创新工场的那位说是 KPI 和 OKR 不能共存),开始定义"有野心的"、“有挑战的” 各种月目标、季度目标、年度目标，实行了半年,发现 OKR 并没有带来多大的改善，自己检讨了一下，主要有几个原因:
1.公司大环境,公司有没有自上而下在推动 OKR
2.成员的实际认知，大家对于 OKR 有没有充分认知、是否认可 OKR
3.新建立的部门是否合适这样宽松放养式的考核制度.
那段时间想了很多，最后还是回去做了改良 KPI 的动作 (为了改善产品品质测试、提交问题，而不是为了 KPI 数据测试、提交问题),最终的考核变成了：有数据支撑的 KPI + 测试技术拓展的 OKR 现在用着觉得还不错.
ps: OKR 里面有两项，个人觉得不错
1.daily report(简单几句话总结当天的工作和所得)
2.全透明的目标管理（全员都清晰了解，上级、下级的近期目标和瓶颈）

#15 楼 @face_south
预发布环境模拟线上环境应该可以解决和测试环境不同的问题。
至于各方面的覆盖问题应该和需求方多沟通，明确责任认定。至少用例评审是对测试的一种保护。

最近也在为 KPI 而烦恼，觉得确实不应该从数据出发，应该从产出来关注。谢谢提醒。
#3 楼 @seveniruby

kpi 只是一把尺子，就看怎么去量，主要团队中的人要以做好一个产品为出发点，这样才能提高产品质量，至于 kpi 就是领导的事了。

#24 楼 @tom_ma 主要是很多老板不懂技术，会瞎指挥。

#11 楼 @face_south 上线出问题频率高吗？

#21 楼 @lihuazhang 😄 恒温为何老是这么幽默～～

#22 楼 @monkey 确实，核心岗位的人决定一个团队的整个气氛。

#20 楼 @tom_ma 额。。。这个都太空，实际的过程中，落地的时候都是看人，无论上面还是下面

#20 楼 @tom_ma 说句不好听的话，开发和测试应该配合起来骗老板。

目标管理中，有一个 SMART 原则（Specific、Measurable、Attainable、Relevant、Time－based），即使是为了提高工作的效率而考核，那如何把提高效率量化也是一门艺术。 通常老板们都是结果导向，在某个特定时间段内能提供什么样的数据给。我们可以提供哪些数据呢，测试阶段发现 bug 数，上线后 bug 漏测数，用户投诉数，app 崩溃率，发布次数，测试覆盖率，其他团队反馈，两个版本横向对比对应数据等。至于我们如何实现这个数据的，是通过流程优化，技术改造，还是短时间赶工，其实他们真心不 care。

至于测试背锅，好的质量一定是设计出来的，不是测试出来的，测试不过是最后一道门而已。不过谁让咱们是最后一道门呢，没有背过锅的测试不是好测试。我们能提前做的就是短期分析问题产生的根源，有什么改进措施，实施改进措施，追踪改进措施的效果；长期而言更早的介入，关注流程，规范流程。

特别是当一个测试团队构建的时候，内部和外部必然摩擦不断，这个时候一定要做好跟上级的沟通，了解他的期望。这个不是投机，而是确认我们提供的是他想要的。

有 KPI，基本都是接近满分，感觉就是纯粹为了那点奖金~很纯粹，说是 14 薪，然后只发 12 薪，另外 2 薪发奖金，有多蛋疼，大家都懂的。。。

先明确原因. 如果是环境的差异, 就逼研发提供一个隔离环境满足测试, 否则就说服他们担责.
在很多公司里面, 出了问题首先是研发的责任, 这样是逼他们提升自己的产品质量. 质量是开发出来的, 测试偏防御.

梳理你们出的所有问题, 然后提出改进建议, 理清需要支持的资源, 然后再明确是谁担责, 在公司树立一个有问题研发先担责的氛围, 这样你们压力就会小些. 也符合利益. 我想 cto 和 ceo 会同意的

#15 楼 @face_south 都一样。。这就是咱们这行的杯具
我上一家老板就是因为这个干掉了我。。。

@lihuazhang 是这样，发现的情况是，主路径线上也有问题，但是测试环境就可以，也在找具体是什么问题；还有就是一些小的地方，这个主要是测试没有覆盖到，要想办法避免；兼容性的一些问题，只要老板看到了就没得说了，等骂，老板不管什么原因。。

#11 楼 @face_south 测试难免会背些黑锅...唉

#8 楼 @lihuazhang 多谢提供思路。对于测试开发，或者架构师有没有比较合理的衡量项目？

#11 楼 @face_south

显而易见的状况是，需求也早提出来了，大家都讨论过了，感觉需求没有问题，开发也给了充足的时间了，测试也给了充足时间测试了，可还是出问题了

靠测试是避免不了线上问题的。真实环境是你永远没有办法模拟的。再说了，哪个东西没 bug？所以要看线上问题是那种问题，是不是主路径，是不是容易发现，是不是兼容性？比如主路径问题，那测试就应该问责了。如果是兼容性，那就只能下次注意。

我这现在就没有，现在有个问题很恶心，只要线上出了问题，立马就问责了，测试为什么没有注意到这个地方等等，然后惩罚。。显而易见的状况是，需求也早提出来了，大家都讨论过了，感觉需求没有问题，开发也给了充足的时间了，测试也给了充足时间测试了，可还是出问题了，大家一直在想问题出在哪，然后结果就是大家认为问题出在测试方面。我的想法是从测试覆盖程度入手，就是看测试用例的覆盖程度，测试用例的执行程度和测试的周期时间。

#7 楼 @xiaoxin okr 吧。学习谷歌的。但是不要严格执行，小公司或者新公司其实没必要用 kpi 来衡量。

#1 楼 @lihuazhang 那更好的办法是？

#3 楼 @seveniruby 多谢提供思路。 我从传统 IT 出来，对互联网公司的相关还是了解不多。

#2 楼 @monkey 我这是新公司嘛..一般先参考下一线互联网的经验，然后慢慢探索修改。 请教下上海支付宝比较看重什么呢？

了解你团队的目标, 你团队的 KPI 要和更高的领导确定. 确认方向.
然后是把 KPI 化解到每个人. 不用太确定细节的数字. 不然就会陷入官僚式的数字魔窟. 覆盖率在 69% 和 70% 并没有差别. 不必纠结.

KPI 要从结果和过程中分别体现出来.
结果就是产品的质量数据. bug 率. 线上故障, 用户投诉, 迭代或者发布次数.
过程就是测试的效率, 人力成本, 需求满足度, 测试覆盖度, 技术应用度, 然后再细化具体的数据就行了
比如测试多少轮, 测试发现多少 bug. 测试时间缩短多少, 技术的价值体现, 测试体系的完备和流程规范. 人员的成长等

kpi 关键是怎么定。kpi 必须有

kpi 是一个比较好的管理方法。