如何有效的参加技术设计方案评审

大家好，我是持续讲干货的sean文哥。

作为QA，职责之一是确保产品高质量上线并产生业务效果。如何确保产品高质量上线，其中一个环节就是三大评审之一的技术设计方案评审，在此过程中如何体现QA价值，帮助开发在满足实现需求的同时建设健壮的系统从而达到高质量上线的目标。

下面将介绍测试人员为什么要参加开发技术设计方案评审、在此过程中应该重点关注哪些方面、评审完测试产出物。

01

测试人员参加开发技术设计方案评审的好处

1. 需求对齐

   • 通过开发设计思路，和开发再次对齐对需求的理解，在这个环节预防，从而减少bug的产生

2. 精准测试

   • 通过开发的逻辑图、时序图、ER图、类图，制定测试策略和方案，理清测试边界，让测试工作更加精准有效

3. 用例覆盖

   • 有了测试策略和方案，同时对齐了需求，后面的测试用例设计将会对需求更加有效的覆盖

4. 工时评估

   • 通过设计，可以确定改动的范围和影响点、接口个数，对测试工时评估更加准确

5. 风险评估

   • 对几种方案的了解，综合范围、影响点和测试边界，可以对比不同方案中风险，从而选择风险较小的方案，并把风险转化为已知，未雨绸缪

02

测试人员参与设计方案评审应该关注哪些点

不论是新开发系统(包括迁移、重构)还是原有系统迭代，好的设计主要体现在几个方面：

• 抽象设计

• 面对错误的设计

• 性能和大数据量

• 安全

• 可测试、可运维、可监控

03

技术设计方案评审checklist

结合实际生产问题和从测试人员角度，细化为如下：

序号	关注点
1	流程图/时序图/类继承图
2	ER图
4	上下游依赖项/影响范围
5	正常场景分支
6	异常场景分支(异常提示配置)、快照
7	外部依赖/第三方 异常
8	幂等/重单、分布式事务、 同/异步流程控制
9	性能(并发、减少远程调用 、减少查询数据库、减少DB事务依赖)
10	安全
11	大数据量处理(年底)
12	数据库字段类型/长度设计
13	历史数据处理
14	下线计划和方案(迁移/重构技术需求)
15	JOB方案(执行时机、方式)
16	容错(网络超时和中断、空、null 、数据结构异常、数据库主从延迟)
17	mybatis规范
18	版本、接口向上向下兼容
19	对用户影响(https、是否清缓存 、交互歧义、报错提示)
20	补偿机制
21	降级
22	可测试(不依赖依赖方自测，比如mock)
23	可运维
24	可监控

写在最后，

技术方案评审是产品生命周期里重要活动之一，是体现自己测试专业能力的机会，在业务和技术实现上，想到开发没有想到，提出开发没有设计到的，和开发一起打造健壮的系统，让开发对你另眼相看从而提升自己的影响力。

你觉得呢？有任何想法欢迎在评论区讨论或留言。

关于我，二十年QA、测试、敏捷研发、研发质量效能相关经历；历任百度、易宝、艺龙、直客通、蔚来等QA负责人、测试总监及研发质量效能负责人；在求职面试、职业规划、职级晋升、职场生存潜规则、敏捷研发、研发质量效能领域专业知识和落地实践有相当丰富经验。

预告：各大厂职级等级及能力模型标准、关于测试相关职级晋升的答辩题正在整理中

如果觉得对你有帮助，还有其他疑问可以联系我进一步深入交流。