MatrixOne混沌测试之道

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

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

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

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

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

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

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

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

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

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

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

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

核心模块：

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

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

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

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

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

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