混沌测试
什么是混沌测试,引用网上查到的资料
混沌工程类似于“故障演练”,不局限于测试,而更像是工程实践。为什么这么说,通常的测试用例会有“期望结果”和“实际结果”,通过将两个结果比较,或者对用户行为的预期,来判断测试通过或失败。而混沌试验类似于”探索性测试“,通过对系统和服务的干预,来观察系统的”反应“。我们将混沌工程原则融入在试验过程中:在生产环境小规模模拟系统故障并定期自动化执行试验,通过试验结果与正常结果进行比对,观察系统“边界”。
总结就是
在生产环境模拟故障场景,主动找出系统中的脆弱环节,试探生产系统的边界
而我将在新业务上线后在未开始导量之前,对其中kafka/redis组件进行破坏测试
Chaosblade文档: https://chaosblade.io/zh/docs
ChaosBlade: 一个简单易用且功能强大的混沌实验实施工具
不仅使用简单,而且支持丰富的实验场景,场景包括:
基础资源:比如 CPU、内存、网络、磁盘、进程等
Java应用:比如数据库、缓存、消息、JVM 本身、微服务等
Docker容器:比如杀容器、容器内 CPU、内存、网络、磁盘、进程等
云原生平台:比如 Kubernetes 平台节点上 CPU、内存、网络、磁盘、进程实验场景,Pod 网络和 Pod 本身实验场景如杀 Pod等
说说我的场景实践:
依赖chaosblade工具,了解mqtt的服务架构,然后针对基础组件做破坏性测试。比如基础组件机器的cpu打满,内存使用率飙升,服务假死等
前期需要了解业务流程,有个预期现象,然后对比测试结果跟预期是否一致,总结暴露出的问题点
测试人员测试,运维模拟故障场景
测试步骤:
1.QA准备正常的测试报告,测试相关功能(功能正常)
2.运维使用chaosblade工具将 kafka/redis/cpu/mem/eth0 引入故障
CPU注入之前:
CPU压力注入:
1 |
|
CPU压力注入后:
CPU解除注入:
1 |
|
进程hang住入前:
进程hang注入:
1 |
|
测试kafka是否真的hang住:
1 |
|
网卡故障注入,eth0发往远端6379端口5%丢包率
1 |
|
到此业务的测试就交给QA啦,虽然QA测试业务但是运维也要参与测试过程这样才好根据QA给的测试指标和现象总结测试报告,其中如果发现有现象和预期不符可在相同的指标和环境下多次测试。。。测试丢包率时就是要求QA测了3遍才出了明显现象!
混沌测试需要与QA和开发紧密沟通进行测试,一边模拟破坏一边测试业务现象,还原再模拟。。作为运维不仅要积极参与其中而且每一步还要和QA开发进行沟通主导测试流程的顺利推进~~
记录一个小坑:
在阿里云服务器上执行模拟网卡破坏操作,恢复失败,需要重启机器才能生效。但是在ucloud下可正常使用命令释放破坏操作。chaosblade注入压力是从内核中进行操作,可能是阿里云服务器的虚拟机不支持这种操作。。。。