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