QA测试规范–流程图

PS：任何因需求、质量等引起的delay/block 风险问题，QA必须及时关注跟进，推动协调接口同学解决，及时邮件通告。

1.需求MRD评审

PS：需求MRD评审，接口PM/RD评估需求复杂度与风险。分析需要QA测试把关的需求，应主动提前邮件通知QA同学，QA同学提前阅读MRD文档熟悉需求，需求评审中提出测试建议。

2.需求排期

PS：需求排期，明确RD、FE排期及QA测试排期，邮件通告各接口人，QA需有owner意识去推动各角色尽快确定排期，以便安排QA资源。

3.设计评审

PS：设计评审，需提前通知QA，QA提前了解背景及设计内容，参与评审，对数据库结构、架构设计合理性等维度，提出可测性建议，发现数据库及架构设计等底层问题。

4.Case 设计

PS：Case 设计，参考MRD文档理解需求业务，设计业务场景Case，参考接口文档理解接口功能与参数意义，设计接口测试Case，优先覆盖接口核心逻辑，关注边界和异常逻辑。强化接口Case 设计，弱化业务场景Case，注重接口case的自动化设计。

5.测前沟通

PS：提测前，QA主动发起与接口RD、PM的测前沟通，如：Case Review 补充遗漏及更新Case，明确测试重点，模块代码改动点，关联影响模块功能，梳理一份测试checkList。

6.准入测试

PS：a.准入测试，QA和接口RD/PM确认需求可正常提测后，梳理提测邮件，提供准入Case，明确RD/PM的准入Case测试通过标准。如：P0 Case 通过率 >= 90%，P1 Case 通过率 >= 80% 。

b.PM准入验收测试时，除基本需求逻辑外，需关注UI交互设计、文案方面。

c.准入测试不通过的需求项目，QA总结质量风险问题，邮件通告驳回，RD修改解决问题且自测通过后，再次重新提测。QA同学必须对需求提测质量做严格把关。

7.系统测试

PS：a.需求通过准入测试后，QA同学合理安排测试排期时间，做2-3轮系统测试，及时同步Bug问题至接口RD，修复后做及时回归验证。每天必须梳理总结当日测试进度、质量风险问题等，群同步或邮件通告各方向接口角色。

8.Mirror回归（预上线）

PS：系统测试通过后，在Mirror机环境做预上线回归测试。

9.上线回归（自动化）

PS：a.正式上线回归测试，优先覆盖主流程，Bug关联功能模块，测试覆盖充分，推动RD/PM一起做上线回归测试。

b.通过执行接口自动化测试，提高回归效率。

c.对质量风险较大的需求项目，QA必须把关不允许上线，且及时发出通告邮件。

d.对上线较晚，如：21:00-23:00及以后，才开始上线的需求项目，QA必须注意上线过晚而低效导致的质量风险问题，评估存在高风险，与接口RD/PM充分沟通，选择第二天再上线。

e.代码上线后，必须打开且密切关注线上监控告警信息。对于存在Warning、Fatal告警信息，必须及时跟进解决，Fatal的确认后做回滚处理。

10.线上高峰问题跟踪

PS：需求正常上线后，必须及时跟进关注线上服务是否正常，直至挺过第二天流量高峰。

11.质量报告，wiki更新

PS：梳理质量报告邮件，同步更新排期wiki。

12.自动化+监控（更新维护）

1.补充维护新接口的自动化Case，使用Numen录入或Code实现，对于不能实现自动化的接口必须明确说明原因，以便评估。

2.补充维护新接口的监控，使用Numen录入或Code实现，对于不能实现监控的接口必须明确说明原因，以便评估。

3.关于接口的自动化case和监控，需和接口RD及方向QA对接确认覆盖。

注：a.所有经QA测试项目，必须上效率云平台，管理需求MRD、Bug等。

b.线上Bug，按方向上效率云管理，此类Bug标题命名，如：【线上问题】-XX。

QA测试规范–核心CheckList (注：所有C级项目的测试流程必须严格参考此CheckList做规范测试，D级可适当裁剪，保证测试质量）

阶段

分类

检查项

强制性

通过标准

执行情况

备注

测前检查

提测阶段

代码设计

提测报告

1.是否进行设计评审，是否通过。

可选(RD排期>5人日)

2.是否进行了代码CodeReview，Review人:xx

必选

3.RD自测通过。

必选

自测结果(核心流程通过)

通过/不通过

不通过，则提测打回

4.RD给出上线步骤，回滚方案。

必选

上线方案(重点,多系统交互时)

通过/不通过

PM验收

PM完成核心功能的效果验收 。

必选

发出验收结果

通过/不通过

不通过，则提测打回

MRD文档

PM保证最终版最新MRD。

必选

效率云MRD更新

通过/不通过

接口、设计等文档

RD给出接口文档，数据库字段含义及对应属性代表含义。

必选

Wiki最终接口文档

RD辅助第一次梳理逻辑

包含在提测报告内

通过/不通过

用例及方案计划评审

QA发起用例、方案计划评审。

必选

输出RD/QA/PM认可用例

通过/不通过

测试中

打回机制

一轮测试时发现P0，阻碍主流程，必须打回。

必选

通过/不通过

Bug管理

相关Bug效率云纪录，流程规范。

按照复现步骤在完整环境中验证并关闭Bug。

必选

天级别总结

通过/不通过

自动化

按需进行 接口/流程自动化，以及线上监控思考。

可选

Numen用例或自动化脚本

进度通报

每晚汇报，状态，进度，风险。

可选

测试排期>=５人天项目

上线标准

日志

php-error无warning/fatal，wf日志无异常。

必选

无warning

通过/不通过

数据库/Redis

新表dba审核通过，Redis数据量有预估。

必选

新表、新库及Redis等通过DBA审核

通过/不通过

性能

性能符合预期or有明确的结论。

必选

有一致的性能测试结论

对外接口/外部依赖：耗时->超时配置

通过/不通过

回归

mirror/线上功能回归ok。

必选

回归覆盖全面，发现且解决完问题

通过/不通过

上线后

监控

一周内完成监控项添加(日志/qps/脚本监控，语义/数据)

必选

完成/未完成

质量报告

第二天午高峰，服务稳定后发出质量报告。

必选

完成/未完成

回归CheckList Case补全

补全方向内回归CheckList Case-上传Git。

必选

完成/未完成

线上问题跟进

持续跟进，梳理方法论/流程图－>工具 → Wiki/Git记录。

可选