背景
随着QA进行全流程的质量把控逐步成为趋势，QA在项目中的关注点不仅仅停留在测试阶段，在项目的每一个阶段都可以看到QA在积极地推进项目进度、把控项目质量。
本文将主要介绍在技术设计评审阶段，QA可以从哪些地方入手，做到真正有效的参与其中，并发挥作用。
为什么要参与技术设计评审？
在介绍参与技术设计评审之前，我们首先要明确为什么要参与技术设计评审？参与技术设计评审能给我们带来什么？只有我们明确了参与技术设计评审能给我们带来的好处，我们才更有动力做这件事情。我认为， QA参与技术设计评审，有以下四点好处：
1、纠正项目成员对需求的错误理解。 在参与技术设计评审时，通过对开发的设计思路的了解，了解开发对于需求的理解，发现开发对需求理解不正确的地方；同时，在了解设计思路的同时，可能会发现自己对需求理解有偏差的地方。通过对这些点的及时纠正，能尽早地避免某些bug的出现。
2、为测试方案提供依据。 通过参与技术设计评审，了解具体的实现方案，针对开发的设计方案进行相应的测试方案选型，例如核心的接口、核心的服务是否需要进行接口测试、重要的逻辑覆盖、测试场景的数据构造、测试所需的工具等，都可以在这个阶段结合开发的技术设计进行思考和产出。
3、有效的评估影响范围。 有些场景需求文档上并未提到，但是因为相应的代码有改动，相关的功能可能会受到影响，参与技术设计评审能够帮我们发现这些影响点，及时地补充测试用例，避免遗漏。
4、有效的评估风险点。 通过了解开发的技术设计，了解改动的范围，评估工作量以及相应的风险点。甚至，在技术评审阶段，开发会提供多种设计方案，通过对每种方案的了解，QA可以有效的评估到每种方案的影响范围和风险点，从而选择风险更小的解决方案。
QA如何高效参与技术设计评审？
设计评审会议的时间一般不会太长，想要在一个设计评审会上跟上开发同学的思路，理解设计方案，达到自己的目的，提前做好准备工作是非常重要的。我把设计评审大致分为三个阶段：设计评审前、设计评审中、设计评审后，在每一个阶段，我们需要做的事情主要有：
1、 设计评审前：通知到位，提前准备。
（1）确保相关人员通知到位。评审会上确保相关人都在场，提前做好通知；
（2）熟悉需求文档，提前看技术设计文档。结合需求文档，理解技术设计文档，有问题提前做好批注。
2、设计评审中：重点关注技术设计是否满足需求、涉及的接口、测试范围。
（1）流程图。可以清晰的展示此次需求的业务流程；
（2）系统间交互图。以时序图或协作图的形式提供，可以清晰的体现出系统间的信息传递；
（3）配置类功能。设计中哪些是配置实现的。apollo配置、缓存、mq、定时任务等；
（4）数据库设计。数据库的库表结构，关键字段的描述；
（5）设计是否完整。是否覆盖了产品需求文档中要求的功能，避免遗漏；
（6）已有接口的复用或修改。如果是复用已有接口的能力，看是否该接口真能满足新的需求，如果在原有接口的基础上修改，需要清楚更改了哪些内容，是否会影响到已有逻辑；
（7）新接口的定义。如果是新的接口，看实现的功能是否符合需求，接口定义是否明确；
（8）需要第三方提供的接口。明确哪些接口是需要第三方提供的，明确对接人，方便后续的沟通；
（9）对外提供的接口。对外提供接口的作用，做好对应的测试方案，与使用方做好沟通；
（10）影响范围的评估。明确此次需求改动影响的范围是什么，需要做哪些场景回归；如果影响范围比较大，是否有更好的设计方案；
（11）具备可测性。面对分批提测的需求，模块拆分后是否具备可测性；针对特殊场景，是否需要开发或测试提供工具方便测试；不可测的情况下，划分分工的边界，明确告知RD我们能测试的点，明确不可测试的地方的质量把控方案；
（12）新老数据兼容。是否涉及新老数据兼容的测试验证；
（13）核心接口性能指标。是否需要对核心接口做性能测试；
总之，评审过程中，要积极地跟上开发同学的思路，理解RD设计的理由，持不同看法时勇敢地提出自己的想法和建议。
3、设计评审后，做好待办事情的跟进，完成测试方案的设计。
（1）相关群里同步待跟进的事情。明确对接人及问题的解决时间，做好持续的跟进；
（2）设计测试方案。按照项目准则选择测试手段、编写测试用例、提供数据构造或脚本工具等、结合技术设计方案，做好风险评估。
QA深度参与技术设计评审的项目实践
下面我将以一个项目为例，具体介绍如何通过技术评审推动项目最终高效、高质地完成。
项目名称：第三方供应商可投转转广告
项目背景：在第三方供应商后台新增“我要推广”入口，撮合第三方供应商使用商业广告投放，提升广告主成单效率，并提升广告收入
在整个设计评审阶段，做了如下的一些工作：
1、熟悉需求文档，加深需求理解，挖掘需求的重难点，并关注其对应的设计方案；
2、提前看技术设计文档，尝试理解开发的设计思路，有疑问的地方提前问；
3、技术评审现场，检查参与项目开发的前后端开发同学以及产品同学是否全数到场，以免评审过程中产生需求改动点而没有同步到所有相关人。
4、检查RD提供的流程图是否正确，是否与需求一致；
5、由于项目涉及第三方，因此需要关注涉及第三方的系统交互图，了解各方负责的功能范围，评估第三方可能带来的风险；
6、关注需求中重点逻辑的实现方案，数据库表设计，评估设计方案对应的测试范围；
7、根据设计文档，指定测试方案，包括数据准备、接口测试、case设计、数据构造工具准备。
设计评审效果：
1、基于对需求理解和对RD提供的流程图的检查，发现了RD流程图与需求不一致的情况，从源头上预防了bug的产生。
2、建议选择对于测试范围影响更小的开发方案，缩小了测试范围。其中涉及2个需求点：
需求点之一：如何标识第三方用户，并记录第三方用户信息(电话、地址)？
可能方案1：原有商业用户表中增加字段？
（1）劣势1：若在原有商业用户表中增加字段标识第三方用户，并且新增字段单独存第三方用户的电话，需要回归原有的商业用户创建功能；
（2）劣势2：新交接的业务，现接手的RD对原有业务不太了解，不太敢直接冒风险改动原有功能；
可能方案2：新增一个表单独记录第三方用户及相关信息？
（1）优势：避免回归商业用户的新增功能；
需求点之二：如何让第三方用户绕开商业用户身份和资质校验，继而使用商业的各种功能？
可能方案1：在每处校验时，判断第三方用户并作特殊处理。
（1）劣势1：商业用户身份和资质校验，是商业营销管理各种功能使用的前提，校验的地方太多涉及多个集群，梳理起来容易遗漏，且回归范围广。
（2）劣势2：后续新增商业功能，都需要识别是否是第三方用户并作特殊处理，兼容成本大。
可能方案2：新登陆接口插入数据以确保后续流程能通过校验。
（1）优势：新接口中加功能，只需保证本次项目涉及的流程功能，影响范围小。
如图所示：
结论：从QA的角度，基于对影响范围的评估，都推荐采用了第二种方案
3、基于RD设计文档中提供的系统间的交互图，明确了涉及第三方的功能分工。
以下是交互图：
由此可知，第三方供应商侧只需要保证用户能够正确跳转到商业侧，以及所带的用户信息的正确性，后续流程则是有商业侧来保证。由交互图也能得知对方的工作量在整个项目中的占比，能大致评估出第三方可能带来的风险大小。
4、基于第2点中需求点之二的方案2，可得知从第三方供应商侧登陆商业侧的接口所做的哪些额外处理，这是仅仅从需求文档中无法获知的。设计评审后，明确了每个接口做了哪些处理，以此为依据，进行了测试方案制定 ， 包括:
（1）数据如何准备;
（2）接口测试重点测试入参是由第三方提供的2个接口，尤其关注入参为空的情况;
（3）case设计;
（4） 数据构造工具准备等。
项目整体效果：各方职责清晰、测试影响范围缩小（case少）、项目质量高（测试期只有1个前端bug，无线上bug)。
写在最后
每个项目有其不一样的特点，本文列出了大而全的检查点，可以帮助提醒我们在设计评审环节可以从哪些方向上去考虑。
通过参与设计评审，QA能够深入理解技术的实现方案，有助于制定合理的测试方案。同时，通过不断的实践，QA也能在设计评审时，提出一些合理的建议，帮助项目更高效、更高质的完成，提升QA在整个项目中的影响力。
作者：张元
转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。
关注公众号「转转技术」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于QA），更多干货实践，欢迎交流分享~
