关注这个时间的目的是为了方便了解各方信息是否对齐，避免业务发起方很了解需求，但和第三方沟通时对方还没开始熟悉需求，沟通时出现误解和偏差.

2.2.方案设计&开发阶段

参与技术设计评审

-参与外部评审

一般是与第三方技术一起确认系统间的交互及依赖，需要关注与第三方的交互边界；关注历史数据清洗；关注灰度计划

-参与内部评审

关注与第三方交互的时序图，要求拿到时序图，评审时如果还不能确认时序图细节，至少在联调节点前补上

确定排期并周知

1）评估内部的测试耗时

基于需求分析和技术设计，首先针对自己负责的业务的测试耗时进行评估，需要确定出测试环境测试时间段、沙箱测试时间段

-时间：设计评审后

-方法：需要拆分功能模块，对每个模块进行耗时评估，大项目一般产品&UI&UE验收耗时较长，需要额外留出配合的时间

2）评估整体测试排期

收集各方QA的测试排期，需要考虑其他方的测试人日、沙箱测试人日，看各方介入测试的排期是否需要拉齐，能否拉齐

如果需要拉齐但又资源不足，可以考虑如下几种解决思路

-看能否请求到QA资源，缩短测试期跨度；

-需要根据依赖关系，来考虑自己介入的时间；

-根据依赖，确认一部分独立的功能是否可以开发自测提前上线

-部分功能开发或产品自测

-部分功能下次迭代

方式：建立共享文档，收集排期,例如：

3）周知整体测试排期及上线时间

周知各方QA在项目管理表中及时填写具体测试排期，并将项目整体测试排期同步在项目大群中；大项目上线时间最好单独预留一天上线时间

测试方案设计与评审

1）内部测试方案设计

除了针对需求的常规测试方案外，还需要考虑多个QA分工协作的问题，因此需要提前规划每个人每日的测试内容划分，沟通确认达成一致后，分别在tapd上拆分任务。如：

此处依赖前面按照模块的估时，在进入case编写阶段后可能会再调整，直到提测前会确定好

2）与外部测试方案设计与评审

整体测试方案设计时主要是确认如下几点：

-涉及的各方项目人员与排期

-关键时间节点

-配置

-数据构造

-测试边界划分

对于配置，需要明确配置提供的人员，要求能够确保配置的正确性；尽可能地使用和线上一致的配置

对于数据构造，需要各方QA提前梳理并列出自己能提供的数据构造工具，需要新开发的给出预计提供时间；有大量数据依赖但无法提供数据构造工具的需要提前帮助对方QA学会如何造数据，可以采用文档教学、组织会议现场教学等方式；仅有少量数据依赖的可以考虑测试期辅助配合造数据或者共用数据即可

设计时间：写case阶段就可以开始

评审时间：需要考虑其他方QA介入的时间，最好是他们case编写完成之后，RD执行冒烟前完成评审；若时间太早，有些QA对需求细节梳理还不是太完整透彻，不能真正理解交互边界

评审参会人员：需要考虑项目的QA是否是新人，如果是新人还需要拉上leader或者能帮助把关的人；如果边界还不是太确定还需要拉上双方的技术，避免出现遗漏或者偏差

2.3.联调冒烟阶段

1)数据构造新工具开发

进入联调阶段后RD提供的接口相对稳定，因此在此阶段进行数据构造工具开发是最合适的时机;开发完成后录入到数据构造平台，串联成流程

2)跟进开发联调进度

有必要可以参与开发的联调站会，了解开发联调进度。对于长流程项目可以提前介入进行流程测试，确保提测前核心流程无卡；积极跟进联调阶段严重问题，督促开发推动合作方进行解决。

3)接口测试

开发在进入冒烟阶段，QA可以同步开始核心接口的接口测试，提前暴露问题

4)diff代码

提测前进行代码diff，特殊情况至少在上沙箱前一定要保证能够diff完成。如果提测后才完成代码diff，会有一定风险，RD会有代码优化，需要RD给出优化的影响范围，再进行回归测试。

2.4.测试阶段

1)提供统一的测试环境

申请一个统一的测试环境，确保测试环境在项目前不会因为到期而被提前回收。正式介入测试的前一天，通知各方部署测试代码到统一的测试环境，通知各方产品完成配置。考虑到测试环境有时需要debug定位关键问题，最好维护有一个备用的测试环境

2)提供统一的沙箱环境

正式进入沙箱测试的前一天，确保各方在沙箱环境部署新分支及配置同步到沙箱。沙箱测试期第一天，再次在大群中艾特各方开发或者QA负责人确认各方的所有分支是否已全部部署，艾特各方PM负责人确认配置是否已全部生效；收到反馈确认无误后才可以正式开始测试，否则可能会出现一些错误数据

3)执行内部测试

按照测试用例及模块分工进行测试，如实际的测试模块与计划不同了，应及时修改计划并周知协作的QA,避免重复测试或者漏测；关注代码覆盖率，测试完成后找RDcheck还有哪些未覆盖的，及时补充测试

4)组织联合测试

联合测试的目的是为了用一条数据将涉及多方的完整流程串起来，避免各自测各自的没问题，但是串起来就有问题的情况；如果时间来不及可以到沙箱环境再进行联合测试

5)问题跟进

-发现外部bug需要在测试群中和对方QA反馈，要求提bug

-本期不解决的问题形成todo，跟进解决排期

-对于大项目普遍周期很长，从设计测试方案到真正上线之前，可能会有别的新业务功能上线，需要确认当前的业务逻辑能否兼容新功能

-对于推不动或者难以解决的问题，若问题长时间未解决可将问题上升

6)每日进度收集&进度同步

对于整体项目，可以每日采用站会的方式或者测试沟通群内沟通的方式收集各方进度，重点关注进度异常及原因，解决方案是否需要协助，再在技术大群内同步结论

对于内部进度周知，则需要周知更详细的细节。关注bug趋势，评估项目风险，尽量做到bug日清，如果没有日清，根据bug的个数和严重程度来评估是否一定日清及可能带来的质量和进度风险

7)参与上线计划评审

关注上线顺序、是否有回滚方案、灰度计划、产品配置。有必要时可拉其他方QA一起参加。对于上线计划评审的结论，尤其是上线的具体时间点，需要在QA群内再次通知以确保每个QA都能为之做好准备

8)组织产品&UI验收

需求提测后即可以让UI找FE同学进行UI验收；测试功能稳定后可组织产品和UE验收

2.5.上线阶段

1)上线

确认各方测试完成后，同步技术负责人可以开始上线；如果实际可以上线的时间与计划不同，需要和各方再次确认是否当日上线

2)线上验证

需要先向各方确认线上配置是否已全部配置完成，再开始线上测试，否则会造成脏数据；对于参与灰度或者线上验证的用户名单，最好确认是内部人员的

2.6.上线后

1)跟进线上问题

由于跨多个部门，大神文档和tapd给所有人开通权限比较麻烦，可以建立线上问题记录的共享表格，包括：

-问题描述

-期望结果