更多軟件測試學習資料戳！??！

在完成JMeter測試腳本執(zhí)行后，首先要做的就是判斷收集到的測試數(shù)據(jù)是否真實有效。實際性能測試中有很多情況會導致測試數(shù)據(jù)失效，例如，運行JMeter的機器性能存在瓶頸、網(wǎng)絡(luò)擁塞，甚至于測試腳本本身設(shè)計存在問題，等等，對無效的測試數(shù)據(jù)進行分析，純粹是浪費時間。那么該如何判斷測試數(shù)據(jù)是否有效呢？

（1）分析在整個性能測試執(zhí)行期間，測試環(huán)境是否穩(wěn)定正常。如果測試環(huán)境在性能測試執(zhí)行過程中出現(xiàn)過異常，那么測試數(shù)據(jù)就會受到“污染”，由此得到的分析結(jié)果也變得毫無價值。

例如，測試期間運行JMeter的機器CPU占用率經(jīng)常達到100%（或者內(nèi)存占用很高）、測試網(wǎng)絡(luò)出現(xiàn)擁塞導致響應(yīng)延遲、待測系統(tǒng)參數(shù)配置錯誤（JDBC連接池等）......

（2）檢查JMeter測試腳本參數(shù)設(shè)置是否合理，檢查JMeter運行模式是否合理。JMeter測試腳本參數(shù)的設(shè)置非常重要，它會直接影響測試數(shù)據(jù)的準確性。例如，有初學者經(jīng)常將線程組的參數(shù)Ramp-Up Period(in seconds)設(shè)置為0或者1。如此一來，JMeter就會瞬間啟動該線程組下的全部虛擬用戶，會為待測服務(wù)器施加巨大的壓力。輕則導致服務(wù)器響應(yīng)時長超長，重則導致部分虛擬用戶等待響應(yīng)超時而報錯。正確的做法應(yīng)該是逐步加壓，而不是瞬間達到目標壓力。另外初學者還容易犯的一個錯誤，就是以GUI模式運行大量并發(fā)測試。相對于費GUI模式而言，GUI模式對機器CPU和內(nèi)存的占用會高得多。對于大并發(fā)量測試，最好采用非GUI模式。

（3）檢查測試結(jié)果是否暴露出了系統(tǒng)瓶頸。沒有必要在一切正常的測試結(jié)果上糾纏不止，應(yīng)該重點關(guān)注異常的測試結(jié)果。如果測試結(jié)果顯示一切正常，那么首先要考慮的是并發(fā)用戶數(shù)是否足夠多，對待測服務(wù)器施加的壓力是否足夠大。另外還需要考慮，待測系統(tǒng)是否存在什么機制屏蔽掉了大部分壓力，例如，禁止同一個用戶多次執(zhí)行某項操作，或者多次查詢同一組數(shù)據(jù)時使用緩存技術(shù)。對于這類情況，需要理清實際情況多加分析，以避免漏掉本該發(fā)現(xiàn)的性能測試缺陷。

確定測試結(jié)果有效后，接下來就需要對待測試數(shù)據(jù)進行深入分析了。而面對龐雜的原始數(shù)據(jù)，該如何進行分析呢？

如圖12-1所示。

對一個軟件應(yīng)用系統(tǒng)而言，最終用戶不會去關(guān)心系統(tǒng)的內(nèi)部架構(gòu)、技術(shù)實現(xiàn)等內(nèi)部細節(jié)，他們只關(guān)心系統(tǒng)是否正確，是否響應(yīng)及時。而且當系統(tǒng)出現(xiàn)性能下降時，最直觀的表現(xiàn)就是響應(yīng)時長邊長。因此應(yīng)該首先從原始測試數(shù)據(jù)中查看系統(tǒng)響應(yīng)時長，判斷它是否滿足用戶的期望，以此作為性能分析的起點。如果系統(tǒng)響應(yīng)時長不滿足用戶期望，則說明系統(tǒng)的性能出了問題。發(fā)現(xiàn)系統(tǒng)存在性能問題后，就需要進一步分析那個環(huán)節(jié)出了問題。

目前的企業(yè)級B/S架構(gòu)應(yīng)用系統(tǒng)的架構(gòu)頗為復雜，甚至存在不同企業(yè)的架構(gòu)體系大不一樣的情況。不過萬變不離其宗，不同B/S架構(gòu)應(yīng)用系統(tǒng)的基本構(gòu)成還是相似的。

如圖12-2所示為B/S架構(gòu)應(yīng)用系統(tǒng)的基本構(gòu)成。從圖中可以看出，用戶從客戶端發(fā)出的請求數(shù)據(jù)包經(jīng)網(wǎng)絡(luò)到達應(yīng)用服務(wù)器，在由應(yīng)用服務(wù)器處理后轉(zhuǎn)交數(shù)據(jù)庫處理，最終響應(yīng)結(jié)果由原路返回。在整個處理過程中，可以吧響應(yīng)時長分為兩段：一段是Ts，即服務(wù)器響應(yīng)時長，包括應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器的響應(yīng)時長；另一段是Tn，即網(wǎng)絡(luò)響應(yīng)時長。

JMeter是開源性能測試工具，自然也無法如LoadRunner一般設(shè)計得非常完備，JMeter工具本身無法區(qū)分Ts和Tn，它只能統(tǒng)計總響應(yīng)時長。不過測試人員可以用其他辦法來加以區(qū)分，例如，使用最簡單的ping收獲Tn，再用響應(yīng)時長減去Tn即可得到Ts。此刻，我們已經(jīng)將響應(yīng)時長分成了兩部分，當然也就能將問題細分成兩種網(wǎng)絡(luò)瓶頸問題和服務(wù)器瓶頸問題。

接下來還需要對服務(wù)器瓶頸問題進一步細分為：應(yīng)用服務(wù)器瓶頸問題和數(shù)據(jù)庫服務(wù)器響應(yīng)問題。要進一步分析問題根源，需要動態(tài)監(jiān)視應(yīng)用服務(wù)器和數(shù)據(jù)服務(wù)器。