QA测试流程

简介: QA测试规范–流程图                PS:任何因需求、质量等引起的delay/block 风险问题,QA必须及时关注跟进,推动协调接口同学解决,及时邮件通告。 1.需求MRD评审    PS:需求MRD评审,接口PM/RD评估需求复杂度与风险。

QA测试规范–流程图 


image2016-9-23%2019%3A33%3A33.png?versio             


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记录。 可选



目录
相关文章
|
1月前
|
弹性计算 监控 测试技术
弹性计算的测试流程
弹性计算的测试流程
18 0
|
2月前
|
安全 测试技术 持续交付
接口自动化测试的基本流程
接口自动化测试的基本流程
|
3月前
|
监控 测试技术
QA 如何审查测试过程?
QA 如何审查测试过程?
QA 如何审查测试过程?
|
3月前
|
存储 测试技术 持续交付
自动化测试与持续集成/持续交付(CI/CD):优化软件开发流程的利器
自动化测试与持续集成/持续交付(CI/CD)是现代软件开发中至关重要的环节,通过将自动化测试与持续集成/持续交付相结合,可以实现开发流程的高效优化,提高软件质量和交付速度。本文将探讨自动化测试与CI/CD的概念、原理及其在软件开发中的重要性,以及如何实施这些技术以提升团队的协作效率和软件交付质量。
58 1
|
2月前
|
测试技术
有了测试标准流程后缺陷就不会遗漏到线上吗?
有了测试标准流程后缺陷就不会遗漏到线上吗?
|
2月前
|
测试技术 BI
性能基准测试基本流程
性能基准测试基本流程
|
2月前
|
敏捷开发 测试技术 持续交付
面试题1: 测试常见工作流程
面试题1: 测试常见工作流程
|
3月前
|
敏捷开发 存储 监控
软件测试在敏捷开发流程中的挑战
软件测试在敏捷开发流程中的挑战
|
3月前
|
监控 测试技术
如何使用PDCA来改进测试流程?
如何使用PDCA来改进测试流程?
|
3月前
|
监控 测试技术 调度
测试管理流程有哪些?
测试管理流程有哪些?

热门文章

最新文章