测试绩效测评指标

一 绩效测评指标：

1.测试任务准时上线率（25%）

2.线上bug数（包括上线后其他产品需求迭代的时候发现的bug及业务覆盖率）（40%）

3.需求理解及发现以往其他产品bug能力（包括发现需求问题的能力（10%）

4.积极性，互相帮助/比重 （5%）

5.技术能力提升及分享/比重 （5%）

6.业务点汇总分享：在wiki上上传测试数据（5%）

二 提测标准：

1.完成需求文档的100%（kickoff里说明分步提测的除外）

2.提测功能的主流程必须在测试环境跑通（有测试用例评审的会在测试用例里标出，没有测试用例评审的一般都是小功能，主流程通即可）

3.有新接口的需提供接口文档（不需要是最后给客户的那个，但是接口的出入参必须提供）

4.标明需要测试回归的点（改动影响的点）

5.提测需发邮件 线上bug（P3及以上）

三 线上问题责任划分（需求未明确说明导致的问题除外）：

1.开发责任（100%）：合代码丢失，修改A功能引起B功能bug但未通知测试回归，上线前数据库脚本未执行或者脚本缺失（开发同意上线后导致的），disconf配置文件发错，代理配置错误, 等由开发原因导致的问题

2. 运维责任：disconf配置文件配置错误（开发提供正确），代理提供错误

3.测试责任（100%）：告知回归未回归导致的问题，测试遗漏（需求有但测试未覆盖导致的）

4.开发责任（30%），测试责任（70%）：包含（带上本次上线功能外的代码）其余不在已上情况导致的问题  

四 上线延期责任划分（需求更改，依赖外部及外部质量原因导致的除外）：

1.开发责任：未如期提测，提测后不达标，提测后P3问题比较多（改一个bug发现能引起好几个）

2.运维责任：环境未如期提供（开发提前告知的）

3.测试责任：后期发现bug明显多余前期（由阻塞性bug导致的除外） 不属于以上的，测试（50%），开发（50%）