對於全鏈路壓測和非全鏈路壓測，以上步驟實施起來在效能測試執行環節區別較大，本文主要講述全鏈路效能測試執行環節與傳統壓測的區別，以及對應的壓測平臺改造點

1.傳統壓測jmeter工具施壓是基於併發執行緒數來控制壓力大小的，且併發執行緒數只是一個增加壓力的手段，實際TPS的大小取決於被壓測系統的效能（jmeter是同步阻塞式IO壓力模式，同一併發執行緒只有當一次請求接收到響應後才會繼續下一次請求發起），換句話說，調整併發執行緒數時不知道TPS實際能夠達到多少。全鏈路壓測如果也是這種模式去施加壓力，對系統的壓力會是多少是未知的，這個過程中被壓測系統穩定性就會存在極大風險，所以全鏈路壓測平臺有必要對壓力發起模式做出改造，讓效能測試工程師明確知道施加了多大的TPS，這也會讓系統被壓掛的可能性極大降低。

2.傳統壓測為了測出系統性能極限，會設定一個梯度增加併發執行緒數的容量測試場景，這種設定需要經過試壓，而且梯度加壓過程中如果發現效能表現不及預期，需要停掉壓測後再去調整併發執行緒數、步長、梯度等，傳統壓測這種方式是沒問題的，但如果在全鏈路壓測中就比較反人類了，這就需要壓測平臺進行改造，讓壓力可隨時調整，且該調整不會影響當前已經存在的壓力。

3.傳統壓測在上下游介面有資料依賴的環節，往往會通過工具本身具備的關聯功能去關聯到值並引用賦值來實現，這種實現方式在全鏈路壓測中不太適用，一方面使用關聯就必須上下游介面TPS是一致的，另一方面全鏈路壓測涉及到介面、鏈路環節眾多，一條資料進入系統，有可能跨越了時空（時間上，某個介面的資料，下游介面需要處理，但不一定是立即需要處理，有多種非同步情況，比如MQ、JOB；空間上，某個介面的資料在A資料庫中存在，也可能在B資料庫中存在，AB是兩個不同的物理節點）。舉一個物流行業的例子，你的快遞訂單下單後會有快遞員過來接貨然後給你開單接著是運輸中轉、派送、簽收、結算、軌跡查詢環節，一筆快遞訂單是不可能在一秒內或者短時間內就完成了這些流程，所以對應全鏈路壓測中的上下游鏈路資料有關聯的需要藉助資料回傳工具以及池化技術來實現，壓測平臺需要進行此類改造。

4.傳統壓測大部分是壓力機部署在內網環境中，全鏈路壓測為了模擬真實使用者的網路鏈路，壓力機需要放到外網環境中，壓測平臺需要進行此類改造以及防火牆策略放行，這樣可以測試出企業入口網路流量是否有瓶頸也可以測試出一些安全高防產品是否有功能或者效能上的缺陷。

5.傳統壓測可能一個產品線就一個介面或者幾個核心介面，且產品線或者介面之間聯絡較少。全鏈路壓測中是基於N個產品線幾十個或者上百個核心介面，對於這些介面之間的壓力發起統籌、拓撲繪製，資料流轉，效能表現需要有一個全域性性的駕駛艙來操作和觀察，壓測平臺需要進行基於此的改造。

6.傳統壓測所使用的的一般是測試環境，或者灰度環境或者生產環境只讀壓測，這些環境一定程度上均存在減配，不真實，覆蓋面小的情況。全鏈路壓測應該在生產環境進行，不僅在成本上有優勢，而且在真實性上也比其他環境高不少，壓測平臺應該對接生產環境並進行網路打通。

轉自https://www.modb.pro/db/194397

本文來自部落格園，作者：up~up，轉載請註明原文連結：https://www.cnblogs.com/soft-engineer/p/15923506.html