测试人员工作流程规范

需求评审

该阶段主要由PM组织进行，其他相关角色参加即可。

对QA的要求：

1. 必须参加各自负责的项目需求评审
2. 认真思考并提出问题
3. 若有特殊情况无法参加，需要自行找人代替

设计评审

该阶段主要由RD组织进行，其他相关角色参加即可。

对QA的要求：

1. 必须参加各自负责的项目设计评审
2. 认真思考，充分理解RD的设计，并提出问题
3. 考虑RD的设计是否满足PM的需求
4. 考虑RD的设计是否满足可测性要求
5. 若有特殊情况无法参加，需要自行找人代替参加

测试计划

由QA同学给出项目具体的测试排期，邮件周知相关方，具体要求可参见《测试计划模板》。

对于多组参与的大项目，由QA整体负责人给出汇总后的测试排期。

 

测试设计

由QA同学完成测试设计后，发起测试用例评审。对于大项目，需要先安排测试分析评审，通过后再着手测试用例设计。

具体要求：

1. 大项目需要安排测试分析，并进行评审，具体要求可参加QA整理的《测试分析模板》。
2. 所有项目都需安排测试设计，并组织测试内部会议评审。具体要求：在提测前2天进行；以脑图形式提供用例，并明确给出准入测试用例供研发自测使用；邀请相关研发和PM参与，记录意见并修改。
3. 完整的测试用例以EXCEL方式保存，并不断梳理。

测试执行

QA实际执行测试，以测试日报形式通报进展，测试完成后发出相应的测试报告。

具体要求：

1. 提测后首先执行准入测试，并发出准入测试结论。原则上要求提测后第二天即发出准入测试结论，具体模板可参见《准入报告模板》。
2. 测试阶段每天同步项目测试进展并发出测试日报。
3. 测试阶段发现的问题，及时录入到BUG空间并跟进解决。具体BUG相关流程参见本文档相关章节。
4. 如需安排ET测试、体验验收，请参考相应的流程。
5. 上线、回滚步骤作为测试项，也需要验证。QA参与讨论上线步骤。

Bug验证修复流程

具体要求：

1. QA在测试阶段发现的问题，需及时录入到BUG空间。按照BUG分级说明给出优先级，并详细填写步骤，预期结果，截图日志等信息。
2. RD修复后在BUG修改状态，QA跟进验证后将其关闭。
3. 对于项目中未解决的BUG，需要在测试后期，PM、RD、QA共同review，确认不修复可以放到后续迭代解决。原则上，优先级高的bug要求全部解决。

ET流程

ET时机（需要RD保证提测质量，QA保证环境通畅可用）

各个端的ET接入时间为主流程和主要功能通过时，各端具体时间依情况而定。

具体到每个项目是否安排ET，以及安排几次ET，由QA负责人确定。可与其他角色商量。建议新功能、前端项目尽量安排ET测试

ET参与人员（请必须参加人员务必准时参加）

必须参加人员

各个角色负责人（PM、RD、QA、FE、UE、UI）

产品需求方（PM、运营、商户BD等）

参与开发的RD

参与测试的QA

需要参加的人员（希望RD经理、QA组长支持，督促大家都去参加）

项目对应RD、QA组成员

ET过程解答

至少确认1~2个负责人（QA、PM各一个），解答ET中大家遇到的问题

ET问题处理

ET完成后，QA项目负责人需要对问题一一进行分析，指定责任人、bug类型等相关；

ET发现的问题（去除not a bug），需要与PM、RD、FE一一确认，明确修复优先级、修复时间

体验验收流程

新功能、前端项目、体验优化类项目，需要相关的需求方（BD、PM、UI等）体验确认。

执行建议：

1. 一般建议安排两轮体验，首轮在提测前安排，主要偏重整体功能是否满足需求预期。由研发提供环境给需求方。
2. 第二轮体验在测试后期安排，主要偏重功能细节和体验。需求方以邮件形式给出体验结论（如问题列表），和研发、测试讨论后安排修复计划。

测试报告

测试完成后，由QA发出测试报告。具体报告形式参见《测试报告模板》。

补充说明：

1. 对于安排了性能测试的项目，需一并发出性能测试报告，具体报告形式参见《性能测试报告模板》。
2. 大项目需跟随测试报告，同时发出质量标准达标结论。
3. 质量标准相关内容，在测试初期发出，与相关的需求方、研发达成一致，作为衡量是否达到上线要求的客观标准。
4. 对于不能达到上线状态的项目，QA根据测试情况给出客观结论，附带遗留问题列表。由需求方MGR、研发MGR、测试MGR共同给出是否如期上线或者延期结论。

上线回归

Qa提供上线验证checklist，并在相应的上线阶段（预发、小流量、全流量）阶段分别check。

补充说明：

1. QA提供上线验证checklist，与研发达成一致
2. 在上线的每一个阶段，QA进行相应的回归验证，并在各组的群里通报验证结论。有问题及时反馈。