准入测试测试规范

 

目的

• 明确测试入口条件
• 减少在测试阶段测试工作被block的次数，提升测试时间统计的准确率
• 提高代码提交质量，增强自测程度，提升对产出物的责任感
• 为整体研发流程更加规范打下基础
• 流程

适合的项目

• 测试时间>=3天的项目
• 阶段以及产出物/沟通方式
• 代码开发/用例设计阶段

i. 代码开发

1. 前置条件：UE+产品需求文档定稿
2. 责任人：开发人员
3. 工作内容：根据需求进行架构设计以及代码开发
4. 产出物：代码
5. 沟通方式：短会+邮件

ii. 用例设计以及评审

1. 前置条件：UE+需求文档定稿
2. 责任人：测试人员为主，产品人员/研发人员参与
3. 工作内容：测试用例设计/测试用例评审/核心用例发给开发人员
4. 产出物：三方明确优先级后的功能矩阵
5. 沟通方式：评审会议+邮件
6. b) 自测阶段

i. 前置条件：代码开发完成/收到评审过的核心用例

ii. 责任人：开发人员

iii. 产出物：自测通过后的代码

iv. 沟通方式：暂无

1. c) 冒烟测试

i. 前置条件：代码自测完成

ii. 责任人：测试人员

iii. 工作内容：根据核心用例进行冒烟测试

1. 测试通过，进入测试阶段
2. 测试不通过，驳回，请开发人员进行修改

iv. 产出物：测试通过/不通过的邮件

v. 沟通方式：邮件/Bug系统

1. d) 测试阶段

i. 前置条件：冒烟测试通过

• 扩展
• 冒烟用例自动化

i. 模块主体功能回归自动化

ii. 新功能的核心部分自动化测试

iii. 新的接口自动化测试

1. b) 数据相关

i. 产品线-模块-人员-冒烟测试通过率

ii. 冒烟测试用例执行时间以及相关情况