谈谈性测试体系的一些经历！
本帖最后由 草帽路飞UU 于 2022-10-18 16:08 编辑去年大半年参与某清算中心健壮性测试体系和重要业务线系统落地试点工作，在借鉴互联网头部企业和国有大型银行混沌工程实施思路基础上，梳理出包括健壮性测试规范、健壮性测试指南、基础案例库、测
试案例思维导图等健壮性测试指导性文档。
通常来说健壮性测试目的为了建立对系统抵御生产环境中失控条件的能力以及信心。避免因某种未预料到的场景，引起类似蝴蝶效应或多米诺骨牌效应，导致大面积的系统混乱、故障和服务中断，对客户
的业务造成影响事件的发生。
同时通过混沌工程实验，及时发现和修复系统中潜在问题，来提高验证系统的高可用性和团队应急能力的升级。
目前健壮性测试体系案例部分已经包括基准测试案例和个性化测试案例。涵盖了应用层、数据库层、平台层、中间件层、路由层、缓存层等主流的应用高可用测试领域，并筛选出一些重要的业务线系统
（比如清算、支付、收单系统等） 进行落地试点的重要业务线，取得初步成果。
在各业务线的平台层、消息中间件层、应用层、数据库层、路由层均发现了一些传统测试难以发现的高可用设计等方面的问题。
在整个测试周期的前期，我们通过对历史故障异常（硬件、系统、程序相关故障、以及资源饱和或资源抖动导致异常），业务间强弱依赖、业务主要核心功能三个维度进行分析，结合故障发生后可能导致
后果严重度（灾难性影响、破坏性影响、极小影响）、发生频率（高、中、低）筛选出对应健壮性测试场景、测试范围、测试重点，给出稳态指标。
-测试手段主要有两种-
常见故障场景注入
故障主要硬件故障场景、docker及虚机类型故障场景，基础及应用软件故障场景、依赖故障场景、JVM故障场景等。
极端异常注入
极端异常比如cpu计算资源超载、内存饱和网络抖动丢包延迟，服务上下游调用超时异常、服务线程池满；磁盘IO资源空间饱和、数据库慢查询死锁连接池满、文件句柄满等。
总体初步实现常见异常故障和复杂异常故障模拟 ，我们目前采用jvm字节码增强方式实现无侵入可扩展性高的mock（主要模拟服务返回码被篡改、服务超时，线程池异常、服务调用异常等服务级别故障
场景）。
目前 故障注入介质包括jvm-sandbox/chaosblade/Litmus/Stress等，统一以命令行调用方式集成，整体测试目的 最终验证系统服务是否健壮，有足够的弹性易扩展，可以容忍计划外的故障。
-测试过程中重点关注-
分布式系统脏读是否会导致资损风险，服务是否存在级联失败风险，失败重试机制（上行或下行输入的大幅波动是否存在重试风暴）。
是否存在拜占庭故障（不满足幂等性，多线程处理安全性问题）、其中线程安全性常出现在单实例的类变量在多线程情况下被赋值修改导致数据错乱，比如订单状态被多线程重复修改导致非预期的终态变
化。
异步事件响应中断后对系统影响（是否存在资损风险，比如出现单边账问题）。
故障转移隔离时发生的主从切换的脏读问题影响面。系统恢复自愈能力。
系统压力过载时对非核心交易进行熔断降级，是否会导致核心交易产生级联失败（服务拆分不合理）问题。
分布式节点宕掉后其前端RPC调用交易重试是否满足幂等性。
负载均衡算法使用是否合理，超时重试机制有效性，超时设置是否满足漏斗原则，集群体系脑裂的规避方式有效性、分布式事务交易一致性、IO密集型操作比如联机批量落库时出现IO阻塞背景下系统可用
性等。
下游异常导致服务线程池满后导致其他服务级联失败问题。
服务队列满、阻塞的自动检测、预警及处理机制是否满足预期要求。
-后续发展计划-
针对业务特性结合金融级可靠性要求，历次生产问题，进一步抽象并设计面向业务的脆弱性分析规则或模型，持续推进实现业务技术脆弱性的全自动化或智能化分析。
页:
[1]
