基于，SLA，测试。先来研究什么是SLA，再研究SLA该怎么测。
什么是SLA？
服务级别协议（service-level agreement，缩写SLA）也称服务等级协议、服务水平协议，是服务提供商与客户之间定义的正式承诺。服务提供商与受服务用户之间具体达成了承诺的服务指标——质量、可用性、责任。
——维基百科
由此可见，SLA 是服务提供者和服务消费者之间的契约，规定了服务内容及度量指标要求。比如云厂商经常宣传高SLA（也就是我们经常听到的的几个9，9越多代表全年服务可用时间越长服务更可靠，停机时间越短，反之亦然），来表达云服务的高可用性。这也解释了为什么我们通常听到SLA的场景是微服务和性能压测。往往在复杂的服务调用过程中会约束服务间协议，制定清晰的SLA项和度量指标，如常见的请求成功率、吞吐量、可用性、数据一致性等。
9是怎么计算的呢？
全年拿365天做计算吧，看看几个9要停机多久时间做能才能达到！
1年 = 365天 = 8760小时
99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小时
99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟
99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟
从以上看来，全年停机5.26分钟才能做到99.999%，即5个9。依此类推，要达到6个9及更多9，可说是非常难了吧。
SLA项必须是清晰可测的，否则就不能证明提供的服务满足SLA的定义。那么SLA测试都包含哪些内容，又该如何进行呢？
基于SLA的测试
由SLA的定义不难看出，基于或面向SLA的测试其实是一种测试方向或测试目标的描述，而非具体的测试方法或技术。
基于SLA的测试，就是针对SLA进行测试，确保服务能达到SLA的定义水平。这里其实包含两个视角：我是服务提供商，还是服务面向的客户。角度不同，所关心的测试也不同。
在云原生测试的语境下，这两个视角是云厂商和云用户。云厂商自己会做面向SLA的测试，来保证提供的云服务满足需求，而云厂商的用户则不需要关心这点。云用户关心自己的微服务架构的应用软件，要考虑微服务内部的SLA。
除了上面的正向理解，再补充一点：在云厂商视角中，因为云系统应用间的依赖关系极其复杂，而且任何产品的SLA都无法做到100%，因此，如果一个对SLA要求很高的产品依赖了一个SLA比较低的产品，就需要有面向失败的设计。Design for failure is the key to success in the cloud.
基于SLA的测试包含XX吗？
可能由此讨论引发出更多问题：基于SLA的测试是否包含混沌工程？是否包含性能测试？是否包含微服务测试？……
上面提到，基于SLA测试的目的是为了验证SLA的约束被满足，但不局限测试种类和方法，具体该采用什么测试方法，应取决于SLA的内容约定了什么。
因此比较严谨的描述应该是：基于SLA的测试可以包含混沌工程，可以包含性能测试或性能工程，可以包含XX……也可以被混沌工程、性能工程或XX所验证和度量。