1.寶路說
寶路最近一直在自我思考：性能基準DevOps工作已經開展一段時間了，目前我們確實已經取得了一些成果，顯然這還遠遠不夠。趁閒暇之餘跟組員進行了簡單的頭腦風暴！於是這就有了今天的主題，當然這僅是主題之一，後面會繼續分享其他主題。
2.背景說明
隨着測試環境DevOps工作的不斷開展，業務場景覆蓋率不斷擴增，涉及的接口數量也是成倍的增長，據統計目前接口數量已近兩百。
在實施過程中，我們愈發明顯的發現，執行一次全場景耗時明顯增長，腳本執行時間越長出現不穩定因素的機率就越大，嚴重可能導致郵件報告可信度降低，如何提升腳本執行效率成了目前需要重點解決的問題。
3.現狀分析
在組員電腦上用JMeter的GUI模式打開腳本一看，嚇一跳，只見N多個事務控制，密密麻麻的！都用上鼠標滾輪了。。。
腳本結構如圖：
後面還有N多個場景未列出來，從圖明顯可以看出，隨着業務場景的增加，腳本肯定執行時間越長。
如置之不理，久而久之，情況只會越來越糟糕。
4.頭腦風暴
就如何提升腳本執行效率，我們也是自由發言的討論，討論可行方案如下：
方案一：將目前腳本進行拆解，形成多個壓測腳本
該方案確實可行，但無疑付出的時間成本太高，就簡單的拆解腳本來說工作量確實不大。拆解成多腳本（多測試計劃）運行，也就意味着會產出多個測試報告。目前平臺還不具備多報告合併功能，還要重新開發。
不合並多個報告，那麼無疑在郵件通知報告中要增加多個動態報告鏈接 方便收件人查看更詳細的報告數據（聚合數據、吞吐量曲線）等，三四個連接我還能忍受。。。一下放那麼多報告鏈接，誰還有心情去點呢。。。
有的同學可能會想想到，放幾個重點報告鏈接不就行了麼。此方式確實可行，但還不能滿足我們目前的要求，重點業務場景也很多，我們最終還是想讓相關人員全方位的看到接口實時性能情況。
顯然此方案不是最優解。
方案二：將目前腳本進行“拆解”，多線程組模式
此方案是在方案一的基礎上進行在調整，將原始的單一線程組改成多線程組模式。這樣扔保持一個測試計劃，也就是說最終扔是一個報告。
腳本結構如圖：
我們目前在做基準測試場景，是單線程組單線線程執行。腳本按多線程組改造後將成倍縮短場景執行時間。
舉個簡單的例子：起初一個包工頭指派一個工人去完成某個項目工程，但是這種工作模式顯然效率不高，於是又指派好幾個工人同時加入到項目工程中同時還依照工人技能不同對工作進行了分工。
那麼問題來了，線程組該怎麼進行分工呢？我們目前的解決方案：業務場景+測試數據 組合分工模式。按業務場景來分，這個大家都還可以理解，怎麼還來個按測試數據分，這是？
歸根結底還是業務場景的“鍋”，有些場景那就是需要特殊用戶數據才能正常執行。進而我們決定採用業務場景+測試數據 組合分工模式。
5.其他建議
關於壓測腳本，還是再多囉嗦幾句：
- 腳本結構不要搞的太複雜。
- 要求高性能的話，儘量少用前置、後置處理器，如果必須要用的話裏面的代碼不搞的很複雜。
- 請求報文涉及到加解密，最優解還是定製開發Sampler採樣器，這樣測試人員不用花更多的時間去關注加解密代碼及相關流程，測試人員編寫腳本僅需填寫服務器地址相關信息、請求明文，這樣編寫腳本效率也會質的提升。