测试开发工程师成长日记016 - 关于提测的那些事

1.提测预演

• 背景：前期存在提测质量低，提测后bug量较多，需求遗漏等情况，现增加并规范落实，提测预演环节，增加预演是否通过的相关标准。
• 目标：提高项目/迭代提测质量。
• 预演流程：

提测标准：

• 完成并通过提测预演

• 提测预演的问题，24小时内完成修复

• 提测后，冒烟用例测试通过

免预演的条件（或）：

• 同一项目/迭代连续3次提测预演中，中优问题数不超过冒烟用例数的5%

• 连续3次，当月创建bug总数不超过200

• 连续5次迭代/项目，未出现提测延期

再次启动预演的条件（或）：

• 当月创建bug总数超过200

• 出现提测延期

2.提测流程

提测发起：

• 【建议】纯前端需求，前端负责提测；纯后端需求，后端负责提测；

• 【建议】前后端需求，前后端自行商定，1人负责提测全部前后端内容；

提测备注：

• 【必要】全部提测：附上对应的需求链接；

• 【必要】部分/分批提测：详细清单，列出具体需求内容，和需求文档标题尽量保持一致；

提测前提：

• 【必要】完成前后端联调

• 【必要】完成代码Review

• 【必要】完成冒烟用例并通过

• 【建议】完成提测预演会议，并修复完成预演中的全部问题

提测通知：

• 【必要】创建提测申请单

• 【必要】提测单中备注需填写【测试重点】、【影响范围】的说明

提测打回：

• 提测分支错误；

• 主流程跑不通；

• 冒烟测试用例不通过；

• 开发未写明测试重点、影响范围；

• 开发未提供正确的yapi文档；接口文档规范参考；

• 未进行提测预演；

免测标准：

• 【必要】对应需求已同步告知测试；

• 需求类型为只改UI布局或文案，没有改交互和业务等。