MatrixOne 混沌测试之道

作者：苏动 MO 测试工程师

导读

近年来，向云原生迁移和采取分布式架构/设计方法来创建云原生应用是当今大势所趋，而且这种趋势还在进一步加快。这其中最重要的驱动因素，莫过于可以大幅度的减少应用的停机时间、高弹性、资源高利用率等，从而增加更多的业务价值。

然而，这种架构无疑给软件测试带来了新的挑战，当涉及到测试云原生/分布式应用系统时，与人们用来测试其他应用系统（如单片机）的传统方法相比，事情就会变得复杂起来。应用程序往往以微服务的方式更加动态、分布式式的、更快的速度发布，并且存在难以预测和跟踪的故障模式。而传统的测试技术，在覆盖此类的问题时，便会捉襟见肘，于是关于一种看似新的测试物种-混沌测试，应运而生。随之，和混沌测试相关的测试概念、理论以及技术工具也越来越多的被提及、探讨以及实现。

那么，到底什么是混沌测试，混沌测试又能解决哪些问题，又该如何开展呢？当前并无权威的答案，而且可能永远也不会有一个放之四海而皆准的标准。众所周知，MatrixOne 数据库先天具备云原生和分布式的所有优势，自然对混沌测试也有着强需求，今天的文章，是从理论/方法论的层面，分享 MatrixOne 测试团队开展混沌测试的全局画布，主要围绕以下几点展开：

•如何理解混沌测试？

•如何开展混沌测试？

•如何评估混沌测试？

Part 1

如何理解混沌测试？

业界对于混沌测试，归纳起来，一般又称为故障演练，是一种可试验的、基于故障模拟和注入的方法来处理大规模分布式系统中的混乱问题。但是，混沌测试与其他的测试类型又有着本质的区别，不局限于测试，而更像是工程实践。

一般来说，不同的行业，不同的产品特点，对于软件测试的分类标准和开展需求都有所差别，但是总结起来，却又大同小异。在此，先分享一下 MO 测试团队为了更好的开展和管理产品测试而对测试进行的划分标准。

你会发现，混沌测试似乎无法被定位到任何测试类型，或者说和任何测试类型都有关联，却又都不尽如此。此处，借用朱少民教授给“软件测试”的定义的公式来阐述 MO 测试团队对于混沌测试的定义：

测试 = 检测已知的 + 试验未知的

• “已知” 指测试目标、测试需求和测试的验证准则等都明确，具有良好的可测性。

• “未知” 指测试目标、测试需求和测试的验证准则等不明确，很难直接进行验证，需要通过不断地试验，才能知道所实现的功能特性是否正确。

通俗点讲，“已知”就是在人力之内，而“未知”则是在人力之外，而且很严然，上图中的所有测试，均是针对“已知”项开展的，而混沌测试针对的就是这些“未知”项，并且，我们认为，对于这些“未知”的考虑，需要遵循如下一些原则：

1. “未知”可能存在于任何测试维度，发生在任何测试阶段，隐藏在任何测试对象和测试手段中；

2. “未知”的范围也是有界的，它包含的只是团队关注的、但是通过人力又无法有效解决的质量要素；

3. “未知”也应该而且必须要能够被评估、度量，否则任何针对其开展的测试都将毫无意义，只是这种衡量的标准可以是模糊的，范围的，或者渐进明细的；

4. “未知”试验的开展，必须要借助工具，或者由一系列工具支撑的工程化实践来完成；

5. 随着针对“未知”试验的开展，会有越来越多的“未知”项变成“已知”项。

我们可以通过下图来进一步理解混沌测试：

因此，在 MO 的测试体系中，让当前产品关注的质量要素可被更多的感知、管理和评估的所有测试努力，都属于混沌测试。混沌测试并不是什么新的测试技术、或者颠覆性的测试理念，它依旧需要遵循软件测试的本质，那就是为产品的商业活动提供质量信息和信心，所以，混沌测试的终级目标就是让“混沌”变得“不混沌”。

Part 2

如何开展混沌测试？

通过之前阐述，混沌测试需要解决的是“未知”问题，那么对于混沌测试的开展的首要前提，就是如何能够更好的去发现这些“未知”项，对于此点，业界也基本是共识的，总结起来，就是 4 个字：故障注入。

而且，当前对于混沌测试的研究，大部分也都聚焦在如何更好的实现故障注入的工具能力层面，比如：

1. Chaos Monkey，NetFlix 公司开发的一套用来测试服务器稳定性的测试工具，核心思路是故意把服务器搞下线，然后可以测试云环境的恢复能力；

2. Chaos Mesh, PingCAP 公司的一个开源云原生混沌工程平台，提供丰富的故障模拟类型，具有强大的故障场景编排能力；

3. ChaosBlade，阿里巴巴开源的一款遵循混沌工程实验原理，提供丰富故障场景实现，帮助分布式系统提升容错性和可恢复性的混沌工程工具，可实现底层故障的注入。

这些都是目前可用的非常优秀的故障注入工具，而且在业界混沌测试中也有着较高的普及度，然而，只解决故障注入是远远不够的，工具只是支撑，要想更好的开展混沌测试，更需要工程化的思维来设计和布局混沌测试。经过反复多次的试验，MO 测试团队混沌测试的架构图，如下图所示：

核心模块：

01

故障注入行为

通过故障注入工具完成，目的就是为了尽可能的识别和发现被测试系统中潜在的“未知”问题触发因素。对于故障注入，可以是纯粹随机的，也可以基于一定的故障注入策略。通过我们的实践证明，根据预定义的策略来注入故障，更有利于开展测试，因为在混沌测试执行中，需要通过策略来控制最小爆炸半径。

当然，故障注入策略的定义，往往跟当前混沌测试的重点有关，此处再次说明，混沌测试也是有界的，有目的性的，不是纯盲目性的行为，比如，如果想验证网络丢包对于事务成功率的影响，就需要适当的调整故障注入策略，提升网络延迟故障的比例以及选择重点的故障注入点。

02

稳态模型定义

所谓的稳态模型，实际就是被测系统的有效状态。这个有效状态可以用被测对象必须被遵守的质量要素规则集合来描述。如：功能可用性必须满足 r1、性能指标比如满足 r2 等等，那么稳态模型即可表示为：

M{r1,r2,......rn}

也就是说，无论在混沌测试中注入了哪些故障，执行了哪些测试，被测试系统都不能违背任何一条质量要素规则，即：

对于稳态模型的定义，需要遵循如下一些原则：

1. 质量要素的选取，依赖于产品测试本身需要覆盖的质量维度；

2. 质量要素规则的描述，可以不是精确的，是基于范围的；

3. 质量要素规则一定是可以根据测试结果计算得出；

4. 质量要素规则尽可能是量化的表述，并可以通过工具进行比较；

5. 质量要素规则依赖于产品能力和测试能力的成熟度，迭代式的进行优化。

03

真实事件模拟执行

测试事件的选择，依赖于稳态模型的定义，即，可以通过最终执行的测试事件结果，计算出稳态模型中各个质量要素的实际状态。

当然，测试事件的执行能够自动化，是混沌测试开展的必要前提，因此混沌测试的有效开展，是一定对测试能力成熟度有一定要求的，而且也会推动测试能力进一步的成熟。

04

行为日志记录

行为日志记录是很容易被忽略的核心要素。如之前所说，混沌测试即使发现了问题，也不能很明确的得知问题触发的因素是什么，而对于无法定位和解决的问题，等同于未知问题。

因此这就要求在混沌测试中，明确记录各种行为和信息，如故障注入点、故障恢复点、执行的测试项、资源使用情况等等，以便给最终定位和分析问题，提供足够多的素材。

05

逆向优化

通过混沌测试的结果，逆向优化测试用例集，以及进一步完善故障模式库，也是混沌测试的重要目的之一。

至于 MatrixOne 在混沌实践中，每个环节都是如何设计的，本次不做过多介绍，后续会有其他文章进一步分享。

Part 3

如何评估混沌测试

关于混合评估混沌测试成熟度，目前业界已经有一些探索，比如阿里的 CMM 模型，但是此模型有些过于复杂和理论化，MO 测试团队基于此，定制了属于自己的一套评估模型，而整个混沌测试的开展和演进，也是再此模型的基础上进行的。