文档介绍：目标: 为了增强部门测试工程师考核的合理性、科学性,特制定本准则,根据本准则来完成对部门所有测试工程师的考核目前部门测试团队共有 11 人,进行多个项目执行的软件测试工作,同时承担着部门大量的随机测试任务、性能测试任务、自动化测试任务在每一项考核中我们都增加了考核的权数,每个文档、用例、 Bug 的提交都需要与权数相乘以后才是最终的得分,所有的得分相加将是测试工程师的最终得分指标: 1 、提交测试相关文档的质量当前部门软件测试过程主要体现测试计划、测试用例、测试报告(会有多个)几个文档,故而对文档的考核将主要依据这几个文档来完成,对文档的质量的考核将在加分、扣分中阐述,文档的质量不满足要求会出现被扣分的情况,但是扣分最多只能扣除本文档带来积分(一般一个文档 1分) 文档的考核权数为 1文档总分=所有文档的总数× 2 、测试设计的质量当前在部门测试过程中,测试设计的工作比重已经逐步增多,从而带来了大量的测试设计工作,测试设计的好坏将直接决定着部门测试水平的高下;我们的测试设计分为测试项和测试用例,由于当前测试管理平台还有待改进,测试用例设计文档中对测试项和测试用例没有严格的区别,故而很难定义、分解两者, 目前按照统一的标准来考核测试设计的考核权数为测试用例总分=所有测试用例的总数× 3、 Bug 的提交情况对测试中发现的 Bug 进行分类和定义的目的,是为测试工程师的评价提供量化依据,为 Bug 的有效性提供参考。在考核过程中,所有的 Bug 统计都基于项目组确认是 Bug 的前提下,项目组不认定是 Bug 的不记入有效 Bug 中、同时不记入考核积分。前提保证:目前所有的 Bug 每个月都会统一汇总公布,故而减少了非正常原因被拒绝的 Bug 数量,提高了项目经理、 BA 工程师对 Bug 的处理准确性?一级 Bug (系统崩溃) 在系统运行中出现严重错误导致系统陷于瘫痪,并且无法自行恢复正常的 Bug 。一般,这类 Bug 的出现和消除都无法控制,只有通过重启系统才能恢复正常。比如,系统运行中出现的死机、系统瘫痪、通信链路频繁或长期中断、系统的关键功能在某些情况丧失、系统关键性能不能达到设计指标等。另外还有稳定性方面的严重问题等。考核权数: ?二级 Bug (应用程序崩溃) 系统功能出现严重错误,严重影响系统运行和用户使用,但无需重启系统就可以恢复或者无法自行恢复,但对系统影响相对较小的 Bug 。比如,局部死机后自动复位恢复、系统资源吊死导致的业务无法进行、系统状态或者数据区混乱影响正常运行、操作维护性能数据或告警无法上报、系统某些重要功能不稳定或者丧失、系统重要性能不能达到设计指标等。系统的重要功能已经实现,但是功能实现不合理,操作十分不便或易引起用户歧义及误操作而产生较严重后果。考核权数: ?三级 Bug (应用程序异常) 系统功能实现上出现错误,导致某些功能不能正常使用,或者系统某些功能未能实现,但对系统其他功能没有严重影响的 Bug 。比如,切换算法错误导致的不能正常切换、操作维护配置无法进行、程序中对异常缺乏保护导致的功能不完善、系统某些提及的功能未实现等。系统的一般功能实现不合理,对用户使用造成一定影响。考核权数: ?四级 Bug (轻微异常) 系统的重要和基本功能都已实现,但存在某些轻