测试时，服务故障如何模拟？

在微服务架构下， 被测服务有时也需要依赖于三方服务/内部服务获取数据，比方说登录接口的验证码服务。作为测试角色，我们不仅要关注正向的场景，也要关注服务交互异常的情况，避免被测服务的逻辑处理不完善或者影响服务的可用性。本文主要介绍我所接触的一些模拟服务故障的方法。

存在依赖服务时的测试点

• 正向场景覆盖

• 依赖服务作为数据源时，返回不同数量的情况，比如返回空数据、单条、多条数据

• 依赖服务返回异常状态码（被测服务的期望值：被测服务返回服务端异常描述）

• 依赖服务返回超时（被测服务的期望值：被测服务有超时处理机制，触发机制时返回超时信息的描述）

• 依赖服务异常下线（被测服务的期望值：保持服务的可用性，返回服务异常的描述）

依赖服务故障模拟方法

场景模拟的测试工具：

fiddler/charles/brupsuite/自动化桩，需要代理被测服务的服务器。

服务故障对应的模拟手段：

• 依赖服务返回异常状态码 - 通过抓包工具篡改结果返回

• 依赖服务返回超时 - 通过抓包工具拦截依赖服务的回调

• 依赖服务异常下线 - kill -9 对应进程

抓包工具模拟服务故障的原理：

拦截依赖服务的响应结果，并进行请求响应信息的修改，再放行给被测服务，验证对于依赖服务的返回异常，被测服务在下游逻辑处理之前或者响应客户端之前是否实现了异常处理逻辑，被测服务返回值是否符合我们的预期。

Charles 抓包工具：

Charles 是一款常用的网络抓包工具，通过将自己设置成系统的网络访问代理服务器，截取请求和请求结果达到抓包分析的目的。

Charles的功能包括但不局限如下：

• 截取 Http 和 Https 网络封包。

• 支持重发网络请求，方便后端调试。

• 支持修改网络请求参数。

• 支持网络请求的截获并动态修改。

• 支持模拟慢速网络。

Charles 模拟服务故障

给测试接口打断点

• 依赖服务返回异常状态码

• 依赖服务返回超时

拦截等待即可