2022年软件测试人员绩效考核详细.docx

《2022年软件测试人员绩效考核详细.docx》由会员分享，可在线阅读，更多相关《2022年软件测试人员绩效考核详细.docx（32页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、精选学习资料 - - - - - - - - - 1、测试 团队绩效考核绩效评估的的客体：是个体成员仍是整个团队； Pascerellayer认为,团队绩效评判应以成员个人完成工作 的状况为基本依据,理由是勉励只能作用于个人而不是群体；技能的提高和行为的改良最 终必需落实到个人；假设仅考核团队绩效,个体的努力得不到充分的确定,就 简洁造成社会懒散现象,即个体由于参与团队工作,其工作效率比自己单独工 作时的效率反而大大降低；此现象一旦在组织中扩散开来,不仅会影响组织绩 效,仍会毒害组织文化；同时,由于绩效考核与薪酬及个人价值的实现相联 系,因此,在团队中,才能高的成员倾向于对个人绩效的考核,从而

2、得到更高 的认可和酬劳； Zingheim 和 Schuster 就认为对个人的考评应考虑团队的整体绩效,因 为团队的胜利很大程度上依靠于团队成员间的团结合作,懂得支持,假设评估 集中于个体层面,会导致个人主义盛行,无视团队的协作精神,阻碍信息、技 能的共享和绩效的提高,降低团队工作的优势； 因此在实际操作中,企业往往实行一种折中的方法,即按肯定比例兼顾 团队和个人两个层面的绩效考核；从目前的讨论来看,仍没有一种很好的方法 可以科学地确定这个比例；但是,假如从团队性质的差异、团队所处的阶段等 方面来考虑,那么至少可以确定考核的天平是更向个体的一极偏仍是更向团体 的一极偏；名师归纳总结 - -

3、- - - - -第 1 页,共 25 页精选学习资料 - - - - - - - - - 绩效考核的内容：结果、行为仍是才能；对于绩效内涵存在着三种不同的观点,即“ 绩效是结果” 、“ 绩效是行为” 和“ 绩效是才能” ；Bernardin将绩效定义为“ 在特定的时间内,由特定的工作职能活动产生的产出记录,工作 绩效的总和相当于关键和必要工作职能中等绩效的总和或平均值” ,这是“ 绩效是结果” 的典型观点；Murphy等人将绩效定义为“ 一套与组织或个体所工作的组织单位的目标相关的行为” ；近年来,以才能作为绩效的观点得到 了广泛的使用,这是以评估个体所拥有的完成某项工作所具备的学问和才能的

4、 方式；相伴着这三种观点的产生和进展,绩效考核大致经受了基于结果、基于 行为以及基于才能的三个考核进展过程；？虽然这三种观点相互区分,且都是 在否认前者的基础之上产生的,但是,假如不带入特定的环境,特定的组织,及组织进展的特定时期,那么三者之间并不存在确定的优劣；假如组织下达的 目标特别清楚,基于结果的绩效考核是最简洁实施,也最有效；相反,假如目 标模糊,无法精确衡量其结果,这种考核方式就会失效；基于才能的考核方式 理论上是从战略治理的角度动身,最具有勉励成效和长期效应,最有利于组织 不断进展,但在实际操作中却很难到达成效；由于才能是无形的,它依附于个 体,既受主观因素的掌握,也受各方面客观因

5、素的影响,很难用标准化的方法 衡量个体的才能,即使是方法对组织期望成员所具有的才能和特质作出明白 释,但这些说明仍是描述性模糊语言,在实际操作中仍旧难以做到真正的科学 公正；基于行为的绩效考核方法通过考核职工为实现既定的结果所必需做出的 行为来实现对结果的掌握,由于行为必定是建立在某种才能基础之上的,并且 行为比才能更具有外显性和可测性,因此肯定程度上,该方法兼顾了组织目标 和个人才能；但是,绩效考核中简洁显现目标置换的现象,一味对行为测评会名师归纳总结 - - - - - - -第 2 页,共 25 页精选学习资料 - - - - - - - - - 导致成员将行为作为目标,进而影响实际目标

6、的实现；因此,无论哪种考核方 式,都有其适用的条件和要求,不存在一种确定好的方法；基于项目团队生命周期的绩效考核： 孵化产生期： 这是指团队形成前到团队正式形成的一个阶段,是选择合 适的项目成员组成团队的时期； 考核的客体是个人；团队的首要任务是选择项目组成员,依据项目目标 的要求,选择最为合适的人选组成团队,所以考核的对象是个人； 考核的重点是才能；从项目团队成立的目的来看,它一般是为了开发一 种新产品或者供应一项新的服务,因此对成员的学问技能要求较高,需要成员具有较高的技术水平和学问储备以及不断学习 和创新的才能；同时,成立项目团队,意在发挥团队快速响应和凝集合体聪明的优势,更加需要团队成

7、员间的 相互合作相互支持,所以需要较为系统地考核成员的和谐合作才能,包括,对 团队其它成职工作任务的熟识、口头沟通、个人成长、问题解决、责任承担、领导技能等等；因此,在选择项目团队成员的时候,通过对被选者专业技能、基本素养当然也包括过去的工作经受和背景等各方面的考核,最终确定较为合 适的人选； 成长期： 这是团队正式形成之后,团队工作逐步步入正轨,团队成员开 始通过个人努力和彼此的合作共同在所讨论的项目上获得初步的成就；名师归纳总结 - - - - - - -第 3 页,共 25 页精选学习资料 - - - - - - - - - 考核的客体是团队；团队成立之初,成员合作的意识仍没有形成,工作

8、 的独立性较强,此时的工作重点应当是营造一种信任、关怀、相互支持的合作 氛围；同时,项目也刚刚起步,没有取得实质性的进展,个人的贡献仍无法准 确衡量,在这种情形下,假如过多地衡量个人绩效,特殊是个人产出绩效,不 仅不利于合作精神的培育,也会由于精确性不高而使成员产生不公正感,从而 对团队工作形成抵触心情；留意团队整体绩效的考核,可以向整个团队成员传 递这样一个信息,即必需留意团队的整体效率,共同开发团队才能；同时,对 团队绩效的考核仍可以提高团队成员对自己团队的骄傲感和全部感,并不断提 高其认同感和归属感； 考核的重点是行为；刚刚进入一个新的团队,假如此前没有进行过合 作,成员之间会由于生疏感

9、而信任度较低,彼此在沟通和沟通上存在困难,需 要相当一段时间的磨合,工作进度也很缓慢；假如不通过有意识的加强合作意 识的培育,难么磨合期就会较长,从而影响目标的实现；因此在项目团队进入 成长期时,绩效考核的重点应当放在对团队成员行为的考核之上；绩效考核不 仅仅是一种过程的监督和事后的衡量,更是一种对职工行为进行引导的方式；作为一种信息的传播途径,通过评估的本身,反馈以及与薪酬的联系,以直接 或间接的方式告知被考核者,组织勉励什么样的行为、反对什么样的行为,从 而引导和勉励成员采纳更加积极的态度和行为,主动参与团队工作,加强团队 成员之间的合作和学习,使项目团队尽快度过磨合期,向着一个良性的方向

10、发 展；名师归纳总结 - - - - - - -第 4 页,共 25 页精选学习资料 - - - - - - - - - 成熟期： 进入成熟期,团队工作进展顺当,项目取得关键性的突破,团 队成员自由沟通,合作意识加强； 考核的客体是个人；此时应当加大对个人绩效考核的比重；由于项目已 经取得肯定的突破,目标接近实现,团队成员的成果和贡献相比照较清楚,可 以较为精确的衡量,需要对其加以确定；假如仍旧只是停留于对团队绩效的整 体考核,并以此为基础进行利益安排,个体会逐步产生不公正感,由于随着项 目工作的深化开展和目标的逐步实现,个人由于态度、才能、技术支持等诸多 方面的差异,贡献度的差距会逐步扩大,

11、客观上会有成员的贡献大于其它人,假如不准时加以确定和认可,那么就会挫伤这一部分核心成员的积极性； 考核的重点是结果；成熟期的团队首要任务是推开工作进展,以保证最 终成果的实现；由于既有的工作方式已经基本形成,合作沟通的氛围已经建 立,假如仍旧强调对个体行为的考核,会使成员将大部分的留意力投入到日常 的工作行为和方式之上；事实上,勉励行为的本身并不是目的,关键是行为带 来的结果,合作和沟通是团队的基本工作手段,但手段不能代替目的,项目及 时高效地完成才是项目团队的存在目的；假如不以任务为导向而长期进行行为 考核,简洁使个体无视目标和结果,影响工作的效率,例如,过分的留意沟通 和沟通,造成决策时议

12、而不决,贻误时机,或者看法趋中,成员过分敬重群体 看法,不愿表达自己突破性的想法和思路； 衰退期： 项目目标已经基本实现,团队即将解散,此时需要对整个项目 团队作一个综合的评估；名师归纳总结 - - - - - - -第 5 页,共 25 页精选学习资料 - - - - - - - - - 考核的客体兼顾个人和团队；进入衰退期,绩效考核一方面需要通过对 项目团队的整体绩效作出评估,以考核项目的完成情形；另一方面,也需要对 团队成员绩效作出公正科学的总结,这不仅打算成员能否取得公正的酬劳,也 是其进入另一个团队的基础； 考核的重点主要是个人的综合绩效以及团队的产出；项目团队任务明 确,业绩是团队

13、成立的最终目的,因此在项目团队解散之际,需要对目标的实 现情形作一个综合评估,以此判定项目的胜利与否；对个人也需要做一个总体 的评判,特殊是产出和才能的评估,组织需要对此进行备案,成为以后的项目 团队选择成员的重要依据；2、测试人员绩效考核考核基于测试过程进行,因此必需在过程终止之后才能进行；由于工程是 分布提交测试的,每月可以依据实际情形进行月考核,工程终止后或任务终止 后再统一考核；依据传统测试周期,测试过程分为：测试方案、测试设计和测 试执行三个方面进行；测试方案属于测试经理的范畴；测试人员主要是测试设 计和测试执行；测试人员的绩效考核包括多个方面： 工作态度；包括工作责任心和工作积极性

14、；名师归纳总结 - - - - - - -第 6 页,共 25 页精选学习资料 - - - - - - - - - 工作职责与期望达成度 留意：在工作支配前需求明确对应测试工程师的 工作职责和对测试工程师的期望值,这里的工作职责一般是和治理相关的工作 职责内容 ； 工作内容考核； 参与软件开发过程的工作内容考核,比方参与需求和设计的评审,就需 要对需求的懂得上,对需求提出问题的质量上等作出评判； 参与测试文档的预备工作,如测试用例等,需要通过评审测试文档来考 核测试人员的才能；如评审测试用例的质量,对需求的掩盖程度,可懂得和执 行等方面来判段测试人员的才能； 执行测试的工作,需要从测试人员所发

15、觉的问题对测试人员进行评判；包括发觉问题是复杂的仍是简洁的,是隐匿较深的,仍是一些外表的问题；包 括问题的书写上进行评判,问题的书写是否具体清楚,开发人员可以再现,仍 是模糊其词,不明所以；一个问题是否写多遍等； 测试结果缺陷残留,对于已经发布的产品,从用户反馈问题考核测试人 员的绩效,但是这个可能需要的时间比较长；对于不同版本的测试,可从版本 的漏检进行统计； 测试人员的沟通才能考核,包括缺陷在开发工程师中沟通的达成率和拒 绝率； 工作效率与工作质量考核；名师归纳总结 - - - - - - -第 7 页,共 25 页精选学习资料 - - - - - - - - - 测试设计中工作效率相关指

16、标： 文档产出率：这项指标值主要为测试用例文档页数除于编写文档的有效时间获得；用于考察测试人员测试用例文档的生产率大小；公式：测试用例文档页数页 / 编写测试用例文档有效时间小时参考指标：依据项目汇总得出平均在 优,低于此值为差；1.14 页 / 小时左右,高于此值为 用例产出率：这项指标值主要为上述指标值的补充,用于考察测试人员 测试用例产出率大小；测试文档页数可能包含的冗余信息较多,因此要查看文 档中测试用例的多少；方法是测试用例文档中测试用例编号总和数除于编写文 档的有效时间；公式：测试用例数个/ 编写测试用例文档有效时间小时参考指标：平均 4.21 个用例 / 小时 测试设计中工作质量

17、相关指标： 需求掩盖率：运算测试用例总数之和除于与之一一对应的功能点数之和,主要查看是否有功能点遗漏测试的情形；公式：测试用例数个/ 功能点个参考指标： 100 ；假如连功能指标都不能满意100 掩盖,起码说明测试不充分；这个指标收集起来相当困难,假如存在需求跟踪矩阵或者测试治理名师归纳总结 - - - - - - -第 8 页,共 25 页精选学习资料 - - - - - - - - - 工具能把用例与需求一一对应就简洁得多；留意：有的功能是难于测试的,那 么未能掩盖到的需求要综合分析,明确是测试人员遗漏？仍是无法测试？这需 要放入问题跟踪表中进行后续跟踪；另外,有的功能点包含的信息较多或者

18、有 的用例包含几个功能点,这时只能把重复的功能点或重复用例按一个计,难于 区分的要做说明； 文档质量：测试用例进行评审和同行评审发觉的缺陷数,或者将此缺陷 数除于文档页数算出比率；此指标考察测试人员文档编写的质量如何；公式：缺陷数评审和同行评审个/ 测试用例文档页数页参考指标：由于评审是发觉的缺陷数是不固定的,因此,这个指标没有可 供参考的数值；假如缺陷数大小不能直接用于比较就使用缺陷 / 页方式进行横向比照； 文档有效率：使用测试用例文档进行测试时发觉的系统测试缺陷数除于 此文档页数；用于考察文档是由有效的指导了测试工作；公式：缺陷数系统测试个/ 测试用例文档页数页参考指标：平均 2.18

19、个缺陷 / 页留意：假如存在测试人员在测试时创建新文档用于帮助测试时应包含这一部分；名师归纳总结 - - - - - - -第 9 页,共 25 页精选学习资料 - - - - - - - - - 用例有效率：使用测试用例发觉的全部缺陷除于测试用例数总和；这一指标是上一指标的补充指标,用于考察用例质量是否较高公式：缺陷数系统测试个/ 测试用例数个参考指标：平均 0.59 个缺陷 / 用例,也就是说,每执行两个用例才得到 1 个缺陷,各工程有所不同,可以自己实践一下 评审问题数：是否存在对需求懂得、系统架构设计、系统设计等方面引 起争议的问题；表达出测试人员发觉问题的深化层次,有利于产品质量的提

20、 高； 测试执行中工作效率相关指标： 执行效率：利用测试用例文档页数除于此次系统测试执行的时间总和不包含用例文档编写时间；补充指标方法是用例的个数除于此次系统测试 的时间总和；用于获得工作中测试人员每小时执行测试的速度；公式：测试用例文档页数页/ 执行系统测试的有效时间小时测试用例数个/ 执行系统测试的有效时间小时参考指标：平均 0.53 页 / 小时, 1.95 个用例 / 小时；即测试人员每小时执行半页测试用例或者每小时执行2 个测试用例；通过横向比较,简洁知道那位成员的执行效率较高；留意：执行效率高的不代表测试质量也高,甚至 执行效率和测试质量成反比,所以后面工作质量的指标会补充这一部分

21、的偏名师归纳总结 - - - - - - -第 10 页,共 25 页精选学习资料 - - - - - - - - - 离；实际结果说明,用例执行效率高的成员,其缺陷发觉率往往偏低,考核如 果不将此纳入进来也可以将其作为测试改良的一项重要数据进行收集； 进度偏离度：检查方案时间和实际时间的进度,方法是方案时间差额减 去实际时间差额除于实际工时总和,用于考察测试人员进度情形,监控测试是 否依据日程进行,是否满意了工程的进度要求；公式：方案开头时间- 实际开头时间方案终止时间- 实际结 束时间/ 总工时参考指标： 15 进度偏离是个相对的指标,可能偏离了 20 个工作日,但是对于一个长达半年时间的

22、测试而言偏离天数比上整体测试所需天数不足 15 ,可能偏离了 3 个工作日,但是对于一个只有 1 星期时间的测试已经 超过了整个测试阶段所需天数的 60 ；留意：运算时分子分母要保持一样,即开头或终止时间已经去除了非工作 日时间,就总工时也要去除非工作日时间；由于制定方案时是依据每个公司的 工作日来制定的,也就是说,考虑了非正常工作日的日程；测试进度也是考核很重要的一步,假如没有进度保证,全部的测试都存在 风险,第一种方法是测试人员可以采纳自下而上的方式向测试经理报告方案用 时,这种方式风险比较少,个人依据自己才能大小确定,但是缺点是存在测试 人员虚报可能性；另一种方法是测试经理进行估算后安排

23、工作日程,这时估算 是很重要的前提,除了依靠于测试经理的体会外,对评估结果进行同行评审是 很客观可取的方法；名师归纳总结 - - - - - - -第 11 页,共 25 页精选学习资料 - - - - - - - - - 缺陷发觉率：测试人员各自发觉的缺陷数总和除于各自所花费的测试时间总和；由于执行效率不能足够代表测试人员是否仔细工作,那么,每小时发现的缺陷数就是重要的考核指标,你的工作可以通过这项指标得到反馈；时公式：缺陷数系统测试个/ 执行系统测试的有效时间小参考指标：平均 1.1 个缺陷 / 小时 假使有位测试人员没有到达 1 小时发觉 1 个缺陷,那么,除非产品质量高、模块较小,否就

24、,就是他的缺陷发觉 才能不如其他测试人员；当然,具体分类中可以依据发觉重要缺陷的多少来定 义缺陷发觉才能； 测试执行中工作质量相关指标： 缺陷数：为了更客观度量,考虑到bug 的严峻性、技术难度、产品类型、模块稳固性等因素影响,不是用“ 所发觉的 bug 数量” ,而是用“ 所获得的 bug value 缺陷值 ” 来度量,公式被定义为：Bug_value= Wd Ws Wt 其中： P0_Bug_Number ：致命的 fatal 缺陷数量；P1_Bug_Number：严峻的 critical 缺陷数量； P2_Bug_Number：一般的major/normal缺陷数量； P3_Bug_N

25、umber：次要的 minor 缺陷数量Wd ：技术难度系数,如 Database , Enterprise Server, Java 难度系数大,发觉 Bug 不简洁, Wd 名师归纳总结 - - - - - - -第 12 页,共 25 页精选学习资料 - - - - - - - - - Ws：稳固性系数,全新模块,Bug 比较多,发觉缺陷比较简洁；版本越高,越稳固； Ws 可以定在 0.5 1.0 , 假设以 version 10.0 为 1.0 ,Version 1.0 = 1/100, Version 2.0 = 4/10, Version 3.0 = 9/100 , , , Ver

26、sion 8.0 = 64/100, Version 8.0 = 81/100 Wt ：产品类型系数,可依据实际情形和历史数据来判定；Wt 也可以和Wd 合并为一个系数； 有效缺陷数 / 率：被拒绝和删除的缺陷数总和,或者被拒绝和删除的缺陷数总和除于缺陷总数；这项指标用于考察测试人员发觉的、被确认为缺陷的缺陷数高低或者百分比,数和比率越低测试质量越高；公式：缺陷数系统测试中被拒绝和删除的个缺陷数系统测试中被拒绝和删除的个个/ 缺陷数系统测试参考指标：平均21.9 测试人员发觉的每100 个缺陷中平均有22 个缺陷不被开发组确认、认为不是“ 缺陷” 或者错误录入缺陷；有效缺陷比 率简洁给出,但是

27、有效缺陷数具体数据要依据项目情形,无法给出可参考的数 值；留意：这项指标可能有不正确的情形,假使缺陷被拒绝和被删除的缘由不 是由于测试人员误操作和需求懂得等自身错误引起,而是系统本身不能实现或 者数据错误引起的,那么就要考虑剔除这部分；对于测试人员发觉系统框架根名师归纳总结 - - - - - - -第 13 页,共 25 页精选学习资料 - - - - - - - - - 本性的、初始化参数设置错误引发的、错误数据、错误环境等而开发人员因无 法修正、可以通过转变环境而无需修改程序、重新导入数据、再次发布从而拒 绝或删除的缺陷,应赐予此测试人员嘉奖； 严峻缺陷率：这个比例用于补偿缺陷发觉率的不

28、足；主要是依据严峻程 度分类的缺陷数比全部缺陷或者有效缺陷数；一般而言,每个公司基本把缺陷 严峻程度分为严峻、一般和微小,或者更细通常等级数为奇数；另外,可以对缺陷严峻程度进行折算严峻：一般：微小 以得出权重,然后在运算测试人员分值；=1 ： 3 ： 5 通过折算可公式：严峻 / 一般 / 微小 / 缺陷数严峻 / 一般 / 微小 / 有效缺陷数参考指标：严峻 10% 一般 70% 微小 20% ；当测试人员发觉的缺 陷中严峻错误比率越高,说明测试质量相对就好,通常严峻程度缺陷数的分布 呈正态分布； 模块缺陷率：这个指标主要是依据一个单独测试模块的缺陷数除于模块本身 功能点数得出来的；假使一个

29、模块是单独测试的话,很简洁可以和其他模块进 行指标横向比照,参照对应的测试人员,得出所测试模块的缺陷数,可以考察 测试人员测试水平,也为开发考核供应数据；名师归纳总结 公式：缺陷数系统测试个/ 功能点个第 14 页,共 25 页缺陷数系统测试个/ 子功能点个- - - - - - -精选学习资料 - - - - - - - - - 参考指标平均 3.74 个缺陷 / 功能点1 个缺陷 / 子功能点留意：有些功能点没有子功能点,运算子功能点时要进行说明； 遗漏缺陷率：发布后的线上故障,现阶段测试相关的故障主要都是由于测试遗漏,有遗漏就说明我们的测试仍是效率不高,可以改良；公式：遗漏缺陷数/ 遗漏

30、缺陷数 + 遗漏版本发觉缺陷数 Bug 发觉的时间点, bug 曲线的收敛性,抱负的效率高的模式应当是前多后少,渐渐收敛的,假如前期bug 特别少,后期却发觉大量bug ,那我们的前期效率就有问题； 缺陷定位和可读性：可读性内容包括 Bug 描述的标准性,分优秀、良好、一般与不合格,描述是否清楚,问题定位的附件是否完备等；假如一个测 试人员只会通过页面将现象表达出来,而无法定位这种现象是有什么引起的,或者无法定位该缺陷究竟错在何处,那么可以判定测试人员只是做了简洁的外 表测试,并没有对所发觉问题进行分析定位； 对技术组 性能自动化和环境 测试人员效率的度量： 自动化测试的引入和使用是否合理,不

31、是每个项目都适合做自动化的,自动化并不能保证效率的提高,用5 个小时开发的自动化脚原来替代3 个小时的手工测试并不合算,自动化测试需要评审,依据项目的大小不同,必要的情 况下才引入自动化测试；名师归纳总结 - - - - - - -第 15 页,共 25 页精选学习资料 - - - - - - - - - 自动化测试,特殊是性能测试终止之后,我们要分析部分测试结果,测试结果的分析水平,也可以作为衡量测试效率的一个指标； 对测试项目负责人的效率的度量： 测试是否提早介入项目,例如FRD 阶段就介入,越早介入,越有利于测试,使测试人员更加熟识整个项目,使问题早暴露,提高整体效率； 开发提交测试的时

32、候,标准是否合理,把关是否严格,假如开发的质量不行,坚决要退回,不然会影响测试的效率和进度； 测试方案阶段,评判测试方案的合理性,包括任务细化,细化的程度是否合理,任务次序,资源支配,任务分协作理,风险预估等等； 项目终止后,评判项目进行阶段中负责人的跟进情形,特殊情形处理,风险触发之后的处理,资源和谐,信息收集,共享,沟通,协作等等； 测试治理； 方案质量：测试方案的评审缺陷数或比率,可以与其他同类型项目或数据库平均指标进行比照；缺陷数评审和同行评审个/ 测试方案文档页数页 成本质量：成本度量主要放在工作量这块；由于无论涉及工资仍是奖 金,都要和工作量挂上关系；成本质量主要是对测试活动的方案

33、工作量总和比名师归纳总结 - - - - - - -第 16 页,共 25 页精选学习资料 - - - - - - - - - 上实际的工作量数值总和；对测试人员考核的进度偏离已经考虑了进度因素,而工作量涉及的是成本因素；公式：测试活动方案工作量估算人日人日/ 测试活动的实际工作量参考指标：原就上不能偏离方案的 15 20 ；实际上,这个 指标是对成本的一种度量；对于一个大的项目来说,估算值往往差距特别大,阶段统计时可能有500 ！这时调整方案是很必要的,在最终阶段取考虑 运算平均估算值；一个测试经理必需对完成任务的成本进行有效掌握；这两项 指标是相对简洁量化的部分,而需要添加其他量化指标需要

34、综合考虑由项目经 理和测试部部门经理给出标准,例如治理用时比率整个项目测试期间治理时 间占整个项目测试总时间、系统整体缺陷数与其他同类型项目或数据库平均 指标进行比照等等； 考核具体方法： 将各项指标进行汇总分析,得出总和表格,依据测试人员各项指标大小名师归纳总结 进行排行榜制作,如列出1 、 2 、3、4 名；50 ；第 17 页,共 25 页 确定阶段涉及的权重；例如将测试设计和测试执行权重各为其中,工作效率占40 即占所在阶段20 ,工作质量占60 即占所在阶段30 ；- - - - - - -精选学习资料 - - - - - - - - - 确定每类指标的分值,然后每类指标到达平均标准

35、给 100 ,达不到或者超过依据 80 120 比率给分； 将比分统计出来后进行综合评定,必要的话增加一些调整系数； 最好将定性分析纳入进来,采纳问卷调查和项目经理评分制度给出定性指标分数,建议这部分权重不要超过 性；10 15 以保证测试考核的可度量 当全部考核分数给出之后,提示一点的是,既然做了考核,就必需公开 这些结果,而且考核具有导向型,不要让考核误导了对质量工作的追求才是最 重要的； 考核留意事项： 项目并不是一个月就能完成的,如每月进行,要考虑“ 可考核部分” 为 那些,选择那些指标能够横向比照,然后分阶段、分任务评定； 参与测试的时间长短也要赐予重视,除了上述量化指标外,测试人员

36、整 体投入时间长短也是很重要的,加班也要作为特殊考虑因素,或许某个测试人 员只参与了测试执行 3 小时,各项指标都是良好的,但是不行能给他比其他参 与时间更长的人员更多的分数；这部分就是增加调整系数的缘由； 测试经理的测试设计和执行部分和项目测试人员一起考核,但是测试管 理工作要单独考核,作为另外的加分,或者如文章前面所述纳入项目组赐予考名师归纳总结 - - - - - - -第 18 页,共 25 页精选学习资料 - - - - - - - - - 核；由于测试经理在项目测试中起着治理者和质量保证负责人的角色,不要把他和其他测试工程师公平对待； 考核前要考虑项目的实际情形,不要盲目的轻易承诺

37、测试组人员考核会和薪金或者剔除机制挂钩,否就考核会起到反成效； 作为考核者要留意以下比例,或许有些没有列入考核内容,但是如下这些点可以指导测试； 测试团队发觉的 bug 和全部 bug 之间的比例 spec 设计造成的 bug 重复或者误提交的 bug 所占的比例 每周发觉的 bug 的趋势图 Bug 严峻等级的构成比例 Bug 从提交到解决的平均需要时间 Bug 从解决到关闭的平均需要时间项目组测试人员考核的主要目的是在于勉励测试组测试人职工作,勉励能者,鞭策落后；另外,仍可以起到发觉人才和查找不足的作用；考核中即要表达多劳多得的原就,也要表达公正性和合理性原就,奖罚分明才能有效促使质量治理

38、工作的进步；要想考核得到中意的成效,上述方法的重要的前提条件是：必需要在项目中充分收集相关的数据,包括采集缺陷数,记录工时、提交名师归纳总结 - - - - - - -第 19 页,共 25 页精选学习资料 - - - - - - - - - 具体工作日志和进行文档配置治理,没有这些数据,定量分析就无从谈起,测试人员考核也无从谈起；3、测试人职工作度量测试度量主要从 3 部分开展工作：一个是缺陷数据的统计分析,其次个是工作量的统计分析,第三个是测试工作量的估算； 缺陷的统计分析；主要是从缺陷严峻性、优先级、模块缺陷的分布、缺陷的收敛情形、缺陷的修复情形进行统计,并依据统计结果,进行肯定的分析；

39、 工作量的统计分析； 日常工作量的记录,这个由团队成员自己编写；在填写工作记录时,需要为每个工作记录选择相应的任务类型,并且工作任务连续时间最长不超过 4小时； 每星期统计本周团队成员在各个项目中的投入情形；不仅让自己了清楚,也让上司明白测试部对于项目的支持情形； 每半个月统计整个团队的工作安排情形但是数据是每周都填写的 统计每个人在各个项目的工作量安排情形；这个和上面那个统计表的侧重点不一 样,上面这个统计表侧重在部门整体,现在这个表侧重于个体；名师归纳总结 - - - - - - -第 20 页,共 25 页精选学习资料 - - - - - - - - - 定期 如每周或半个月 将团队成员

40、在项目中的工作量投入情形记录到项 目工作量投入表中；这个表格主要用于统计具体每个项目的测试工作投入情 况,及作为后续测试工作量估算的原始数据； 在项目到达一个阶段后,将项目测试收集的数据进行汇总、统计；收集 的数据除项目基本信息外,仍包括工作量、测试投入成本、项目规模、项目总 成本、项目总工作量；主要分析测试在项目中的投入情形、成本情形、各个测 试任务的安排情形等； 最终,依据对几个项目的工作量、成本以及测试任务占项目总测试投入 的比例分析后,得到测试团队测试工作量估算的简易公式；可以依据这个简易 的公式进行测试的估算,便利测试方案中关于工作量估算部分的编写,防止在 估算工作量时缺乏依据；估算

41、内容主要包括：测试总人力成本占项目总人力成 本的比例及各项测试任务的工作量安排比例；4、效率提高 测试负责人与开发负责人共同对项目进度进行商讨分析,作出合理的测 试方案,并在测试执行过程中严格依据测试方案的进度和测试策略进行；名师归纳总结 - - - - - - -第 21 页,共 25 页精选学习资料 - - - - - - - - - 测试人员尽早的进入需求懂得阶段,充分懂得需求文档； 必要时做跟进测试,提高需求懂得深度,可间接提高测试执行的效率；跟进测试,即系统测试之前的草稿版测试,需要与开发方沟通,让其帮助来执行；跟进测试的目的不是发觉 设计；bug ,而是熟识系统环境,助于需求懂得和

42、测试 尽量防止失败的接收测试；一次版本无法接收,会铺张许多人力和时间,仍会影响测试人员的测试热忱； 任务分协作理化；测试负责人应依据项目组成员的体会和才能能个人因素,合理的安排测试任务,并将测试任务的模块和时间具体化,这样有助于提高整个项目的测试效率； 测试工作从某种角度看,会很简洁掺杂个人主观看法,测试质量也受测试人员的责任感的因素影响,所以,培育良好的测试风格,提高测试人员的责任感,也能间接提高项目的测试效率； 谨慎支配职工职务；治理者应当充分明白职工的特点,才能特长,个人气质,以让这些特质和安排的工作最正确协作,从而能够到达更好的成效；这样,职工也简洁从高效的工作种找到乐趣,满意感,成就

43、感,得到锤炼,同时很好地完成工作任务； 设定高绩效工作标准：名师归纳总结 - - - - - - -第 22 页,共 25 页精选学习资料 - - - - - - - - - 给职工制定一个一般人都很简洁到达的“ 低标准” ,让职工觉得,你认 为他才能不强,即使他努力到达了标准,也很难从工作中得到满意感,由于这 个工作标准其它人也很简洁就到达； 低的工作标准,让大家很难打起精神努力工作,由于这很简洁让人觉 得,这个事情根本不重要,它对公司,对部门重要性不够,所以他们也不会将 很大的精力投入到治理层认为不重要的工作中去,即使做好了,也是余外,因 为这项工作本身部要求那么好； 许多职工时间长了,很

44、简洁在潜意识中觉得,你安排给他的工作不重 要,那么就意味着,他对这个团队,对这个部门也不重要,他大好的青春应当 能够制造不俗的成果,产生期望寻求实现自己价值的团队；原来最求胜利的好 职工,在这个的低标准工作中被铺张了,惋惜； 供应职工自我掌握方面的信息；这里的信息是指：让职工知道自己所负 责的工作,对公司,对团队胜利具有哪方面的意义；假如做砸了,对公司的损 失是什么,对团队影响有多坏；这样,很简洁让职工对工作产生很强的责任 感；仍有,这项工作到达何种程度可以认为完成杰出,这样,他可以自行依据 高要求高效完成工作,以到达高绩效；这些信息的确是特别必要； 供应职工参与时机以培育治理者的愿景；要让职工具有和团队一起胜利 的骄傲感,成就感,这样,他会站在团队集体利益的立场上看待自己的工作；那么如何赐予