一、引言
很多做性能測試的同學都問過我這樣一個問題：魚哥(Carl_奕然)，你說性能測試的重點是什麼?
我的回答很簡單：瓶頸分析與問題定位。
在性能項目的整個周期，不管是腳本設計，腳本編寫還是腳本執行，都還算簡單。
難點在于如何定位瓶頸，分析瓶頸，解決瓶頸。
如果你不會性能分析，腳本設計的再好，腳本編寫的再完美，分析不出問題所在，那都是白白浪費時間。
是以，這一講，我們來學習：如何進行性能分析，學會了性能分析的思路，才能定位問題，分析問題，進而解決問題。
在性能項目中，我總結的性能分析思路，分5個子產品，即性能分析5部曲，如下：
1、判斷性能瓶頸；
2、線程遞增政策；
3、性能衰減過程；
4、拆分響應時間；
5、建構分析決策tree；
接下來，我就對這5部曲進行一一解釋。
二、判斷性能瓶頸
在整個性能測試階段，讓性能測試工程師最艱難的，就是如何定位性能瓶頸。
如果無法定位到性能瓶頸，那麼對開發同學的支援也就有了限制，這無疑即增加了解決問題的時間，又增加了開發工程師的工作量。
這時候，你會說，開發工程師的職責不就是解決性能瓶頸嗎，
那要是這樣說， 測試工程師的職責，可不僅僅是發現性能瓶頸，還需要定位性能瓶頸，換句話說，也就是協助開發工程師快速定位并解決性能問題。
為什麼說在整個性能項目中，最難得就是分析性能瓶頸。
這裡，我先上一張圖，為了更形象的表現接下來要描述的内容，我把圖檔做了一點處理：
通過這張圖，我們很直覺的知道：這是一個階梯式增加的壓測場景。
但是，根據這個圖，你能判斷出拐點在哪裡嗎？
如果無法判斷哪裡是拐點，那我再上一張ResponseTime(後面簡稱為RT)圖：
同樣，為了讓你更直覺的檢視RT圖，， 我同樣也對RT圖做了優化處理。
結合RT圖與TSP圖，我們能不能判斷拐點在哪裡呢？
如果你覺得在3.3s的位置是拐點。我不能否認你說的完全錯誤，但是，我也不會認同你的觀點， 為什麼呢？
因為，根據多年的經驗，判斷的标準是：随着TPS的不斷增加，找到那個清晰可見的弧度。
這一點很重要，需要你記住。
我舉個例子：如果按照你剛剛的說法，隻根據一個拐點來進行判斷，想象一下，
假如網絡出現突然的抖動，按照你剛剛的判斷依據(隻根據一個拐點)，是不是就不準确了。。
是以，一定是找到那個 清晰可見的 弧度。
我們在回來說上面的TPS圖與RT圖，根據這兩個圖，你能得出哪些結論呢？
是不是可以得出這個系統有瓶頸，系統的瓶頸與壓力有關系，并且随着壓力的增加，漲幅在逐漸減少。
到這裡， 需要請你在思考一個問題：瓶頸點是否跟壓力的大小有關？
答案：肯定不是跟壓力大小有關。
既然不是跟壓力大小有關，那麼，根據什麼有關呢？
其實結合上面的圖， 我們可以知道：
①引起系統瓶頸的問題是有規律的；
②TPS是周期性的降低，并且最大的TPS也都差不多是一緻的；
是以，即使壓力降低，最多隻是降低最大的TPS水位，這種情況隻是讓問題出現的更晚一點，但不會不出現的。
……
由于作者版權要求，僅展示文章的一部分，如需閱讀完整版文章，可以私信回複”文章“即可免費擷取。
最後：
1）關注+私信回複：“測試”，可以免費領取一份10G軟體測試工程師面試寶典文檔資料。