问题缘起

在信通院发布的《云原生测试白皮书》正文第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.（可参考文末推荐阅读获取更多信息）