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