关于测试: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}
也就是说，无论在混沌测试中注入了哪些故障，执行了哪些测试，被测试零碎都不能违反任何一条品质因素规定，即：

对于稳态模型的定义，须要遵循如下一些准则：品质因素的选取，依赖于产品测试自身须要笼罩的品质维度；品质因素规定的形容，能够不是准确的，是基于范畴的；品质因素规定肯定是能够依据测试后果计算得出；品质因素规定尽可能是量化的表述，并能够通过工具进行比拟；品质因素规定依赖于产品能力和测试能力的成熟度，迭代式的进行优化。
03 实在事件模仿执行
测试事件的抉择，依赖于稳态模型的定义，即，能够通过最终执行的测试事件后果，计算出稳态模型中各个品质因素的理论状态。
当然，测试事件的执行可能自动化，是混沌测试发展的必要前提，因而混沌测试的无效发展，是肯定对测试能力成熟度有肯定要求的，而且也会推动测试能力进一步的成熟。
04 行为日志记录
行为日志记录是很容易被疏忽的外围因素。如之前所说，混沌测试即便发现了问题，也不能很明确的得悉问题触发的因素是什么，而对于无奈定位和解决的问题，等同于未知问题。
因而这就要求在混沌测试中，明确记录各种行为和信息，如故障注入点、故障复原点、执行的测试项、资源应用状况等等，以便给最终定位和剖析问题，提供足够多的素材。
05 逆向优化
通过混沌测试的后果，逆向优化测试用例集，以及进一步欠缺故障模式库，也是混沌测试的重要目标之一。至于 MatrixOne 在混沌实际中，每个环节都是如何设计的，本次不做过多介绍，后续会有其余文章进一步分享。

Part 3 如何评估混沌测试

对于混合评估混沌测试成熟度，目前业界曾经有一些摸索，比方阿里的 CMM 模型，然而此模型有些过于简单和理论化，MO 测试团队基于此，定制了属于本人的一套评估模型，而整个混沌测试的发展和演进，也是再此模型的根底上进行的。