51Testing软件测试论坛

标题: 测试人员的绩效考核应该如何开展？？（09-3-2）（获奖名单已公布） [打印本页]

作者: 默默巫 时间: 2009-3-2 16:51
标题: 测试人员的绩效考核应该如何开展？？（09-3-2）（获奖名单已公布）
企业越来越重视对员工的绩效考核，对于一些传统的计时、计件类岗位工作比较容易确定考核的指标，但是对于测试人员来说，如果只凭Bug的数量、用例的数量这些简单的指标来衡量并不是很准确，而且每个人负责的模块不同，针对的开发人员技术水平不同
也有很大的差别。尤其是随着时间的推移，在项目结尾阶段发现的Bug数量肯定会减少。那么针对软件测试人员，该如何设定考核方式、使用指标、评判标准等内容呢？

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	摆饐ＰǎＳe	当当购物卡50元	16#
二等奖	zte_boy	300论坛积分	7#
三等奖	阿七	100论坛积分	23#

作者: whan78 时间: 2009-3-2 18:04
对软件测试人员的量化考核是一个长期的过程，在Leader level去对测试人员的产出进行跟踪仅限于数据收集，真正要考核还是要用一些硬指标，比如一段时间的漏测率，或者一段时间内的缺陷产出比；而考评的最终目标应该符合公司阶段性的目标和策略，如效率或者质量目标。

作者: shanghai001007 时间: 2009-3-3 03:55
我的做法不是看测试人员完成了多少基本测试（这是应该完成的），而是看测试人员对自动化测试的贡献有多大，每人各分难度相当的一块，最后看完成百分比

作者: kuailederen 时间: 2009-3-3 09:25
想想这个问题，测试人员的绩效考核，有几个公司做了？又有几个公司做好了？即使强制做了，下面的人员全部接受吗？
我也经历过做绩效考核的公司，基本存在以下弊端：
1.浮于形式型。
公司要求这么做，部门就这么做了。做了以后并不影响个人的利益。
2.经理一人独断型
无论有没有具体考核内容，但经理不理会这些，自己凭自己的主观最后打分。
3.不公平型
没有经过实践，就相当的觉得以数据说话最公平，于是就以执行用例数，发现缺陷数等为标准。我亲自经历过这样的事，自从
以发现缺陷数为重要考核标准后，大家都争着测文档，一个错别字提一个缺陷。。。。何必呢？
4.敢怒不敢言型
这种是与工资挂钩的，或者末尾淘汰。他们考核的无非也是从工作量，积极度和看得见的数据，
整不好，你在埋头苦干，却告诉你被淘汰了。怪谁呢，只怪你不会做面子工程。

绩效考核大家都理解，提高效率，提高质量，说白了就是节约成本。
我觉得绩效考核有几个工作外的东西必须考虑进去。
1。文化背景
一个国家的文化背景。在中国就不适合做互评的考核，让同事一起打分。就象让你指出别人的缺陷一样让人不知所措。
  一个公司的文化背景。公司的文化氛围，团队氛围。
2.公司发展定位
人力资源管理上讲，一个处于迅速发展期的公司，不适合做严格的管理制度和考核办法，公司应该鼓励员工去积极的发挥
  个人能力，因为公司要靠这个迅速发展；而一个处于稳定期的公司，却要通过比较严格的制度来维持这种稳定；处于衰败期的公司，
  最需要制定严格的制度来控制成本。
3.公司测试制度的完善程度
一个测试团队如果连最基本的测试制度都没有（我指的是测试体系方面），比如你连鉴定缺陷等级的细则都没有，连有（无）效测试  用例的标准都没有，你凭什么来统计这些数据？
4.测试团队对考核制度的支持情况
如果被考核的人都觉得制度不公平，太片面的话，那最好别执行了，心理抵制比言行抵制更可怕。
鉴于上述，我想公司给测试人员做绩效考核，要根据具体情况来实施。

下面我分析的要考核那几方面：
1.工作量：
这是无可厚非的，不干活的人是没有绩效的。
2.工作质量：
写出无效用例多，提交的缺陷开发看不懂等，负责测试的模块有明显的重要缺陷却视而不见。（注意不能以偶尔现象为准则）
3.工作态度：
这点很容易理解，就是不好好干活，应付任务。
4.工作角色。
为什么说只凭工作量不公平呢，因为测试是分角色的，比如测试组长，他可能很多精力放在沟通和进度跟踪，缺陷跟踪
  等其他方面，而执行的用例较少。所以不同角色不通对待。
5.贡献度。
在工作过程中，凭自己的特长，为公司测试过程改进，测试方法提高，测试团队建设做出突出贡献者。比如编写出测试工具，
  极大提高测试效率。
6.挽救风险。
  比如测试已经结束，但他还是凭着怀疑精神坚持自主测试，在上线前测试出重大问题。

总之，测试部门考核的目的是为了提高测试水平，规范测试流程，约束自由懒散者，鼓励个人智慧的发挥等。所以，
我觉得范有违这个目的的考核，还是不做的好。

最后补充一点，测试工作并不是独立存在的，它要与其他部分配合工作，我们很难把测试部门单独考虑做考核，我所经历过的是
以项目为单位进行考核，只要与这个项目有关的所有人都绑在一起，这样比较合理。
另一点，某个考核标准如果采集数据或者是依据，如果比较困难，麻烦，那么这点基本不可取了。还是那句话，脱离了实际的一切行为都是纸上谈兵。

[ 本帖最后由 kuailederen 于 2009-3-5 15:04 编辑 ]

作者: kuailederen 时间: 2009-3-3 09:33

原帖由 shanghai001007 于 2009-3-3 03:55 发表
我的做法不是看测试人员完成了多少基本测试（这是应该完成的），而是看测试人员对自动化测试的贡献有多大，每人各分难度相当的一块，最后看完成百分比

你的做法让很多人失去了积极性。
本事你就让他们觉得你所说的基本测试是不能体现工作价值的工作，那他们为什么要做好那部分工作？
我不知道你说的自动化测试具体是那方面，但你倡导的方向确实错了。
有的人他就是适合做手动测试，这也是他的特长，你为什么强迫他也搞自动化？并且还全民自动化。
另一方面，你这样做就等于直接告诉他们，会写个程序就比手工测试的要高个档次，给他们引导了错误的方向。
再次，即使你搞的很成功，大家都做的很努力，基于现状，做自动化测试的需求量大，待遇也高些，等他们觉得自己有一定能力了，势必跳槽。你这样做危害了公司的利益。
我推断你是做开发的出身，重视编程技术，但确实不适合做管理。
说错的地方，还请原谅。

作者: archonwang 时间: 2009-3-3 10:47
抽空一起探讨了。最近比较忙。

作者: zte_boy 时间: 2009-3-3 10:49
我认为需要采用矩阵式的管理方式，同一个项目的测试人员采用测试基础指标进行比较，如测试设计速率、测试执行速率等。而不同项目之间则需要通过项目质量来进行比较，如缺陷泄露率等指标。对于能够量化且合理的指标给予量化，对于不适合量化的指标可以根据实际情况考核，最后加权折合成考核分数
个人考核应该从以下几个方面来进行：工作饱和度、工作质量、工作效能、工作积极性
简单谈下目前我的做法：
1、工作饱和度
主要考核测试各个阶段的有效工时，以小时为单位。以每月实际工作日*8为基准，按实际有效工时/基准值进行计算，可以将饱和度分为几个区间，相应的区间对应分值区间，其中实际有效工时包括设计工时、执行工时和其它工时

2、工作效能
主要考核测试人员整体工作效率，也是人员能力体现的一个方面
主要指标包括：设计效率、设计覆盖率、执行效率、执行覆盖率、是否在指定时间内完成工作任务（主要考察实际和计划的偏离度），对于以上单项指标，根据团队规模按照一定比例划分，如前10％分值为6分，中间80％分值区间是2－5分，后10％为0－2分等，当然需要根据实际情况进行调整，并不绝对化

3、工作质量
考核测试人员工件的质量，可以从用例质量、文档质量、系统质量等方面进行考核。
a）用例质量
可以用总有效缺陷除以用例总数，得出单位用例的缺陷检测率，用以考核用例设计的质量
b）文档质量
主要体现在测试计划、方案、评估报告的考核上，主要从规范性、及时性、有效性等方面进行评估
c）系统质量
主要考察有效缺陷质量、缺陷泄漏率、有效缺陷比、各级别缺陷比重等指标

4、工作积极性
主要考核测试人员沟通、学习等方面的能力。如测试过程中问题的反馈、解决测试过程中出现问题的能力、在项
目阶段测试完成后的真空期进行测试学习的能力、测试技术的创新能力等等。

将以上指标通过横向和纵向的比较得出每个测试人员考核的总分数进行排名。当然需要强调的一点是考核不是目的，而是种手段，希望通过考核来激励测试人员更好的工作，而不完全依靠考核来评判一个测试人员的好与坏。

作者: weifei1031 时间: 2009-3-3 10:55
楼上点评的相当到位

作者: newsun 时间: 2009-3-3 13:23
我想请教下7楼考核的具体实施，比如设计效率如何评判？

作者: alextowxm 时间: 2009-3-3 14:43
我也是认为 7楼说的很对
测试是要个人的能力的
不是只是考自动化水平的
不是所有的人都会写代码的。
要是都会写代码的话那为什么不去做开发呢。

作者: qinxiaocang1202 时间: 2009-3-3 15:15
昨天回去好好想了哈，根据自己的工作，谈哈自己的见解：

（1）测试需求、测试计划、测试用例、测试执行第个阶段的评审（同行或同级），通过此可以发现工作中的工作效率；
（2）周报和日报的编写：通过它们能够让测试人员清楚的看到自己按照测试计划完成了多少任务，还有多少没有完成，测试负责人通过此来了解测试的进度并了解各个测试人员的工作情况；
（3）工作的态度：因为测试本身是一个反复性很强的测试过程，比如有一次我们公司的产品要测试与IE6.0、IE7.0、FIRFOX的兼容性，一个项目由开发到完成，用户的需求再变，测试需求、计划、用例都要跟着变化，可想其工作量之大，一个系统反反复复要测试上几遍，三种浏览器都要按相同的方法去测，要是工作人员的心里产生厌烦的话，就会“偷工减料”，造成很多的测试用例没有执行。

支持7楼，说的太好了！语言表达能力也强，我有的想到的都不知道怎么说，

刚刚看了份PPT，也是在51testing中下的，觉得在考虑这个问题时，这里面的有些也是参考标准，但确说不出来，现在传上来，大家可以看哈，希望会有新的发现吧！

[ 本帖最后由 qinxiaocang1202 于 2009-3-3 17:16 编辑 ]

作者: hongyan 时间: 2009-3-3 15:23
我们公司最近也想制定一套方法来考察测试人员的工作绩效，还在讨论之中。要考虑的因素很多，还必须结合到公司的具体情况。

作者: keevinl 时间: 2009-3-3 15:42
别讲的太复杂了啊.
1.根据测试人员的工作积极性,态度上要很好.
2.当然.也要根据测试人员所负责的项目,对项目质量上的贡献.
3.可适当参考一下,从BUG的数量上.来进行.进一步提高测试人员的积极性

作者: tengmy 时间: 2009-3-3 16:09
真是巧，这几天正在跟以前公司的一个刚刚被提升为测试
leader的人谈论这个话题。就有了说话的地方。

为我的一家之言先占个地方

http://www.51testing.com/index.p ... space-itemid-109622

[ 本帖最后由 tengmy 于 2009-3-9 11:08 编辑 ]

作者: 小草 时间: 2009-3-3 16:43
我们现在针对于测试人员的考核主要基于以下几个大的方面：个人的工作质量、项目组内其他人员的评价、客户对系统的反馈综合来进行考虑。

1、个人工作质量
主要考核测试各个阶段的测试用例设计、测试用例执行情况、缺陷提交情况以及测试提交物的质量。
2、组内人员的评价
主要考核项目组对你的沟通、工作态度，团结协作情况，给你进行考核的有其他测试人员，开发人员等等。
3、客户反馈
主要将系统上线试运行后客户发现的问题做为一项考核指标，因为这个最直接反馈出项目的质量，反馈问题的严重度直接影响到你的考核分数。但是这个周期可能会跨度很长。

都说考核不是目的，但是还是希望能够依据考核结果来鼓励测试人员更好的工作，好的就是要给予奖励，例如绩效奖金、推荐培训等等，总是不好的肯定要处罚和淘汰了。

作者: 摆饐ＰǎＳe 时间: 2009-3-4 00:17
一测试设计
工作效率相关指标
文档产出率这项指标值主要为测试用例文档页数除于编写文档的有效时间获得。用于考察测试人员测试用例文档的生产率大小。
公式：∑测试用例文档页数（页） / ∑编写测试用例文档有效时间（小时）
参考指标：根据项目汇总得出平均在 1.14 页 / 小时左右，高于此值为优，低于此值为差。
用例产出率这项指标值主要为上述指标值的补充，用于考察测试人员测试用例产出率大小。测试文档页数可能包含的冗余信息较多，因此要查看文档中测试用例的多少。方法是测试用例文档中测试用例编号总和数除于编写文档的有效时间。
公式：∑测试用例数（个） / ∑编写测试用例文档有效时间（小时）
参考指标：平均 4.21 个用例 / 小时
工作质量相关指标
需求覆盖率计算测试用例总数之和除于与之一一对应的功能点数之和，主要查看是否有功能点遗漏测试的情况。
公式：∑测试用例数（个） / ∑功能点（个）
参考指标： 100 ％。如果连功能指标都不能满足 100 ％覆盖，起码说明测试不充分。这个指标收集起来相当困难，如果存在需求跟踪矩阵或者测试管理工具能把用例与需求一一对应就容易得多。
注意：有的功能是难于测试的，那么未能覆盖到的需求要综合分析，明确是测试人员遗漏？还是无法测试？这需要放入问题跟踪表中进行后续跟踪；另外，有的功能点包含的信息较多或者有的用例包含几个功能点，这时只能把重复的功能点或重复用例按一个计，难于区分的要做说明。
文档质量测试用例进行评审和同行评审发现的缺陷数，或者将此缺陷数除于文档页数算出比率。此指标考察测试人员文档编写的质量如何。
公式：∑缺陷数（评审和同行评审）（个）
∑缺陷数（评审和同行评审）（个） / ∑测试用例文档页数（页）
参考指标：由于评审是发现的缺陷数是不固定的，因此，这个指标没有可供参考的数值。如果缺陷数大小不能直接用于比较就使用缺陷 / 页方式进行横向对比。
文档有效率使用测试用例文档进行测试时发现的系统测试缺陷数除于此文档页数。用于考察文档是由有效的指导了测试工作。
公式：∑缺陷数（系统测试）（个） / ∑测试用例文档页数（页）
参考指标：平均 2.18 个缺陷 / 页
注意：如果存在测试人员在测试时创建新文档用于辅助测试时应包含这一部分。
用例有效率使用测试用例发现的全部缺陷除于测试用例数总和。这一指标是上一指标的补充指标，用于考察用例质量是否较高
公式：∑缺陷数（系统测试）（个） / ∑测试用例数（个）
参考指标：平均 0.59 个缺陷 / 用例，也就是说，每执行两个用例才得到 1 个缺陷，各工程有所不同，可以自己实践一下
二测试执行
工作效率相关指标
执行效率利用测试用例文档页数除于此次系统测试执行的时间总和（不包含用例文档编写时间）。补充指标方法是用例的个数除于此次系统测试的时间总和。用于获得工作中测试人员每小时执行测试的速度。
公式：∑测试用例文档页数（页） / ∑执行系统测试的有效时间（小时）
∑测试用例数（个） / ∑执行系统测试的有效时间（小时）
参考指标：平均 0.53 页 / 小时， 1.95 个用例 / 小时。即测试人员每小时执行半页测试用例或者每小时执行 2 个测试用例。通过横向比较，容易知道那位成员的执行效率较高。注意：执行效率高的不代表测试质量也高，甚至执行效率和测试质量成反比，所以后面工作质量的指标会补充这一部分的偏离。实际结果表明，用例执行效率高的成员，其缺陷发现率往往偏低，考核如果不将此纳入进来也可以将其作为测试改进的一项重要数据进行收集。
进度偏离度检查计划时间和实际时间的进度，方法是计划时间差额减去实际时间差额除于实际工时总和，用于考察测试人员进度情况，监控测试是否按照日程进行，是否满足了工程的进度要求。
公式：∑（计划开始时间 - 实际开始时间）＋∑（计划结束时间 - 实际结束时间） / 总工时
参考指标： 15 ％进度偏离是个相对的指标，可能偏离了 20 个工作日，但是对于一个长达半年时间的测试而言偏离天数比上整体测试所需天数不足 15 ％，可能偏离了 3 个工作日，但是对于一个只有 1 星期时间的测试已经超过了整个测试阶段所需天数的 60 ％。
注意：计算时分子分母要保持一致，即开始或结束时间已经去除了非工作日时间，则总工时也要去除非工作日时间。因为制定计划时是根据每个公司的工作日来制定的，也就是说，考虑了非正常工作日的日程。
测试进度也是考核很重要的一步，如果没有进度保证，所有的测试都存在风险，第一种方法是测试人员可以采用自下而上的方式向测试经理报告计划用时，这种方式风险比较少，个人根据自己能力大小确定，但是缺点是存在测试人员虚报可能性。另一种方法是测试经理进行估算后分配工作日程，这时估算是很重要的前提，除了依赖于测试经理的经验外，对评估结果进行同行评审是很客观可取的方法。
缺陷发现率测试人员各自发现的缺陷数总和除于各自所花费的测试时间总和。由于执行效率不能足够代表测试人员是否认真工作，那么，每小时发现的缺陷数就是重要的考核指标，你的工作可以通过这项指标得到反馈。
公式：∑缺陷数（系统测试）（个） / ∑执行系统测试的有效时间（小时）
参考指标：平均 1.1 个缺陷 / 小时假使有位测试人员没有达到 1 小时发现 1 个缺陷，那么，除非产品质量高、模块较小，否则，就是他的缺陷发现能力不如其他测试人员。当然，详细分类中可以根据发现重要缺陷的多少来定义缺陷发现能力。
工作质量相关指标
有效缺陷数 / 率被拒绝和删除的缺陷数总和，或者被拒绝和删除的缺陷数总和除于缺陷总数。这项指标用于考察测试人员发现的、被确认为缺陷的缺陷数高低或者百分比，数和比率越低测试质量越高。
公式：∑缺陷数（系统测试中被拒绝和删除的）（个）
∑缺陷数（系统测试中被拒绝和删除的）（个） / ∑缺陷数（系统测试）（个）
参考指标：平均 21.9 ％（测试人员发现的每 100 个缺陷中平均有 22 个缺陷不被开发组确认、认为不是“缺陷”或者错误录入缺陷）。有效缺陷比率容易给出，但是有效缺陷数具体数据要根据项目情况，无法给出可参考的数值。
注意：这项指标可能有不正确的情况，假使缺陷被拒绝和被删除的原因不是因为测试人员误操作和需求理解等自身错误引起，而是系统本身不能实现或者数据错误引起的，那么就要考虑剔除这部分。对于测试人员发现系统框架根本性的、初始化参数设置错误引发的、错误数据、错误环境等而开发人员因无法修正、可以通过改变环境而无需修改程序、重新导入数据、再次发布从而拒绝或删除的缺陷，应给予此测试人员奖励。
严重缺陷率这个比例用于弥补缺陷发现率的不足。主要是根据严重程度分类的缺陷数比全部缺陷或者有效缺陷数。一般而言，每个公司基本把缺陷严重程度分为严重、一般和微小，或者更细（通常等级数为奇数）。另外，可以对缺陷严重程度进行折算（严重：一般：微小 =1 ： 3 ： 5 ）通过折算可以得出权重，然后在计算测试人员分值，在此不冗述
公式：∑严重 / 一般 / 微小 / ∑缺陷数
∑严重 / 一般 / 微小 / ∑有效缺陷数
参考指标：严重 ~10% 一般 ~70% 微小 ~20% 。当测试人员发现的缺陷中严重错误比率越高，说明测试质量相对就好，通常严重程度缺陷数的分布呈正态分布。
模块缺陷率这个指标主要是根据一个单独测试模块的缺陷数除于模块本身功能点数得出来的。假使一个模块是单独测试的话，很容易可以和其他模块进行指标横向对比，参照对应的测试人员，得出所测试模块的缺陷数，可以考察测试人员测试水平，也为开发考核提供数据。
公式：∑缺陷数（系统测试（个） / 功能点（个）
∑缺陷数（系统测试（个） / 子功能点（个）
参考指标平均 3.74 个缺陷 / 功能点 1 个缺陷 / 子功能点
注意：有些功能点没有子功能点，计算子功能点时要进行说明。
三测试管理
开头提到对测试经理的考核就复杂一些，除了测试经理参与测试设计和执行外，还要考察他的测试管理能力，即测试计划阶段工作，其中
计划质量测试计划的评审缺陷数或比率，可以与其他同类型项目或数据库平均指标进行对比。
公式：∑缺陷数（评审和同行评审）（个）
∑缺陷数（评审和同行评审）（个） / ∑测试计划文档页数（页）
参考指标：无
成本质量成本度量主要放在工作量这块。因为无论涉及工资还是奖金，都要和工作量挂上关系。成本质量主要是对测试活动的计划工作量总和比上实际的工作量数值总和。对测试人员考核的进度偏离已经考虑了进度因素，而工作量涉及的是成本因素。
公式：∑测试活动计划工作量（估算人日） / ∑测试活动的实际工作量（人日）
参考指标：原则上不能偏离计划的 ± 15 ％～ ± 20 ％。实际上，这个指标是对成本的一种度量。对于一个大的项目来说，估算值往往差距非常大，阶段统计时可能有± 500 ％！！这时调整计划是很必要的，在最终阶段取考虑计算平均估算值。一个测试经理必须对完成任务的成本进行有效控制。
这两项指标是相对容易量化的部分，而需要添加其他量化指标需要综合考虑由项目经理和测试部部门经理给出标准，例如管理用时比率（整个项目测试期间管理时间占整个项目测试总时间）、系统整体缺陷数与其他同类型项目或数据库平均指标进行对比等等。
考核具体方法：
1 ．将各项指标进行汇总分析，得出总和表格，根据测试人员各项指标大小进行排行榜制作，如列出 1 、 2 、 3 、 4 名。
2 ．确定阶段涉及的权重。例如将测试设计和测试执行权重各为 50 ％。其中，工作效率占 40 ％（即占所在阶段 20 ％），工作质量占 60 ％（即占所在阶段 30 ％）。
3 ．确定每类指标的分值，然后每类指标达到平均标准给 100 ％，达不到或者超过根据 80 ％ ~120 ％比率给分
3 ．将比分统计出来后进行综合评定，必要的话增加一些调整系数。
4 ．最好将定性分析纳入进来，采用问卷调查和项目经理评分制度给出定性指标分数，建议这部分权重不要超过 10 ％～ 15 ％以保证测试考核的可度量性。
当所有考核分数给出之后，提醒一点的是，既然做了考核，就必须公开这些结果，而且考核具有导向型，不要让考核误导了对质量工作的追求才是最重要的。
考核注意事项：
1 ．项目并不是一个月就能完成的，如每月进行，要考虑“可考核部分”为那些，挑选那些指标能够横向对比，然后分阶段、分任务评定。
2 ．参与测试的时间长短也要给予重视，除了上述量化指标外，测试人员整体投入时间长短也是很重要的，加班也要作为特殊考虑因素，也许某个测试人员只参加了测试执行 3 小时，各项指标都是良好的，但是不可能给他比其他参与时间更长的人员更多的分数。这部分就是增加调整系数的原因。
3 ．测试经理的测试设计和执行部分和项目测试人员一起考核，但是测试管理工作要单独考核，作为另外的加分，或者如文章前面所述纳入项目组给予考核。因为测试经理在项目测试中起着管理者和质量保证负责人的角色，不要把他和其他测试工程师平等对待。
4 ．考核前要考虑项目的实际情况，不要盲目的轻易承诺测试组人员考核会和薪金或者淘汰机制挂钩，否则考核会起到反效果。
项目组测试人员考核的主要目的是在于激励测试组测试人员工作，鼓励能者，鞭策落后；另外，还可以起到发现人才和查找不足的作用。考核中即要体现多劳多得的原则，也要体现公正性和合理性原则，奖罚分明才能有效促使质量管理工作的进步。要想考核得到满意的效果，上述方法的重要的前提条件是：必须要在项目中充分收集相关的数据，包括采集缺陷数，记录工时、提交详细工作日志和进行文档配置管理，没有这些数据，定量分析就无从谈起，测试人员考核也无从谈起。

作者: qinxiaocang1202 时间: 2009-3-4 17:43
标题: 回复 4# 的帖子
支持哈！！

作者: 我要我的快乐 时间: 2009-3-5 00:10
测试人员的绩效考核应该如何开展？

关于“测试人员的绩效考核应该如何开展？ ”的问题，本人结合实际，总结了以下几点：

一）熟悉测试人员的工作职责，根据测试人员职责内容执行情况进行评估

一般测试人员的工作职责包含三大块：

1）测试前的准备工作
测试需求的提取，这是测试人员测试时是否明确测试需求的一项非常重要的指标
测试用例的编写和细化完善，编写较好的测试用例是可以比较全面的覆盖产品的各项功能急功能点，而且通过编写测试用例可以让测试人员非常深刻全面的了解产品功能。
测试计划的制定，实际测试时就可以检验测试计划制定是否合理了
测试环境的搭建，通过该项工作也可以反应测试人员实际是否细心收集客户问题环境及相关的需求环境。

2）测试执行，在测试执行过程中会有bug的提交及bug质量情况，测试人员对bug的描述是否简洁明了，bug优先级的把握是否合理，是否只追求数量不追求质量等都是可以看出一个测试人员实际的工作效率的。

3）测试总结及相关测试文档的编写。

二）制定合理的工作计划，根据测试计划执行情况进行评估

一般绩效考核是对测试人员一段时间内的工作进行考察，那么制定一份合理的工作计划是非常重要的，一般组长会协助测试人员

安排好一段时间内的工作（临时插入工作也是在所难免的），然后制定好计划提交给经理确认，最后双方签字确认后，工作计划便生

效，测试人员在实际工作中就要按计划执行了，绩效考核时工作计划达成情况及计划之外的工作情况（计划之外就需要领导细心掌握

了）对于领导来说是一项非常重要的指标。

三）有相关的流程规范遵守及执行情况

一般每个公司都会有一定的工作流程，作为测试人员对测试流程的掌握情况是需要非常清楚的，而实际测试人员对流程的遵守及

执行情况也反应了测试人员的工作态度，这也是绩效考核时一项重要的指标。

四）测试相关的经验交流

可以定期组织一次测试经验交流会议，通过交流，领导也可以初略了解到测试人员理论及实际技能提升水平。

五）测试人员心态情况

良好的心态对于测试人员来说至关重要，所以作为领导要随时能够了解下属的心态，领导可以根据下属的心态波动情况进行绩效考核评估。

总之，只要大家用心观察，工作绩效尽在眼底了。

[ 本帖最后由 wanghua2009 于 2009-3-5 00:18 编辑 ]

作者: gongju 时间: 2009-3-5 14:36
我们现在针对于测试人员的考核主要基于以下几个大的方面：个人的工作质量、项目组内其他人员的评价、客户对系统的反馈综合来进行考虑。

1、个人工作质量
主要考核测试各个阶段的测试用例设计、测试用例执行情况、缺陷提交情况以及测试提交物的质量。
2、组内人员的评价
主要考核项目组对你的沟通、工作态度，团结协作情况，给你进行考核的有其他测试人员，开发人员等等。
3、客户反馈
主要将系统上线试运行后客户发现的问题做为一项考核指标，因为这个最直接反馈出项目的质量，反馈问题的严重度直接影响到你的考核分数。但是这个周期可能会跨度很长。

都说考核不是目的，但是还是希望能够依据考核结果来鼓励测试人员更好的工作，好的就是要给予奖励，例如绩效奖金、推荐培训等等，总是不好的肯定要处罚和淘汰了。

顶

作者: 月野幻儿 时间: 2009-3-5 17:30
每一个测试经理都面临这样的问题，如何对测试人员进行绩效考核。因为测试人员参与的工作不单一，需要的技能也各种各样，考核测试人员的绩效似乎不是很容易的事，除了一般需要考核的对工作的态度，工作的责任心，积极性这些方面以外，还有一些其它方面的内容。

要想对测试人员进行考核，就需要开始工作的时侯明确测试人员的职责，对测试人员的期望等，一个团队中不同的测试人员可能职责不同，比如测试负责人，测试设计人员，自动化测试人员，普通测试人员等，那么对这些人的期望也是不同的，进行绩效考核的时候需要根据对测试人员的期望进行考核，而这些职责和期望测试人员也是很明确的。

测试人员可能参与不同的软件开发过程，比如需要参与需求和设计的评审，那么也需要对这些工作进行考核，比如需求评审时可以从测试人员对需求的理解上，测试人员对需求提出的问题的质量上等作出评价。

如果需要测试人员准备测试文档，如测试用例等，那么可以通过评审测试文档来考核一个测试人员的能力。如评审测试用例的质量，对需求的覆盖程度，可理解和执行等方面来判段一个测试人员的能力。

对于执行测试的测试人员来说，可以从测试人员所发现的问题对测试人员进行评价。测试人员所发现的问题是复杂的还是简单的，是隐藏比较深的，还是一些表面的问题。还可以从问题的书写上进行评价，问题的书写是否详细清晰，开发人员可以再现，还是含糊其词，不明所以。或者测试人员书写的问题是否是自己的操作问题，一个问题是否写多遍等。

而对于已经发布的产品，也可以从用户反馈的问题来考核测试人员的绩效，但是这个可能需要的时间比较长。

测试人员的沟通能力也是考核的一个方面，无论是书面的还是口头的，测试人员都应该有较好的沟通能力。

另外测试人员的接受指示，把握细节的能力也应该进行考核，测试经理希望把任务分配给可以按照指示完成的人来完成，如果测试人员自行其事，即使技术能力比较强也对工作无益。

当然我想不同的公司的绩效考核制度不同，不能一概而论，自己总结而已。
转载自qingyue2008的文章
http://www.51testing.com/?uid-11 ... space-itemid-103728

作者: 月野幻儿 时间: 2009-3-5 17:31
[attach]49781[/attach]

作者: moondall 时间: 2009-3-6 10:39
标题: 我觉得不要这么复杂吧
测试人员的考核是很多方面的。。
经常有不公平的情况存在。而且，最重要的，我觉得要让测试人员知道考核结果啊。
我们公司很怪，考核完了，什么也不说，也不通知。你到年底也不知道公司考核的到底是个什么标准，什么结果。。

作者: 阿七 时间: 2009-3-6 11:18

项目组自评表

评价指标	典型行为或事件举例（参照标准）	自评得分	自评说明	上级评分	上级说明	最终得分
严格认真	（1分）由于不严格不认真，导致工作出现了疏漏，且没有及时补救；（2分）工作出现了问题，但能够积极补救，不推卸责任；（3分）按本岗位工作要求做，没有出现工作疏漏；（4分）发现他人的工作疏漏，告知对方，并协助其补救；（5分）严格认真地履行岗位职责，发现隐患，并预先采取措施，避免问题的发生。
主动高效	（1分）被动执行上级安排的工作，遇到困难被动等待，对工作中的问题视而不见；（2分）反应工作中的困难和问题，但没有改进建议；——至少没有主动去思考问题，（3分）主动调动各方面资源，以达成目标；（4分）工作中主动发现问题，提出有价值的改进建议；（5分）独立提出确实可行的解决方案，并推进实施，并取得良好的成效。
服务意识	（1分）不关心客户的需求和感受，对客户提出的需求没有响应。（2分）在上级要求和客户投诉的压力下，为客户解决问题；（3分）积极响应客户意见投诉，及时满足客户的需求；（4分）主动征询客户的意见与感受，并以友善愉悦的态度提供服务；（5分）提供的服务，超乎客户期望的满意度。
团队协作	（1分）不与团队成员沟通，完全按照个人设想来工作；（2分）告知团队成员自己的设想，但不响应团队成员提出的建议和要求，固执己见；（3分）能够认真听取团队成员的意见，修正个人的工作设想；（4分）当他与团队成员意见发生分歧的时候，不仅能够听取对方的意见，而且能够提出有价值的建议；（5分）在协助对方获得成功，并达成团队整体目标的同时，实现个人目标；
纪律意识	上班时间是否经常打私人电话或发送短信（经常的定义为：考核周期内5分钟以上的打私人电话或发短信达9次或以上）；是否经常迟到、早退（经常的定义为：考核周期内10分钟以上的迟到和早退达9次或以上）；上班时间是否浏览与工作无关的网站；上班时间是否看报纸、杂志和与工作无关的书籍；上班时间是否大声喧哗或吵闹；（以上每一项行为，否为1分，是为0分）
学习总结	（1分）多次出现相同的失误；（2分）能够不出现相同的失误，但不能防范于未燃；（3分）在工作中学习，能够从失误中吸取教训，举一反三；（4分）有意识地学习岗位要求的知识、技能，和业界先进的经验，并在工作中加以实践；（5分）在岗位要求的知识技能以外，还主动学习与他相关的知识技能，工作能力明显提高；
合计

项目组内部互评表

——测试方面

一、
完成工作量情况
A、
季度内在整个测试组中完成的工作量最高；
B、
季度内在整个测试组中完成的工作量较高（处于中间水平之上）；
C、
季度内在整个测试组中完成的工作量一般（处于中间水平）；
D、
季度内在整个测试组中完成工作量较低（处于中间水平之下）；
E、
季度内在整个测试组中完成工作量最低。

二、
测试过程质量
A、
测试过程质量令人放心, 基本能全部测出一般情况下的Bug外，还能测出隐藏很深的Bug，项目交给他进行测试把关很放心，在整个测试组来说，相对是最好的；
B、
测试过程质量较好, 基本能全部测出一般情况下的Bug，隐藏很深的Bug偶尔能测出，在整个测试组内来说，处于中间水平之上；
C、
测试过程质量一般，能测出大部分一般情况下的Bug，但总觉得欠火候，在整个测试组内来说，处于中间水平；
D、
测试过程质量较差,有些一般情况下的Bug都不能够测出来，或者总是那下某个功能点，在整个测试组内说，处于中间水平之下；
E、
测试过程质量极差, 有些明显的Bug都不能够测试出来，在整个测试组内来说，相对是最差的。
说明：
指提交功能测试开始到项目最终发布的测试过程质量。有些人测试过程质量很好，总体上能够把基本问题全部揪出来，而且还能够揪出一些隐藏很深的问题（当然，我们不能指望揪出所有的问题）。而且还有很重要的一点，这些人能够很早的把问题发现，而不是等到快最后来发现（不是说快最后的时候发现问题不提）。其实，作为一个开发人员，还是很欢迎测试揪出问题来的，但缺很厌烦快到最后了，才把它揪出来，心里总会想，为什么不早发现呢。而有些人测试过程质量就很差，很多很基本的Bug都测不出来，而且还丢三落四的。搞得最后都提心吊胆的发布系统。
其实，测试过程质量，虽然表现在整个开始测试到最终发布的过程，但实际上与前期准备工作还是很有关系的，就像系统实现过程质量与需求和分析设计的质量很有关系一样。测试准备工作做得好，测试用例想的很周到，编写得很全面，而且能够按照测试用例认真逐个执行，再加上实际测试过程的一些功底，测试过程质量就会明显的好。

三、
测试用例编写质量
A、
测试用例编写质量很好，编写的内容除少量细节外，一般一次可通过，在整个测试组来说，相对是最好的；
B、
测试用例编写质量较好，编写的内容虽然有些时候通不过，但明显看出，是经过认真思考了的，在整个测试组内来说，处于中间水平之上；
C、
测试用例编写质量一般，虽然由于能力有限，存在比较多的问题，但文档需要描述的各个方面都已经想到了，在整个项目组内来说，处于中间水平；
D、
测试用例编写质量较差，其内问题较多，且需要描述的好多方面，都没有提及。不过经过讨论后，修改的质量很好，在整个项目组内来说，处于中间水平之下；
E、
测试用例编写质量很差，文档只是涉及到了梗概，很多细节都没描述到，讨论后修改的结果也不理想，要修改多次，或者因为别的原因，没有达到要求还是放过去。在整个测试组内来说，是相对最差的。
说明：
指测试用例提交评审的质量。有些人写文档前想的很周全，文档也写得很仔细，提交出来的文档基本上一遍就可以通过。而有些人写的文档，提交出来讨论，一遍未通过，讨论完了改，改了再讨论，而且很多细节也没有写出来，搞得负责审核的人，最后没办法，就直接改。因为叫当事人改，还不如审核人自己改来得省心。当然，测试用例的编写质量，在测试过程中会反映出来。

[ 本帖最后由阿七于 2009-3-6 11:24 编辑 ]

作者: 阿七 时间: 2009-3-6 11:25
一个季度考核一次

作者: believe 时间: 2009-3-6 12:36
1.bug数量、严重重度、优先级等比例
2.有效bug与总bug数的比例
3.根据实际情况（如：阶段性测试），对bug把握程度是否恰当，下阶段的bug点数
4.无效bug数的比例
5.跟踪bug情况
6.所提bug的深度、广度
7.遇到有歧义bug是否有强的说服力

作者: archonwang 时间: 2009-3-6 14:05
标题: 回复 23# 的帖子
阿七的答案比较实用点。之前曾给测试部门做过一个绩效模型，改天发上来。

作者: puchonghui 时间: 2009-3-6 23:23
懂得软件工程的人都明白数据积累的意义，其中很重要的一条就是便于对个人能力和特质进行衡量。
没有经过长期的数据积累是不可能进行有效的绩效考核的。所谓的绩效考核纯粹都是一些欺上瞒下的形式主义。

23#的表格就是个典型例子。整个表格都充满了含糊不清的界定，比如第一项：

由于不严格不认真，导致工作出现了疏漏，且没有及时补救；
工作出现了问题，但能够积极补救，不推卸责任；
1 如果我尝试去补救了，怎么才算及时？怎么样又算不及时？
2 事实上碰到问题只要不先想着推责任，首先去积极补救就行。如果确实是别人的责任，当然应该别人为后果负责。

还有什么迟到早退，只有分不清人跟机器的区别的人才会拿这种弱智标准去衡量技术人员。至于规定迟到10分钟更是拍脑袋的扯谈，难道这和迟到9分59秒有什么本质区别么？只要我该做的事情做好了，你管我什么时候来什么时候走。

不想多说了，忠告喜爱类似考核的人：如果没有一定量的数据积累，不要去试图做什么个人的绩效考核（上级有要求的话自己想办法应付），把实际精力致力于有效的团队建设才是正道。

作者: lky3 时间: 2009-3-8 14:14
我们这里是多个人员共同打分。

作者: deanaa 时间: 2009-3-9 11:23
对于测试人员的绩效考核确实是一个很头疼的问题。我觉得应该是主客观相结合，个人发展和项目/部门利益相结合来考量。
主观的评定主要是根据部门主管，项目主管，项目测试组内部，项目其他组的综合评定来定性\定量评定。评定的依据应该包括工作态度，主观的工作能力，学习能力，管理和领导能力，沟通能力等等。为了在主观评定中尽量减少由于个人喜好导致的评定不合理，可以由HR或公司层面制定一个评定指导，根据每一项来打分。
客观的评定则主要是根据统计数据来进行评定。包括工作量（用例编写数量，自动化测试用例数量，执行用例数量，发现缺陷数量等等），工作质量（缺陷遗漏率等）的评定。客观评定可以最大程度的减少人为因素在评定中的影响，但是随着软件行业的发展，软件复杂度的提升，个人英雄主义已经逐渐被团队精神所取代，所以客观评定还是应该和主观评定相结合。

我想说的很重要的一点是个人发展和项目/部门利益相结合的考量。
对于软件行业来讲，人毫无疑问是决定性的因素。我们在整个管理过程中，对人的尊重也是越来越重要的一个方面。当然在绩效考核中我们不仅要考虑项目/部门利益，也需要考虑到员工个人的意愿。这就需要在制定考核目标和进行考核的过程中充分听取被考核者的意见。在项目\部门利益保证的前提下，我们应该尽量满足个人发展的要求，为个人发展提供有利的环境和条件，把考核转变成为帮助员工实现个人发展的一个催化剂，只有这样，才能使公司和部门获得最大的人力资源效益。

作者: 阿七 时间: 2009-3-9 15:11

原帖由 puchonghui 于 2009-3-6 23:23 发表
懂得软件工程的人都明白数据积累的意义，其中很重要的一条就是便于对个人能力和特质进行衡量。
没有经过长期的数据积累是不可能进行有效的绩效考核的。所谓的绩效考核纯粹都是一些欺上瞒下的形式主义。

23#的表格就是个典型例子。整个表格都充满了含糊不清的界定，比如第一项：

由于不严格不认真，导致工作出现了疏漏，且没有及时补救；
工作出现了问题，但能够积极补救，不推卸责任；
1 如果我尝试去补救了，怎么才算及时？怎么样又算不及时？
2 事实上碰到问题只要不先想着推责任，首先去积极补救就行。如果确实是别人的责任，当然应该别人为后果负责。

还有什么迟到早退，只有分不清人跟机器的区别的人才会拿这种弱智标准去衡量技术人员。至于规定迟到10分钟更是拍脑袋的扯谈，难道这和迟到9分59秒有什么本质区别么？只要我该做的事情做好了，你管我什么时候来什么时候走。

不想多说了，忠告喜爱类似考核的人：如果没有一定量的数据积累，不要去试图做什么个人的绩效考核（上级有要求的话自己想办法应付），把实际精力致力于有效的团队建设才是正道。

１　及时... 　　比如你在ｔｅｓｔ一直没测试出来，等模拟部署的时候，才测试出来．导致程序又要修改，重新ｔｅｓｔ到模拟到真实部署
　而不及时　就是你在真实部署完了　，好久都没测试出来，导致客户使用出了问题

２　至于迟到问题，　我们公司是用ＯＡ系统考勤，不是用打卡机，所以定义了１０分钟为迟到时间，比如你迟到了９分针５９秒．ＯＫ　我不算你迟到．但是要扣考勤分．而且类似这样３次，就直接扣钱，但是迟到１０分钟１秒．ｓｏｒｒｙ了　你迟到了，直接扣钱了.

３　我不知道你为什么这样愤世嫉俗，也不知道你高人说的"把实际精力致力于有效的团队建设"是如何做到的，我只知道公司必须要有刚性的制度和人性化的管理才能使团队有序．

４　另外想说的是，越是害怕考核的人，越是无能的人．生怕别人发现自己的缺点．

完了...　　　看样子你会跟帖ｊｊｗｗ的．．．

作者: 潇潇雨语 时间: 2009-3-18 12:07
好贴，谢谢！

作者: sogoc 时间: 2009-4-8 10:20
说白了，就是要看考核的最终目的！
大家都知道，考核的最终结果难免会在工资上提现！
一个没有人情味的公司是不太可能的，一个没有人情味的主管也是不太可能的，考核带有片面和主观性，导致结果也不是很让人满意或者不公平！
考核的形式是以奖励形式还是淘汰制度只能根据公司实际情况出发
我觉得大家讨论来讨论区的实际意义并不是很大，从根本上来说，大部分人只关注一个地方：工资！
从根本上来说，如果你的工资比别人高不少，那你去搞末尾淘汰制度吧，如果你的工资跟别人差不多，还是不要去搞这个末尾淘汰的，免得人员都走光了，不是我偏激，这是事实，不管怎么考核，都有不公平的，比如说用发现BUG的数量来考核，又不是所有测试人员测试同一个模块来发现BUG率的比较，而且不同人测试不同模块甚至系统，而BUG多少主要是靠程序员的程序把握，虽然测试人员很重要，但是程序员如果控制得很好，BUG可能就会很少了，甚至很那发现。

作者: lcyrb 时间: 2009-5-20 13:26
才看到
学习一下吧

作者: lansemogu1985 时间: 2009-7-23 17:31
作为一个测试人员，受教了。

作者: xinwuhanqqm 时间: 2009-8-24 16:49
学习中！

作者: zajy 时间: 2009-9-4 15:37
初来咋到，还希望多多指教啊！

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)