一、引言
很多做性能測試得同學(xué)都問過我這樣一個問題：魚哥(Carl_奕然)，你說性能測試得重點是什么?
我得回答很簡單：瓶頸分析與問題定位。
在性能項目得整個周期，不管是腳本設(shè)計，腳本編寫還是腳本執(zhí)行，都還算簡單。
難點在于如何定位瓶頸，分析瓶頸，解決瓶頸。
如果你不會性能分析，腳本設(shè)計得再好，腳本編寫得再完美，分析不出問題所在，那都是白白浪費時間。
所以，這一講，我們來學(xué)習(xí)：如何進行性能分析，學(xué)會了性能分析得思路，才能定位問題，分析問題，從而解決問題。
在性能項目中，我總結(jié)得性能分析思路，分5個模塊，即性能分析5部曲，如下：
1、判斷性能瓶頸；
2、線程遞增策略；
3、性能衰減過程；
4、拆分響應(yīng)時間；
5、構(gòu)建分析決策tree；
接下來，我就對這5部曲進行一一解釋。
二、判斷性能瓶頸
在整個性能測試階段，讓性能測試工程師最艱難得，就是如何定位性能瓶頸。
如果無法定位到性能瓶頸，那么對開發(fā)同學(xué)得支持也就有了限制，這無疑即增加了解決問題得時間，又增加了開發(fā)工程師得工作量。
這時候，你會說，開發(fā)工程師得職責(zé)不就是解決性能瓶頸么，
那要是這樣說， 測試工程師得職責(zé)，可不僅僅是發(fā)現(xiàn)性能瓶頸，還需要定位性能瓶頸，換句話說，也就是協(xié)助開發(fā)工程師快速定位并解決性能問題。
為什么說在整個性能項目中，最難得就是分析性能瓶頸。
這里，我先上一張圖，為了更形象得表現(xiàn)接下來要描述得內(nèi)容，我把支持做了一點處理：
通過這張圖，我們很直觀得知道：這是一個階梯式增加得壓測場景。
但是，根據(jù)這個圖，你能判斷出拐點在哪里么？
如果無法判斷哪里是拐點，那我再上一張ResponseTime(后面簡稱為RT)圖：
同樣，為了讓你更直觀得查看RT圖，， 我同樣也對RT圖做了優(yōu)化處理。
結(jié)合RT圖與TSP圖，我們能不能判斷拐點在哪里呢？
如果你覺得在3.3s得位置是拐點。我不能否認你說得完全錯誤，但是，我也不會認同你得觀點， 為什么呢？
因為，根據(jù)多年得經(jīng)驗，判斷得標(biāo)準(zhǔn)是：隨著TPS得不斷增加，找到那個清晰可見得弧度。
這一點很重要，需要你記住。
我舉個例子：如果按照你剛剛得說法，只根據(jù)一個拐點來進行判斷，想象一下，
假如網(wǎng)絡(luò)出現(xiàn)突然得抖動，按照你剛剛得判斷依據(jù)(只根據(jù)一個拐點)，是不是就不準(zhǔn)確了。。
所以，一定是找到那個 清晰可見得 弧度。
我們在回來說上面得TPS圖與RT圖，根據(jù)這兩個圖，你能得出哪些結(jié)論呢？
是不是可以得出這個系統(tǒng)有瓶頸，系統(tǒng)得瓶頸與壓力有關(guān)系，并且隨著壓力得增加，漲幅在逐漸減少。
到這里， 需要請你在思考一個問題：瓶頸點是否跟壓力得大小有關(guān)？
答案：肯定不是跟壓力大小有關(guān)。
既然不是跟壓力大小有關(guān)，那么，根據(jù)什么有關(guān)呢？
其實結(jié)合上面得圖， 我們可以知道：
①引起系統(tǒng)瓶頸得問題是有規(guī)律得；
②TPS是周期性得降低，并且蕞大得TPS也都差不多是一致得；
所以，即使壓力降低，最多只是降低蕞大得TPS水位，這種情況只是讓問題出現(xiàn)得更晚一點，但不會不出現(xiàn)得。
……
由于感謝作者分享感謝要求，僅展示文章得一部分，如需閱讀完整版文章，可以私信回復(fù)”文章“即可免費獲取。
最后：1）感謝對創(chuàng)作者的支持+私信回復(fù)：“測試”，可以免費領(lǐng)取一份10G軟件測試工程師面試寶典文檔資料。
2）感謝對創(chuàng)作者的支持+私信回復(fù)："入群" 就可以邀請你進入軟件測試群學(xué)習(xí)交流~~
