混沌测试

五月 31, 2021

文档

什么是混沌测试，引用网上查到的资料

混沌工程类似于“故障演练”，不局限于测试，而更像是工程实践。为什么这么说，通常的测试用例会有“期望结果”和“实际结果”，通过将两个结果比较，或者对用户行为的预期，来判断测试通过或失败。而混沌试验类似于”探索性测试“，通过对系统和服务的干预，来观察系统的”反应“。我们将混沌工程原则融入在试验过程中：在生产环境小规模模拟系统故障并定期自动化执行试验，通过试验结果与正常结果进行比对，观察系统“边界”。

总结就是
在生产环境模拟故障场景，主动找出系统中的脆弱环节，试探生产系统的边界
而我将在新业务上线后在未开始导量之前，对其中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压力注入：

$ sudo ./blade create cpu load
{"code":200,"success":true,"result":"819563aecb286618”}

$ sudo ./blade status --type create
{
        "code": 200,
        "success": true,
        "result": [
                {
                        "Uid": "819563aecb286618",
                        "Command": "cpu",
                        "SubCommand": "fullload",
                        "Flag": "",
                        "Status": "Success",
                        "Error": "",
                        "CreateTime": "2021-05-26T14:37:16.172761961+08:00",
                        "UpdateTime": "2021-05-26T14:37:17.268172618+08:00"
                }
}

CPU压力注入后：

CPU解除注入：

$ sudo ./blade destroy 819563aecb286618
{"code":200,"success":true,"result":{"target":"cpu","action":"fullload"}}
内存使用率注入80%：

$ ./blade create mem load --mode ram --mem-percent 80
{"code":200,"success":true,"result":"7c99dad44139049d"}

进程hang住入前：

进程hang注入：

1 2	`[easemob@ali-cn1-mqtt-kafka01 chaosblade-1.0.0]$ sudo ./blade create process stop --process java {"code":200,"success":true,"result":"d120218cfdd73430”}`

测试kafka是否真的hang住：

1	`$ /data/apps/opt/kafka/bin/kafka-topics.sh --bootstrap-server $(hostname):9092 --list`

网卡故障注入，eth0发往远端6379端口5%丢包率

1 2	`$ sudo ./blade create network loss --percent 5 --interface eth0 --remote-port 6379 {"code":200,"success":true,"result":"cccb1ad550bfb06a”}`

到此业务的测试就交给QA啦，虽然QA测试业务但是运维也要参与测试过程这样才好根据QA给的测试指标和现象总结测试报告，其中如果发现有现象和预期不符可在相同的指标和环境下多次测试。。。测试丢包率时就是要求QA测了3遍才出了明显现象！

混沌测试需要与QA和开发紧密沟通进行测试，一边模拟破坏一边测试业务现象，还原再模拟。。作为运维不仅要积极参与其中而且每一步还要和QA开发进行沟通主导测试流程的顺利推进~~

记录一个小坑：
在阿里云服务器上执行模拟网卡破坏操作，恢复失败，需要重启机器才能生效。但是在ucloud下可正常使用命令释放破坏操作。chaosblade注入压力是从内核中进行操作，可能是阿里云服务器的虚拟机不支持这种操作。。。。

查看评论