以压测百度搜索为例

• https://www.baidu.com/s?wd=lakernote

下面的步骤在大部分情况下可以套用。

添加线程组

右键单击“Test Plan” -> “Add” -> “Threads (Users)” -> “Thread Group”。

• Name：取一个描述性的名称

• Action to be taken after a Sampler error: 在请求发生错误时的处理方式，可以选择中止线程、中止测试等。

• Number of Threads (users): 设置模拟用户数，即同时并发执行请求的用户数。这决定了在每个线程组中启动的线程数量。

• Ramp-Up Period (in seconds): 设置启动所有用户的时间间隔。如果将用户数设置为100，Ramp-Up Period设置为10秒，则系统将在10秒内逐渐启动100个用户。

  • Ramp-Up Period定义了启动所有虚拟用户所需的时间。如果设置为10秒，而同时有100个虚拟用户（线程），那么在10秒内，系统将逐渐启动这100个用户，而不是立即启动所有。
  • 这个选项的目的是模拟真实场景中用户逐渐增加的情况，而不是突然出现大量用户。这有助于更真实地模拟系统在负载逐渐增加时的性能表现。

• Loop Count: 设置每个线程运行的次数。如果设置为1，每个线程将仅运行一次。如果设置为-1（无限循环），则线程将一直运行直到测试停止。

  如果要达到刚好运行10次测试，则可以配置线程数：2，循环次数：5

  如果要达到运行10s测试，而不管多少次，则可以设置循环次数：永远，选中调度器设置持续时间：10

• Same user on each iteration: 如果选中此选项，每个迭代中的同一个线程将使用相同的用户。

  • 如果选择了这个选项，那么在每次迭代（循环）中，同一个线程（虚拟用户）将使用相同的用户标识。这意味着在每次循环中，该线程将以相同的身份（用户标识）执行请求。
  • 对于模拟单个用户在多次迭代中使用相同的身份进行一系列操作很有用，例如登录并执行多个操作，而不是在每次迭代中使用不同的用户。

• Delay Thread Creation until needed: 如果选中此选项，JMeter将推迟线程的创建，直到需要运行它们为止。这可以帮助减小资源消耗。

  • 如果选择了这个选项，JMeter将不会在测试计划启动时立即创建所有线程（虚拟用户）。相反，它将等到线程实际需要运行时才创建它们。
  • 这可以帮助减小资源消耗，特别是在你有大量线程但不是所有线程都在同一时间运行的情况下。例如，如果你有100个线程，但是测试计划启动后的第一秒只需要运行10个线程，那么只有这10个线程会在初始时创建，而其余90个线程将在后续需要时逐渐创建。

• Scheduler Configuration: 可选的调度配置，允许你按照特定的时间计划执行测试。如果你想在特定的时间段内执行测试，可以选择此选项。

  • Duration (持续时间): 设置测试计划的持续时间。可以选择执行测试的总时长，例如设置为3600秒（1小时）。
  • Startup Delay (启动延迟): 设置测试计划开始执行前的延迟时间。这可以用来在启动测试之前等待一段时间，以便进行预热或等待其他资源的准备。

添加定时器

定时器（Random Timer）可以帮助模拟用户在执行操作时的不规律性。你可以设置一个基础定时器和一个随机范围，以便每个请求之间有一些随机的等待时间，通常添加在需要模拟用户请求之间的时间间隔的位置，常见的情况是将定时器添加在HTTP请求之前，以模拟用户在执行不同操作之间的停顿。

以统一实际定时器举例

• Random Delay Maximum (in milliseconds): 设置随机等待时间的最大值（毫秒）。这个值表示在每个请求之间的最大等待时间。
• Constant Delay Offset (in milliseconds): 设置随机等待时间的偏移值（毫秒）。这个值表示在每个请求之间的基本等待时间。
• 计算公式:
  • 实际等待时间 = Constant Delay Offset + (0 到 Random Delay Maximum 之间的随机值)
• 例如，如果你设置最大等待时间为500毫秒，偏移值为200毫秒，那么实际等待时间将在200毫秒到700毫秒之间变化。
• 设置示例：
  • Random Delay Maximum: 500
  • Constant Delay Offset: 200

添加HTTP请求默认值

HTTP Request Defaults可以在多个HTTP请求中设置默认的服务器和协议信息，减少冗余配置。

HTTP Request Defaults 的设置会应用于同一级别下所有的 HTTP 请求。如果在具体的 HTTP 请求中有设置，它会覆盖这里的默认设置。这样，你就可以更方便地共享和管理一些通用的请求参数。

选择 Add -> Config Element -> HTTP Request Defaults进行添加。

• Server Name or IP: 输入服务器的主机名或 IP 地址。这是服务器的基本地址，实际请求中的具体路径可以在具体的 HTTP 请求中指定。
• Port Number: 输入服务器的端口号。默认是80，如果是HTTPS则通常是443。
• Protocol: 选择使用的协议，可以是 http 或 https。
• Path: 如果有一些请求共享相同的路径，你可以在这里设置。在具体的请求中，你仍然可以覆盖这个路径。
• Content Encoding: 可选项，可以选择请求的内容编码方式，例如 gzip。
• Parameters: 如果有一些参数在多个请求中都是相同的，可以在这里设置。

添加HTTP头管理

HTTP Header Manager允许你添加自定义的HTTP头部信息，如User-Agent，用于更真实地模拟浏览器行为。

选择 Add -> Config Element -> HTTP Header Manager。

• User-Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
• Authorization: Bearer your_access_token
• Content-Type: application/json
• Accept: application/json

添加HTTP请求

在Thread Group下右键单击 -> Add -> Sampler -> HTTP Request。

• Name: 用于标识请求的名称，显示在测试计划中，便于识别。
• Protocol: 指定使用的协议，可以是 http 或 https。
• Server Name or IP: 服务器的主机名或 IP 地址。
• Port Number: 服务器的端口号，默认是80。如果使用 HTTPS，通常是443。
• Method: HTTP 请求的方法，常见的有 GET、POST、PUT、DELETE 等。
• Path: 请求的路径，即请求的具体终点。
• Content Encoding: 请求的内容编码方式，例如 gzip。
• Parameters: 请求的参数，可以手动输入键值对，也可以使用 “Add” 按钮添加键值对。这是请求的查询参数。
• Body Data: 如果是 POST 请求，你可以在这里输入请求体的内容，通常用于传递 POST 请求的数据。
• Files Upload: 用于上传文件的配置，可以指定要上传的文件。
• Redirect Automatically: 如果勾选，JMeter 将自动处理重定向。
• Follow Redirects: 如果勾选，JMeter 将跟随重定向。如果取消勾选，将不会跟随重定向。
• Use KeepAlive: 如果勾选，将使用 HTTP Keep-Alive 以在单个连接上执行多个请求。
• Use multipart/form-data for POST: 如果勾选，请求将使用 multipart/form-data 编码方式。常用于文件上传等场景。
• Implementation: HTTP 请求的实现方式。默认为 “HttpClient4”，可以选择其他实现。
• Retrieve All Embedded Resources from HTML Files: 如果勾选，JMeter 将尝试检索 HTML 页面中引用的所有嵌入资源（例如图像、样式表等）。

添加结果断言

结果断言（Response Assertion）是一种用于验证请求响应是否符合预期的断言。

常用的断言类型，它们分别用于验证不同方面的请求响应。以下是这几种常用断言的简要说明：

1. 响应断言（Response Assertion）：
   • 用途: 用于验证响应的内容是否符合预期，包括响应文本、响应代码、响应消息等。
   • 配置选项: 可以设置响应文本的包含、不包含、匹配等条件，以及验证响应代码、消息等。
2. JSON断言（JSON Assertion）：
   • 用途: 用于验证 JSON 格式的响应是否符合预期。适用于处理 API 接口返回的 JSON 数据。
   • 配置选项: 可以设置 JSON 路径表达式和期望的值，以确保响应中包含或不包含特定的 JSON 数据。
3. 持续时间断言（Duration Assertion）：
   • 用途: 用于验证请求的响应时间是否在指定的时间范围内。
   • 配置选项: 可以设置期望的响应时间范围，如果实际响应时间在这个范围内则断言通过，否则失败。

响应断言 Response Assertion

响应断言是最常用的一种断言方法，主要是对响应结果中的文本内容进行断言，比如响应结果是否包含指定的值，或者是否等于指定的值。响应断言可以适用各种返回类型的响应结果，如Test、html、application/json、application/xml等。

JSON断言 JSON Assertion

JSON断言也是测试工作中经常用到的一种断言方法，它一般用于断言某个字段值是否等于我们指定的值。所以JSON断言只能针对响应结果为applicaton/json格式的进行断言操作。如果是其他类型（如：Test、html），则无法使用这种方式。

持续时间断言 Duration Assertion

断言持续时间通常用于做性能测试，一般用于检查HTTP请求的响应时间是否超过预期值。而这个响应时间是性能测试中常关注的一个性能指标。

添加察看结果树

选择Add -> Listener -> 察看结果树。

将看到所有请求的详细信息，包括请求头、响应头、响应数据等。

察看结果树 是一个非常有用的监听器，用于调试和分析测试中的问题。通过查看这个监听器，你可以深入了解每个请求的执行情况，包括请求和响应的各个方面。

请注意，在进行实际的性能测试时，由于 察看结果树 会占用大量资源，建议在测试结束后禁用或删除该监听器，以避免影响测试性能。

添加聚合报告

选择 Add -> Listener -> 聚合报告。

看到有关测试结果的聚合信息，包括平均响应时间、最小响应时间、最大响应时间、错误百分比等。

聚合报告 监听器是用于查看整体性能指标的一种方便工具。它将汇总所有线程组中的结果，并显示关键的性能统计信息。

请注意，在进行实际的性能测试时，由于 聚合报告 也会占用一些资源，建议在测试结束后禁用或删除该监听器，以避免影响测试性能。

添加表格察看结果

选择 Add -> Listener -> 察看结果表格。

将看到表格形式的结果，包括请求的详细信息、响应时间、响应代码等。

察看结果表格 是一种以表格形式查看结果的监听器，提供了简洁的视图，便于查看关键信息。你可以在这个表格中查看每个请求的详细信息，包括响应时间、响应代码、错误等。

请注意，在进行实际的性能测试时，由于监听器会占用一些资源，建议在测试结束后禁用或删除不需要的监听器，以避免影响测试性能。

参考

• http://testingpai.com/article/1655452307498