【性能测试】Web压力测试+性能稳定性场景设计（详细总结）

---

前言

1、Web应用压力测试

在众多软件测试类别中，Web应用压力测试是其中基础的测试工作，常见的软件压力测试要关注怎么给应用进行施压，正确评估系统存在的瓶颈问题，以及预估系统能够承载的测试压力等方面因素。

web应用压力测试也不例外，举个简单的例子，线上演唱会门票抢购页面在面对大量的用户涌入时系统常常崩溃，让网友体验感很差。

如何确保系统不崩溃就与做好web应用压力测试有关了，那么怎么做Web应用压力测试？常规的步骤有哪些呢？

1）什么是Web应用压力测试？

Web应用压力测试可以分开来进行解读，是针对web应用程序/服务器做的压力测试，对web应用程序的性能指标制定压力测试方案，从而验证系统的性能指标是否满足既定值。测试的目的也是为了发现系统瓶颈。

2）Web应用压力测试常用考核指标

常用的Web应用压力测试常用考核指标包含不仅限于以下几点：

资源利用率；主要是针对web服务器、操作系统等系统资源的使用程度，这也是为了改善系统性能的重要依据。

并发数；指模拟用户在同一时刻同时对系统执行同一操作，以此观察系统的各项性能指标。

其他；比如在试压情况下系统的响应时间（web请求处理完毕的时间），吞吐量等。

3）怎么做Web应用压力测试？

做好web应用压力测试需要尽可能的模拟真实环境对被测系统进行施压，那么与压力测试工具、单独测试环境有关系。

比如测试环境的搭建，如果计算机软硬件平台的配置跟不上，那对测试结果也会有很大的影响。

现在市场上也有针对此项业务做的比较好的独立第三方测试机构，比如卓码软件测评，拥有完善的自动化测试环境和成熟的测试技术能力，能帮助企业做好Web应用压力测试。

4）相关软件测试解决方案

随着软件测试业务逐渐受到重视，软件测试已经不仅仅局限与公司内部测试了，企业也可以通过第三方测试机构或者本地评测中心来做，不仅能够帮助企业节省人力物力，而且能够给企业提供公正客观的系统测试解决方案。

2、性能测试的稳定性场景设计

人们谈到测试设计，往往是指功能测试设计，往往忽视性能测试的场景设计，例如，如何进行性能测试时，如何把性能负载加上去，就需要根据业务进行负载发起策略的设计，包括逐步加载、一次性加载和峰谷加载等。

不管你是否重视，性能场景应该说是在性能测试中非常关键的一个环节。经常在一些场合被问到性能场景的设计问题，但是大部分都是和容量相关的。

但为什么稳定性问的人少呢？
稳定性是不是说在容量场景做好了之后就水到渠成了呢？

首先稳定性场景的设计应该说比容量场景设计要简单一点。

如果容量测试结果非常好的话，稳定性场景只要维持较长时间的动作就可以了。但是不要小看这个时间变长的动作，它会让你要准备和思考的内容多出不少。

1）数据的增加

数据的增加有两个方面：
参数化数据、基础数据。

这里以参数化数据为例：
拿一个100TPS和稳定性场景来说，假设业务数据不能复用，如果只测试30分钟。需要的数据是1003060=180000，也就是18万的参数化数据。但如果要跑12个小时呢？

就是1001260*60=4320000，也就是432万条数据。

甚至有人还说：我要跑7*24。嗯，很好，那就需要60480000，即6千多万条数据，慢慢准备吧

如果这些数据是做insert的动作呢？可想而知，对表结构的要求就会多出很多，索引创建的合理性就非常重要了。

举个例子。同样的一个SQL，在查找基数为5537362的表，都是查一条数据出来。如果是从9万多条的索引命中的数据中找的话，需要0.219s，而在索引命中100多条数据中找的话，只需要0.016s。

这是14倍的差距。

insert的动作是会被折成insert select的。所以在稳定性中，如果select的基数越来越大，对索引的考验那是可想而知的。
对update、delete也是一样。

2）监控的考验

如果是自己写监控脚本，稳定性场景中数据量的处理那是非常耗时的。所以在稳定性场景中，基本上不会像容量场景中那样设计监控粒度。

粒度的扩大导致的另一个问题是毛刺看不到。

一般容量场景中使用1-3s的监控采样粒度，1s对系统监控还是会消耗些资源，3s不会有太大的影响。但是对稳定性来说，3s却有点短了。

可以设置5-10s的监控粒度。5-10的跨度是不是有些大呢？这个取决于系统的稳定程度，对不稳定的tps曲线，可以设置为5s，对稳定的tps曲线，10s其实是够了的。

监控工具也要选择好，尽量不要用手工生成数据和曲线的工具，费时费力又容易出错。用自动生成图表的工具比较理智，并且要用可以持续保存数据的，像zabbix类型的工具。

先要设置好监控的计数器。从OS层开始，到应用层、jvm层，再到数据库层。os层一定要监控cpu、memory、io、network这几个基本资源，如果是C/C++的应用，还要有process层的监控。

在场景结束时，如果发现还有需要的数据没取到，那就悲催了，还要再来一遍，所以场景设计和监控设置时都要认真对待。

3）对压力工具的选择

一般情况下，选择压力工具要注意压力工具本身的稳定性。

像loadrunner/jmeter之类的工具已经被普遍接受了，没有什么问题。
但是jmeter，本地的jvm也是需要关注的。
尽量不要用压力工具取监控的数据，这种做法会让结果整理比较费力。

4）稳定性场景的时长确定

这应该是稳定性场景中最关键的一个点了。但我看到有不少设计稳定性的时候没有计算过，只是凭感觉。

那怎么设计这个时长？

我们可以做一个计算，这个计算有一个前提条件。就是系统在运维的过程中需要稳定运行多长时间。假设在运维中是要三个月做一次正常的维护动作，在这个动作中包括了对一些资源的归档、系统的重启等。那下一步要计算的就是系统三个月内的业务总量。

我们来做一个假设场景：
一个系统一天业务量是100万笔。稳定运行要求3个月。那总的业务量就是100万330=9000万。假设系统最大TPS是2000。

这时候要设计的稳定性场景时长就是：
（9000万/2000tps）*3600=12.5h

根据这个系统的业务需求，稳定运行时间是三个月。线上均值tps是329。

那业务量在三个月就是：329330243600=2558304000笔业务。

稳定性场景用80%*最大TPS的压力做的话（这里的稳定性场景的TPS可以灵活设置，不一定都是80%*最大TPS），就是4000tps左右。

来计算一下：2558304000/4000/3600/24=7.4天

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

不要停下脚步，即使路途遥远，也要坚持前行。披荆斩棘的奋斗，将开启属于你的壮丽篇章。相信自己的力量，勇往直前，追逐梦想，创造辉煌人生。你是无限可能的！

无畏困境，勇往直前。努力奋斗，追逐梦想。相信自己的力量，超越极限。只有坚持不懈，才能创造属于自己的辉煌人生。你的未来，由你书写！

不要害怕失败，每一次跌倒都是成长的契机。坚持追求梦想，勇往直前，才能超越自我，创造属于自己的辉煌人生。相信自己，你注定成就非凡！