背 景
转转QA一直践行全项目流程的质量把控，QA不再局限于测试阶段，还在积极的推进测试左移，尽早参与测试活动，尽早发现和解决问题，以期望提高交付效率、把控项目质量。
这其中很核心的一环：技术方案评审。在技术方案设计时规避掉一些问题，成本是极低的，就像建造房子，改图纸总比推墙更容易。
目 标
在工作中审视自己和观察同事发现，QA在参与技术方案时通常会有以下几种状态：
- 光听不发表意见，全程都没有问题（没有准备和熟悉方案）
- 听不懂但能提出问题，需要解释才能理解
- 听懂并理解，能发现方案中的问题，提出好的建议
希望通过本文，让大家都能有效参与技术方案评审，避免需求理解偏差，理解并帮助RD完善技术方案，为后续的测试环节做好准备。
动 作
1、技术方案的要求
技术方案的内容格式因RD而异，但理应包含各方需要关注的内容，这些内容是通用的。
以下是本业务QA梳理出的技术方案目录，经和RD讨论后在团队实施，供大家参考。
目录说明：
业务流程：流程图帮助大家理解和理清思路，需要包括正向、逆向、异常链路
核心设计思路：需求中核心的、复杂的逻辑是如何设计的
交互细节：对外提供的和提供给外部的接口、MQ等内容
改动和回归：改动的接口、库表字段和一些配置的说明，开发评估的影响范围
测试建议：不容易测试的环节、容易忽略的测试场景
沙箱和上线：沙箱和线上计划，数据的处理
评审纪要：评审中的问题，需要会后确认的内容
2、评审前置准备
2.1 需求分析转化
梳理需求中的业务场景、相关链路，思考需求中核心的功能应该怎么设计，这样设计的优势是什么（此处是为了和开发的设计思路做比较）
2.2 熟悉技术文档
评审前至少详细阅读一遍技术方案文档。
阅读目标：
- 理解：接收和了解技术方案中的信息，能理解技术方案
- 对比：和自己的设计思路对比，谁的设计更合理
- 审核：找到技术方案的遗漏场景，挖掘技术方案的问题
3、技术方案评审
3.1 思维方式
在技术方案（包括在CASE设计）中，我们通常会使用以下几种思维方式来帮助我们梳理思路
正向 – 完整的正向/分支链路，穷举场景
逆向 – 完整的逆向/异常链路，假设场景
组合 – 梳理复杂多场景的情况，组合交叉
简单 – 用简单的设计实现需要的场景
全局 – 站在业务系统上而不是仅一个服务上考虑，比如与各方的交互
用户 – 根据用户真实操作和体验来设计场景
比较 – 和原有业务流程或市场上做的好的产品进行比较
过程 – 注意过程数据的准确性，中间态变化
3.2 核心：理解设计思路，提出问题和建议
举几个设计上的关注点：
a. 穷举核心业务处理的异常场景，是否都已处理
例如：接口超时、失败，数据为空、字段应符合业务最大长度b. 关键的业务场景避免重复
例如：前端防抖（重复提交），后端防超卖（并发提交）、防重复执行（重复消费）c. 性能相关
例如：占用资源时间长的操作，允许适当延迟的操作，最好使用异步
经常访问的数据做好缓存：内存初始化/存放Redis，缓存更新
批量查询场景是否需要设计分页，分页条件和break结束是否生效
d. 多步操作的数据一致性，是否有使用事务
e. 不同版本、新老数据和在途数据做好兼容
···
需求案例：
【实现一个线上拍卖卖场，创建具有指定开始和结束时间的卖场，发布拍卖商品到卖场】
1.发布商品到卖场，调用量肯定很大就需要设计缓存，需要考虑：
缓存内容
缓存初始化
缓存更新
失效降级
2.如果缓存失效，则需要降级从表中获取，如果表中也没有，则需要创建
3.创建卖场，从配置中读取需要创建的类型、开始时间和结束时间
校验配置正误
如果库表里存在，则不创建
如果库表里不存在，则创建
创建成功，更新缓存
4.发布商品（创建商品，数据落表），穷举发布商品逻辑场景：
调商品中台接口成功
调商品中台接口失败
本地落表成功
本地落表失败
5.幂等（重复发布），保证同时在架的实物商品只能有一个，防止超发超卖
这个过程中，实际设计中我们应避免掉卖场不存在的情况，所以最好是预创建好未来的卖场。
过程数据状态一致：发布商品获取infoId后落表，落表失败删除商品（这里仅举例单商品发布，类似业务都应保证状态一致）
对于测试CASE设计，在技术方案评审中能想到可能的问题点即是我们的测试点
3.3 评估影响范围
1、技术文档中给出的代码改动，对业务功能的影响
2、不同的设计方案，对于业务功能和测试方案的影响
选择实现简单，影响范围小，可扩展的方案；涉及接口的复用或修改，分析对调用方和原业务的影响
不要盲目相信RD提供的影响范围，结合业务理解圈定回归范围
3.4 提高可测性
在技术方案的设计中，要想办法让测试阶段更好测，怎么测的快
1、使用关键日志
提出测试诉求，让RD增加关键日志，比如打印计算过程数据等，通常很有用
2、合理后门
对于需要特殊才能触发的场景，让RD提供后门来触发，帮助测试提效
3、单测/构造
提前准备构造，或向RD提出单测诉求，没有数据源时方便构造数据
4、不好测试的内容
明确需要测试，但不好测试的地方寻得开发帮助，比如指定时间的测试点增加配置来缩短时间
某些组件或某些领域功能不需要QA测试的提前沟通清楚
以上截图的例子都是在技术设计期间考虑到给RD提出的诉求，在测试期间提供了便利。
结 果
1、完善技术方案
发现并纠正产品、开发、测试之间的需求理解偏差
发现需求与技术方案的差异或错误
2、帮助测试方案选型
哪些是核心接口需要单独测试，哪些重要逻辑需要全覆盖。
结合技术方案提前编写合适的Mock构造，提高测试效率。
3、帮助测试设计CASE
针对技术方案里涉及到的场景设计CASE，覆盖隐藏的分支，避免漏测。
通过分析技术方案中的影响范围，明确回归内容，缩小测试范围，保证原功能的基础上减少回归case。
4、提高白盒测试思维
通过技术方案对被测系统和底层实现更了解，Code Review时思路更清晰，同时定位Bug也更快更精准。
5、项目上的变化
通过技术方案梳理的内容，合理评估系统的复杂度，技术排期更准确
各方补充方案中的内容，降低了项目后期又发现遗漏点的问题
QA在测试时覆盖技术方案中get到的测试点，发现潜在的BUG
写在最后
交付高质量产品需要团队成员共同对质量负责，其中一个理念：从源头预防bug产生。
测试同学发现技术方案中的设计问题很难，但可以不断积累这方面的思维，同时利用QA的业务经验，多在业务角度上挖掘问题。
当对技术方案有疑问时，敢于质疑，及时提问，充分参与技术方案的评审，希望大家能发现更多的问题，提出更多的建议。
资源分享
下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 【保证100%免费】
