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