容量测试解决了什么问题？

前面几篇性能测试知识科普系列的文章，介绍了性能测试中的核心术语和指标、常用测试策略、压测工具选型、性能需求分析、测试能力分层、新手学习路径以及监控分析工具相关的内容。

这些知识可以说是性能测试最基本的能力，也是日常工作中需要经常用到的知识。

但在实际的工作中，我们面临的往往是复杂的业务场景和技术架构以及突增的用户访问流量，在这种情况下以往单纯的压测已经无法很好的解决问题。

要想很好的保障这种复杂情况下的系统性能和稳定性，我们需要在性能测试的基础上更进一步，做好容量保障工作。

这篇文章，我想聊聊容量保障以及容量测试相关的话题。

如何理解容量保障？

常规的性能测试，一般是采用不同的手段和策略去验证系统在不同业务场景下的性能表现是否满足预期指标，是否存在性能瓶颈并进行优化验证的过程。

但随着移动互联网的发展，业务场景越发多变，技术架构也随着微服务、云原生等技术的出现越来越复杂。以电商业务为例，性能测试同学经常面临这几个问题：

• GMV增长两倍，系统性能可以满足业务增长需要吗？
• 如果无法满足，扩容能否解决问题？如果扩容扩多少？
• 如果要搞双11大促，如何保障系统在大促期间的稳定性？

诸如上诉此类问题，都是当前性能测试同学甚至运维、架构师面临的技术挑战。

而容量保障工作就是为了解决诸如此类问题的有效手段。

1、什么是容量？

软件系统是基于硬件服务器部署的，硬件服务器限于本身的配置，其本身处理能力是有限的，这点需要明确。

从软件工程的角度出发，容量就是单位时间内软件系统能够承载并处理的最大业务量。

2、什么是容量保障？

理解了软件系统的容量，就可以很好的理解容量保障的工作内容了。

我们日常工作中的功能测试工作，就是保障软件功能的正确性、易用性等，当然现在也叫做质量保障。

容量保障，就是通过运用各种方法和工具，保障软件系统的容量可以承载并处理各种业务，并具有一定的弹性能力。

3、容量保障有哪些难题？

• 容量的不确定性：业务场景多样、技术架构复杂，导致容量在不同场景不同时间段有不同表现；
• 容量评估的复杂性：服务调用链路复杂，上下游服务彼此的制约导致很难评估出一个较为准确的预期值；
• 容量测试的不准确性：测试和生产环境的差异、服务配置差异、硬件资源差异、网络环境差异、业务场景差异；
• 容量规划治理的复杂性：业务场景不断变化、代码版本不断迭代、新技术的引入、人员的流动变化都让容量规划和治理变得难上加难；

如何理解容量测试？

上面的内容介绍了容量保障面临的四大难题，而容量测试，就是运用各种方法和工具在这种复杂的情况下去不断验证容量结果，最终保障线上软件系统容量可以支撑业务正常运行的过程。

这是一个持续验证的过程，相比于传统的性能测试压几个接口，得到结果，优化验证完发布上线而言。

容量测试更提倡持续验证，做到对各环节的容量永不信任，持续验证，最终达到持续的保障线上系统稳定性。

当然，容量测试和传统性能测试类似的点也有很多，同样需要需求分析，场景设计，数据准备，实施压测以及性能优化。

或者可以理解为，容量测试和传统性能测试并没有本质上的区别，都是为了让软件系统满足业务需要，支撑业务目标更好的达成。只是容量测试所提倡的方法和理念，更适用于当前我们所面临的环境和挑战。

了解容量测试，然后忘掉各种高大上的新概念，做到持续验证持续保障即可。

容量测试解决了什么问题？

常规的性能测试，是有了需求，然后进行需求分析，场景设计，数据准备，脚本编写和压测执行以及定位优化验证这些步骤，而容量测试的特点在于计划性和预期性。

可以理解为常规的性能测试更偏向先有需求再出结果，而容量测试更注重预先评估结果，针对结果进行计划性的有步骤的验证。如果分类的话，可以将容量测试要做的事情，分为如下三种情况：

1. 日常事件：日常的迭代压测、性能巡检；
2. 计划事件：比如新服务上线、双十一大促；
3. 突发事件：比如线上流量突增、异常告警、紧急扩容；

容量测试就是为了达成容量保障目标的一种持续验证手段，要解决的问题除了日常工作中的需求，还要有计划的应对未来的需求，以及预期可能出现的容量风险并做好应对措施。

本篇文章是对容量保障和容量测试的一个大体介绍，下篇文章，我会详细的介绍容量保障工作四步走的详细过程。