1.寶路說

寶路最近一直在自我思考：性能基準DevOps工作已經開展一段時間了，目前我們確實已經取得了一些成果，顯然這還遠遠不夠。趁閑暇之餘跟組員進行了簡單的頭腦風暴！於是這就有了今天的主題，當然這僅是主題之一，後面會繼續分享其他主題。

2.背景說明

隨著測試環境DevOps工作的不斷開展，業務場景覆蓋率不斷擴增，涉及的介面數量也是成倍的增長，據統計目前介面數量已近兩百。

在實施過程中，我們愈發明顯的發現，執行一次全場景耗時明顯增長，腳本執行時間越長出現不穩定因素的幾率就越大，嚴重可能導致郵件報告可信度降低，如何提升腳本執行效率成了目前需要重點解決的問題。

在組員電腦上用JMeter的GUI模式打開腳本一看，嚇一跳，只見N多個事務控制，密密麻麻的！都用上滑鼠滾輪了。。。

腳本結構如圖：

後面還有N多個場景未列出來，從圖明顯可以看出，隨著業務場景的增加，腳本肯定執行時間越長。

如置之不理，久而久之，情況只會越來越糟糕。

就如何提升腳本執行效率，我們也是自由發言的討論，討論可行方案如下：

方案一：將目前腳本進行拆解，形成多個壓測腳本

該方案確實可行，但無疑付出的時間成本太高，就簡單的拆解腳本來說工作量確實不大。拆解成多腳本（多測試計劃）運行，也就意味著會產出多個測試報告。目前平台還不具備多報告合併功能，還要重新開發。

不合併多個報告，那麼無疑在郵件通知報告中要增加多個動態報告鏈接方便收件人查看更詳細的報告數據（聚合數據、吞吐量曲線）等，三四個連接我還能忍受。。。一下放那麼多報告鏈接，誰還有心情去點呢。。。

有的同學可能會想想到，放幾個重點報告鏈接不就行了么。此方式確實可行，但還不能滿足我們目前的要求，重點業務場景也很多，我們最終還是想讓相關人員全方位的看到介面實時性能情況。

顯然此方案不是最優解。

方案二：將目前腳本進行「拆解」，多執行緒組模式

此方案是在方案一的基礎上進行在調整，將原始的單一執行緒組改成多執行緒組模式。這樣扔保持一個測試計劃，也就是說最終扔是一個報告。

腳本結構如圖：

我們目前在做基準測試場景，是單執行緒組單線執行緒執行。腳本按多執行緒組改造後將成倍縮短場景執行時間。

舉個簡單的例子：起初一個包工頭指派一個工人去完成某個項目工程，但是這種工作模式顯然效率不高，於是又指派好幾個工人同時加入到項目工程中同時還依照工人技能不同對工作進行了分工。

那麼問題來了，執行緒組該怎麼進行分工呢？我們目前的解決方案：業務場景+測試數據組合分工模式。按業務場景來分，這個大家都還可以理解，怎麼還來個按測試數據分，這是？

歸根結底還是業務場景的「鍋」，有些場景那就是需要特殊用戶數據才能正常執行。進而我們決定採用業務場景+測試數據組合分工模式。

關於壓測腳本，還是再多啰嗦幾句：

腳本結構不要搞的太複雜。
要求高性能的話，盡量少用前置、後置處理器，如果必須要用的話裡面的程式碼不搞的很複雜。
請求報文涉及到加解密，最優解還是訂製開發Sampler取樣器，這樣測試人員不用花更多的時間去關注加解密程式碼及相關流程，測試人員編寫腳本僅需填寫伺服器地址相關資訊、請求明文，這樣編寫腳本效率也會質的提升。