How to Run a Stress Test in JMeter

   让我们考虑以下情况:显示学生考试结果的系统通过多个自动化功能测试。 性能测试结果也是有充满希望的。 系统已准备好部署到实时服务器。 但是,当考试结果发布在系统上时,服务器变慢并停止工作。

    发生了什么? 考试结果公布后,所有学生都想尽快查看考试结果。 它们产生了同时非常高的服务器负载,并且服务器无法处理请求。 首先,数据库机器减慢了。 然后,它没有为中间层提供数据,软件没有为这种情况做好准备,所以就停止运行了。

    性能测试人员错过了什么? 压力测试。 除了测试预期的用户数量之外,压力测试还会测试系统在强烈负载下的行为,并检查如何重新恢复正常使用情况。 压力测试可以通过像JMeter这样的开源测试工具轻松完成。


Choosing a test scenario

   在这篇文章中我们将用于测试的示例应用程序是正在开发的项目管理工具。 目前它有一些基本特点:

    - 登录

    - 创建项目并将Github存储库链接到该项目

    - 在创建的项目中创建问题

  压力测试的第一步是确定关键场景。 根据自己的业务价值选择情景(他们对于成功有多重要)和用户偏好(用户大部分时间花费的操作)。

  在本测试中,我们将检查网站的登录页面和项目详细信息页面的响应时间。

  响应时间很重要,因为加载时间是页面崩掉的主要原因。 随着互联网连接速度的提高,用户的平均耐心正在下降。 如果网站的加载时间超过4秒,大约25%的用户将离开。

   我们选择了登录功能,它提供对数据库的访问,因为它是每个系统的重要组成部分。

   我们选择了项目详细信息页面,因为在经过测试的系统中,它从许多表中读取数据,我们希望用户将大部分时间花在该页面上。 因此,我们想确保该页面是否会在合理的时间内被加载,即使在使用过度的情况下也是如此。

   Tibor1.png


tibor2.png

  现在我们已经确定了我们的测试目标,我们来描述下他们的测试用例:

    测试用例1 - 登录测试步骤:

    - 转到登录页面

    - 输入用户凭据

    - 点击登录按钮

    - 等待登录响应


    测试案例2 - 项目详细信息页面测试步骤:

    - 转到登录页面

    - 输入用户凭据

    - 点击登录按钮

    - 加载仪表板页面

    - 点击现有项目


Creating and recording the test script

  在决定测试用例之后,我们可以继续创建测试脚本。 创建JMeter测试脚本的最快方式是录制。 您可以使用JMeter录制或BlazeMeter Chrome扩展程序,这是Chrome商店免费提供的,并且对用户更加友好,因为您不必设置代理来使用它,例如使用JMeter刻录制。

   通过Chrome,开始录制并模拟您决定测试的用户场景。 完成后,停止录制。

              tibor3.png

   将文件导出到jmx并在JMeter中打开它,您可以在其中编辑和配置其参数。

   


Configuring the Thread Group

   每个测试都有自己独特的配置,如csrf令牌,响应断言和定时器,但几乎所有压力测试的相似性都是检查大用户量是的系统性能。 您应该根据你的业务目标应确定您正在测试的用户数。

   在这种情况下,我们想测试1000个用户。

   要做到这一点,您需要配置线程组。 线程组最重要的配置是线程数,ramp-up时间和循环数。 线程数设置模拟用户的数量,ranmp-up时间设置JMeter开始执行所有线程需要多长时间,循环计数是测试场景应执行的次数。

    tibor4.png


   结果显示,登录页面的请求处理时间为68毫秒,项目详细信息页面为1539毫秒。 因此,我们可以得出结论,在项目页面加载期间使用了大量资源。

   tibor5.png    

    现在,我们可以开始增加我们正在测试的线程数。 我们继续进行10个线程,0个ramp-up和1个循环。 由于我们仍在测试少量的线程,所以我们可以在GUI模式下使用JMeter,并通过监听器查看测试。

    tibor6.png  

    我们可以看到系统能够正确处理所有的请求:

    tibor7.png   所以现在我们将把用户数量增加到100(目标的10%)。 我们需要更改的脚本中唯一的参数是线程数,我们可以再次运行该脚本。 不要忘记在测试运行之间清理侦听器,以防万一你使用它。

   之后,将负载增加到目标的50%,在我们的情况下,这是500个用户。 根据结果,我们可以继续增加负载(如果测试成功)或下降(如果有错误)。 如果我们需要下降,我们应该知道有多少用户破坏我们的系统,所以我们可以决定如何解决瓶颈。

   如果500线程测试的结果都是绿色的,则将线程数增加到1000个用户的目标。 为了获得更准确的结果,我们建议您将测试切换到步进线程组,您可以从JMeter插件管理器添加。

   步进线程组允许您配置要启动多少线程,随时间推移应该添加多少线程以达到最大值,线程应该保持多长时间以及减速周期多长时间。 由于其ramp-up的能力,步进线程组能完美的检查系统的恢复力。

   tibor8.png

   该测试开始于我们知道服务器可以处理的500个线程。 然后,我们配置JMeter每30秒增加100个线程。 这样,如果在达成目标之前有问题,我们可以找出它在哪里有问题。 我们配置了1000个线程运行2分钟(120秒)。 要了解系统恢复的情况,有一个ramp-up时间 - 每10秒钟50个线程将被停止。

   在压力测试期间,在单个机器上可以运行多少线程是有限制的。 但是有几种简单的方式来增加这个数字。 尝试以非gui模式运行JMeter,这在大量线程的情况下是必须的。 我们还应该避免测试计划中包含监听器来进一步优化测试运行。 如果这些简单的调整不够,请分发多台机器之间的线程数。 结果可以在测试完成后生成。 当然,您也可以使用CA BlazeMeter,它是云中的JMeter。

   JMeter将为我们提供响应时间,吞吐量和错误率等KPI。 此外,我们还建议您监控服务器性能。 CPU使用率,内存使用量,输入/输出和数据库日志是确定系统瓶颈的有用参数。


翻译至:https://www.blazemeter.com/blog/how-perform-stress-test-jmeter



發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章