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