软件测试工程师绩效评估表.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文档。上传文档
查看更多
软件测试工程师绩效评估表 一. 软件测试工程师职责: 与软件产品部协作完成软件需求分析辩论,并依据需求说明书制定《项目测试(计 划)方案》;编写《测试用例》;建立测试环境; 负责研发部门各开发组研发的软件产品开发经过和投入运营之前的新增软件和修改 软件的模块测试和系统测试;建立、推广并维护实施软件版本管理系统; 使用并维护软件缺陷管理系统 mantis,负责软件问题解决经过跟踪记录,提交 《mantis 报告》; 负责推广实施软件开发文档规范化工作,管理研发产品相关文档; 负责协作软件研发部门等对待新项目软件或修改升级项目软件的测试工作,并提供 测试报告; 负责监督软件开发流程的执行,并负责提出软件开发经过改进建议,提升软件产品 质量。 与开发工程师和研发部门沟通报告任务进展情况,并提出最近的测试需求; 测试部负责制订测试规划、测试用例和测试实施方案,项目主负责人布置测试与对 应的开发人员沟通完成测试执行工作;及时提交准确、完整的《项目测试报告》; 项目主负责人负责开发流程管理和人力资源、测试用软硬件资源调配,需要与研发 之外的部门定期沟通把握下周或近期可能测试任务; 外部接口都由测试部主管负责完成,与其他项目组和产品部门协调项目进度; 二.软件测试的不确定性: 软件测试的目的就是使软件的错误不断趋进于零,但软件的错误是永久找不完的; 开头测试时,可能软件使用 1 个小时就出现 10 个错误;测试修正后 1 个小时出现一个错误,继续修正,继续测试,直到约一个月出现一个错误。这时这个出错几率已经经过终结评审能够接受了。那么测试就结束了。移植成功之后测试工作由开发部 门来维护。 测试一些成熟的游戏或应用,测试经过中很难发觉大量的缺陷;而测试一些不成熟 的游戏或应用,在测试前期,会出现大量的问题;这样就导致不同的工程师发觉不 同数量的 bug; 软件测试的进度首先会依据测试规划逐步进行,但是在测试经过中,测试进度会随 研发部门的进度而调整;所以乐观的与研发部门沟通、协调测试中的问题是相当必 要的。 三.测试工作最低成功标准及测试工程师考核内容: 测试工作的最后目标就是发觉客户可能发觉的所有错误。假若移植测试在使用第一 天就发觉了你没测试出来的错误,那测试是失败的。假若使用了很久(如几个月) 才出现错误,那说明测试还是成功的 。 测试工程师考核内容: 测试工程师比开发工程师更认识产品;(产品各模块总体把握能力) 测试工程师能从客户的角度来检测软件的功能;(用户身份) 测试工程师取得资料,使得编制的测试用例更切合测试的重点、难点以及关注点; (编写测试用例) 测试工程师比开发工程师更简单发觉产品的问题;(不同的思维模式) 测试工程师总是不断的发觉问题,验证问题;(提交 bug 数量、bug 质量) 测试工程师依据测试规划完成各自工作;(测试规划的执行能力) 测试工程师以操作员的角度测试产品;(Free 测试能力) 测试工程师及时与开发工程师沟通、沟通解决问题;(部门间的工作协调能力) 测试工程师及时提交测试报告;(报告的及时性、准确性) 测试工程师之间处理问题;(共同完成任务) 测试工程师协助开发工程师,认识开发流程等信息;(学习能力) 等……….. 四.软件测试人员工作业绩评估的误区: 不能仅从提交的问题数量、测试执行用例数量来推断测试人员的好坏; 模块 A 很不稳定,潜在的问题数可能有 100 个,由测试人员甲负责测试,他一个月执行 300 个用例,提交 50 个问题单,发觉 30 个有效问题,有 10 个严峻问题; 模块 B 比较稳定,潜在的问题数可能有 20 个,由测试人员乙负责测试,他一个月执行 100 个用例,提交 20 个问题单,发觉 18 个有效问题,有 8 个严峻问题; 从上述测试执行结果来看,甲提交的问题单数量和执行用例数量都要远远高于乙,但是从测试的质量来看,模块 B 的遗留问题明显少于模块 A,甲执行测试的充分性明显不如乙,从问题单质量来看,甲提交的问题单虽然许多,但近半数是非问题,做了无用功,还影响到开发人员对问题的定位所消耗的时间。 因此,必需要走出用问题单数量、用例数量评价测试人员的误区。 对软件人员发觉的问题的价值没有进行评估; 发觉一个系统架构设计方面的缺陷和隐患远比发觉几个一般界面显示问题的价值大的 多; 不重视测试文档的质量; 测试文档的质量往往是测试人员测试水平的反映;只有对系统进行了统分的、深入的 测试人员才能写出高质量的测试报告; 不重视测试人员的综合能力; 责任心、乐观性、制造性以及沟通和协调能力 附:软件测试工程师业绩评估模板:(满分:100 分) 软件测试工程师业绩评估模板:(满分:100 分) 类型 类型 问题 (35%) 评定参数 提交有效问题数量提交的非问题数量 参数值 单位(个)

文档评论(0)

泰和宸风 + 关注
官方认证
文档贡献者

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

认证主体泰和宸风文化科技(青岛)有限公司
IP属地北京
统一社会信用代码/组织机构代码
91370211MA94GKPQ0J

1亿VIP精品文档

相关文档