背景介紹
- 相信很多測試項目上，很多都是身兼多職(既要做功能、自動化、性能啥都要做)；這次依據個人對壓測這塊的理解，分享一下壓測的思路。因爲個人以前對壓測有很多誤區，所以在此分享下避免繼續入坑(不喜勿噴，如果還有理解誤區求指點,我在來完善);
- 下面就講下入門級的愚見:1、壓力測試重點關注點是什麼？2、壓力測試怎麼做？
一、壓力測試重點關注點是什麼？
1.1、因爲看我以前的同事或者現在測試朋友們get不到重點，都是按照各公司現有的demo去做，用jmeter配置線程數去壓。最後都是說支持500併發、1000併發，把聚合報告的指標撈出來再給個結論；但其中的對應關係還是很茫然的。
1.2、先捋一下壓測的目的是什麼：壓測主要目的是結合當前服務資源以及當前環境配置基礎下，對應用接口在不同壓力場景下得出各指標結果是否滿足實際應用需求【所以要優化性能指標的話，除從應用接口的代碼邏輯和設計鏈路去優化的話，還需要結合環境的配置（例：連接數、隊列值、jvm配置等）以及本身的物理資源去出發；能調到最合理的、最充分的利用率那就是性能大咖了】；
1.3、對“併發”名詞說明：併發這個詞在項目中很容易混淆，所以在此先講解下這個詞;併發分爲相對併發和絕對併發；相對併發是指在一個時間段內發生的事務（可理解跟tps掛鉤），絕對併發是指在同一時刻發生的事情（可理解爲跟線程數掛鉤，jmeter的“集合點”功能可以實現這種方式）；以下講的併發都是依據絕對併發來說。
✔所以首先列下重點關注點，根據如下四點去判斷壓測是否達標通過:
1）、TPS指標:
2）、響應時間:
3）、出錯率:
4）、服務資源情況:
✔下述分享個樣例：
【測試結果】：
1）、TPS拐點峯值：依據壓測結果，在90併發時達到峯值（2277筆/s），而後續持續遞增併發數後TPS呈平穩趨勢，即保持峯值在2200左右；--【達到預期≥1557筆要求】
2）、接口響應時間指標((以負載併發截圖爲準)：依據tps峯值下進行併發，平均響應時間爲63.83ms,95%百分位響應時間爲92ms；--【達到預期≤100ms要求】
3）、出錯率：整個梯級壓測過程中出現0.29%異常情況，經覈查爲環境XXXX問題受影響，非業務邏輯或資源問題，即忽略此錯誤率；--【達到預期99.9%成功率要求】
4）、服務資源消耗：整體服務資源利用正常，內存及CPU利用平穩無異常情況；TPS下降時cpu正常對等下降，壓測結束後資源也可正常釋放；--【符合預期,詳見報告鏈接】
2.1、先說下TPS指標方面：
1）、TPS是主要是爲了測出拐點峯值，得出當前服務環境下最大的事務處理量（例如上述得出2277筆/s）；
2）、TPS峯值達標判斷：需要結合本身實際要求（例如上述-結合實際生產要求得出不小於1557筆），那我峯值已經覆蓋預期要求，那TPS指標就算滿足達標了；
3）、TPS峯值不滿足或者需要達到更佳情況下：就要考慮怎麼去調優了，主要方向：從業務代碼方面優化、服務配置的優化、再到物理資源的提升；
4）、額外說明：關於實際預期要求多少，這個是需要參考生產實際使用量有多少；目前普遍比較多的是有埋點功能，可以統計到調用量；再結合有一定參考價值的二八原則計算（指80%的業務量在20%的時間裏完成，另此公式不一定適合所有項目，具體需要結合每個系統項目應用場景）；
2.2、響應時間指標：
1）、需結合要求衡量取哪個響應時間，一般主要關注平均值和95%分位值；如果嚴謹一點的話可以以99%分位爲準(這樣情況下確保每個調用都能達標)；
2）、響應時間達標判斷：首先先知道指標要求是多少，一般可以從產品經理那給出或者下游調用方超時設置值爲參考，這些都算指標要求;另這塊一般都是和tps事務處理量 and 並行要求的(例如:上述相當於說在每秒tps不低於1557的時候,並且95%分位要小於100ms)；
2.3、出錯率：
1）、出錯率也是一個重點關注項，如果都異常了肯定是不可接受的；另對整體的指標可能要考慮是否有價值了，但這塊肯定需要結合異常情況去分析，在給出結論（如在壓測過程報錯，有些業務層面上認爲是合理的。但往往比較容易忽略，其實可能隱藏很大的性能問題）：
2）、注意點:當整體壓測下出現小部分概率異常，這個需要自身衡量下指標是否有價值，因爲那一小部分影響整體指標可能會很大(比如百分98都是在200毫秒左右，百分之二因爲異常5毫秒就響應了，導致整體指標影響很大)
2.4、服務資源消耗：
1）、服務資源主要關注施壓機(即請求方)和壓力機(被請求方)，施壓機需要確保自身環境資源夠滿足（避免因自身請求方機器原因無法滿足設置場景，導致未壓出真實指標）；
2）、服務資源利用情況常規的需要重點關注下cpu（例如是互聯網產品cpu使用率應該不能超50%，內部使用的一般80%；保證預期最大tps下，服務器還是很健康的）、內存（需要關注應用內存，如jvm的內存變化，只關注服務器內存意義不大），磁盤讀寫、網絡接收發送 -->>各資源消耗不合理的變化或者有較大的異常波動需要再結合分析；
3）、這塊服務監聽的工具還是很多的，jmeter插件的探針工具也有的，雖然不是很強大，勉強能用【插件下載1：jmeter-PerfMon服務監聽；服務資源探針2：Stepping Thread Group--提取碼：8888 】
二、壓力測試怎麼做?(以TPS爲例)
常規的壓測大家基本都會做，這裏講下另一種壓測方式，既通過梯度增壓方式去找出核心指標：TPS峯值
- 在jmeter中，可以利用【插件下載：Stepping Thread Group】來做到遞增壓測，直接在一次線程組中找出TPS峯值（詳解如下圖）
![]()
jmeter插件1.png
1.1、配置思路：
①、上述第一點-->最高併發值：可預估一個較高的併發值，確保在最高併發值內找出tps峯值（如果在此預估配置下未找到tps拐點，需設置更大值）；
②、上述第二點-->持續增壓（高度）：遞增的併發數值需要更準確一點的話，建議設置以最高併發值5-10%區間遞增（此處主要避免在遞增爬坡的時候出來了tps拐點峯值）；
③、上述第三點-->恆定併發量時間（長度）：此處的設置長度（即時長），如果確保要精確些可以設置時間久一點（這裏的設置時長：確保tps是趨向平穩狀態，如非平穩狀態需設置更長或者可能需要考慮其他因素）
1.2、TPS效果參考圖【插件下載：Transactions per Second】
①、確保已經到tps峯值判別：即tps是曲線是橫向狀態（停止繼續上升了）或者tps拐點往下走；
②、tps峯值橫向一段時間的解釋：到峯值時是在現狀資源環境下，可最大處理事務量；橫向是後續持續增加處於最大隊列內，此時段響應時間相對而言增加會更大（每個服務系統不一樣，具體需要對應分析）；
1.3、附上-響應時間插件【插件下載：ResponseTimesOverTime】
結尾語：
1)、未放更多實際已做的壓測場景和圖片（因爲涉及信息安全，你懂的），就直接用jmeter截些圖片做講解了；
2)、後續會持續更新，在繼續完善並且補充負載、穩定性方面的點.現先收收尾；
3)、此文章更多分享的是思路，主要對於入門級是怎麼設計去做壓測，而不至於直接茫然去壓；可能其中還有一些誤區，我在保持持續更新；
作者：迷糊的Test小白
鏈接：https://www.jianshu.com/p/7d09eb3d3bf0
來源：簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。