基于SLA的测试

基于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所验证和度量。


推荐阅读:

All rights reserved
Except where otherwise noted, content on this page is copyrighted.