软件测试工程师绩效评估表.docxVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
软件测试工程师绩效评估表 一.?软件测试工程师职责: 1?与软件产品部配合完成软件需求分析讨论,并根据需求说明书制定《项目测试(计 划)方案》;编写《测试用例》;建立测试环境; 2?负责研发部门各开发组研发的软件产品开发过程和投入运营之前的新增软件和修改 软件的模块测试和系统测试;建立、推广并维护实施软件版本管理系统; 3 使用并维护软件缺陷管理系统?mantis,负责软件问题解决过程跟踪记录,提交 《mantis?报告》; 4?负责推广实施软件开发文档规范化工作,管理研发产品相关文档; 5?负责配合软件研发部门等对于新项目软件或修改升级项目软件的测试工作,并提供 测试报告; 6?负责监督软件开发流程的执行,并负责提出软件开发过程改进建议,提高软件产品 质量。 7?与开发工程师和研发部门交流报告任务进展情况,并提出最近的测试需求; 8?测试部负责制订测试计划、测试用例和测试实施方案,项目主负责人安排测试与对 应的开发人员交流完成测试执行工作;及时提交准确、完整的《项目测试报告》; 9?项目主负责人负责开发流程管理和人力资源、测试用软硬件资源调配,需要与研发 之外的部门定期交流掌握下周或近期可能测试任务; 10?外部接口都由测试部主管负责完成,与其他项目组和产品部门协调项目进度; 二.软件测试的不确定性: 1?软件测试的目的就是使软件的错误不断趋进于零,但软件的错误是永远找不完的;   2 开始测试时,可能软件使用?1?个小时就出现?10?个错误;测试修正后?1?个小时出现 一个错误,继续修正,继续测试,直到约一个月出现一个错误。这时这个出错几率 已经通过终结评审可以接受了。那么测试就结束了。移植成功之后测试工作由开发 部门来维护。  3 测试一些成熟的游戏或应用,测试过程中很难发现大量的缺陷;而测试一些不成熟 的游戏或应用,在测试前期,会出现大量的问题;这样就导致不同的工程师发现不 同数量的?bug; 4?软件测试的进度首先会按照测试计划逐步进行,但是在测试过程中,测试进度会随 研发部门的进度而调整;所以积极的与研发部门交流、协调测试中的问题是相当必 要的。 三.测试工作最低成功标准及测试工程师考核内容: 测试工作的最终目标就是发现客户可能发现的所有错误。如果移植测试在使用第一 天就发现了你没测试出来的错误,那测试是失败的。如果使用了很久(如几个月) 才出现错误,那说明测试还是成功的?。 测试工程师考核内容: 1?测试工程师比开发工程师更了解产品;(产品各模块总体把握能力) 2?测试工程师能从客户的角度来检测软件的功能;(用户身份) 3?测试工程师获取资料,使得编制的测试用例更切合测试的重点、难点以及关注点; (编写测试用例) 4?测试工程师比开发工程师更容易发现产品的问题;(不同的思维模式) 5?测试工程师总是不断的发现问题,验证问题;(提交?bug?数量、bug?质量) 6?测试工程师按照测试计划完成各自工作;(测试计划的执行能力) 7?测试工程师以操作员的角度测试产品;(Free?测试能力) 8?测试工程师及时与开发工程师沟通、交流解决问题;(部门间的工作协调能力) 9?测试工程师及时提交测试报告;(报告的及时性、准确性) 10?测试工程师之间处理问题;(共同完成任务) 11?测试工程师协助开发工程师,了解开发流程等信息;(学习能力) 等……….. 四.软件测试人员工作业绩评估的误区: 1?不能仅从提交的问题数量、测试执行用例数量来判断测试人员的好坏; 模块?A?很不稳定,潜在的问题数可能有?100?个,由测试人员甲负责测试,他一个月执 行?300?个用例,提交?50?个问题单,发现?30?个有效问题,有?10?个严重问题; 模块?B?比较稳定,潜在的问题数可能有?20?个,由测试人员乙负责测试,他一个月执行 100?个用例,提交?20?个问题单,发现?18?个有效问题,有?8?个严重问题; 从上述测试执行结果来看,甲提交的问题单数量和执行用例数量都要远远高于乙,但 是从测试的质量来看,模块?B?的遗留问题显然少于模块?A,甲执行测试的充分性显然 不如乙,从问题单质量来看,甲提交的问题单虽然很多,但近半数是非问题,做了无 用功,还影响到开发人员对问题的定位所消耗的时间。 因此,必须要走出用问题单数量、用例数量评价测试人员的误区。 2?对软件人员发现的问题的价值没有进行评估; 发现一个系统架构设计方面的缺陷和隐患远比发现几个普通界面显示问题的价值大的 多; 3?不重视测试文档的质量; 测试文档的质量往往是测试人员测试水平的反映;只有对系统进行了统分的、深入的 测试人员才能写出高质量的测试报告; 4?不重视测试人员的综合能力; 责任心、积极性、创造性以及沟通和协调能力 附:软件测试工程师业绩评估模板:(满分:100?分)

文档评论(0)

damoyihao + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档