准入测试测试规范
目的
- 明确测试入口条件
- 减少在测试阶段测试工作被block的次数,提升测试时间统计的准确率
- 提高代码提交质量,增强自测程度,提升对产出物的责任感
- 为整体研发流程更加规范打下基础
- 流程
适合的项目
- 测试时间>=3天的项目
- 阶段以及产出物/沟通方式
- 代码开发/用例设计阶段
i. 代码开发
- 前置条件:UE+产品需求文档定稿
- 责任人:开发人员
- 工作内容:根据需求进行架构设计以及代码开发
- 产出物:代码
- 沟通方式:短会+邮件
ii. 用例设计以及评审
- 前置条件:UE+需求文档定稿
- 责任人:测试人员为主,产品人员/研发人员参与
- 工作内容:测试用例设计/测试用例评审/核心用例发给开发人员
- 产出物:三方明确优先级后的功能矩阵
- 沟通方式:评审会议+邮件
- b) 自测阶段
i. 前置条件:代码开发完成/收到评审过的核心用例
ii. 责任人:开发人员
iii. 产出物:自测通过后的代码
iv. 沟通方式:暂无
- c) 冒烟测试
i. 前置条件:代码自测完成
ii. 责任人:测试人员
iii. 工作内容:根据核心用例进行冒烟测试
- 测试通过,进入测试阶段
- 测试不通过,驳回,请开发人员进行修改
iv. 产出物:测试通过/不通过的邮件
v. 沟通方式:邮件/Bug系统
- d) 测试阶段
i. 前置条件:冒烟测试通过
- 扩展
- 冒烟用例自动化
i. 模块主体功能回归自动化
ii. 新功能的核心部分自动化测试
iii. 新的接口自动化测试
- b) 数据相关
i. 产品线-模块-人员-冒烟测试通过率
ii. 冒烟测试用例执行时间以及相关情况