对于全新项目中QA侧的流程工作总结和质量把控方法

【测试前】

1. 测试排期评估依据
   a. 依据产品/需求的上线时间点
   b. 依据产品的开发完成并联调成功的时间点
   c. 依据PRD文档列出的测试点数量
   d. QA的人力数量
   评估测试时长的大概公式： (开发，联调)时长的一半，或者三分之一

2. 人力分配
   a. 按照组内QA对项目的了解程度和过往经验来分配适合的人选
   b. 收集QA对于负责模块所需要的测试时间，或压缩或申请延长测试时间

3. 测试环境的准备
   a. 测试环境能跑通基本流程，保证P0级别的case能够通过
   b. 对于测试环境中，依赖的某些service和API，测试环境是不支持调用的，预先抛出。对于这类case是否支持在生产环境进行测试，或者说能不能测得到，要提前告知到产品和研发

4. 测试数据的准备
   a. 根据业务需要构造数据：可以纯粹通过跑业务场景来构造数据；也可以通过直接在测试环境进行插库，改库来构造数据；如果有相关工具，也可以利用工具来进行构造数据；或者mock数据
   b. 准备的测试数据必须只能生效于测试环境，不可拉线上数据作为测试数据，也不可将测试数据打到线上

5. 日更case的编写进度
   a. 在提测前夕的每天，对于各个模块的用例编写进度进行汇总，并且@到相关的QA
   b. 让组内的QA对于自己负责的模块在编写的过程中，所遇到的问题要及时在提测之前抛出，以免耽误测试时间

6. RD自测
   a. 研发在模块开发完成之后，除了单元测试需要自己通过外，需要以QA的测试用例的中的P0级别的进行自测，以免将P0级别的BUG遗留到测试阶段。
   PS：P0级别的BUG不可留到测试阶段，P0级别的case如果有问题的话，基本可以理解研发的代码质量与需求明显不一致，所以会可能导致研发在修复BUG之后会引入之前没有发现的问题，耽误测试进度和时间。

【测试中】

1. 测试日报
   a. 收集组内QA所负责的模块的测试进度，已经测试中遇到的问题，尤其是阻塞问题，要重点标注
   b. 汇总整体进度，与昨天的预期进度是否符合，符合最好。不符合的话为什么？什么原因导致？一定要在日报中标注出来
   c. 汇总BUG数量，标记出新增了多少个，解决了多少个，是哪个端的产生的，是否有严重问题要重点关注
   d. 基于今天的工作进度和测试情况，给出明天的进度能做到多少，明天要待解决哪些测试中遇到的问题
2. 日会(有需要的话)
   a. 重点讲今天的进度多少，是否有阻塞的问题
   b. 明天预计要测试到多少，与整个项目的排期的时间是否能赶上

【测试完】

1. PM验收环节：
   a. 构造线上测试数据：由于线上数据是不可轻易去修改的，所以在构造的过程中，需要注意数据隔离问题。一般较为可用的方法为：mock数据，走真实完整的业务场景，来测试
   b. 邀请PM进行验收，RD也需要参与，主要跑P0的主要业务场景
2. 同步组内各方人员，进行上线前的准备工作（该流程交由RD进行）

【上线后】

1. 线上回归：
   由于线上数据是不可轻易去修改的，所以在构造的过程中，需要注意数据隔离问题。一般较为可用的方法为：mock数据，走真实完整的业务场景，来测试
2. 回归结果同步：
   将结果类似于日报的模板将回归的情况和进度反馈至各方