效能測試中的關聯，說簡單一點，就是把某些寫死（固定）的資料，通過引數化變成動態的資料；或者說把前面指令碼中的結果資料，提取出來作為後續指令碼的請求資料使用。

進一步理解關聯之前，我們簡單看一下請求-響應模型：

客戶端和伺服器的連線是基於一種請求-應答模式。在HTTP1.1協議中，客戶端和伺服器建立一個連線，客戶端提交一個請求，伺服器收到請求後返回一個響應，客戶端解析該響應資料後，根據該響應資料組織併發送請求，伺服器返回響應資料，直到交易完成。

基於請求-響應模型，我們再來看一下關聯：在錄製指令碼的時候，發出請求後，伺服器返回的響應中會給一個sessionId，在指令碼中後續的請求中也會基於這個“寫死的”sessionId資料繼續傳送請求；當腳本回放時，發出第一次請求後，伺服器返回新的sessionId值，接著在執行指令碼傳送第二次請求時，由於sessionId在指令碼中是寫死的，客戶端會依然以指令碼錄製時的sessionId發出請求，此時伺服器會返回異常響應。在這種場景中，就需要把“寫死”的sessionId提取為一個動態引數，在後續指令碼用到這個值時都用該動態引數替換。

那麼在HyperPacer工具中是怎麼達到關聯的呢？下面我們用一個簡單的例項來說明一下：

例子：某效能測試場景中，每個使用者登入業務系統，都會獲得一個sessionId，在一個虛擬使用者內，這個資料是不會發生變化的，更換使用者後，資料才發生變化。我們需要做的，是將sessionId這個資料提取為變數，引數化到後面的請求中。

HyperPacer中，關聯就是通過資料抽取器將某一資料定義成變數，再將指令碼中的所有相同資料都替換成變數，步驟如下：

1、指令碼錄製完成後，找到我們要進行關聯的資料，如圖：

說明：檢視響應資料，檢視的是錄製指令碼過程中產生的響應資料。

2、在取樣器下，建立資料提取器sid；

3、提取響應資料中的sessionId值；

資料提取器的具體設定，可以參見HyperPacer幫助文件，這裡不再贅述。

4、引數化後續的請求；

HyperPacer中引數化的寫法是${變數名}，本例中即為${sessionId},引數化之後為：

系統中需要引數化的資料比較多，推薦一個批量替換的方式，將所有的例項資料“6556957688931024897”替換為“${sessionId}”：

5、在HyperPacer工具中回放指令碼，指令碼執行通過即可。

明確了關聯在HyperPacer中的實現步驟後，我們來探討一下什麼時機使用關聯。很不幸的，並沒有一個明確的錯誤資訊標明指令碼中需要做關聯。一般情況下，回放指令碼的時候，執行有錯誤，有可能是需要做關聯的。我們判斷的標準是動態的、重複出現的且資料來自於響應的情況下，是需要做關聯的。

關於關聯，為了保證關聯提取資料的質量和穩定，我們規定以下幾條規範：

1、關聯應遵循“就遠原則”，即從服務端第一次返回該資訊的響應中提取資料。比如上面的例子中，如果指令碼中的響應資料多次出現sessionId，那麼應該用第一次響應的資料做關聯；

2、由於關聯的原理是通過字串匹配的方式進行資料提取，因此，作為判斷條件的邊界字串應該保證穩定，邊界字串本身不可以再包含動態資訊。

3、為了提高邊界字串匹配的效率，邊界字串的選擇應儘量簡短並儘可能保證提取的資料唯一性。實在無法做到唯一性，也要儘量保證提取的資料範圍最小。建議最多不超過5個，否則指令碼本身的正確性和效率都不能得到保證。

這裡給大家介紹的參考文章：


Jmeter關聯


原文出處