技术方案设计中：
1.首次完善流程图：
初步流程图绘画完成后，大概率会有一些流程的问题，比如状态的流转实现方式、逻辑处理等情况上的理解差别，或实现出入。我们需要和开发进行讨论不断完善。这就是牵动需求与开发结合的过程，也是联动监督的过程。以业务视角牵动技术实现，防止开发盲目设计，造成缺少需求逻辑或理解偏差等情况的“返工”。
2.进一步沟通，初步明确信息:
(1)需求边界，里程碑等确认：涉及多系统联合的需求过程中，清晰需求边界要有主人翁意识。需求测试负责人不是自己的情况下，也要主动了解关联系统的节奏，多系统的测试负责人，需求功能拆分等。清晰各个系统的边界等信息。在测试过程中才不会“无头苍蝇”。
(2)诉求同步确认，初步分析。自身是否依赖其他系统提供配合或是否需提供给其他系统一些能力，如：数据准备、数据构造、信息配置等。
(3)节奏沟通：初步了解其他系统的提测节奏，可更好的规划测试计划与测试策略。
比如：
依赖的服务提测时间较晚，此功能相关的测试任务就要往后排；
如果上层依赖本服务功能，若是节奏统一可以上层发起场景覆盖；上层提测较晚的，可以自行接口测试；
若自身被多个系统依赖，要前置做好内部测试从而不影响其他系统节奏等等。了解这些可以对有强依赖且节奏差异过大等风险前置提出。
2.3 第三阶段：技术方案设计后
要将涉及的配置，库表设计，流程实现都清晰起来。功能实现方案的二次矫正，更新测试方案对应内容。
1.流程逻辑的确认：
技术方案评审后再校验流程图是否与实现一致；
多方交互的功能依赖，顺序依赖
2.配置确认：
如阿波罗，页面配置，一些涉及了线上流程都都要与产品和开发做好线上数据配置的确认，做好沙箱检查
3.库表设计：
库表设计关注是否影响线上流程和数据；
是否对大量级数据表有字段变动这种SQL只能在晚上执行，需要在沙箱前要提醒开发前一天执行SQL语句，防止因为没执行影响验证进度；
状态机是否变动，OMS若状态机变动，部署沙箱后线上不可以重启，否则服务无法启动要与运维前置沟通。同时期需求不可以合并上线。
4.接口变动：
是否对原有接口有增减字段处理，若有要清晰接口调用方，是否都会随之升级jar包。以增加字段为例，增加字段且有校验逻辑时，调用方未升级jar，这个字段就是null有逻辑的时候会出现空指针。此种情况要做好兼容回归。
2.4 第四阶段：测试方案评审前
这个节点，若有其他关联系统的情况下，各方向应该已经很明确需求设计与技术设计了。这个时候要与各系统QA负责人，做最终的确定，完善测试方案初稿中模糊的内容；
1.是否有数据构造依赖
2.系统功能交互的场景，同步关联场景用例的牵头方与关注方；
3.对于依赖其他系统的情况，根据其他系统提测节奏，评估影响，分析是否需要调整自身测试计划与测试策略；
4.我对其他系统需要提供什么，期望的时间节点等。
2.5 第五阶段：测试方案评审
测试方案评审的时间，我一般会与技术方案同一天完成，趁需求“热度”还在，更好可以拉齐视角，统一节奏和差异点。大家更清晰接下来要做的事情，项目节奏更加明确。
3、关注点的变化
真正理解测试方案内容后发现，我们公司所用的测试方案模板包含了每个系统的特性。项目中测试需要关注的内容，就像一份详细的提纲一样，提醒我们关注一些没有考虑到的内容。认真的完成每一项，更可以协助我们详化测试的方法与节奏。个人从刚接触测试方案到理解测试方案，心态变化也是有一定的过程的。
按规章办事:
最开始按照项目规范的要求，对大于3D的项目进行测试方案编写。编写测试方案的过程也是“不知所以然”的“填空”。写了几个测试方案的过程中发现，测试方案中测试计划模块可以细化排期，方便清晰需求的节奏。清晰节奏里程碑于测试计划，有助于合理规划测试节奏。
关注重点：项目里程碑，项目计划
多方调研，知己知彼：
一段时间后，OMS在此期间开始收拢业务接入随着零食，门店等多个业务的不断接入，过程的累计自己也开始去关注系统的测试边界、多系统交付中的衔接功能节点、系统对接人、以及相关系统的实现和系统依赖顺序等，在多系统的配合的过程中，这些信息是很重要的。可以更快捷定位问题与所属系统和系统联系人，更快排查问题。清晰自身的业务，减少对其他系统的功能盲点，业务思维更完善。
关注重点：需求边界，需求拆分，多方系统对接人，前期准备等
战术清晰：
