测试人员的绩效考核应该如何开展？？（09-3-2）（获奖名单已公布）
企业越来越重视对员工的绩效考核，对于一些传统的计时、计件类岗位工作比较容易确定考核的指标，但是对于测试人员来说，如果只凭Bug的数量、用例的数量这些简单的指标来衡量并不是很准确，而且每个人负责的模块不同，针对的开发人员技术水平不同也有很大的差别。尤其是随着时间的推移，在项目结尾阶段发现的Bug数量肯定会减少。那么针对软件测试人员，该如何设定考核方式、使用指标、评判标准等内容呢？
如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
获奖名单奖项获奖名单奖励答案链接一等奖摆饐ＰǎＳe当当购物卡50元16#二等奖zte_boy300论坛积分7#三等奖阿七100论坛积分 23#
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
相关文章：
测试人员能力考核方法—业务能力掌握程度考核
软件项目成员的业绩考核面面观
软件测试工程师考核标准
更多内容请点击＞＞＞ 想想这个问题，测试人员的绩效考核，有几个公司做了？又有几个公司做好了？即使强制做了，下面的人员全部接受吗？
我也经历过做绩效考核的公司，基本存在以下弊端：
1.浮于形式型。
公司要求这么做，部门就这么做了。做了以后并不影响个人的利益。
2.经理一人独断型
无论有没有具体考核内容，但经理不理会这些，自己凭自己的主观最后打分。
3.不公平型
没有经过实践，就相当的觉得以数据说话最公平，于是就以执行用例数，发现缺陷数等为标准。我亲自经历过这样的事，自从
以发现缺陷数为重要考核标准后，大家都争着测文档，一个错别字提一个缺陷。。。。何必呢？
4.敢怒不敢言型
这种是与工资挂钩的，或者末尾淘汰。他们考核的无非也是从工作量，积极度和看得见的数据，
整不好，你在埋头苦干，却告诉你被淘汰了。怪谁呢，只怪你不会做面子工程。
绩效考核大家都理解，提高效率，提高质量，说白了就是节约成本。
我觉得绩效考核有几个工作外的东西必须考虑进去。
1。文化背景
一个国家的文化背景。在中国就不适合做互评的考核，让同事一起打分。就象让你指出别人的缺陷一样让人不知所措。
一个公司的文化背景。公司的文化氛围，团队氛围。
2.公司发展定位
人力资源管理上讲，一个处于迅速发展期的公司，不适合做严格的管理制度和考核办法，公司应该鼓励员工去积极的发挥
个人能力，因为公司要靠这个迅速发展；而一个处于稳定期的公司，却要通过比较严格的制度来维持这种稳定；处于衰败期的公司，
最需要制定严格的制度来控制成本。
3.公司测试制度的完善程度
一个测试团队如果连最基本的测试制度都没有（我指的是测试体系方面），比如你连鉴定缺陷等级的细则都没有，连有（无）效测试用例的标准都没有，你凭什么来统计这些数据？
4.测试团队对考核制度的支持情况
如果被考核的人都觉得制度不公平，太片面的话，那最好别执行了，心理抵制比言行抵制更可怕。
鉴于上述，我想公司给测试人员做绩效考核，要根据具体情况来实施。
下面我分析的要考核那几方面：
1.工作量：
这是无可厚非的，不干活的人是没有绩效的。
2.工作质量：
写出无效用例多，提交的缺陷开发看不懂等，负责测试的模块有明显的重要缺陷却视而不见。（注意不能以偶尔现象为准则）
3.工作态度：
这点很容易理解，就是不好好干活，应付任务。
4.工作角色。
为什么说只凭工作量不公平呢，因为测试是分角色的，比如测试组长，他可能很多精力放在沟通和进度跟踪，缺陷跟踪
等其他方面，而执行的用例较少。所以不同角色不通对待。
5.贡献度。
在工作过程中，凭自己的特长，为公司测试过程改进，测试方法提高，测试团队建设做出突出贡献者。比如编写出测试工具，
极大提高测试效率。
6.挽救风险。
比如测试已经结束，但他还是凭着怀疑精神坚持自主测试，在上线前测试出重大问题。
总之，测试部门考核的目的是为了提高测试水平，规范测试流程，约束自由懒散者，鼓励个人智慧的发挥等。所以，
我觉得范有违这个目的的考核，还是不做的好。
最后补充一点，测试工作并不是独立存在的，它要与其他部分配合工作，我们很难把测试部门单独考虑做考核，我所经历过的是
以项目为单位进行考核，只要与这个项目有关的所有人都绑在一起，这样比较合理。
另一点，某个考核标准如果采集数据或者是依据，如果比较困难，麻烦，那么这点基本不可取了。还是那句话，脱离了实际的一切行为都是纸上谈兵。
[ 本帖最后由 kuailederen 于 2009-3-5 15:04 编辑 ] 对软件测试人员的量化考核是一个长期的过程，在Leader level去对测试人员的产出进行跟踪仅限于数据收集，真正要考核还是要用一些硬指标，比如一段时间的漏测率，或者一段时间内的缺陷产出比；而考评的最终目标应该符合公司阶段性的目标和策略，如效率或者质量目标。 我的做法不是看测试人员完成了多少基本测试（这是应该完成的），而是看测试人员对自动化测试的贡献有多大，每人各分难度相当的一块，最后看完成百分比 原帖由 shanghai001007 于 2009-3-3 03:55 发表 http://bbs.51testing.com/images/common/back.gif
我的做法不是看测试人员完成了多少基本测试（这是应该完成的），而是看测试人员对自动化测试的贡献有多大，每人各分难度相当的一块，最后看完成百分比
你的做法让很多人失去了积极性。
本事你就让他们觉得你所说的基本测试是不能体现工作价值的工作，那他们为什么要做好那部分工作？
我不知道你说的自动化测试具体是那方面，但你倡导的方向确实错了。
有的人他就是适合做手动测试，这也是他的特长，你为什么强迫他也搞自动化？并且还全民自动化。
另一方面，你这样做就等于直接告诉他们，会写个程序就比手工测试的要高个档次，给他们引导了错误的方向。
再次，即使你搞的很成功，大家都做的很努力，基于现状，做自动化测试的需求量大，待遇也高些，等他们觉得自己有一定能力了，势必跳槽。你这样做危害了公司的利益。
我推断你是做开发的出身，重视编程技术，但确实不适合做管理。
说错的地方，还请原谅。 抽空一起探讨了。最近比较忙。 我认为需要采用矩阵式的管理方式，同一个项目的测试人员采用测试基础指标进行比较，如测试设计速率、测试执行速率等。而不同项目之间则需要通过项目质量来进行比较，如缺陷泄露率等指标。对于能够量化且合理的指标给予量化，对于不适合量化的指标可以根据实际情况考核，最后加权折合成考核分数
个人考核应该从以下几个方面来进行：工作饱和度、工作质量、工作效能、工作积极性
简单谈下目前我的做法：
1、工作饱和度
主要考核测试各个阶段的有效工时，以小时为单位。以每月实际工作日*8为基准，按实际有效工时/基准值进行计算，可以将饱和度分为几个区间，相应的区间对应分值区间，其中实际有效工时包括设计工时、执行工时和其它工时
2、工作效能
主要考核测试人员整体工作效率，也是人员能力体现的一个方面
主要指标包括：设计效率、设计覆盖率、执行效率、执行覆盖率、是否在指定时间内完成工作任务（主要考察实际和计划的偏离度），对于以上单项指标，根据团队规模按照一定比例划分，如前10％分值为6分，中间80％分值区间是2－5分，后10％为0－2分等，当然需要根据实际情况进行调整，并不绝对化
3、工作质量
考核测试人员工件的质量，可以从用例质量、文档质量、系统质量等方面进行考核。
a）用例质量
可以用总有效缺陷除以用例总数，得出单位用例的缺陷检测率，用以考核用例设计的质量
b）文档质量
主要体现在测试计划、方案、评估报告的考核上，主要从规范性、及时性、有效性等方面进行评估
c）系统质量
主要考察有效缺陷质量、缺陷泄漏率、有效缺陷比、各级别缺陷比重等指标
4、工作积极性
主要考核测试人员沟通、学习等方面的能力。如测试过程中问题的反馈、解决测试过程中出现问题的能力、在项
目阶段测试完成后的真空期进行测试学习的能力、测试技术的创新能力等等。
将以上指标通过横向和纵向的比较得出每个测试人员考核的总分数进行排名。当然需要强调的一点是考核不是目的，而是种手段，希望通过考核来激励测试人员更好的工作，而不完全依靠考核来评判一个测试人员的好与坏。 楼上点评的相当到位:lol 我想请教下7楼考核的具体实施，比如设计效率如何评判？ 我也是认为 7楼说的很对
测试 是要个人的能力的
不是只是考自动化水平的
不是所有的人都会写代码的。
要是都会写代码的话 那为什么不去做开发呢。 昨天回去好好想了哈，根据自己的工作，谈哈自己的见解：
（1）测试需求、测试计划、测试用例、测试执行第个阶段的评审（同行或同级），通过此可以发现工作中的工作效率；
（2）周报和日报的编写：通过它们能够让测试人员清楚的看到自己按照测试计划完成了多少任务，还有多少没有完成，测试负责人通过此来了解测试的进度并了解各个测试人员的工作情况；
（3）工作的态度：因为测试本身是一个反复性很强的测试过程，比如有一次我们公司的产品要测试与IE6.0、IE7.0、FIRFOX的兼容性，一个项目由开发到完成，用户的需求再变，测试需求、计划、用例都要跟着变化，可想其工作量之大，一个系统反反复复要测试上几遍，三种浏览器都要按相同的方法去测，要是工作人员的心里产生厌烦的话，就会“偷工减料”，造成很多的测试用例没有执行。
支持7楼，说的太好了！语言表达能力也强，我有的想到的都不知道怎么说，:loveliness:
刚刚看了份PPT，也是在51testing中下的，觉得在考虑这个问题时，这里面的有些也是参考标准，但确说不出来，现在传上来，大家可以看哈，希望会有新的发现吧！
[ 本帖最后由 qinxiaocang1202 于 2009-3-3 17:16 编辑 ] 我们公司最近也想制定一套方法来考察测试人员的工作绩效，还在讨论之中。要考虑的因素很多，还必须结合到公司的具体情况。 别讲的太复杂了啊.
1.根据测试人员的工作积极性,态度上要很好.
2.当然.也要根据测试人员所负责的项目,对项目质量上的贡献.
3.可适当参考一下,从BUG的数量上.来进行.进一步提高测试人员的积极性 真是巧，这几天正在跟以前公司的一个刚刚被提升为测试
leader的人谈论这个话题。就有了说话的地方。
为我的一家之言先占个地方
:P :P :P :P :P :P :P
http://www.51testing.com/index.php?uid-47068-action-viewspace-itemid-109622
[ 本帖最后由 tengmy 于 2009-3-9 11:08 编辑 ] 我们现在针对于测试人员的考核主要基于以下几个大的方面：个人的工作质量、项目组内其他人员的评价、客户对系统的反馈综合来进行考虑。
1、个人工作质量
主要考核测试各个阶段的测试用例设计、测试用例执行情况、缺陷提交情况以及测试提交物的质量。
2、组内人员的评价
主要考核项目组对你的沟通、工作态度，团结协作情况，给你进行考核的有其他测试人员，开发人员等等。
3、客户反馈
主要将系统上线试运行后客户发现的问题做为一项考核指标，因为这个最直接反馈出项目的质量，反馈问题的严重度直接影响到你的考核分数。但是这个周期可能会跨度很长。
都说考核不是目的，但是还是希望能够依据考核结果来鼓励测试人员更好的工作，好的就是要给予奖励，例如绩效奖金、推荐培训等等，总是不好的肯定要处罚和淘汰了。 一 测试设计
工作效率相关指标
文档产出率 这项指标值主要为测试用例文档页数除于编写文档的有效时间获得。用于考察测试人员测试用例文档的生产率大小。
公式：∑测试用例文档页数（页） / ∑编写测试用例文档有效时间（小时）
参考指标：根据项目汇总得出平均在 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 ．考核前要考虑项目的实际情况，不要盲目的轻易承诺测试组人员考核会和薪金或者淘汰机制挂钩，否则考核会起到反效果。
项目组测试人员考核的主要目的是在于激励测试组测试人员工作，鼓励能者，鞭策落后；另外，还可以起到发现人才和查找不足的作用。考核中即要体现多劳多得的原则，也要体现公正性和合理性原则，奖罚分明才能有效促使质量管理工作的进步。要想考核得到满意的效果，上述方法的重要的前提条件是：必须要在项目中充分收集相关的数据，包括采集缺陷数，记录工时、提交详细工作日志和进行文档配置管理，没有这些数据，定量分析就无从谈起，测试人员考核也无从谈起。
回复 4# 的帖子
支持哈！！ 测试人员的绩效考核应该如何开展？关于“测试人员的绩效考核应该如何开展？ ”的问题，本人结合实际，总结了以下几点：
一）熟悉测试人员的工作职责，根据测试人员职责内容执行情况进行评估
一般测试人员的工作职责包含三大块：
1）测试前的准备工作
测试需求的提取，这是测试人员测试时是否明确测试需求的一项非常重要的指标
测试用例的编写和细化完善，编写较好的测试用例是可以比较全面的覆盖产品的各项功能急功能点，而且通过编写测试用例可以让测试人员非常深刻全面的了解产品功能。
测试计划的制定，实际测试时就可以检验测试计划制定是否合理了
测试环境的搭建，通过该项工作也可以反应测试人员实际是否细心收集客户问题环境及相关的需求环境。
2）测试执行，在测试执行过程中会有bug的提交及bug质量情况，测试人员对bug的描述是否简洁明了，bug优先级的把握是否合理，是否只追求数量不追求质量等都是可以看出一个测试人员实际的工作效率的。
3）测试总结及相关测试文档的编写。
二）制定合理的工作计划，根据测试计划执行情况进行评估
一般绩效考核是对测试人员一段时间内的工作进行考察，那么制定一份合理的工作计划是非常重要的，一般组长会协助测试人员
安排好一段时间内的工作（临时插入工作也是在所难免的），然后制定好计划提交给经理确认，最后双方签字确认后，工作计划便生
效，测试人员在实际工作中就要按计划执行了，绩效考核时工作计划达成情况及计划之外的工作情况（计划之外就需要领导细心掌握
了）对于领导来说是一项非常重要的指标。
三）有相关的流程规范遵守及执行情况
一般每个公司都会有一定的工作流程，作为测试人员对测试流程的掌握情况是需要非常清楚的，而实际测试人员对流程的遵守及
执行情况也反应了测试人员的工作态度，这也是绩效考核时一项重要的指标。
四）测试相关的经验交流
可以定期组织一次测试经验交流会议，通过交流，领导也可以初略了解到测试人员理论及实际技能提升水平。
五）测试人员心态情况
良好的心态对于测试人员来说至关重要，所以作为领导要随时能够了解下属的心态，领导可以根据下属的心态波动情况进行绩效考核评估。
总之，只要大家用心观察，工作绩效尽在眼底了。
[ 本帖最后由 wanghua2009 于 2009-3-5 00:18 编辑 ] 我们现在针对于测试人员的考核主要基于以下几个大的方面：个人的工作质量、项目组内其他人员的评价、客户对系统的反馈综合来进行考虑。
1、个人工作质量
主要考核测试各个阶段的测试用例设计、测试用例执行情况、缺陷提交情况以及测试提交物的质量。
2、组内人员的评价
主要考核项目组对你的沟通、工作态度，团结协作情况，给你进行考核的有其他测试人员，开发人员等等。
3、客户反馈
主要将系统上线试运行后客户发现的问题做为一项考核指标，因为这个最直接反馈出项目的质量，反馈问题的严重度直接影响到你的考核分数。但是这个周期可能会跨度很长。
都说考核不是目的，但是还是希望能够依据考核结果来鼓励测试人员更好的工作，好的就是要给予奖励，例如绩效奖金、推荐培训等等，总是不好的肯定要处罚和淘汰了。
顶 每一个测试经理都面临这样的问题，如何对测试人员进行绩效考核。因为测试人员参与的工作不单一，需要的技能也各种各样，考核测试人员的绩效似乎不是很容易的事，除了一般需要考核的对工作的态度，工作的责任心，积极性这些方面以外，还有一些其它方面的内容。
要想对测试人员进行考核，就需要开始工作的时侯明确测试人员的职责，对测试人员的期望等，一个团队中不同的测试人员可能职责不同，比如测试负责人，测试设计人员，自动化测试人员，普通测试人员等，那么对这些人的期望也是不同的，进行绩效考核的时候需要根据对测试人员的期望进行考核，而这些职责和期望测试人员也是很明确的。
测试人员可能参与不同的软件开发过程，比如需要参与需求和设计的评审，那么也需要对这些工作进行考核，比如需求评审时可以从测试人员对需求的理解上，测试人员对需求提出的问题的质量上等作出评价。
如果需要测试人员准备测试文档，如测试用例等，那么可以通过评审测试文档来考核一个测试人员的能力。如评审测试用例的质量，对需求的覆盖程度，可理解和执行等方面来判段一个测试人员的能力。
对于执行测试的测试人员来说，可以从测试人员所发现的问题对测试人员进行评价。测试人员所发现的问题是复杂的还是简单的，是隐藏比较深的，还是一些表面的问题。还可以从问题的书写上进行评价，问题的书写是否详细清晰，开发人员可以再现，还是含糊其词，不明所以。或者测试人员书写的问题是否是自己的操作问题，一个问题是否写多遍等。
而对于已经发布的产品，也可以从用户反馈的问题来考核测试人员的绩效，但是这个可能需要的时间比较长。
测试人员的沟通能力也是考核的一个方面，无论是书面的还是口头的，测试人员都应该有较好的沟通能力。
另外测试人员的接受指示，把握细节的能力也应该进行考核，测试经理希望把任务分配给可以按照指示完成的人来完成，如果测试人员自行其事，即使技术能力比较强也对工作无益。
当然我想不同的公司的绩效考核制度不同，不能一概而论，自己总结而已。
转载自qingyue2008的文章
http://www.51testing.com/?uid-111426-action-viewspace-itemid-103728
页:
[1]
2
