软件测试人员绩效管理考核详细.docx

1、测试团体绩效考评
　　绩效评定客体：是个体组员还是整个团体。
　　● Pascerellayer认为，团体绩效评价应以组员个人完成工作情况为基础依据，理由是激励只能作用于个人而不是群体；技能提升和行为改善最终必需落实到个人。若仅考评团体绩效，个体努力得不到充足肯定，就轻易造成社会懒散现象，即个体因为参与团体工作，其工作效率比自己单独工作时效率反而大大降低。此现象一旦在组织中蔓延开来，不仅会影响组织绩效，还会毒害组织文化。同时，因为绩效考评和薪酬及个人价值实现相联络，所以，在团体中，能力高组员倾向于对个人绩效考评，从而得到更高认可和酬劳。
　　● Zingheim和Schuster则认为对个人考评应考虑团体整体绩效，因为团体成功很大程度上依靠于团体组员间团结合作，了解支持，若评定集中于个体层面，会造成个人主义盛行，忽略团体协作精神，阻碍信息、技能共享和绩效提升，降低团体工作优势。
　　● 所以在实际操作中，企业往往采取一个折中方法，即按一定百分比兼顾团体和个人两个层面绩效考评。从现在研究来看，还没有一个很好措施能够科学地确定这个百分比。不过，假如从团体性质差异、团体所处阶段等方面来考虑，那么最少能够确定考评天平是更向个体一极偏还是更向团体一极偏。
　　绩效考评内容：结果、行为还是能力。对于绩效内涵存在着三种不一样见解，即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin将绩效定义为“在特定时间内，由特定工作职能活动产生产出统计，工作绩效总和相当于关键和必需工作职能中等绩效总和（或平均值）”，这是“绩效是结果”经典见解。 Murphy等人将绩效定义为“一套和组织或个体所工作组织单位目标相关行为”。多年来，以能力作为绩效见解得到了广泛使用，这是以评定个体所拥有完成某项工作所含有知识和能力方法。伴伴随这三种见解诞生和发展，绩效考评大致经历了基于结果、基于行为和基于能力三个考评发展过程。？即使这三种见解相互区分，且全部是在否定前者基础之上产生，不过，假如不带入特定环境，特定组织，及组织发展特定时期，那么三者之间并不存在绝正确优劣。假如组织下达目标很清楚，基于结果绩效考评是最轻易实施，也最有效；相反，假如目标模糊，无法正确衡量其结果，这种考评方法就会失效。基于能力考评方法理论上是从战略管理角度出发，最含有激励效果和长久效应，最有利于组织不停发展，但在实际操作中却极难达成效果。因为能力是无形，它依附于个体，既受主观原因控制，也受各方面客观原因影响，极难用标准化方法衡量个体能力，即使是方法对组织期望组员所含有能力和特质作出了解释，但这些解释仍是描述性模糊语言，在实际操作中仍然难以做到真正科学公正。基于行为绩效考评方法经过考评职员为实现既定结果所必需做出行为来实现对结果控制，因为行为肯定是建立在某种能力基础之上，而且行为比能力更含有外显性和可测性所以一定程度上，该方法兼顾了组织目标和个人能力。不过，绩效考评中轻易出现目标置换现象，一味对行为测评会造成组员将行为作为目标，进而影响实际目标实现。所以，不管哪种考评方法，全部有其适用条件和要求，不存在一个绝对好方法。
　　基于项目团体生命周期绩效考评：
　　● 孵化诞生期：这是指团体形成前到团体正式形成一个阶段，是选择适宜项目组员组成团体时期。
　　→ 考评客体是个人。团体首要任务是筛选项目组组员，依据项目目标要求，选择最为适宜人选组成团体，所以考评对象是个人。
　　→ 考评关键是能力。从项目团体成立目标来看，它通常是为了开发一个新产品或提供一项新服务，所以对组员知识技能要求较高，需要组员含有较高技术水平和知识贮备和不停学习和创新能力。同时，成立项目团体，意在发挥团体快速响应和凝聚集体智慧优势，愈加需要团体组员间相互合作相互支持，所以需要较为系统地考评组员协调合作能力，包含，对团体其它成职员作任务认识、口头交流、个人成长、问题处理、责任负担、领导技能等等。所以，在选择项目团体组员时候，经过对被选者专业技能、基础素质当然也包含过去工作经历和背景等各方面考评，最终确定较为适宜人选。
　　● 成长久：这是团体正式形成以后，团体工作逐步步入正轨，团体组员开始经过个人努力和相互合作共同在所研究项目上取得初步成就。
　　→ 考评客体是团体。团体成立之初，组员合作意识还没有形成，工作独立性较强，此时工作关键应该是营造一个信任、关心、相互支持合作气氛。同时，项目也刚刚起步，没有取得实质性进展，个人贡献还无法正确衡量，在这种情况下，假如过多地衡量个人绩效，尤其是个人产出绩效，不仅不利于合作精神培养，也会因为正确性不高而使组员产生不公平感，从而对团体工作形成抵触情绪。重视团体整体绩效考评，能够向整个团体组员传输这么一个信息，即必需重视团体整体效率，共同开发团体能力。同时，对团体绩效考评还能够提升团体组员对自己团体自豪感和全部感，并不停提升其认同感和归属感。
　　→ 考评关键是行为。刚刚进入一个新团体，假如以前没有进行过合作，组员之间会因为陌生感而信任度较低，相互在沟通和交流上存在困难，需要相当一段时间磨合，工作进度也很缓慢。假如不经过有意识加强合作意识培养，难么磨合期就会较长，从而影响目标实现。所以在项目团体进入成长久时，绩效考评关键应该放在对团体组员行为考评之上。绩效考评不仅仅是一个过程监督和事后衡量，更是一个对职员行为进行引导方法。作为一个信息传输路径，经过评定本身，反馈和和薪酬联络，以直接或间接方法告诉被考评者，组织激励什么样行为、反对什么样行为，从而引导和激励组员采取愈加主动态度和行为，主动参与团体工作，加强团体组员之间合作和学习，使项目团体立即度过磨合期，向着一个良性方向发展。
　　● 成熟期：进入成熟期，团体工作进展顺利，项目取得关键性突破，团体组员自由沟通，合作意识加强。
　　→ 考评客体是个人。此时应该加大对个人绩效考评选重。因为项目已经取得一定突破，目标靠近实现，团体组员结果和贡献相对比较清楚，能够较为正确衡量，需要对其加以肯定。假如仍然只是停留于对团体绩效整体考评，并以此为基础进行利益分配，个体会逐步产生不公平感，因为伴随项目工作深入开展和目标逐步实现，个人因为态度、能力、技术支持等很多方面差异，贡献度差距会逐步扩大，客观上会有组员贡献大于其它人，假如不立即加以肯定和认可，那么就会挫伤这一部分关键组员主动性。
　　→ 考评关键是结果。成熟期团体首要任务是推进工作进展，以确保最终结果实现。因为现有工作方法已经基础形成，合作沟通气氛已经建立，假如仍然强调对个体行为考评，会使组员将大部分注意力投入到日常工作行为和方法之上。实际上，激励行为本身并不是目标，关键是行为带来结果，合作和交流是团体基础工作手段，但手段不能替换目标，项目立即高效地完成才是项目团体存在目标。假如不以任务为导向而长久进行行为考评，轻易使个体忽略目标和结果，影响工作效率，比如，过分重视沟通和交流，造成决议时议而不决，贻误时机，或意见趋中，组员过分尊重群体意见，不愿表示自己突破性想法和思绪。
　　● 衰退期：项目目标已经基础实现，团体立即解散，此时需要对整个项目团体作一个综合评定。
　　→ 考评客体兼顾个人和团体。进入衰退期，绩效考评首先需要经过对项目团体整体绩效作出评定，以考评项目标完成情况；其次，也需要对团体组员绩效作出公正科学总结，这不仅决定组员能否取得公平酬劳，也是其进入另一个团体基础。
　　→ 考评关键关键是个人综合绩效和团体产出。项目团体任务明确，业绩是团体成立最终目标，所以在项目团体解散之际，需要对目标实现情况作一个综合评定，以此判定项目标成功是否。对个人也需要做一个总体评价，尤其是产出和能力评定，组织需要对此进行立案，成为以后项目团体选择组员关键依据。
2、测试人员绩效考评
　　考评基于测试过程进行，所以必需在过程结束以后才能进行。因为工程是分布提交测试，每个月能够依据实际情况进行月考评，工程结束后或任务结束后再统一考评。根据传统测试周期，测试过程分为：测试计划、测试设计和测试实施三个方面进行。测试计划属于测试经理范围。测试人员关键是测试设计和测试实施。
　　测试人员绩效考评包含多个方面：
　　● 工作态度。包含工作责任心和工作主动性。
　　● 工作职责和期望达成度(注意：在工作安排前需求明确对应测试工程师工作职责和对测试工程师期望值，这里工作职责通常是和管理相关工作职责内容)。
　　● 工作内容考评。
　　→ 参与软件开发过程工作内容考评，比如参与需求和设计评审，就需要对需求了解上，对需求提出问题质量上等作出评价。
　　→ 参与测试文档准备工作，如测试用例等，需要经过评审测试文档来考评测试人员能力。如评审测试用例质量，对需求覆盖程度，可了解和实施等方面来判段测试人员能力。
　　→ 实施测试工作，需要从测试人员所发觉问题对测试人员进行评价。包含发觉问题是复杂还是简单，是隐藏较深，还是部分表面问题。包含问题书写上进行评价，问题书写是否具体清楚，开发人员能够再现，还是含糊其词，不明所以。一个问题是否写多遍等。
　　→ 测试结果缺点残留，对于已经公布产品，从用户反馈问题考评测试人员绩效，不过这个可能需要时间比较长；对于不一样版本测试，可从版本漏检进行统计。
　　→ 测试人员沟通能力考评，包含缺点在开发工程师中沟通达成率和拒绝率。
　　● 工作效率和工作质量考评。
　　→ 测试设计中工作效率相关指标：
　　△ 文档产出率：这项指标值关键为测试用例文档页数除于编写文档有效时间取得。用于考察测试人员测试用例文档生产率大小。
　　公式：∑测试用例文档页数（页）/∑编写测试用例文档有效时间（小时）
　　参考指标：依据项目汇总得出平均在 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 个缺点，那么，除非产品质量高、模块较小，不然，就是她缺点发觉能力不如其它测试人员。当然，具体分类中能够依据发觉关键缺点多少来定义缺点发觉能力。
　　● 测试实施中工作质量相关指标：
　　→ 缺点数：为了更客观度量，考虑到bug严重性、技术难度、产品类型、模块稳定性等原因影响，不是用“所发觉bug数量”，而是用“所取得bug value (缺点值)”来度量，公式被定义为：
　　Bug_value=（P0_Bug_Number × 1.6 + P1_Bug_Number× 1.4 + P2_Bug_Number× 0.7 + P3_Bug_Number×0.3）× Wd × Ws × Wt
　　其中：P0_Bug_Number：致命（fatal）缺点数量；P1_Bug_Number：严重（critical）缺点数量；P2_Bug_Number：通常（major/normal）缺点数量；P3_Bug_Number：次要（minor）缺点数量
　　Wd：技术难度系数，如Database， Enterprise Server， Java难度系数大，发觉Bug不轻易，Wd能够定在1.5 – 5.0
　　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， …， ， Version 8.0 = 64/100， Version 8.0 = 81/100

　　Wt：产品类型系数，可依据实际情况和历史数据来判定。Wt也能够和Wd合并为一个系数。
　　→ 有效缺点数/率：被拒绝和删除缺点数总和，或被拒绝和删除缺点数总和除于缺点总数。这项指标用于考察测试人员发觉、被确定为缺点缺点数高低或百分比，数和比率越低测试质量越高。
　　公式：∑缺点数（系统测试中被拒绝和删除）（个）
　　∑缺点数（系统测试中被拒绝和删除）（个） / ∑缺点数（系统测试）（个）
　　参考指标：平均 21.9 ％（测试人员发觉每 100 个缺点中平全部有 22 个缺点不被开发组确定、认为不是“缺点”或错误录入缺点）。有效缺点比率轻易给出，不过有效缺点数具体数据要依据项目情况，无法给出可参考数值。
　　注意：这项指标可能有不正确情况，假使缺点被拒绝和被删除原因不是因为测试人员误操作和需求了解等本身错误引发，而是系统本身不能实现或数据错误引发，那么就要考虑剔除这部分。对于测试人员发觉系统框架根本性、初始化参数设置错误引发、错误数据、错误环境等而开发人员因无法修正、能够经过改变环境而无需修改程序、重新导入数据、再次公布从而拒绝或删除缺点，应给此测试人员奖励。
　　→ 严重缺点率：这个百分比用于填补缺点发觉率不足。关键是依据严重程度分类缺点数比全部缺点或有效缺点数。通常而言，每个企业基础把缺点严重程度分为严重、通常和微小，或更细（通常等级数为奇数）。另外，能够对缺点严重程度进行折算（严重：通常：微小 =1 ： 3 ： 5 ）经过折算能够得出权重，然后在计算测试人员分值。
　　公式：∑严重 / 通常 / 微小 / ∑缺点数
　　∑严重 / 通常 / 微小 / ∑有效缺点数
　　参考指标：严重 ~10% 通常 ~70% 微小 ~20% 。当测试人员发觉缺点中严重错误比率越高，说明测试质量相对就好，通常严重程度缺点数分布呈正态分布。
→ 模块缺点率：这个指标关键是依据一个单独测试模块缺点数除于模块本身功效点数得出来。假使一个模块是单独测试话，很轻易能够和其它模块进行指标横向对比，参考对应测试人员，得出所测试模块缺点数，能够考察测试人员测试水平，也为开发考评提供数据。
　　公式：∑缺点数（系统测试（个） / 功效点（个）
　　∑缺点数（系统测试（个） / 子功效点（个）
　　参考指标 平均 3.74 个缺点 / 功效点 1 个缺点 / 子功效点
　　注意：有些功效点没有子功效点，计算子功效点时要进行说明。
　　→ 遗漏缺点率：公布后线上故障，现阶段测试相关故障关键全部是因为测试遗漏，有遗漏就说明我们测试还是效率不高，能够改善。
　　公式：∑遗漏缺点数 / (∑遗漏缺点数 + ∑遗漏版本发觉缺点数)
　　→ Bug发觉时间点，bug曲线收敛性，理想效率高模式应该是前多后少，慢慢收敛，假如前期bug很少，后期却发觉大量bug，那我们前期效率就有问题。
　　→ 缺点定位和可读性： 可读性内容包含Bug描述规范性，分优异、良好、一般和不合格，描述是否清楚，问题定位附件是否完备等。假如一个测试人员只会经过页面将现象表示出来，而无法定位这种现象是有什么引发，或无法定位该缺点到底错在何处，那么能够判定测试人员只是做了简单表面测试，并没有对所发觉问题进行分析定位。
　　● 对技术组(性能自动化和环境)测试人员效率度量：
　　→ 自动化测试引入和使用是否合理，不是每个项目全部适合做自动化，自动化并不能确保效率提升，用5个小时开发自动化脚原来替换3个小时手工测试并不合算，自动化测试需要评审，根据项目标大小不一样，必需情况下才引入自动化测试。
　　→ 自动化测试，尤其是性能测试结束以后，我们要分析部分测试结果，测试结果分析水平，也能够作为衡量测试效率一个指标。
　　● 对测试项目责任人效率度量：
　　→ 测试是否提早介入项目，比如FRD阶段就介入，越早介入，越有利于测试，使测试人员愈加熟悉整个项目，使问题早暴露，提升整体效率。
　　→ 开发提交测试时候，标准是否合理，把关是否严格，假如开发质量不行，果断要退回，不然会影响测试效率和进度。
　　→ 测试计划阶段，评价测试计划合理性，包含任务细化，细化程度是否合理，任务次序，资源安排，任务分配合理，风险预估等等。
　　→ 项目结束后，评价项目进行阶段中责任人跟进情况，特殊情况处理，风险触发以后处理，资源协调，信息搜集，共享，沟通，配合等等。
　　● 测试管理。
　　→ 计划质量：测试计划评审缺点数或比率，能够和其它同类型项目或数据库平均指标进行对比。
　　∑缺点数（评审和同行评审）（个） / ∑测试计划文档页数（页）
　　→ 成本质量：成本度量关键放在工作量这块。因为不管包含工资还是奖金，全部要和工作量挂上关系。成本质量关键是对测试活动计划工作量总和比上实际工作量数值总和。对测试人员考评进度偏离已经考虑了进度原因，而工作量包含是成本原因。
　　公式：∑测试活动计划工作量（估算人日） / ∑测试活动实际工作量（人日）
　　参考指标：标准上不能偏离计划 ± 15 ％～ ± 20 ％。实际上，这个指标是对成本一个度量。对于一个大项目来说，估算值往往差距很大，阶段统计时可能有± 500 ％！！这时调整计划是很必需，在最终阶段取考虑计算平均估算值。一个测试经理必需对完成任务成本进行有效控制。这两项指标是相对轻易量化部分，而需要添加其它量化指标需要综合考虑由项目经理和测试部部门经理给出标准，比如管理用时比率（整个项目测试期间管理时间占整个项目测试总时间）、系统整体缺点数和其它同类型项目或数据库平均指标进行对比等等。
　　● 考评具体方法：
　　→ 将各项指标进行汇总分析，得出总和表格，依据测试人员各项指标大小进行排行榜制作，如列出 1 、 2 、3、4 名。
　　→ 确定阶段包含权重。比如将测试设计和测试实施权重各为 50 ％。其中，工作效率占 40 ％（即占所在阶段 20 ％），工作质量占 60 ％（即占所在阶段 30 ％）。
　　→ 确定每类指标分值，然后每类指标达成平均标准给 100 ％，达不到或超出依据 80 ％ ~120 ％比率给分。
　　→ 将比分统计出来后进行综合评定，必需话增加部分调整系数。
　　→ 最好将定性分析纳入进来，采取问卷调查和项目经理评分制度给出定性指标分数，提议这部分权重不要超出 10 ％～ 15 ％以确保测试考评可度量性。
　　→ 当全部考评分数给出以后，提醒一点是，既然做了考评，就必需公开这些结果，而且考评含有导向型，不要让考评误导了对质量工作追求才是最关键。
● 考评注意事项：
　　→ 项目并不是30天就能完成，如每个月进行，要考虑“可考评部分”为那些，挑选那些指标能够横向对比，然后分阶段、分任务评定。
　　→ 参与测试时间长短也要给重视，除了上述量化指标外，测试人员整体投入时间长短也是很关键，加班也要作为特殊考虑原因，可能某个测试人员只参与了测试实施 3 小时，各项指标全部是良好，不过不可能给她比其它参与时间更长人员更多分数。这部分就是增加调整系数原因。
　　→ 测试经理测试设计和实施部分和项目测试人员一起考评，不过测试管理工作要单独考评，作为另外加分，或如文章前面所述纳入项目组给考评。因为测试经理在项目测试中起着管理者和质量确保责任人角色，不要把她和其它测试工程师平等对待。
　　→ 考评前要考虑项目标实际情况，不要盲目标轻易承诺测试组人员考评会和薪金或淘汰机制挂钩，不然考评会起到反效果。
　　→ 作为考评者要注意以下百分比，可能有些没有列入考评内容，不过以下这些点能够指导测试。
　　　　△ 测试团体发觉bug和全部bug之间百分比
　　　　△ spec设计造成bug
　　　　△ 反复或误提交bug所占百分比
　　　　△ 每七天发觉bug趋势图
　　　　△ Bug严重等级组成百分比
　　　　△ Bug从提交四处理平均需要时间
　　　　△ Bug从处理到关闭平均需要时间
　　项目组测试人员考评关键目标是在于激励测试组测试人职员作，激励能者，鞭策落后；另外，还能够起到发觉人才和查找不足作用。考评中即要表现多劳多得标准，也要表现公正性和合理性标准，奖罚分明才能有效促进质量管理工作进步。要想考评得到满意效果，上述方法关键前提条件是：必需要在项目中充足搜集相关数据，包含采集缺点数，统计工时、提交具体工作日志和进行文档配置管理，没有这些数据，定量分析就无从谈起，测试人员考评也无从谈起。
　　3、测试人职员作度量
　　测试度量关键从3部分开展工作： 一个是缺点数据统计分析，第二个是工作量统计分析，第三个是测试工作量估算。

　　● 缺点统计分析。关键是从缺点严重性、优先级、模块缺点分布、缺点收敛情况、缺点修复情况进行统计，并依据统计结果，进行一定分析。
　　● 工作量统计分析。
　　→ 日常工作量统计，这个由团体组员自己编写。在填写工作统计时，需要为每个工作统计选择对应任务类型，而且工作任务连续时间最长不超出4小时。
　　→ 每星期统计本周团体组员在各个项目中投入情况。不仅让自己了清楚，也让上司了解测试部对于项目标支持情况。
　　→ 每半个月统计整个团体工作分配情况(不过数据是每七天全部填写)统计每个人在各个项目标工作量分配情况。这个和上面那个统计表侧关键不一样，上面这个统计表侧重在部门整体，现在这个表侧重于个体。
　　→ 定时(如每七天或半个月)将团体组员在项目中工作量投入情况统计到项目工作量投入表中。这个表格关键用于统计具体每个项目标测试工作投入情况，及作为后续测试工作量估算原始数据。
　　→ 在项目抵达一个阶段后，将项目测试搜集数据进行汇总、统计。搜集数据除项目基础信息外，还包含工作量、测试投入成本、项目规模、项目总成本、项目总工作量。关键分析测试在项目中投入情况、成本情况、各个测试任务分配情况等。
　　● 最终，依据对多个项目标工作量、成本和测试任务占项目总测试投入百分比分析后，得到测试团体测试工作量估算简易公式。能够依据这个简易公式进行测试估算，方便测试计划中相关工作量估算部分编写，避免在估算工作量时缺乏依据。估算内容关键包含：测试总人力成本占项目总人力成本百分比及各项测试任务工作量分配百分比。

4、效率提升
　　● 测试责任人和开发责任人共同对项目进度进行商讨分析，作出合理测试计划，并在测试实施过程中严格根据测试计划进度和测试策略进行。
　　● 测试人员尽早进入需求了解阶段，充足了解需求文档。
　　● 必需时做跟进测试，提升需求了解深度，可间接提升测试实施效率；跟进测试，即系统测试之前初稿版测试，需要和开发方沟通，让其帮助来实施。跟进测试目标不是发觉bug，而是熟悉系统环境，助于需求了解和测试设计。
　　● 尽可能避免失败接收测试。一次版本无法接收会浪费大家力和时间，还会影响测试人员测试热情。
　　● 任务分配合理化。测试责任人应依据项目组组员经验和能力能个人原因，合理分配测试任务，并将测试任务模块和时间具体化，这么有利于提升整个项目标测试效率。
　　● 测试工作从某种角度看，会很轻易掺杂个人主观意见，测试质量也受测试人员责任感原因影响，所以，培养良好测试风格，提升测试人员责任感，也能间接提升项目标测试效率。
　　● 慎重安排职员职务。管理者应该充足了解职员特点，能力专长，个人气质，以让这些特质和分配工作最好配合，从而能够达成愈加好效果。这么，职员也轻易从高效工作种找到乐趣，满足感，成就感，得到锻炼，同时很好地完成工作任务。
　　● 设定高绩效工作标准：
　　→ 给职员制订一个通常人全部很轻易达成“低标准”，让职员认为，你认为她能力不强，即使她努力达成了标准，也极难从工作中得到满足感，因为这个工作标准其它人也很轻易就达成。
　　→ 低工作标准，让大家极难打起精神努力工作，因为这很轻易让人认为，这个事情根本不关键，它对企业，对部门关键性不够，所以她们也不会将很大精力投入到管理层认为不关键工作中去，即使做好了，也是多出，因为这项工作本身部要求那么好。
　　→ 很多职员时间长了，很轻易在潜意识中认为，你分配给她工作不关键，那么就意味着，她对这个团体，对这个部门也不关键，她大好青春应该能够发明不俗成绩，产生期望寻求实现自己价值团体。原来最求成功好职员，在这个低标准工作中被浪费了，可惜。
　　● 提供职员自我控制方面信息。这里信息是指：让职员知道自己所负责工作，对企业，对团体成功含有哪方面意义。假如做砸了，对企业损失是什么，对团体影响有多坏。这么，很轻易让职员对工作产生很强责任感。
　　还有，这项工作达成何种程度能够认为完成出色，这么，她能够自行根据高要求高效完成工作，以达成高绩效。这些信息确实是很必需。
　　● 提供职员参与机会以培养管理者愿景。要让职员含有和团体一起成功自豪感，成就感，这么，她会站在团体集体利益立场上看待自己工作。那么怎样给予职员这种自豪感，成就感？当职员确实做了值得骄傲时期是，她们才会认为骄傲，不然就是不老实，反而含有杀伤力。只有当职员确实有成就感时，她们才会有成就感，也只有当她们负担了关键任务时，才会真正认为自己对团体关键。真正自豪感，成就感和受重视感是奠基于主动，负责地参与相关自己工作和团体管理决议。让职员认为团体成功有她关键贡献，假如她失败了，那么团体就会受牵连，她是团体成功不可缺乏一份子，她和团体是紧密联络在一起，那么她就会对团体产生强烈责任感，从而高绩效，高要求地完成自己工作。
　　5、测试团体评定
　　测试团体评定目标： 高效提升软件测试用例覆盖率。高效提升软件测试用例覆盖度可分解为三个指标：
　　● 经过测试用例复用。
　　● 以数据驱动形式自动化测试用例。
　　● 经过有效测试用例设计方法扩大覆盖率。
　　软件测试用例覆盖率提升判定条件：
　　● 现有测试用例进行了有效管理，建立测试用例基线。
　　● 明确测试用例编写颗粒度，测试用例颗粒度能够跟代码行数对应，能够跟功效点对应，组织内部测试用例颗粒度要统一，确保全部些人员大致是一致。
　　● 单个功效点全部进行了有效规整，确定最小测试范围。确保单一个功效点进行了规整。
　　● 提升方法放在功效点组合和测试数据增加上。