前言
在公司里的项目都是采用了微服务架构，存在多个微服务长期运行时，局部出现故障时是不可避免的。所以有必要提前模拟产生各种任何可能发生的故障，来观察系统的反应，验证预期策略。我从测试角度出发，提出了服务故障演练的测试方案，在这里总结记录下。
什么是故障演练
- 故障演练是指模拟生产环境中可能出现的故障，测试系统或应用在面对故障时的反应和响应能力。
可覆盖场景
-
基于单一服务考虑，测试场景是被测服务和依赖服务的交互校验。
模拟方式-Mock和桩
- Mock和桩
- Mock是一种创建模拟对象的技术，用于在测试过程中替代真实的依赖对象。我们利用Mock模拟被测服务和依赖服务之间的请求行为，包括inpu和output的过程。
- 桩可以理解为模拟的服务实例。由于依赖服务可能是第三方的，存在无法接入到测试环境的情况，便可以用桩来替代依赖服务，桩只需要满足通信方式能正常返回消息包即可。
- 实现方式。 由于桩一般只处理某一种数据返回的场景，可以结合Mock来实现多种数据处理的场景覆盖。我们可以利用抓包工具（Charles）来实现Mock能力。抓包工具可以理解为代理被测服务，被测服务和依赖服务之前的请求和返回行为都会先经过抓包工具处理，可模拟请求行为的协议正确性、返回超时、返回处理异常和数据处理等多种场景。
用例场景设计
1) 被测服务请求依赖服务的协议正确性。
- 测试方法：拦截被测服务请求三方服务的消息包
- 期望：消息包对齐三方服务接口协议
- 未测试的影响面：依赖服务交互失败
2) 依赖服务返回超时
- 测试方法：通过mock工具模拟依赖服务返回超时的情况，比方说拦截消息包然后长时间不回复。
- 期望：被测服务有超时处理机制
- 未测试的影响面：在依赖服务返回超时时，导致被测服务某事务阻塞或者使客户端页面保持loading状态退不出操作页
3) 返回处理异常情况（在业务逻辑下可能出现的异常问题）
- 测试方法：通过mock工具模拟依赖服务返回异常处理的返回（包括状态码、返回体）
- 期望：被测服务遇到异常返回时有对应的处理方法。
- 未测试的影响面：导致服务宕机、暴漏安全隐患
4) 依赖服务宕机（网络问题、运维问题）
- 测试方法：在测试环境模拟依赖服务宕机行为，如果有操作权限直接kill -9依赖服务的进程，如果没有需要找开发配合模拟场景（支持配置更改依赖对象）
- 期望：被测服务有对应的处理方法。
- 未测试的影响面：导致服务宕机、暴漏安全隐患、事务阻塞
5) 依赖服务的数据处理情况
- 测试方法：如果是查询业务，可能需要考虑依赖服务返回空数据、单数据、多条数据的情况
- 期望：每种数据返回情况被测服务都可处理
- 未测试的影响面：可能某种数据场景存在缺陷。
如果存在服务负载均衡的处理，还需要测试负载策略和某一实例宕机的情况。
评论区