背 景
转转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 评估影响范围
技术文档中给出的代码改动，对业务功能的影响2、不同的设计方案，对于业务功能和测试方案的影响
-
选择实现简单，影响范围小，可扩展的方案；涉及接口的复用或修改，分析对调用方和原业务的影响
-
不要盲目相信RD提供的影响范围，结合业务理解圈定回归范围
3.4 提高可测性
在技术方案的设计中，要想办法让测试阶段更好测，怎么测的快
使用关键日志
提出测试诉求，让RD增加关键日志，比如打印计算过程数据等，通常很有用
合理后门
对于需要特殊才能触发的场景，让RD提供后门来触发，帮助测试提效
单测/构造
提前准备构造，或向RD提出单测诉求，没有数据源时方便构造数据
不好测试的内容
明确需要测试，但不好测试的地方寻得开发帮助，比如指定时间的测试点增加配置来缩短时间
某些组件或某些领域功能不需要QA测试的提前沟通清楚
以上截图的例子都是在技术设计期间考虑到给RD提出的诉求，在测试期间提供了便利。
结 果
1、完善技术方案
发现并纠正产品、开发、测试之间的需求理解偏差
发现需求与技术方案的差异或错误
2、帮助测试方案选型
哪些是核心接口需要单独测试，哪些重要逻辑需要全覆盖。
结合技术方案提前编写合适的Mock构造，提高测试效率。
3、帮助测试设计CASE
针对技术方案里涉及到的场景设计CASE，覆盖隐藏的分支，避免漏测。
通过分析技术方案中的影响范围，明确回归内容，缩小测试范围，保证原功能的基础上减少回归case。
4、提高白盒测试思维
通过技术方案对被测系统和底层实现更了解，Code Review时思路更清晰，同时定位Bug也更快更精准。
5、项目上的变化
通过技术方案梳理的内容，合理评估系统的复杂度，技术排期更准确
各方补充方案中的内容，降低了项目后期又发现遗漏点的问题
QA在测试时覆盖技术方案中get到的测试点，发现潜在的BUG
写在最后
交付高质量产品需要团队成员共同对质量负责，其中一个理念：从源头预防bug产生。
测试同学发现技术方案中的设计问题很难，但可以不断积累这方面的思维，同时利用QA的业务经验，多在业务角度上挖掘问题。
当对技术方案有疑问时，敢于质疑，及时提问，充分参与技术方案的评审，希望大家能发现更多的问题，提出更多的建议。
作者：聂飞
转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。
关注公众号「转转技术」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于QA），更多干货实践，欢迎交流分享~
