有同學留言問我：如何得到精確的效能瓶頸？
相比於問我怎麼造測試資料，用什麼壓測工具監控工具的問題，我更喜歡這個問題。為什麼呢，因為在我的理解裡，工具的使用依然是入門難度，熟練使用哪個工具並不會改變效能測試這一技術實踐的最終結果，差別只是效率高低的問題。
而對於效能瓶頸的準確定義，反而會影響效能測試最終的結果，並對後續的效能最佳化驗證產生直接影響。
這篇文章，聊聊我對於效能瓶頸的理解和實踐經驗。
效能測試和功能測試在本質上沒有區別，大體的流程也沒差，無非是分析需求，準備用例、執行用例、確認BUG、跟進修複驗證，最終出具測試結果/報告。
兩者的不同點在於，側重不一樣：功能測試側重需求的正確實現，效能測試更注重系統的處理能力是否能支撐真實的使用者訪問。
在功能測試開展前，我們會分析需求，確認需求要實現的功能最終是什麼表現形式，以便於設計測試用例和預期結果，效能測試同樣如此。
在效能測試開展之前，依然要分析需求，確認預期的效能指標，即當系統達到什麼指標的情況下，可以支撐線上業務的使用者訪問，而效能瓶頸，對應的則是未達到預期效能指標。
網上充斥著太多的水文，講了太多錯誤的效能測試方法，荼毒了不少人。比如用高併發把伺服器資源使用率壓上去，直到服務掛了，這個時候的效能測試結果就是所謂的效能瓶頸；再比如當RT明顯上升和出現請求報錯時，就到效能瓶頸了。諸如此類，誤人子弟。
什麼是效能瓶頸？一句話概括：在給定條件下未達到預期效能指標，就是效能瓶頸。
需求：建立訂單場景，伺服器配置4C8G，預期效能指標是單機在CPU使用率40%以下時，TPS>200&99RT<200ms。這個時候的預期效能指標是什麼？
答案：單機CPU%<40%+TPS>200+99RT<200ms，這就是預期效能指標。
其中的給定條件，業務場景是建立訂單，伺服器配置是4C8G，環境配置是單機伺服器。
分析完需求後，接著該做什麼呢？按要求搭建壓測環境，根據建立訂單的業務場景準備對應的測試資料，然後找個壓測工具編寫指令碼，同時部署好監控，以便壓測時可以實時觀察效能指標的變化。
如果在給定條件下，效能表現符合預期指標，那就是不存在效能瓶頸。如果效能表現未達到預期指標，就出現其他問題，比如請求超時、報錯率較高、記憶體資源耗盡，則判斷存在效能瓶頸。
然後就是根據具體的問題具體分析，逐一排查，修復後再次進行壓測驗證，直至達到預期結果。
很多剛學習效能測試的同學都對效能測試有個誤解，那就是我一定要把伺服器資源壓滿，或者一定要讓它出現RT拐點才表明到了效能瓶頸，其實並不是這樣。
無論是功能測試還是效能測試，工作開展的前提一定是需求說明。透過需求分析確認測試場景，預期結果，然後針對性的設計測試用例，執行用例進行驗證。至於你是手動點點點還是利用工具自動執行，本質上對測試結果沒有影響。
當然，對於剛開始入門學習效能測試的同學來說，確實很容易犯一些基礎的常識性錯誤，如果有一定的專案實踐經驗，就會知道效能測試比我們想象的要複雜得多。
除了對技術的廣度和深度有一定要求之外，對業務的熟悉程度，對需求和場景的分析理解能力，甚至在壓測實施過程中的溝通和協調能力，也有較高的要求。