什么是软件容量测试？

在现实的性能测试工作中，我们面临的往往是复杂的业务场景、技术架构以及突增的用户访问量，在这种情况下单纯的压测已经无法很好的解决问题。
要想很好的保障在这种复杂情况下的系统性能和稳定性，我们需要在性能测试的底子上更进一步，做好容量保障工作。

这篇文章，我们就来聊聊容量、容量保障、容量测试以及容量规划相关的话题。
一、容量

1、什么是容量？
软件系统是基于硬件服务器摆设的，硬件服务器限于自己的设置，其处理本事是有限的。
容量，即系统处于最大负载状态或某项指标到达所能担当的最大阈值下对请求的最大处理本事。
详细来讲，系统的容量（处理本事）是有限的，容量是可度量的。
2、怎样统计容量指标？
1）统计维度
通常可以从如下两个维度来定量系统的容量：

2）统计方法
通常采集数据的方法，有以下几种方式：
① 埋点采集：即在系统的各个节点，根据需要添加埋点，针对性的进行数据采集。
② 日志/数据库：通过日志服务（如ELK）或者运维监控（如Devops）采集分析数据。
③ Agent/探针：在需要采集的节点添加Agent/探针，实时采集；数据存入时序数据库（比如influxdb），实时展示。
3）注意事项
采集对比的数据肯定要采集线上的真实数据，这样才能反映真实客观的系统压力。
二、容量保障

1、什么是容量保障？
理解了软件系统的容量，就可以很好的理解容量保障的工作内容了。
我们一样平常工作中的功能测试工作，就是保障软件功能的正确性、易用性等，叫做 质量保障 。
而容量保障，就是通过运用各种方法和工具，保障软件系统的容量可以承载并处理各种业务，并具有肯定的弹性本事。
2、为什么需要容量保障？
随着移动互联网的发展，业务场景越发多变，技术架构也随着微服务、云原生等技术的出现越来越复杂。
以电商业务为例，性能测试同砚经常面临这几个问题：

• GMV（商品交易总额）增长两倍，系统性能可以满意业务增长需要吗？
  
• 如果无法满意，扩容可否解决问题？如果扩容扩多少？
  
• 如果要搞双11大促，怎样保障系统在大促期间的稳定性？
  

诸如上诉此类问题，都是当前性能测试同砚甚至运维、架构师面临的技术挑战。而容量保障工作就是为了解决诸云云类问题的有用手段。
3、容量保障有哪些困难？

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

三、容量测试

1、怎样理解容量测试？
容量测试，是性能测试里的一部分，它的目的是测量系统的最大容量，为系统扩容、性能优化提供参考，节省成本投入，提高资源利用率。就是运用各种方法和工具在这种复杂的情况下去不绝验证容量结果，最终保障线上软件系统容量可以支撑业务正常运行的过程。
这是一个持续验证的过程，相比于传统的性能测试压几个接口，得到结果，优化验证完发布上线而言。容量测试更提倡持续验证，做到对各环节的容量永不信托，持续验证，最终到达持续的保障线上系统稳定性。
固然，容量测试和传统性能测试类似的点也有很多，同样需要需求分析，场景设计，数据准备，实施压测以及性能优化。
可以理解为，容量测试和传统性能测试并没有本质上的区别，都是为了让软件系统满意业务需要，支撑业务目标更好的达成。只是容量测试所提倡的方法和理念，更适用于当前我们所面临的环境和挑战。
了解容量测试，然后忘记各种高大上的新概念，做到持续验证持续保障即可。
2、怎样做容量测试？
1）测试思路
① 根据详细的业务情况和系统架构，通过设置测试的手段，测量得到单个服务节点在对应的业务场景下最大的性能表现。
② 根据系统架构（集群、分布式、微服务）特点，通过启用≥2的服务节点，来得到服务节点的增长后系统性能的提拔比例。
③ 通过线上采集的系统数据，分析出过去某段时间（或某个业务）的高峰流量，然后通过盘算，得到容量扩容，需要投入的现实服务数目。
2）束缚/停止条件
在测试过程中，只要限定的某项指标到达最大可担当阈值或某项资源到达最大利用状态，立即停止测试。
3）选择合适的容量指标
考虑到业务需求和系统架构的不同，在选取容量指标时一般遵照如下原则：

• 数据麋集型：即并发请求量较大的范例，一般TPS和RT（响应时间）是比较关注的指标。
  
• 数据存储型：即需要存储读写的数据量较大的范例，一般吞吐量和IO是比较关注的指标。
  

3、注意事项
容量测试环境的设置，肯定要和线上保持一致（服务器数目可以不同，但设置尽可能保持一致）。
4、容量测试解决了什么问题？
通例的性能测试，是有了需求，然后进行需求分析，场景设计，数据准备，脚本编写和压测执行以及定位优化验证这些步骤，而容量测试的特点在于计划性和预期性。
可以理解为通例的性能测试更偏向先有需求再出结果，而容量测试更注重预先评估结果，针对结果进行计划性的有步骤的验证。
如果分类的话，可以将容量测试要做的事变，分为如下三种情况：

• 一样平常事故：一样平常的迭代压测、性能巡检。
  
• 计划事故：比如新服务上线、双十一大促。
  
• 突发事故：比如线上流量突增、异常告警、紧急扩容。
  

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

1、为什么需要容量规划？
对于业务越来越复杂的商业形态，每个业务都由一系列不同的系统来提供服务，每个业务系统都摆设在不同的机器上。容量规划的目的在于让每一个业务系统可以或许清晰地知道：

• 什么时候应该增长服务节点，什么时候应该减少服务节点（比如服务端担当到的流量到达什么量级）？（比如双十一，大促，秒杀）
  
• 为了双 11 、促销、秒杀、渠道拓展引流等业务需求，需要扩充到什么数目级的服务，才能即包管系统的可用性、稳定性，又能节省成本？
  

2、容量规划四步走
① 业务流量预估阶段：通过分析历史数据以及实时的线上监控，预估未来某个时间点或者某个业务可能会有多少的流量冲击。
② 系统容量评估阶段：根据详细的业务场景，分析每个业务场景的流量配比，然后盘算每个业务大概需要多少服务节点来提供可靠稳定的性能支撑。
③ 系统容量测试阶段：通过全链路压测或者PAT/UAT环境的压测，来模拟真实的业务场景，确定每个服务节点的详细性能表现，进行针对性的调整。
④ 流量分配调整阶段：根据压测的结果，设定限流、服务降级、熔断、隔离等系统掩护步伐，来预防当现实流量超过系统所能承受的最大流量时系统无法提供服务。
3、盘算公式
容量规划通例的盘算公式如下：
A服务单机容量在50%水位时，TPS=200，设定为T；线上流量转化预估TPS为3000，设定为S；为保障服务高可用，预留30%机器资源做扩容buffer，设定为B。
那么A服务最终线上需要摆设的机器数目的盘算公式为：
Count（A）= (1+B)*(S/T）
Count（A）= (1+30%)*(S/T）= 19.5台机器；取整，那么服务A线上容量规划时，需要摆设20台机器。
注意：

• 水位，一个带有刻度的容器当前装有液体的水面位置则为水位，而服务的最大水位就是系统的极限TPS；而服务的当前水位 = 当前总TPS/（单台机器极限TPS*机器数）*100%
  
• 服务的处理本事是有限的，而且为了保障服务的稳定可用性，不能让服务器持续处于高负载的状态，因此要提前预留肯定的资源可用比率，作为缓冲区。
  

4、扩容手段
1）垂直扩容
升级服务的硬件设置，让单个服务节点的容量更大，来提供更高的系统服务本事。比如：加大服务机器的CPU数目和内存，更换性能更好的高速缓存服务器，数据存储用NAS盘替换等。
2）水平扩展
增长服务节点的数目，让可提供服务的服务变得更多，来提拔系统总体的服务本事。
常见的方式有：

• 服务集群：服务器的数目由1→N（但需要重点关注负载均衡）。
  
• 分布式：提供服务的节点由同一集中管理摆设，分散到不同的地点。
  
• 容器：提供更灵活的弹性扩容机制，根据详细的访问流量大小来弹性扩容或者缩容。
  

末了：下方这份完备的软件测试视频学习教程已经整理上传完成，朋侪们如果需要可以自行免费领取【包管100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，而且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

1. 获取方式：QQ社区：902061117

复制代码

这些资料，对于【软件测试】的朋侪来说应该是最全面最完备的备战堆栈，这个堆栈也陪伴上万个测试工程师们走过最艰难的路程，盼望也能资助到你！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。