QA测试流程

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

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



相关文章
|
9月前
|
监控 测试技术
QA 如何审查测试过程?
QA 如何审查测试过程?
166 0
QA 如何审查测试过程?
|
安全 定位技术 UED
测试思想 QA的价值体现
测试思想 QA的价值体现
183 0
|
测试技术
选好冒烟测试用例,为进入QA的制品包把好第一道关
选好冒烟测试用例,为进入QA的制品包把好第一道关
287 0
|
测试技术
软件测试面试题:QA 和测试的区别?
软件测试面试题:QA 和测试的区别?
350 0
|
Web App开发 数据采集 JavaScript
种草 Cypress 和 TestCafe,QA 同学一定想了解的 Web UI 自动化测试工具
谈起 Web UI 自动化测试,首先想到的肯定是 Selenium 了,毕竟 Selenium 是名噪一时的 Web UI 自动化测试工具。在一次 QA Community 的 Catch Up 上,大家聊起了最近火起来的 Cypress、TestCafe 等测试工具,那时候还不知道这是什么,心里想着大概就像是 Selenium 的改进版吧。
|
测试技术 架构师 前端开发
网易测试分享会——“一起打造你想要的QA团队”
[本文出自天外归云的博客园] 昨天(2016.11.30)参加了网易资深测试专家王晓明的测试分享会——“一起打造你想要的QA团队”,以下为笔者做的归纳总结。 重点 1.让测试更加容易做好。不容易测试的代码,不具有健壮性。
1116 0
|
安全 测试技术 数据库
|
安全 测试技术 数据安全/隐私保护

热门文章

最新文章