基于SLA的测试
新技术？新方法？
问题缘起
在信通院发布的《云原生测试白皮书》正文第9页，提到“基于SLA的测试”。有社区伙伴提问，什么是基于SLA的测试？之前并未细想过这个概念。带着QA刨根问底的职业病，是时候借此契机搞明白这个问题了。
对于不熟悉的问题，我的习惯是先做关键词拆解：基于，SLA，测试。所以先来研究什么是SLA，再研究SLA该怎么测。
什么是SLA
服务级别协议（英语：service-level agreement，缩写SLA）也称服务等级协议、服务水平协议，是服务提供商与客户之间定义的正式承诺。服务提供商与受服务用户之间具体达成了承诺的服务指标——质量、可用性、责任。
由此可见，SLA是服务提供者和服务消费者之间的契约，规定了服务内容及度量指标要求。比如云厂商经常宣传高SLA（也就是我们经常听到的的几个9），来表达云服务的高可用性。这也解释了为什么我们通常听到SLA的场景是微服务和性能压测。往往在复杂的服务调用过程中会约束服务间协议，制定清晰的SLA项和度量指标，如常见的请求成功率、吞吐量、可用性、数据一致性等。
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所验证和度量。