谈论JMeter？ 最有可能的是，如果您正在学习本主题，那么您已经阅读了有关此工具进行压力测试的所有内容。 但是我有一些令您惊讶的东西。 在QA的三年中，我意识到JMeter具有多种用途，可以用于多种用途。 例如，用于：
- 搜索某些用户在网站崩溃时难以捉摸的错误；
- 快速缓存预热数千个产品页面；
- 测试移动应用程序的后端；
- 在短时间内在应用程序数据库中创建2000条带有用户数据的记录。
如果您有兴趣，欢迎猫。 结果很多，因此我将文章分为两部分。
免责声明：出于明显的原因，我不会在文章中插入真实项目的屏幕截图（或从中提取所有重要信息）。 提供插图仅用于研究和教育目的。
经典JMeter应用
JMeter-带有GUI的Java小程序。 为了进行测试，它从没有图形界面开始。 对于编写测试脚本，他有一个面板，您可以在其中进行任何操作。
这就是创建脚本的过程的样子（这里甚至连“ writer”一词都不适合）创建一个通用的测试计划，线程组将其与测试的主要元素进行比较：流程控制器和请求（HTTP，FTP等）。
此外，还有其他用于设置参数的元素。 例如，HTTP请求默认值允许您指定主服务器，标头并启用/禁用其他资产（图片，样式，字体等）的下载。 很容易弄清楚。 您可以立即从该界面运行测试并查看结果。
JMeter可以记录此类测试案例。 它在本地计算机上作为代理运行，如果您配置了浏览器（或应用程序），则通过该代理来驱动流量，JMeter将记录所有请求和响应。 从这个集合中，您可以编制一个测试脚本，该脚本将重复用户的操作，并在任何需要的位置和时间运行它：
主要问题是Java本身的内存堆。 它放在天花板上，即使同时在高端机器上，也可能掉落50条并发测试的线。
如果机器没有足够的功率进行满负荷测试，请联系第三方组织。 他们部署了一组服务器基础架构。 他们得到了相同的JMeter。 这些家伙需要付费才能运行脚本。 我们在Octoperf和Blazemeter申请了此类服务。
宝贝，这就是足球：我们如何在部分服务器崩溃的情况下捕获错误
我们从事Web开发已有18年了（欢呼声-现在您可以吸烟，结婚并观看John Wick）。 他们一生中有很多客户，但是最近出现了最大的客户。 例如，我们在
Sitecore上为具有SPW范例的英超足球俱乐部之一创建了一个网站（单页网站：所有页面都打开，而无需重新加载浏览器页面本身）。 后台是用于管理实时比赛页面的管理面板。 这是该游戏的在线文字广播：主要事件（进球，删除，任意球）是从Opta系统自动加载的，Twitter和Instagram上粉丝的照片，评论和转发是由直播人（足球俱乐部内容经理）发布的。
我将自豪地注意到：发布后，英国媒体以“最后，足球俱乐部旧址的霸权结束了”的标题发布了文章。 当时，大多数俱乐部已经拥有场地。 但是它们看起来好像是在2000年代初开发的，此后一直没有改变-带有相应的设计和UX。
在发布之前，我们进行了满负荷测试，并确保一切正常进行。 服务器结构如下所示：
- 客户端的请求转到负载平衡服务器→
- 负载平衡服务器检查八台CD服务器的状态→
- 负载平衡服务器将请求发送到负载最少的CD服务器→
- CD服务器响应客户端。
推出一年后，在大量用户涌入该网站的过程中，客户致电并说该网站已关闭：
-我们的网站无法正常工作！ 根本不起作用！ 只是一个白色的屏幕和浏览器上的题词，该网站已关闭！ -客户说。
我们正慌张地打开该站点，一切正常：
我们仍然回答：“它仍然有效。”
客户端通过电话和计算机打开该站点，并且...一切都还可以！
-真的，对不起。 显然，用户有问题。
这些消息不会从头开始出现，因此我们进行了一项研究：我们启动了一个实用程序，用于监视服务器密度服务器的状态，并查看在站点用户大量涌入期间它们发生了什么情况：
负载很大，但是所有CD服务器看起来都差不多，甚至故事很快就重演了-一些用户报告说网站完全损坏了。 这不是某种错误或找不到页面-服务器只是没有响应该请求。 在JMeter的帮助下，有可能赶上形势。
目标很简单-加载所有八台服务器，然后看看会发生什么。 黎明在车里雅宾斯克进行了压力测试，在伦敦那是一个深夜。 我们在非接口模式下使用了多台计算机（它允许您同时运行更多线程）。 该脚本无休止地打开了主页，这是我们的主要错误。
我们下载了已经被缓存一百次的相同资产。 因此，负荷微不足道。 然后，这个想法就来了：在站点上–一辆马车和一小段载有特定日期新闻的纸车。 如果您提前几个变量并将其替换为URL，我们将始终获得一个随机页面（例如-... url / news / 2016/08/23 /？Page = 4）。
突然，我们意识到服务器密度在过去一段时间的服务器负载图中具有一些内置的“平滑”功能。 如果在五分钟内服务器上的负载达到100％，然后降至0％，并在20-30秒后增加到90％，则它将显示该时间段的平均值-约为80-90％。 因此，我们没有看到真正的服务器崩溃。
在压力测试期间详细检查了日志之后，我们发现其中一台CD服务器以100％的负载重新启动，并且没有告诉任何人（他是如此内向）。
负载平衡器仅查看所有服务器的CPU利用率。 他看到其中一个负载为20％，其余负载为90％，然后将用户带到第一个。 然后他重新启动并发出白屏。 另外，分发服务器将用户暴露给cookie，并将其紧密绑定到空闲服务器。 因此，即使在更新之后，该站点也不可用。 8位用户中的其余7位同时享受了生活，并说一切正常。
结论：
我们发现JMeter可用于压力测试，并在使用其他工具进行测试的同时分析服务器的状态。 我们设法在某些用户中“捕获”了网站崩溃的问题，并通过更正了负载分配逻辑并添加了状态控制来解决了该问题。
在下一部分中，我将告诉您如何在JMeter的帮助下设置产品页面的缓存过程，如何在没有应用程序本身的情况下测试移动应用程序的操作以及如何在系统中创建2000个用户而无需访问数据库。