1、背景

        工作上的项目规范要求：测试排期大于3D的项目要编写测试方案。调研了部分同学的情况，在此流程规范要求的基础上，对于需求的逻辑复杂或技术实现复杂等情况也会准备测试方案。

        我个人主要负责OMS系统测试，它是整个履约流转中一个重要的节点，系统的定位是管理履约中的订单数据，业务中系统是用户与履约能力流程中的衔接点，是订单与履约间的流转的核心。由于系统对业务整体流程影响较大，所以要对系统的流程结构十分清晰，质量要严格保障。想根据个人视角结合系统的情况来简单分享一下我编写测试方案的小习惯。

---

2、编写的方式

        每个人编写测试方案的方法都各有差异，做了部分人员统计，大部分同学的测试方案是在技术方案评审完成后开始。由于系统特性、系统了解程度、以及个人编写的习惯等原因，我编写测试方案的时间节点在需求评审完成后，再在技术设计，技术评审后等阶段不停的优化完善。

2.1 第一阶段：在需求评审开始前

        初步了解本次需求是什么？

        产品会将需求提前发出，要前置查看需求背景，目标，需求设计。针对需求看是否有不清晰的地方，比如：是否有二期？是临时方案吗？通用性？是否有业务流程缺失？需求边界是否清晰？功能是否符合系统定位？流程是否完善合理？等等。带着这些问题进行需求评审，有助于协助分析需求，对一些业务上的模糊细节前置。尽量在一次评审中将可以确认的事情全部确认清楚。

2.2 第二阶段：在需求评审开始后，技术方案设计中

需求评审后：

        1.填写测试方案：填写测试方案中的项目背景、目标等需求层面的明确信息。

        2.初步沟通：清晰本次需求变动是否涉及多个业务系统，前置沟通明确需求边界与关联系统的负责人。相关问题可以快速定位负责人。

        3.清晰需求流程，绘制初版流程图：用QA视角绘制需求流程图，涉及流程上的最好是自己再画一遍。此节点的开发才开始设计技术方案，可以先用需求角度，纯业务流程的思维初步绘制流程图，有疑问的地方记录下来。

        关于流程图还是有话说的：一般来说产品在需求中是会有个流程图的。一开始想的是，产品有就用产品的就好了。直到有一次测试方案评审中，产品说：“这个流程图‘抄袭我’”。也是一时“好面子”，想不就是个图嘛！我自己画。第一次画的时候发现，原来产品的流程图对QA来说是有些“盲点的”，如：状态的流转不够清晰，逻辑处理都不够细化等。在绘画流程图的过程，以QA测试视角去详细了解业务流转的流程、逻辑上的处理、不同场景下的结果等。

技术方案设计中：

        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在此期间开始收拢业务接入随着零食，门店等多个业务的不断接入，过程的累计自己也开始去关注系统的测试边界、多系统交付中的衔接功能节点、系统对接人、以及相关系统的实现和系统依赖顺序等，在多系统的配合的过程中，这些信息是很重要的。可以更快捷定位问题与所属系统和系统联系人，更快排查问题。清晰自身的业务，减少对其他系统的功能盲点，业务思维更完善。

      关注重点： 需求边界，需求拆分，多方系统对接人，前期准备等

战术清晰：

        测试手段安排就如同战场制定战术一样重要。提高这个模块的重视程度在一次OMS内部技术优化的需求中。在业务大范围介入OMS系统后，OMS内部开始了系统内部优化，最大的核心变动就是库存模型的调整。这个需求是对外部业务无感知，但内部结构变动极大的需求。这个测试方案内容也是在负责人要求的过程中多次优化。要对技术方案深入了解，完善测试方案内容如：灰度策略，配置相关，测试策略和测试手段等。还对回归范围，影响的系统，以及协助回归的负责人做好确认与前置沟通。将风险降至最低，将需要确认的方向持续矫正，保障质量。

     关注重点： 技术方案流程，测试策略，测试手段，配置与检查项相关等

贴近业务：

        随着工作时长的累加，意识到若想真的了解系统，就要贴近业务。明白系统的定位，发展的方向和接下来的计划都是很重要。这样在一些大需求中可以针对业务方向、长期的目标、系统定位、是否长期发展来分析需求的设计，技术的设计方向协同分析是否适合长期的迭代。要重视需求的目标、背景、实现才能更好的做好质量把控，项目的前提一定是业务。

        关注重点： 项目背景，项目目标等

> 转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。

> 关注公众号「转转技术」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于QA），更多干货实践，欢迎交流分享~