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用例或自动化脚本 | |||||
进度通报 | 每晚汇报,状态,进度,风险。 |
可选 | 测试排期>=5人天项目 | |||||
上线标准 | 日志 | php-error无warning/fatal,wf日志无异常。 | 必选 | 无warning | 通过/不通过 | |||
数据库/Redis | 新表dba审核通过,Redis数据量有预估。 | 必选 | 新表、新库及Redis等通过DBA审核 | 通过/不通过 | ||||
性能 | 性能符合预期or有明确的结论。 | 必选 | 有一致的性能测试结论 对外接口/外部依赖:耗时->超时配置 |
通过/不通过 | ||||
回归 | mirror/线上功能回归ok。 | 必选 | 回归覆盖全面,发现且解决完问题 | 通过/不通过 | ||||
上线后 |
监控 | 一周内完成监控项添加(日志/qps/脚本监控,语义/数据) | 必选 | 完成/未完成 | ||||
质量报告 | 第二天午高峰,服务稳定后发出质量报告。 | 必选 | 完成/未完成 | |||||
回归CheckList Case补全 | 补全方向内回归CheckList Case-上传Git。 | 必选 | 完成/未完成 | |||||
线上问题跟进 | 持续跟进,梳理方法论/流程图->工具 → Wiki/Git记录。 | 可选 |