一 绩效测评指标：
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%）
网友评论