新人必看，測試大佬私藏的入門效能測試五步走，果斷收藏！
分享一個江湖小輩如何參透效能測試這本武功祕籍的心路歷程，適用於剛踏入效能測試江湖裡的小白，一起來一探究竟。
【開幕】武林祕籍驚現江湖在龐大的效能測試面前，我還是一個江湖小輩。然而在被YW大神領進門之後，效能測試中的變化莫測、十面埋伏、剛柔並濟、九九歸一，彷彿讓自己窺見了一門武林絕學，繼而心生敬畏之心。
LongLongAgo，聽過YW大神對效能測試方面的分享。那個時候就感覺眼前的這個男人不明覺厲，練就了一身武林絕學，是自己以後發展的榜樣。當時他還給我們展示了他的武林祕籍，是這樣的：
【第一幕】該不該預測一個初始值？
第一次真正接觸效能測試是在郵箱大師組，當時是要去對“郵件撤回”的介面進行效能測試，2017年6月25日接到任務，二話不說開始準備了起來。對jmeter速成之後，拿著wzprecall的指令碼就開始開壓。
那麼第一個問題來了：
我：我應該怎麼壓？我是說有沒有一個初始的值可以入手去壓？...
我：YW大神經驗豐富，是否可以預測出這個初始值？
YW大神：不能。
我：...
YW大神：如果我都預測出來了，那還需要效能測試做什麼？
我：哦...
YW大神：兩個方法：要麼和產品交流拿到實際的使用者量資料，要麼自己想辦法。
我：好嘞。
屁顛屁顛跑去找產品同學，在我的三寸不爛之舌以及一籮筐解釋下，產品同學終於聽懂了，但是回答是：我不知道，我真的不知道，我真的真的不知道。。。懷著複雜的心情我翻開了YW大神的武林祕籍第一頁，當時有這麼一張圖：
看著這本高深的武功祕籍開始發散性思維：
效能測試就像過山車，開始的慢速起步讓你緊張，中途的起起伏伏讓感覺很爽，最後戛然而止回到起點。
所以，效能測試中：
起步階段一定不要立馬就開始，而是需要一個逐步緩衝階段，這個時候就需要調整“Ramp-upPeriod”；這裡普及一下【Ramp-upPeriod】：Ramp-upPeriod用於告知JMeter要在多長時間內建立全部的執行緒。該資料預設值是0，表示JMeter將立即建立所有執行緒如上圖圖一。假設Ramp-upPeriod設定成T秒，全部執行緒數設定成N個，JMeter將每隔T/N秒建立一個執行緒。如上圖圖二。
這個車不知道能坐多少人的情況下，你不能無限制新增人員，否則造成事故就壞了。記錄你被“甩”的最爽的那段時光，因為那段時光是過山車最大的意義，隨後一切都是滿臉激動的淚水。在效能測試中可以將90%Line作為一個重要的參考資料。
經過初探武林祕籍形成練法心得之後，開始了自己的第一層修煉，資料如下：
看到圖中顯示的這麼多Error，發現第一次在沒有高人點撥的時候，很難參悟其中奧義。但是也習得一些武功心法：
1、在以上使用者量的情況下，這個效能是很差的；
2、知道了報告裡面欄位的意義：
1）#sample：這次測試任務中，一共發出了多少個請求
2）Average：單個request的平均響應時間
3）Median：50%使用者的響應時間
4）90%Line：90%的使用者一個請求的響應時間
還有Error和Throughtput以及最大、最小響應時間等。
我們這次指令碼中設定的超時時間也是8000ms，所以可以看到還是有一部分請求超時，才會導致最後請求失敗。
根據武俠小說的經驗得出，再這樣練下去肯定會走火入魔，當務之急需要YW大神指點一二，必能得其真傳。
【第二幕】從單執行緒開始
拿著上面粗糙的資料，我又去找了YW大神。
當時大神只問了一個問題，我立馬打道回府幹勁十足：“單執行緒的響應時間是多少？”
開始參悟：當沒有人坐過山車時，過山車肯定是不會開的。但是就算只有一個人坐過山車，一段時間內，也必須開車。（當然在國內不可能）。而本文的第一張圖可以看到，使用者量也是從0開始增長，而單執行緒（1個使用者）可以作為一個參考的基準。
上圖可以看到一個使用者的執行一次的響應時間，然後可以慢慢遞增。然後我將執行緒數逐漸增加的同時，有了以下的測試資料：
拿著上圖手中的測試資料，說不出來的感覺，早晨測試出使用者量在20~25之間似乎接近飽和，但是下午的資料基本是在30~40之間，帶著疑問我又來諮詢YW大神。
【第三幕】用命令列形式跑效能測試，然後觀察機器效能。
YW大神：你是在哪裡跑的？機器的cpu如何？記憶體怎樣？
我：...這些我有看的啊，在我本地機器跑的（順便隨手拿出了我的電腦記憶體和cpu資料）
YW大神：要在伺服器用jmeter命令列跑。
我：哦...
認真回去看了Jmeter官方文件，第一頁赫然寫到：欲練此功，必先...使用命令列！
Forloadtesting,youmustrunJMeterinthismode(WithouttheGUI)togettheoptimalresultsfromit.這裡對命令列格式的使用記錄如下：
例1：測試計劃與結果，都在%JMeter_Home%\bin目錄
>jmeter-n-t../scripts/wzprecall.jmx-lresult.jtl
例2：指定日誌路徑的：
>./jmeter-n-t../scripts/wzprecall.jmx-lreport-output\01-result.csv-jreport-output\01-result.log
【拓展】：
例3：預設分散式執行：
>jmeter-n-t../scripts/wzprecall.jmx-r-lreport-output\01-result.csv-jreport-output\01-result.log
例4：指定IP分散式執行：
>jmeter-n-t../scripts/wzprecall.jmx-R192.168.10.25:1036-lreport-output\01-result.csv-jreport-output\01-result.log
測試資料以及分析：
資料中看到：使用者量在30到40之間基本飽和，withdrawQuery請求吞吐量基本在16.5/s。
測試資料看起來已經有點樣子也得到了結果，拿著資料我找了YW大神。
【第四幕】控制吞吐！控制吞吐！控制吞吐！
YW大神：吞吐20都不到，這個是不可能的。
我：...
YW大神：注意控制吞吐！
測了這麼多的資料，發現很多時候的步驟都是自己不斷嘗試不同的執行緒數，在有很多未知的情況下去試探，這種方法耗時耗力，而且最後得到的資料並不能說明問題。那麼另一種方法就是完全通過定時器來控制QPS，這就類似於控制變數法，將吞吐控制之後，如果實際的吞吐達到限制的吞吐表示現在效能合理，且有上升空間，如果隨著執行緒數的增加限制的吞吐和實際吞吐差別很大，那麼恭喜你，你找到了這個介面效能的天花板中的一板。Jmeter提供了一個非常有用的定時器，稱為ConstantThroughputTimer（常數吞吐量定時器），該定時器可以方便地控制給定的取樣器傳送請求的吞吐量。
Targetthroughput（insamplesperminute）：目標吞吐量。注意這裡是每分鐘傳送的請求數。20QPS，這裡的值應該是1200。
CalculateThroughputbasedon：有5個選項，分別是：
Thisthreadonly：控制每個執行緒的吞吐量，選擇這種模式時，總的吞吐量為設定的targetThroughput乘以該執行緒的數量。
Allactivethreads：設定的targetThroughput將分配在每個活躍執行緒上，每個活躍執行緒在上一次執行結束後等待合理的時間後再次執行。活躍執行緒指同一時刻同時執行的執行緒。
Allactivethreadsincurrentthreadgroup：設定的targetThroughput將分配在當前執行緒組的每一個活躍執行緒上，當測試計劃中只有一個執行緒組時，該選項和Allactivethreads選項的效果完全相同。
Allactivethreads（shared）：與Allactivethreads的選項基本相同，唯一的區別是，每個活躍執行緒都會在所有活躍執行緒上一次執行結束後等待合理的時間後再次執行。
Allcativethreadsincurrentthreadgroup（shared）：與Allactivethreadsincurrentthreadgroup基本相同，唯一的區別是，每個活躍執行緒都會在所有活躍執行緒的上一次執行結束後等待合理的時間後再次執行。
在控制吞吐之後，得到的資料有模有樣：
【第五幕】武林祕籍重現江湖！
手捧著資料，回到了YW大神身邊，YW大神語重心長的說：在我的武功祕籍裡，不對，在我的ppt裡有一張performancecurve。
你的結果能對的上performancecurve，你就能明白一些結果了。
一切彷彿又回到了起點，只是世界變得安靜了。靜靜地翻看這本祕籍，我想我有點懂了。
總結：
使用者量為40的時候，平均響應時間基本在400ms左右，此時吞吐量在1500/min（25/s），吞吐量還在上升階段。
使用者量到55~65階段，吞吐量基本達到峰值2076/min（34.6/s），使用者量在65的時候，響應時間開始快速上升。
使用者量在70+以後，吞吐量急速下降，相應的響應時間也在75的時候達到了1000ms+左右。
通過以上評估，壓力<=40階段，為lightload階段，壓力在40~50之間比較理想飽和階段，50~65之間伺服器heavyload階段。
當用戶>70的時候，為buckleZone階段。
歡迎加入 51軟體測試大家庭，在這裡你將獲得【最新行業資訊】，【免費測試工具安裝包】，【軟體測試技術乾貨】，【面試求職技巧】... 51與你共同學習，一起成長！期待你的加入： QQ 群： 755431660