摘要：随着系统逐步由单体架构向分布式微服务架构转型，直接面临因系统重构、底层技术栈升级、系统间交互增多等变化因素带来的系统可靠性风险。混沌测试是一种对系统开展可靠性验证的有效测试手段。
在混沌测试开展的过程中，一大挑战是测试场景如何选取。测试人员通常会面临两难的局面，当场景选的较少时担心覆盖不全、验证不够充分，场景选取的多时又无法做到穷举各类场景、执行过多场景花费时间和人力成本较高等问题。因此一种合理的故障场景分析方法是不可或缺的。
一、基于容错视角的故障场景分析方法
在面对测试场景发散或疏漏的问题上我们发现，虽然系统发生的故障种类繁多，但故障处置手段却是有限的，诸如启停、隔离、切换等处置操作能作为多种不同故障的容错手段。由于混沌测试的目的就是验证系统可靠性能力，具备相同容错手段或高可用能力的故障则无需重复验证。因此从容错的视角反推，将使用相同容错手段的故障归为一类，验证系统是否具备该类型的容错能力，即可做到对故障场景的有效精简，进而形成基于容错视角的故障场景分析方法。
基于这种思路从容错视角出发梳理故障场景，并结合分布式稳定性领域的经验积累，故障场景被归纳成单点类故障、局部类故障、整体类故障、过载类故障、依赖类故障五类，每类故障可对应验证被测系统的冗余能力、容灾能力、重建能力、过载控制能力、依赖解耦能力。在以应用系统为风险对象开展故障场景分析时，通常除部分业务有特殊设计外同一微服务内各类功能或交易的容错能力是相同的，因此只需将系统待测试的服务或业务功能按照这五类故障场景分类，之后视情况对特殊设计进行针对性的场景补充，即可实现对被测系统混沌测试场景的完整分析，避免场景重复设计和执行带来的重复工作。
二、测试实践
本次测试实践的主要需求来源为应用系统技术栈迁移，因此重点开展面向应用系统的应用层混沌测试。依照基于容错视角的故障场景分析方法针对单点、局部、整体、过载、依赖五类故障进行场景分析和设计。根据本次测试需求，对每类故障的验证点如下：
·单点类：模拟系统各个微服务的应用POD发生故障，单个或部分POD故障后验证系统是否为多实例部署具备冗余能力、探活机制是否有效、隔离和漂移等策略是否生效。
· 局部类：针对系统的容灾架构和切换方案模拟集群、单元、园区级故障，验证切换方案的有效性和对业务连续性的影响。
· 整体类：验证夏令时、闰年闰月、跨年等日期跳变场景对系统服务是否产生影响，系统如发生故障后是否具备重建能力。
· 过载类：模拟短时间流量洪峰和长时间流量激增对系统产生的影响，验证系统是否具有流控等过载保护能力。
· 依赖类：模拟被测系统与下游系统间调用发生故障，验证超时、重试、降级机制是否合理，强弱依赖设计是否合理。
在场景执行上，对于单点、局部、依赖三类故障场景，通过注入网络类故障、应用抛异常等手段模拟发生服务不可用的故障场景。过载类故障采用高并发混合发压的方式模拟流量洪峰。整体类故障则没有通用的模拟手段，需要根据具体场景选择故障。
三、测试总结
在本次混沌测试实践中主要发现两类问题。第一是应用K8S探针参数配置不合理，在单点类故障场景测试中发现配置的存活和就绪探针失败次数阈值较高，造成服务已处于不可用状态但隔离和重启动作触发迟滞的情况，对业务连续性产生一定影响。第二是部分关键交易不具备流控能力，在过载类故障场景测试中发现部分交易缺少流控设计，对被测系统及下游系统产生较大压力。之后通过评估生产实际业务流量完成流控配置和验证，提升系统过载保护能力。
通过本次混沌测试实践，在方法层面有效验证了基于容错视角的故障场景分析方法的可行性，避免了故障场景梳理过程中发散和疏漏的问题，实现对各类常见故障场景的测试覆盖。同时在实践层面对应用系统迁移新技术栈测试过程中细化了各类型故障场景关联的可靠性设计和容错能力，并明确了场景执行时对应的故障模拟手段，为后续分布式系统混沌测试实践提供参考。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
