混沌测试

混沌测试

五月 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压力注入:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ 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解除注入:

1
2
3
4
5
6
$ 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注入压力是从内核中进行操作,可能是阿里云服务器的虚拟机不支持这种操作。。。。