阿里微服务质量保障系列：域内测试

进入阿里之前，我就职的公司所在部门的产品都是单体应用，例如第一家公司是做投顾平台的，第二家公司所在的团队是做在线教育的，负责的产品是内容生产平台。投顾平台这个产品是服务于券商投顾员工的，属于券商内部应用，用户量并不大。内容生产平台是为公司内部的QC团队使用的，用于录入K12资料内容，用户量其实也不算大。

因此，用户量不大的情况，单体应用也是产品实现的最优解。

01-阿里的团队结构

而支付宝的用户量以亿级，单体架构已不适用，取而代之的是微服务架构，随着不同的团队结构也发生变化。下面用一张图可以展示出差异所在。

单体架构团队：

QA对负责的产品业务比较熟悉，测试策略就是(业务维度)功能测试与回归测试。

微服务架构团队：

行业QA对面向用户端业务经验丰富，对下游平台侧业务不甚了解。

平台QA对平台侧业务经验丰富，但对用户端业务经验不足。

PS: 行业QA/平台QA 也可以归为xx域(平台)QA。

02-何为域内测试？

在微服务架构中，产品被拆分为N个子模块，即每个模块代表单个微服务，单个微服务由特定的团队维护，可以单独部署与发布(见下图所示)。单个微服务也称为平台(域：蚂蚁这边的叫法)，因此微服务测试也称为域内测试，可以理解为对所负责的(领)域测试。

03-域内测试策略

在一个典型的微服务应用程序中，会有许多微服务，且它们之间存在相互调用关系。因此，要想高效地对单个微服务进行测试，需要将其依赖的其他微服务和数据存储模块进行模拟（mock）。

测试内容：

接口测试
契约测试
异常测试
幂等测试

其实和单体应用测试内容无太多差异，最大的差异就是契约测试。

04-域内测试测什么

接口测试

针对接口契约设计接口测试用例，与单体应用的接口测试差异在于微服务架构下产品被拆成多个域，因为单域在测试时候需要将依赖的下游服务给mock掉。

异常测试

异常测试来源于域内部和外部，外部的异常通常指代下游调用异常，例如下游调用异常/超时等，这种场景多需要mock测试。

此外，微服务架构多为分布式系统，因此系统会采用很多异步通信机制，其中异步消息则是最常见的实现。异步消息通常需要一个通信代理（communication broker），这是一个独立的系统组件，负责接收事件并把它们分发给对应的消费者。有时候也叫作事件中枢（event backbone），这也表明了这个组件对整个应用是多么重要。常用作代理的工具包括Kafka、RabbitMQ和Redis，阿里也有自研的类似工具。

对于QA来说，如果域内有需要消费外部消息，则需要重点考虑：消息乱序和消息重投的场景

幂等测试

为什么会产生接口幂等性问题？

其实可以分两类：

一类是受不可抗且非常规操作导致的重复请求，例如网络波动引起的重复请求；用户重复操作,用户在操作时候可能会无意触发多次下单交易，甚至没有响应而有意触发多次交易应用。

另一类则是请求失败需要重复发起请求的场景，例如用户请求受理成功，需要异步通过定时任务重复执行的情况。

幂等检验的范围有哪些？

资金类服务的特点就是很容易发生资损。因此在设计幂等逻辑的时候，需要分析请求报文中哪些字段需要严格“幂等”（就是重复请求中哪些字段需要严格保持一致）。

如上文说到的服务，是以requestId作为幂等字段，且对amount做了金额一致性校验，通过后才能继续向下调用。那么refundDetialList是否应该纳入幂等校验的范畴之内的，我觉得这个需要By业务分析，单纯从平台角度无法给出特定的结论。因为平台要提供的是通用能力，理论上是不吃业务的，但是如果针对业务诉求强，那就需要做业务定制的处理逻辑，这显然违背平台设计的初衷。但有时候确实是这样，平台建设没法完全脱离业务。

幂等测试场景分析

对于测试来说，通常情况下，我们分析幂等场景一般幂等字段（也可能是多个字段联合作为幂等条件）、关键资金字段如金额作为场景因子设计幂等测试用例：

CASE001：同号发起（幂等条件不变）+不换金额，预期幂等REPEAT_REQUEST；

CASE002：同号发起（幂等条件不变）+换金额，预期幂等校验不通过报错；

CASE003：换号发起（幂等条件变化）+不换金额，预期作为新请求处理；

此外，幂等发起的次数也应该引起关注，作为一个场景因子来对待：

幂等请求次数建议考虑2次以上的场景。

当然，我们设计幂等场景的时候，最好要review下开发的实现思路，不要完全采取黑盒方法，结合白盒方法设计的测试用例才更有效。

对资金类服务幂等设计与测试的思考