软件项目中测试人员的考核.ppt_第1页
软件项目中测试人员的考核.ppt_第2页
软件项目中测试人员的考核.ppt_第3页
软件项目中测试人员的考核.ppt_第4页
软件项目中测试人员的考核.ppt_第5页
已阅读5页,还剩17页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件测试工程师培训,软件项目中测试人员的考核,由安博测试空间技术中心/提供,考核指标,按照传统测试周期,测试过程分为:测试计划、测试设计和测试执行三个方面进行。 测试计划属于测试经理的范畴。 测试人员主要是测试设计和测试执行,测试经理的考核可包含在测试人员的考核内 。,考核指标,测试设计 测试执行 测试管理,考核指标,测试设计 工作效率相关指标 工作质量相关指标,工作效率相关指标,文档产出率 这项指标值主要为测试用例文档页数除于编写文档的有效时间获得。用于考察测试人员测试用例文档的生产率大小。 公式:测试用例文档页数(页) / 编写测试用例文档有效时间(小时) 参考指标:根据项目汇总得出平均在 1页 / 小时左右,高于此值为优,低于此值为差。,工作效率相关指标,用例产出率 这项指标值主要为上述指标值的补充,用于考察测试人员测试用例产出率大小。测试文档页数可能包含的冗余信息较多,因此要查看文档中测试用例的多少。方法是测试用例文档中测试用例编号总和数除于编写文档的有效时间。 公式:测试用例数(个) / 编写测试用例文档有效时间(小时) 参考指标:平均 个用例 / 小时,测试设计,工作质量相关指标 需求覆盖率 文档质量 文档有效率 用例有效率,工作质量相关指标,需求覆盖率 计算测试用例总数之和除于与之一一对应的功能点数之和,主要查看是否有功能点遗漏测试的情况。 公式:测试用例数(个) / 功能点(个) 参考指标: 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 考核前要考虑项目的实际情况,不要盲

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论