软件测试工程师考核标准,(软件测试工程师考核标准.docx

(软件测试工程师考核标准

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