多线程通常会将不同的业务逻辑分配到不同的线程组中。
为什么要做多线程：
模拟真实世界场景：在实际应用中，服务器通常需要同时处理来自多个用户的请求。通过多线程，JMeter可以模拟这种并发用户的行为，更准确地反映出应用程序在面对大量并发请求时的响应能力和稳定性。
测试系统极限：利用多线程，JMeter可以帮助识别系统在高负载下的性能瓶颈，比如响应时间增加、吞吐量下降等。这对于了解系统能够承受的最大负载非常有用。
提高测试效率：通过并发执行多个线程，可以在较短的时间内完成更多的测试案例，加快测试进程。
资源利用率：多线程允许更好地利用测试机器的硬件资源（如CPU和内存），尤其是在高性能测试环境中，这样可以更加充分地发挥测试工具的能力。
分布式测试：对于特别大型的测试需求，JMeter支持分布式测试，通过协调多台机器上的JMeter实例来产生更高的负载，这同样依赖于多线程技术的支持
例如：
登录线程组：专门用于处理用户登录，获取
token或其他认证信息。业务线程组：依赖于登录线程组的结果（如
token），执行后续的业务操作（如下单、支付、查询等）。
这种设计的好处是：
职责分离：每个线程组专注于特定的任务，便于管理和调试。
模拟真实场景：可以更好地模拟实际用户的操作流程，比如一个用户先登录，然后进行一系列操作。
性能测试：通过调整线程组的并发数，可以分别测试登录服务和业务服务的性能瓶颈。
首先在测试计划中独立运行每个线程组(例如在一个组运行结束后启动下一个）给勾选上
jmeter默认同级别线程组，同时运行没有先后之分，这个叫并发
并发就是我们站在同一个起跑线上，同时往前跑，谁先到终点谁就赢
引入setup与teardown概念
setup是开始，teardown是终点
跨线程在调用变量
前提:产生变量的线程组,一定要在消费变量的线程组之前执行
可以将产生变量的线程组设置成setUp线程组也可以在测试计划中勾选"独立运行每个线程组"
使默认的并发机制转变为线性机制
线性机制就是从上到下，也就是上面提到的独立运行线程组
这是两种方法 操作：
在登录接口中添加后置处理器中的BeanShell 我们需要将提取的token的值全局化，作用到全局，因为我们后续有多个线程组在调用token的时候，是需要将token的值进行全局化的
具体操作，直接贴图添加断言：
响应断言：
响应断言是最常用的断言之一，它用来检查服务器返回的响应内容是否符合预期。这包括但不限于检查响应文本、响应代码、响应头部等。例如，在一个HTTP请求之后，你可以使用响应断言来验证响应体中是否包含特定的字符串，或者响应头中是否含有某个特定的字段。
断言状态码：
断言状态码专门用于验证HTTP请求后的状态代码是否为预期值。HTTP状态码是服务器对客户端请求的响应状态，如200表示成功，404表示未找到资源等。通过设置断言状态码，可以确保请求达到了预期的结果。比如，如果你期望的是一个成功的GET请求，那么你可以在断言中设置状态码为200。
断言持续时间：
断言持续时间是用来验证操作执行所需的时间是否在可接受的范围内。这对于性能测试尤为重要，因为它可以帮助确定服务的响应速度是否满足业务需求。如果一个请求的响应时间超过了设定的阈值，断言就会失败，提示可能存在性能瓶颈或其他问题。
包括：包含上面的信息即算匹配通过，支持正则表达式
匹配：完全对应上上面的信息才算匹配通过，支持正则表达式
相等：响应结果与上面指定信息完全一致才算匹配通过，不支持正则表达式
字符串：包含上面的信息即算匹配通过。不支持正则表达式，对大小写敏感
否：与上面勾选的信息反转即算通过，不包含不匹配勾选的信息
具体操作：响应断言以及状态码断言
响应断言时间：
需要在“持续时间（毫秒）”字段中输入期望的最大响应时间，例如500毫秒。这样，当实际响应时间超过这个值时，测试就会失败，提示存在性能问题。
Apply to: Main sample and sub-samples：主样本和子样本，子样本如图片、CSS、JavaScript文件等。
Main sample only：只针对主样本 这意味着断言只会检查主请求的结果，而忽略任何子样本（如嵌套资源）的响应 Sub-samples only：只针对子样本 这意味着断言会跳过主样本，只针对嵌套资源（如图片、CSS、JS等）的响应进行检查
)
