開頭
寫這篇文章的目的其實有2個：
1.總結自己的工作收獲工作中的經驗
2.也是應我離開公司後，測試小夥伴們的訴求，給他們一些指點吧（楊霞，雅潔，高巧，還有雪晴，希望此篇文章能給你們提供一些幫助，助你們在測試的道路上越走越好）
好了，廢話說了很多，回歸正題，性能測試的工具有很多，但是總體還是思路和設計主導，再帶入工具。此次我将依據工作中的實際場景，總結一下性能測試怎麼入手
分類
性能測試主要分為幾個大塊
1. 伺服器
2. 資料庫
3. 中間件
4. 負載均衡
以上是需要測試到的地方
伺服器與場景設計
計算TPS
任何系統都是需要人來使用的，那麼有一個比較通用的公式能夠很好的依據系統的預計使用壓力，來設計我們的場景
系統的壓力名額最直接的也就是TPS（系統吞吐量），按照二八原則，公式如下：
TPS=日交易次數*80%/（日開放的交易時間秒*20%）
舉個例子：一個系統每天業務請求有2百萬次，24小時開放。 那麼對應的TPS為：2000000*80%/（24*3600*20%）= 3.7 次/秒
如果對系統性能需求較為嚴苛，則可以遵循一九原則
設計場景
在知道系統吞吐量以後，可以開始設計實際使用場景
1）單交易目标TPS=腳本配置占比*總目标TPS
2）單交易并發使用者數=單交易目标TPS*ART
3）實際并發使用者數=單交易并發使用者數上取整
4）交易間隔時間=實際并發使用者數/單交易目标TPS
由此設計出單業務TPS，單交易并發使用者數，交易間隔時間。
場景運用
單交易最大壓力：
上面我們已經獲得了單業務的吞吐量，按照單業務的并發量開始加壓，壓力不能小于單業務的吞吐量，并試探伺服器的最大承受極限
伺服器最大資源門檻值達到系統最大處理能力時，為最大承受極限，最大tps和最大并發數依據最大處理能力填寫，運作時間為半小時到一小時
單交易穩定性：
單個請求保持最大壓力，持續12小時，測試系統穩定性
混合場景穩定性：
混合場景則按照計算的實際最大總吞吐量，按照百分比配置設定的單場景混合腳本運作，伺服器名額和單交易穩定性一緻
業務名額：
其中業務名額也需要考慮，如伺服器硬性名額和業務名額任何一項未達到，則不合格
至此，場景設計完成。
資料庫
資料庫壓力在性能測試中也至關重要，比如MySQL連接配接數，表的大小，insert和查詢時間速度等
就用MySQL為例
通過分析，在一定資料量下，針對資料庫的基本操作的時間不能超過上圖範圍
至于資料庫工具，大家可以用Jmeter提供的現成的JDBC來進行測試
當然如果基于python技術棧，也可以自己寫個時間方法，查詢方法來的更快更靈活，并且可通過matpoltlib繪制直覺的趨勢圖
同樣資料庫伺服器的系統資源同樣重要
中間件
中間件此處以Tomcat為例
其中JDBC連接配接等待數，線程繁忙率比較重要
JDBC連接配接等待數和繁忙率：http://ip:port/probe
通過tomcat的probe工具，放入webapp下，輸入對應的ip位址，對性能進行監控（此處不詳細介紹probe，自行查資料）
負載均衡：
負載均衡有很多工具，用的比較多的應該有nginx反向代理。
此處我們要關注的不是nginx怎麼配置與怎麼工作，很簡單，此處我們隻需要知道輸入和輸出，并且對比
在最大TPS下，使用伺服器性能監控工具（nmon等工具，自行查資料），對比多伺服器之間的cpu使用差異率即可
最後：
大體的性能測試入手與思路介紹完成，具體應該根據實際業務情況，使用環境和工具做進一步的詳細設計。
locust，sql性能等，完全可以自行寫适合公司的架構來進行性能測試（個人建議）
如要轉載，請注明出處
轉載于:https://www.cnblogs.com/grandlulu/p/10831340.html