之前参与的项目都有设计评审这个环节，每次评审中或多或少都会带着一些问题，零零散散的也记了不少，做个总结，避免后续踩坑。
为什么要有设计评审？
设计评审也可称为技术评审，在测试前期，QA需要了解技术设计方案，并根据对应的技术方案选择合适的测试方案。通过review技术方案，尽可能的提前暴露架构设计问题，避免后期出现高成本的重构。
设计评审的核心目的：
发现项目/系统架构设计上的缺陷
设计评审中重点关注的要点和问题：
数据相关
1、涉及到多机房部署(南北地域限制)并且有涉及数据更新的时候，如何保证机器间的数据读写一致性？
2、服务所依赖的下游是否是多机房部署，多机房部署如何保证读写的流量均衡？
3、数据库/redis的读写操作有哪些，以及读写频率？
4、有涉及事务的模块，原子性如何保证，事务中是否包含外部调用？
5、在更新数据时如何保证服务不受影响？
6、redis的键数据结构设计，要考虑热点key的问题，是否有数据打散？
7、涉及到频繁操作表的，查询/添加，表结构的设计/索引和查询方式是否高效？
8、数据库的表设计要考虑存储资源消耗、读写效率、可扩展性等。
9、DB的扩容方案，以及扩容效率如何？
10、表结构设计如果有添加/删除/修改字段，是否能做到兼容，尽量避免删除字段。
11、对于有些实时性比较强的数据如何处理？(涉及跨地域)
高可用性
1、避免单点，挂了后如何保证服务不会受影响？
2、DB/redis是否有冗余机制，如何实现的？
3、DB/redis是否有备份机制，如何实现的？
4、是否有合理的限流方案，对一些突发流量如何处理？
5、异地多活方案，数据同步延时无法读到数据？
6、对于高并发的场景，是否有降级方案？
扩展性
1、增加服务器是否可以使服务保持稳定，是否能提高业务处理能力？
2、是否有添加缓存？
3、如果压测结果不符合预期，是否可以对服务/DB/方案进行扩展，以及扩展成本是如何？
接口相关
1、接口在设计上是否有合理的超时和重试？
2、接口服务处理一个请求预计耗时是多长时间？
3、接口能够承受的最大并发数？(压测需要关注)
4、接口有涉及下游服务的，对下游的读写超时是否可监控可配置？
设计文档完整性
1、设计文档是否包含完整的架构设计图、接口流程图、表结构设计图？
2、设计文档中是否有不符合需求/遗漏核心需求的地方？
3、设计是否遵循已有的设计规范标准，如果有引入新的技术，是否可以完美兼容已有规范标准？
4、公共/通用/三方API是否有遗漏？
业务相关
1、是否有补偿脚本？
2、一些配置项是否有默认值？如果不填的话有没有兜底默认值？
3、是否要被外网访问/访问外网，如果有的话是否需要申请外网权限？
设计评审作为一个重要的环节，QA可以在这个环节中了解到：
- 项目涉及的技术，和RD/FE/PM各方讨论方案是否合理；
- 如果按照该方案开发，上线后的效果是否符合PM预期；
- 以及在开发中有哪些技术难点，该如何实现；
- 项目中所涉及到的降级预案有哪些，降级预案效果等。
所有参与项目的同学都有着同一个目标：保障线上质量。所以在技术评审阶段，不要怕问问题，就怕不敢问，没有把问题提前暴露出来，如果等到上线后出现问题，那就亡羊补牢为时已晚，线上问题只能尽快去止损，当然没有问题是最好的。
源自公众号 Tester之路