QA 如何高效参与技术设计评审

背景

随着 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），更多干货实践，欢迎交流分享~