多線程通常會將不同的業務邏輯分配到不同的線程組中。
為什么要做多線程：
模擬真實世界場景：在實際應用中，服務器通常需要同時處理來自多個用戶的請求。通過多線程，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等）的響應進行檢查
)
