最近找我諮詢效能測試問題的同學挺多，見識了不少案例，發現很多同學對效能測試依然存在很多理解的誤區，即使是一些在測試崗位工作多年的資深工程師，依然存在這種情況。
市場上關於效能測試的專業書籍不少，專業的課程和免費的學習資料以及技術文章也有不少乾貨，但部分同學依然是從來不主動學習，遇到問題才想起來臨時抱佛腳，這樣其實對技術提升不怎麼友好。
效能測試，說簡單也簡單，因為實施效能測試的方法和流程和正常的功能測試沒太多區別。說難也難，因為要想正確的開展效能測試並達到目標，對技術廣度和深度都有一定的要求。
這篇文章，我會列舉一些常見的理解誤區，並對此做出解釋，希望能對測試同學們有所幫助。
誤區一、效能測試就是工具+高併發
這是很多初學者最容易犯的一個錯誤，認為效能測試就是找個工具模擬高併發，不斷加壓然後看監控統計結果，其實不然。
舉一個在技術交流群看到的例子：單介面呼叫沒問題，用JMeter除錯系統返回code:500。遇到這個問題該如何處理呢？
一般來說，當請求響應返回的狀態碼為500時，可以判斷請求是通的，只是返回的響應體不是我們預期的結果。這個時候可以從這兩點出發來分析問題：
1、檢視被測服務日誌，看詳細的請求和響應資訊，以及報錯的堆疊資訊。
2、對比單介面除錯的請求內容和用JMeter組裝的請求內容，是否存在差異。
為什麼要對比JMeter的請求內容呢？因為它模擬請求的原理，是自己定義請求頭和請求的body主體，和postman等測試工具還是存在一定差異的，很多時候就是因為些許差異導致請求失敗。
對於效能測試的初學者，我建議在學習壓測工具之前，先對網路協議如HTTP/TCP協議有一定的瞭解，否則只是學習壓測工具的使用方法，很容易被卡在效能測試的門檻之外。
誤區二、效能瓶頸一定要壓到資源耗盡
即使是對效能測試有一定實踐經驗的測試同學來說，這個誤區依然是錯誤高發區。
前幾天有同學告訴我，他每次壓測都要壓到伺服器資源耗盡才認為到了瓶頸，但有時候會發現資源使用率不高但已經壓不上去，RT不斷增高的現象，很困惑。原因就是走入瞭如副標題所述的誤區。
所謂的效能瓶頸，是沒有定量標準的，是否存在效能瓶頸，取決於效能目標如何定義。比如某個業務，希望能支撐200併發，並且響應時間不能超過50ms，這個時候如何判斷是否存在效能瓶頸呢？
從需求的角度來看，透過壓測並監控觀測，是否能達到預期的指標。從技術的角度來看，還要考慮系統穩定性以及系統效能的冗餘能力，那就加上成功率99.99%和CPU%<40%。
合併一下，效能指標就是：TPS>200，99RT<50ms，請求成功率>99.99%，CPU使用率<40%。只要壓測監控到的效能表現滿足這些要求，就可以認為滿足效能預期，不存在效能瓶頸，否則就要針對性分析定位和最佳化。
所謂效能瓶頸，是沒達到效能預期指標，而壓測監控到的諸如TPS之類的技術指標，只是反映了系統當前的效能表現，這是現象，不是瓶頸。
除了上述兩個測試同學的理解誤區之外，效能測試對技術的廣度和深度都有一定要求。
首先，你要對被測系統和請求鏈路很熟悉，這就要求你熟知被測系統的系統架構和請求呼叫關係；其次，要對業務有很深入的理解，並且和業務以及研發團隊有良好的溝通，這樣才能得到比較明確的效能指標。
最後，還要對常見的各種中介軟體如Redis/MQ比較瞭解，且對網路協議和作業系統有基本的瞭解，否則請求報錯檢視日誌都搞不定，就很難將效能測試工作開展下去。
再擴充套件來說，效能測試是很吃經驗的，很多所謂的效能瓶頸其實並不難定位，但經驗的價值就在於可以讓你快速篩選出大機率存在問題的部分，並且快速驗證和最佳化。
對新手來說，打好技術基礎，熟練掌握工具使用，深入理解業務，再找到好的效能測試資料深讀，就能快速掌握效能測試並應對大多數日常的效能測試工作。