测试左移-深入技术方案

• 光听不发表意见，全程都没有问题（没有准备和熟悉方案）

• 听不懂但能提出问题，需要解释才能理解

• 听懂并理解，能发现方案中的问题，提出好的建议

目录说明：

• 业务流程：流程图帮助大家理解和理清思路，需要包括正向、逆向、异常链路

• 核心设计思路：需求中核心的、复杂的逻辑是如何设计的

• 交互细节：对外提供的和提供给外部的接口、MQ等内容

• 改动和回归：改动的接口、库表字段和一些配置的说明，开发评估的影响范围

• 测试建议：不容易测试的环节、容易忽略的测试场景

• 沙箱和上线：沙箱和线上计划，数据的处理

• 评审纪要：评审中的问题，需要会后确认的内容

阅读目标：

• 理解：接收和了解技术方案中的信息，能理解技术方案

• 对比：和自己的设计思路对比，谁的设计更合理

• 审核：找到技术方案的遗漏场景，挖掘技术方案的问题

正向 - 完整的正向/分支链路，穷举场景

逆向 - 完整的逆向/异常链路，假设场景

组合 - 梳理复杂多场景的情况，组合交叉

简单 - 用简单的设计实现需要的场景

全局 - 站在业务系统上而不是仅一个服务上考虑，比如与各方的交互

用户 - 根据用户真实操作和体验来设计场景

比较 - 和原有业务流程或市场上做的好的产品进行比较

过程 - 注意过程数据的准确性，中间态变化

a. 穷举核心业务处理的异常场景，是否都已处理

    例如：接口超时、失败，数据为空、字段应符合业务最大长度

b. 关键的业务场景避免重复

    例如：前端防抖（重复提交），后端防超卖（并发提交）、防重复执行（重复消费）

c. 性能相关

    例如：

经常访问的数据做好缓存：内存初始化/存放Redis，缓存更新

d. 多步操作的数据一致性，是否有使用事务

e. 不同版本、新老数据和在途数据做好兼容

···

【实现一个线上拍卖卖场，创建具有指定开始和结束时间的卖场，发布拍卖商品到卖场】

1.发布商品到卖场，调用量肯定很大就需要设计缓存，需要考虑：

2.如果缓存失效，则需要降级从表中获取，如果表中也没有，则需要创建

3.创建卖场，从配置中读取需要创建的类型、开始时间和结束时间

4.发布商品（创建商品，数据落表），穷举发布商品逻辑场景：

5.幂等（重复发布），保证同时在架的实物商品只能有一个，防止超发超卖

• 选择实现简单，影响范围小，可扩展的方案；涉及接口的复用或修改，分析对调用方和原业务的影响

• 不要盲目相信RD提供的影响范围，结合业务理解圈定回归范围

1、使用关键日志

提出测试诉求，让RD增加关键日志，比如打印计算过程数据等，通常很有用

2、合理后门

对于需要特殊才能触发的场景，让RD提供后门来触发，帮助测试提效

3、单测/构造

提前准备构造，或向RD提出单测诉求，没有数据源时方便构造数据

4、不好测试的内容

明确需要测试，但不好测试的地方寻得开发帮助，比如指定时间的测试点增加配置来缩短时间

某些组件或某些领域功能不需要QA测试的提前沟通清楚

1、完善技术方案

发现并纠正产品、开发、测试之间的需求理解偏差

发现需求与技术方案的差异或错误

2、帮助测试方案选型

哪些是核心接口需要单独测试，哪些重要逻辑需要全覆盖。

结合技术方案提前编写合适的Mock构造，提高测试效率。

3、帮助测试设计CASE

针对技术方案里涉及到的场景设计CASE，覆盖隐藏的分支，避免漏测。

通过分析技术方案中的影响范围，明确回归内容，缩小测试范围，保证原功能的基础上减少回归case。

4、提高白盒测试思维

通过技术方案对被测系统和底层实现更了解，Code Review时思路更清晰，同时定位Bug也更快更精准。

5、项目上的变化

通过技术方案梳理的内容，合理评估系统的复杂度，技术排期更准确

各方补充方案中的内容，降低了项目后期又发现遗漏点的问题

QA在测试时覆盖技术方案中get到的测试点，发现潜在的BUG