通常我们在谈论性能测试的时候，往往将性能测试分为压力测试和负载测试两大类去讨论，在设计性能测试方案和执行性能测试过程的时候，也是基于这两个角度去思考。在传统意义上，通过这两个手段去评估某个系统的性能表现已经很完美了。

但是随着大数据互联网、移动互联网等新兴概念的兴起，传统的性能测试概念、方法已经无法全面的引导我们开展性能测试工作。比如移动端的兴起与广泛应用，移动端的性能也是性能测试的范围；再比如如何评估系统扩展性、弹性性能表现相关的容量测试，也要我们去关注。因为公司最近做服务端容量的相关工作，因此我们就性能测试，容量评估两个角度去重新定义性能测试的工作范围和职责。

1、性能测试

性能测试的最终目的是评估系统的吞吐量（TPS），因此我们从测试中经常见到的跟吞吐量（TPS）有关的三个图展开讨论。

图1很好的描述了压力测试的过程（VUSER是因，TPS是果）。理论上来讲，对一个健康的系统进行压力测试时，随着并发数的增加，系统吞吐量呈递增趋势，一直到系统处理能力达到饱和的时候，系统吞吐量保持在一个数字（t点）保持不变。但是，对于存在性能缺陷的系统，它的表现往往不是这样，可能因为网络、服务器、中间件的配置；软件设计、实现方面的缺陷，当吞吐量到达t点的时候，吞吐量不再数字t保持稳定，而是出现波动，因此，我们在做性能测试的时候，吞吐量曲线不是这个状态，系统肯定存在性能缺陷，我们应该具有分析这种情况的能力。

那么，我们根据图1的结果，是不是可以得出下面两个结论:

①系统的最大吞吐量是t ?

②系统的最优并发数是a ?

答案是否定的。因为，我们在定义软件的性能需求时候，往往说我们系统要支持多少个并发，吞吐量要达到多少，忽略了几个很重要的指标，如响应时间（SLA），稳定性，硬件资源，网络等。如果说，我们不考虑响应时间等因素，上面两个是无误的。

图2很好的论证的前面两个结论的不足之处，随着并发数的持续增加，系统的处理时间也越来越长，上图中，如果说t2是用户可接受的时效，那么当用户量超过v2时，那么我们系统就有了性能缺陷。

在互联网上对于用户响应时间，有一个普遍的标准。2/5/8秒原则。也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验。在5秒之内响应客户被认为“比较不错”的用户体验，在8秒内给用户响应被认为“糟糕”的用户体验。如果超过8秒还没有得到响应，那么大多用户会认为这次请求是失败的。

对于任何程序，它的运行离不开硬件环境。目前流行的研发框架下一个健康的程序，随着硬件资源的递增，其处理能力也会呈递增的状态，比如说，CPU密集型的程序，我们在提高CPU数据或者CPU处理能力时，其吞吐量肯定会递增；IO密集型的程序，提供IO处理能力强的设备，其吞吐量肯定会递增。基于上面三个图，尤其是第三个，我们引出容量评估的概念，作为性能评估工作的补充。

2、容量评估

如果说，性能测试过程帮助我们评测出当前系统的处理能力，那么容量评估跟性能恰恰相反，它解决我们要如何做，才能使系统达到更高的吞吐能力。

电商，O2O等行业的发展，各种促销活动也应用而生，促销活动带来系统压力也呈量级增长。任何一个健康的系统，自身处理能力当然是有限的，尽管我们通过性能测试获得了一些数据，但是这些数据的价值大打折扣。因为我们经常会遇到下面的问题：

• 系统单个节点的处理能力是多少？

• 这个活动我们要XXX的TPS，我们应该怎么扩容？

• 目前这个流量，生产上是不是有资源浪费？

显然，传统意义上的性能测试无法回答上面的问题，这时候容量评估就显的很有意义了，下面，我们就上面提到的三个问题展开讨论。

我们在做容量评估之前，必须考虑下面几个问题：

• 这个系统架构适合做容量评估吗？

• 我们怎么做容量评估？

• 容量评估的产出是什么？

在系统没有明显瓶颈的情况下，要扩展它的服务能力，无怪乎只有两种方法，垂直扩展和水平扩展。垂直扩展意思是我们提升硬件配置，CPU密集型的服务,如加解密相关应用，我们提升CPU的处理能力，IO密集型的服务，我们提升IO处理能力。再者就是水平扩展，就是通过加机器或者加节点的办法提高容量，如果通过这两个手段，系统容量都没有提升，那么对这样的系统做容量规划是无意义的。那么，容量工作该怎么进行呢？

第一步：确认容量目标和约束条件。目标是如何通过水平，垂直的方式提供最经济的扩容方案。监控以及容灾的保障型工作，对其服务能力也有诸多制约，我们要结合这些制约条件进行容量的工作。

第二步：确定容量指标。容量指标主要用作衡量服务器的处理能力。

容量指标的选取原则：

• 线下（上）数据可采集；

• 能够客观反映服务器处理能力。

作为容量指标，需要通过线下（上）监控获取统计数据，其历史数据用于计算集群的实际负荷，而通过压测获得集群的最大处理能力。如上所说，CPU密集型集群常选TPS作为容量指标，而存储型集群常选流量作为容量指标。

第三步：通过压力测试获取基础数据。通过压力测试的方式，评估系统在横向扩展、纵向扩展时候容量的表现，寻找系统短板，通过扩容的方式看容量表现，通过压测采集基础数据，数学建模的方式，绘制出系统容量的变化曲线，用来指导大流量活动时如何扩容。

第四步：线上监控结果分析。线上监控用于收集集群历史数据，计算集群的实际负荷，也可以对容量工作提供原始数据。根据集群的特点和之前性能测试经验关注容量指标和约束条件的业务和资源指标。而这里的历史数据，是需要长期的采集和整理。

第五步：根据收集到的数据，进行趋势预测。预测结果并非是个准确的数字。

通过上面的工作，我们手头数据积累，以及我们拥有的经验，包括直觉，可以较为准确的对扩容提供方案，也有能力回答前面提出的三个问题。

作者：软件测试高质量人

原文链接：https://blog.csdn.net/Maggie97/article/details/122212124