前言
本来十一的时候没想发帖的，因为媳妇怀孕了，专心伺候媳妇是第一位的，毕竟鄙人写文字费时太长，并且脑子是单线程运转，干一件事就顾不上其他的了。但是刚才翻论坛看到有个哥们说到了测试团队的考核，里面的内容着实的戳中了我的痛点。他尝试用 bug 数量来考核 QA 的绩效，并且是学习我老东家的模式。。。哎，想一想老东家技术部那恐怖的离职率。我觉得趁着媳妇睡午觉还是写个帖子专门说说吧。今天说的纯属灌水，没啥技术含量。
关于 bug 数
这貌似是一个永恒的话题，很多人都爱统计 bug 的数目并以此来评判一个 QA 是否称职。QA 发现的 bug 多了就说他是个好 QA，发现的少就说他不努力或者业务不行。其实这是一个悖论，QA 的职责是保证产品的质量，而 bug 过多则证明了产品质量差而不是产品质量好。 所以我挺纳闷那些测试大佬们总追求 bug 数量干什么，这是希望产品质量好啊，还是差啊。你们难道不应该追求线上无 bug 么？我是不太清楚这种扭曲的价值观当初是怎么在 QA 圈子里流行起来的，但我很清楚有这么扭曲的价值观的 QA 团队一定是失败的，也是可笑的。
我说说我是怎么看待 bug 数量的吧。如果在测试中发现 bug 过多，第一个反应是这么多的 bug 会不会影响发布？这些 bug 中有多少是可以忍受直接带上线的，有多少是不可妥协一定要修的？跟当前的排期对比一下，还有多少 feature 没开发完？剩下多少时间修 bug？这么多 bug 修完了有没有时间重新验收了？总结完所有风险就该找上产品和开发聊聊了，咱们该进小黑屋的进小黑屋，该加班的加班，该砍需求的砍需求。那么我们说下一步，第一反应是评估发布风险，第二反应就是思考为什么有这么多 bug，我们的流程有没有问题？RD 的 UT 够不够？需求的评审到位不到位？每日的 CI 有没有效果？之前用例的设计全不全面？当前产品的架构有没有问题？等等等等，这方面的事情我在上一篇文章测试开发之路--QA 的能力中总结过了。如果团队有良好的流程和质量保证意识，再加上合理的工具和自动化，是不会在测试中发现这么多 bug 的。bug 多了证明团队当前是有问题的，证明 QA 在一定程度上没有做到位，证明当前的产品是有风险的，反正 bug 过多肯定不是啥好事。所以一看到 QA 发现的 bug 多就高兴的老大们，你们到底咋想的呢？
关于 KPI
说到考核一定避不开 KPI，KPI 是个神奇的东西，有无数人趋之若鹜，也有无数人弃之如敝履。我的老东家是一个成立不到一年就引入 KPI 管理机制的神奇的公司。过程不表，但是 bug 数目，代码覆盖率，是否开发了什么测试工具，推广到了几条业务线等等貌似都变成了 KPI。我当时的心情是复杂的，因为这些玩意，只要我想糊弄你，真特么的轻轻松松就给你搞定了。用不着一个季度，我一个人撑死一个月就能把一个部门的任务超额完成。反而是线上事故率，trouble shooting 的反应速度等等没人过问没人管了，出了事随便骂几句就拉倒了。貌似大家都盯着那些看得见，摸得着，能带你装逼带你飞的功绩上。
结果是什么呢？ 我就举一个例子吧。我曾经跟我的直属上司因为代码覆盖率的事情吵翻天了。她的理由很简单，QA 得有代码覆盖率，QA 一定要加代码覆盖率统计，QA 必须得掌控代码覆盖率，重要的事情说三遍。我的理由也很简单，特么的除了我和另一个测试架构师以外，这些 QA 里有一个算一个，谁看的懂产品代码？你给一帮从没碰过代码的人统计代码覆盖率有 JB 毛用。不过后来大家应该懂，人家是老大，我得妥协。
再后来的局势就很明朗了，你不是追求 bug 数量么，能用一个 bug 描述的问题我拆成 10 个描述给你看，别笑，我真碰见过这样的，各种看上去高大上但基本没什么卵用的平台也出现了。不过技术部这都还好，市场，销售那边才激烈呢。花公司的钱找第三方公司刷流量，刷数据的都是小场面。我没有在诋毁 KPI 这个机制，一定有公司用的好。只是我没碰见过。
总结
其实我貌似没说怎么考核 QA，恩，对了，因为我也不知道怎么考核。我觉得咱们在公司都是结果导向的，即便可能没发现什么 bug 但只要产品能按质保量的发布，线上没出什么篓子就是合格的吧。恩，我暂时也就这么想了。
首先不评论你的老东家了，家家有本难念的经。
很高兴我的想法让你产生了共鸣，说说我的痛点：每个月的 24 号是为每个团队成员填写考核的日子，对我来说绝对是一件痛苦的事情，当前的状态是能加尽量加，毕竟都看到大家都这么幸苦，我通常会为其加考核有几个原因：
1、这个月经常加班完成了紧急的测试项目；
2、完成了安排的测试工具开发任务，考核至少 1.2；
3、能够利用晚上加班时间进行充电，例如阅读测试相关的书籍，和测试团队的其他成员分享自己的测试经验；
4、这个月测试的工作量，高效完成安排的测试任务的同时，主动协助其他模块进行版本测试；
5、主动进行测试工具开发并运用到产品测试过程中，考核至少 1.3；
6、主动项目总结、主动发现测试团队中的问题，分为：
- 发现问题
- 发现问题，提供解决方案
- 发现问题，提供解决方案，尝试解决
- 发现问题，提供解决方案，尝试解决，效果反馈
自我认为这些都是比较不好量化的，完全凭借的是主观感受，对测试团队成员可能不太公平。
为此我考虑了 BUG 数（不考虑具体的版本数量）作为其中的一个考核指标，这是一个可以量化的过程，规则很容易定，最重要的还是要进行过程管控，作为测试团队的 leader，在施行阶段要对 BUG 进行查阅，对团队成员提出的 BUG 进行评估，这也能很好的评估开发团队的产品质量：
针对测试：
1、让团队成员有一种目标感，能够知道自己离目标还有多远，会尽可能的发现产品中的 BUG，这是正向的。
2、目标完不成，说明你发现不了问题，能一定程度说明你在用例设计或者测试过程做的不够好，你该在这方面提升了。
3、每次都能完成的，这个说明你有独到的方法和发现问题的眼睛，你该和你的测试团队分享你的经验了。
针对开发：
1、BUG 数可以进行排名，一看就知道哪个开发团队的产品质量如何，对开发是有一定约束力和推动力的。
不知道大家是用什么方式来考核测试团队成员的，说的再多，还不多先做了再说，我将会在 Q4 阶段进行尝试，先会和我的测试骨干进行商量这个事情，大家认可后就开始开干，到时候再和大家分享我的实际效果。
#1 楼 @aizaimenghuangu
首先很感谢你码了这么多字来回应这篇帖子，我分 4 点来说一下我的感受吧。
真的劝你一句，千万别用 bug 数量来考核 QA，原因我帖子里说过，过于专注于 bug 数量也很容易忽略流程上的，机制上的，工具上的东西。而且也容易因为 bug 数量的问题跟开发团队造成矛盾。
我理解你的痛点，我曾经也为这些痛苦过。但后来我把这些考核都抛弃了，只要产品上线没什么问题就可以。这个是实的，其他都是虚的。即便发现了一万个 bug，如果线上还是出问题那又有什么用呢。
就像你说的，我们是以结果为导向的，那么线上质量就是结果。中间大家加了多少班，利用业余时间学习了多少，分享了多少经验为什么要列入考核呢？如果这些都变成 KPI 了，那么结果我几乎可以肯定是，大家尽量加班耗时间，营造一种很忙，很爱学习的样子。动不动就开什么技术分享会来分享一下装个 B 也是很常见的。时间长了只会培养出了一个很不好的气氛而已。我们的文化以加班为耻，能不加班就不加班。逼着大家把效率提升上来，逼着大家把自动化做起来。所以我不太理解你费尽心思营造一个加班的团队文化是为什么？
产品质量不是 QA 一个团队的事情，感觉你的眼界太局限于 QA 团队个体了。应该多想想怎么协同其他部门，定制标准，规范流程。如果某一天你发现 RD 提测以后测试出的 bug 特别少。那时候 QA 团队才是成功的
bug 数来考核？是 80 年代的国企么？
#5 楼 @aizaimenghuangu 如果是以 bug 数为考核标准，那就是感觉对自身的产品有足够的信心咯？
如果是这种 “大家一起来找茬” 模式，找到一个多少钱的这种模式，我是认可的！
- 感觉在考核和评估团队成员这个事情上确实要有自己的一套体系，不管是从结果导向以线上质量为主，还是平时在项目进度控制以及开发质量保证上，这些都是方法。
- KPI 不过只是将其正规化让大家都知道并让大家去跟着做，其实初衷是好的，不过凡事涉及到利益相关的自然不可避免都会产生一定的质变和偏差，这个东西做得好可以很好的激励大家，提高团队效率和产品质量，做的不好自然就是各种为了 KPI 而 KPI。
- 回归到测试这个职位本质来看终究还是保证好产品质量，关键还是人，团队人都为产品考虑，都想着怎样提高产品质量，方法嘛也是自己人在项目中摸索出来的，所以培养团队氛围和团队成员我认为才更重要。
- 至于加班文化反正我是没有好感，让大家都以加班为荣并且还欣然接受，除了像华为那样用福利和待遇去砸，一般公司我觉得还是难的，毕竟不是人人都是上进有为青年，只想着学好做好做贡献的，带人现实点还是好的。以上纯属个人看法
#5 楼 @aizaimenghuangu 这个也要看业务的，有些业务出错率高，有些低。
然而你直接用 bug 数量量化，导致敢承担责任的开发反而得到不公平的待遇啊。
关于 bug 数作为 kpi 的教训
那边把 bug 数作为 kpi 的那个帖子被我屏蔽了.
八年前我在阿里的时候所在的团队就推行过这个以 bug 数作为 kpi 的例子. 导致了如下结果
- 如果是一个新手 碰到一个烂的开发, 一个项目就能成为 kpi 第一, 所以测试同学非常期待研发团队多招水平低的人.
- 如果是个老手遇到一个好的项目, 就会倾向于把很多低级别的 bug 想办法夸大.
巧合的是研发那边是正好反着, 把 bug 数也作为 kpi. bug 越少 kpi 越高. 然后修 bug 已经不是主业了, 结果就是 bug 就跟黄金一样, 测试团队和开发团队天天在围绕着 bug 是否够量, 是否够纯等问题上来会拉扯. 推行一次后就再也不用了
纯从线上故障也不能完全反映 qa 团队的能力, 因为线上故障有的时候也是运气成本居多, 有的人运气好, 哪怕漏测很多也不出事, 有的人就算测试的很辛苦较全面, 也会倒霉的踩上地雷.
对于每个故障, 都要分析缘由不要贸然背锅和甩锅.
测试团队的考核维度
我理解的考核方式是先确定结果愿景, 再定义过程数据, 最后才是结果数据. 但是不要求数据严格化. 有些数据不能强制. 比如这个月员工工作了多少人日小时, 自动化测试用例多少个, 覆盖率多少. 在复杂的项目下, 这个数据统计方式和标准都不是精准的, 如果强制要求下面的人, 他们就会拿各种数据拼凑导致数据不精确. 不精确的数据就会导致错误的决策.
要求自动化测试用例数, 就跟研发要求代码行数, 飞机要求重量一样荒谬.
那什么是测试团队核心的评估维度那. 我认为一个好的维度是能即简单直观又能细分的指标. 因为这些指标是要能让老板和研发团队信服的. 我列举下我认可的能反应团队实力的几个维度.
质量维度: app 崩溃率, 线上 bug 数, 漏测率, 用户 bug 反馈数 测试用例的覆盖度, 测试行为的覆盖率...
效率维度: 测试成本, 测试周期 分层自动化 工具利用率, 自动化辅助, 创新与改进, 测试的提前度, 测试的并行度, 执行的效率...
团队维度: 流程管理, 文化建设, 沟通协作, 成员能力成长, 技能交流分享, 项目支持, 合作团队反馈...
以上只是列举的部分指标, 这些指标有的可以直接获取的, 就确定统计方式 不能有效获取的, 也不要求一线员工去补充.
很多问题其实都可以一叶知秋, 比如从线上漏测的 bug 就能知道从什么方向如何弥补质量,效率和团队三个主要资源的短板.
里面的每个指标都是和其他的指标关联的. 都不是孤立存在的.
质量管理的坑
很多管理者很迷信精确的数据, 的确数据量化是团队的终极目标. 但是不要在未成熟的阶段就刻舟求剑. 不正确的统计指标比如过于要求工作时间精确到小时, 测试覆盖率高到 90%, 自动化数量超过几百几千之类的, 既会让一线员工痛苦, 也会让以后的维护成本变的越来越大. 需要综合考量和参考.
管理方式和方法需要根据公司大环境, 行业环境和团队能力确定.
比如身处国企, 团队已经是一群不会编程的老员工组成, 你就得从测试用例的覆盖率和优化上去改进才能达到目标. 公司有钱有预算用来申请外部的咨询和培训辅助你的理念和目标落地.
如果团队里面新老参半, 你就得加强团队交流, 让新人快速的成长, 以免有人挟持业务自重尾大不掉, 这种时候把交流分享的 kpi 比重定的较高或者建立导师制度都有利于解决
如果你身处一家已经发展成型的大公司, 你就得规范流程, 明确责任, 重管理. 严格把关上线流程.
如果你身处一家茁壮发展的创业型公司, 你的首要任务就是招聘, 提升执行力和团队战斗力.
当然了, 还有更多的如何和复杂的环境需要处理.
如果用发展国企的风格来管理创业型公司 或者用创业型公司的方式来管理国企, 你都会死的很惨. 而且会拖死一家公司.
所以质量管理看似是小事情, 实则是一个难度极高的工种. 要对质量有深入的理解, 对自己的岗位要存敬畏之心.
说说我们公司目前的考核方法
我们公司目前还是已黑盒为主，还没有引入自动化测试这些东西，一方面是人员水平普遍不够，另一方面是我们部门还要同时负责技术支持，每个人的工作量都挺大的没什么时间搞（其实就是懒...）
考核的几个方面
- 需求覆盖率
- 用例执行率
- 用例有效率
- 缺陷验证及时性
- 线上 BUG 数
实际的考核方式就是通过自己开发的一套系统，从需求到测试所有的数据都在里面，然后进行计算，完全已数据为准，计算完成后领导们会根据实际的任务量和工作压力等等平衡一些主观分数，但调整的范围都比较小。
目前感觉这套 KPI 的考核方式仅从考核项来讲还是有一定的评估能力，比 BUG 数还是高明了不少，但是实际的 KPI 计算方法我就不想多说什么，因为计算这个数据的系统是我们部门自己写的，所以针对测试人员的 KPI 考核你们懂的...
以 BUG 数量来作为考核的话，只会起反作用，也是最 low 的管理理念。
以上回答都有一个共性，就是断定如果以 bug 数量驱动，测试会乱报 bug。
另外也没有提到一点，测试人员的素质和职业操守。职业操守低的同学什么标准都是没用的。
我并不觉得 bug 数量为 kpi 有什么不妥的。一个产品放在一个测试团队面前，只有几个 bug，上线后一堆问题，谁会觉得测试阶段发现 bug 数量少是好事？不要提什么流程，理想化的东西都落不了地，落地了也是走样。
如果以 bug 数量为 kpi，必须还加上质量。开发不是任测试宰割的小羊羔，低质量的 bug，投诉没有二话。
以管理为目的而不是项目质量为目的进行的考核，都是呵呵的。KPI 应该引导公司价值观导向，应该是一个合适周期根据实际情况变化的。单独的测试团队考核 BUG 数没什么意义，而和开发一起考核，又容易陷入无休止的 “这个问题是不是 BUG” 的争执。至于大家干的都差不多，非要考个优良中差的公司，
非常深刻！
以 bug 来考核比较扯淡，这应该是大家的共识（最起码是战斗在一线的 tester）
单纯的以结果来考核，如线上 bug 数等，也不会公平
有的团队的产品活跃用户过亿，有的才百万级别
你用绝对数量来对比，显然有失公平
非常认可 @seveniruby 的观点
对测试的考核应该是多个维度的
而且这些数据不应该是死板的，也不是孤立存在的
以 bug 数量来考核测试人员是上头人能想到的最直接的考核方式了，说用 bug 数量作为考核的已经将测试工作划分到生产劳动中了，比如生产线也是考核产量，部分开发也是看代码行数的。但是测试工作也用这个考核方法不适用。
真的做测试了就会发现，测试还不同于生产，而且有一部分属于服务行业了，还有追踪、反馈、各类文档等等工作，绝非单纯的像领导们说的 “产出 bug”。连坛子里这些懂测试的人都没能说出个所以然，所以测试考核真的很难定论。
目前我的团队的绩效考核方法是：想要团队成员做的工作都体现在基本考核中，我期待他们做的工作都在加分项中。
说实在的，工作做好是最重要的。
#9 楼 @seveniruby 没有漏测是很多质量团队首要目标，互联网公司的质量保证归根结底是又好又快的实现版本的发布，不同的行业不同的阶段对 bug 要求也不应该是一样的。对新人来说，熟悉业务的阶段，发现 bug 多少确实可以是一个考核标准，当已经成为业务熟手以后很难说还有什么用处。相反的，以前听过某个通讯行业公司的分享，不光通过 bug 考核 QA 也同样的考核开发，而且双方的 KPI 是背道而驰鼓励对立的，提 bug 的行为被称为上甘岭，双方反复争夺，这样去倒推开发去提高自己的代码质量，测试去尽最大可能的发现验证代码质量。
关键还是看清楚自己的公司性质，自己队伍是怎么样的情况。
我是超级讨厌用 bug 数量来考核 QA 的，上家公司才干了 4 个月，尼玛走人的原因就 SB 组长说我提交的 bug 数量偏少，尼玛四个月提交了 230 个 bug 还被嫌弃少。
思寒_seveniruby
回复
整体是赞同的，但是不太理解里面说的 “漏测率”，此处的漏测率大体是怎么定义的呢？我理解的是线上的 bug 数与 (线下 + 线上 bug 数) 之比，但这里又用到了线下 bug 数，当测试人员提交的 bug 数很高时就拉低了漏测率，当提交的教少时漏测率就上去了，为了达到低漏测率就又跟统计 bug 数作为 QA kpi 是一个路数了。
这个问题与所属的行业，公司，团队成员素质都有关系。
比如，由于待遇没有竞争力找来被动工作的人，也不主动学习和改进，那么既要完成项目的总体目标，引入这种机械式的考核标准，可能比较合适了，看得见，摸得着，易量化，为了弥补不足，可以定期轮换项目等等，当然，总体上肯定是比较低效了。
我所在的公司测试人员较少，一个人负责多个功能或小产品，是典型的敏捷开发，发布周期也很短，saas 模式，所以呢，对质量还是很重视的，因为质量问题很快就会暴露出来，且引发赔钱等坏的影响。
招人阶段标准要高，比如基础的编码能力，学习能力，和别的角色的配合能力等，好多轮的面试，结果就筛选出来一些技术不弱，乐于合作，积极主动，兼顾业务和技术的同学，负责相关产品的一系列测试，功能，自动化，接口，集成，性能，也负责一些 ticket 的处理。
说了这么多，我们的 kpi 或考核怎么做的？
我们定了一些公司级别的核心能力指标，比如团队协作很好，比如重视客户体验，比如技术上的领先，比如。。。
然后，你自己挨个列举事实，把自己在该领域的成长，事迹写上去，再打个分，等级。
而最后，这个结果，要经过直属经理，和其他接口部门的领导一起 review.
最后再汇总一个总的绩效等级。也就几个等级而已。
说了这么多，就是比较宽泛，而根据各个合作组的整体印象或对事实的评价来打分，不看太具体的数据。
公司较小，所以没什么混的人，你干得好坏，是否得力，大家都知道。
负面的：如果你负责的项目线上经常出问题，那肯定是备受瞩目的。
我遇到过一个项目，测试经理以每天跑的 case 数，报的和验的 bug 数来定工作量, 弊端很多
测试环境测试出来的 bug 数量，是用来考核开发团队的代码质量的。
生产环境发现的 bug 数量，是用来考核测试团队的测试质量的。
