Web系統的性能測試技術研究

張輝

摘要： 為保證網絡服務質量，對Web系統進行性能測試，成為企業在軟件測試工作中重要的環節。從Web體系的架構及特點出發，對Web系統性能測試的要求、場景、指標、流程、策略以及測試用例設計等內容進行分析，研究性能測試的方法，采用測試工具JMeter進行了Web系統的性能測試。結果表明，對Web系統進行性能測試有助于找出系統中存在的問題，為系統進一步優化提供依據。

關鍵詞： 性能測試; Web系統; 軟件測試; JMeter

中圖分類號：TP3? ? ? ? ? 文獻標識碼：A? ? ?文章編號：1006-8228（2021）10-28-04

Research on performance testing technology of Web system

Zhang Hui

（Gaobo School of software， Nanning University， Nanning， Guangxi 530001， China）

Absrtact： In order to ensure the quality of network service， the performance test of Web system has become an important part in the software testing work of enterprises. Starting from the architecture and characteristics of the Web system， this paper analyzes the requirements， scenarios， indicators， processes， strategies and test case design etc. of the Web system performance test， studies the testing methods， and carries on the performance testing to Web system by using the test tool JMeter. The results show that the performance test of web system is helpful to find out the problems existed in the system and provides a basis for further optimization of the system.

Key words： performance test; Web system; software testing; JMeter

0 引言

隨著Web服務的發展，網絡用戶數量日漸增多，用戶與系統產生的交互場景及軟件產生的數據量也日益增加，Web服務器必須能夠快速響應用戶請求。為了及時解決Web系統所面臨的問題，利用性能測試技術對系統進行有效測試，以分析系統是否滿足用戶對軟件在功能和性能上的需求，驗證系統的各項性能指標是否達到用戶的目標，以便于發現系統存在的瓶頸。

1 Web體系架構

由于Web系統是分布式系統，采用并發、多用戶結構，Web系統使用的用戶數量更高，受眾群體更廣。Web系統采用多層體系構架，系統只需根據計算機瀏覽器，就可以實現軟件的功能。Web系統主要采用表示層、業務邏輯層、數據訪問層三層架構。三層架構的操作界面主要由計算機瀏覽器來實現完成，一部分事務管理邏輯在前端完成，關鍵事務管理邏輯性則在服務端完成。

三層架構執行嚴格的分層方式，數據訪問層只有被業務邏輯層訪問，業務邏輯層只有被網頁顯示層訪問，用戶根據表示層將信息傳輸給業務邏輯層，業務邏輯層進行處理有關業務流程標準，并根據數據訪問層訪問數據庫查詢得到數據信息，然后將反饋回來的數據在頁面顯示層進行顯示輸出[1]。三層設計目的是實現高內聚和低耦合。

2 Web性能測試

2.1 性能測試定義

Web性能測試是指在一定的軟硬件網絡環境下，通過模擬特定的網絡環境，對Web系統進行針對性測試，在服務器正常響應時間內，設置不同的負載壓力，查看系統可以承擔的并發用戶的數量，檢測進行實務處理的效率，觀察系統指標和空間資源是否達到預期標準，判斷系統瓶頸可能發生的位置，如果Web系統測試未達到預期，需對結果指標進行分析，為軟件調優提供解決方案。

2.2 性能測試模擬場景

性能測試模擬場景主要有以下三個方面。

⑴ 基于網絡的分布式架構：基于網絡協議去模擬用戶發送請求。

⑵ 多線程：模擬多線程操作，多用戶同時操作，模擬大負載量。

⑶ 模擬真實場景：在真實的網絡環境，得出的數據才是準確的。如果場景設置不符合實際情況，測試數據也不一定可用。

2.3 性能測試的要求

⑴ 測試Web系統的最佳用戶數。隨著用戶數量的增多系統的響應時間并沒有受到影響，但是直到達到某個用戶數量時，響應時間開始明顯增長。

⑵ 測試系統的最大用戶數。隨著用戶數量的增多，系統的響應時間開始延遲，直到用戶的數量達到某一數值，系統開始響應失敗或崩潰。

⑶ 找到目前系統的性能瓶頸。依次測試系統的數據庫和服務層各個接口，分析找到系統的瓶頸。

⑷ 測試系統的穩定性。系統保持較高的用戶數量及較高負載持續訪問的時間長度內，系統一直能有效響應，并沒有明顯的響應時長起伏或死機。

2.4 性能測試類別

⑴ 負載測試：在系統能承受的壓力極限范圍內持續運行，以測試系統的穩定性。主要用于掌握系統的性能，為提升系統性能提供基礎依據。

⑵ 壓力測試：指持續提升Web系統的工作壓力，直到被測系統無法正常運行，以測試系統能承受的工作壓力，由此得到系統性能的最大服務質量。

⑶ 并發測試：在一定的軟硬件網絡環境下，并發測試多種業務場景，在同一個負載壓力下，構造相同的測試數據，目的是為了測試系統是否能正常運行。

⑷ 穩定測試：在一定負載的情況下，給予外界或內部非正常的干擾，檢測系統是否能提供穩定服務，目的主要是為了驗證正常情況下，系統是否能滿足性能指標要求。

⑸ 容量測試：通常是獲取數據庫的最佳容量能力，又稱為容量預估。在一定的并發用戶，不同的數據量訪問下，觀察數據庫的處理能力，獲取數據庫的各項性能指標。

2.5 性能測試指標

⑴ 響應時間：是指系統對請求作出響應的時間，不同的功能的響應時間也不盡相同。通常指該系統所有功能的平均響應時間或者所有功能的最大響應時間[2]。

⑵ 吞吐量：吞吐量是指單位時間內服務器處理的字節數。在一定時間內，用戶數量持續增加，而吞吐量趨于平衡甚至有略微減少不見遞增，說明該用戶數量即為當前系統所能承受的最大用戶數量，系統處理能力已經達到瓶頸。

⑶ TPS：是指服務器每秒處理的事務數，TPS值越大，系統處理能力越強。

⑷ 并發用戶數：模擬多個用戶在同一時間訪問服務器，并發用戶數指的就是在線用戶數量。

2.6 性能測試的流程

⑴ 對測試需求進行分析，劃定性能測試的范圍，了解系統的性能指標，把業務模型映射成測試模型，進行工作評估，制定測試計劃。

⑵ 錄制測試腳本，調試測試腳本，設計測試場景，根據測試模型來準備被測系統的主數據與業務數據，測試數據[3]。

⑶ 運行、監控場景，收集性能數據，對性能測試過程中發現的缺陷進行管理。

⑷ 分析性能測試結果，編寫測試報告，性能測試人員與開發人員一起來解決性能問題，提供系統優化方案。

2.7 測試用例設計

⑴ 基于場景的測試用例設計。

① 單業務功能場景：運行測試期間，所有虛擬用戶只執行同一種業務功能的某個操作。

② 混合業務功能場景：運行測試期間，部分虛擬用戶執行某種業務的某個環節操作，部分虛擬用戶執行該業務功能的其他環節。或者部分虛擬用戶執行某種業務功能，部分虛擬用戶執行其他業務功能。

⑵ 事務定義。根據合理的定義事務，方便分析系統瓶頸，尤其在混合業務功能場景測試中。比如，購買商品，可以把下訂單定義為一個事務，把支付也定義為一個事務。

⑶ 場景監控對象。針對每條用例，明確可能的壓力點，比如數據庫、Web服務器等。同時需要監控不同的對象，比如tps，耗時，CPU，內存，I/O等。

2.8 測試策略

⑴ 先做混合業務功能場景的測試，然后做單業務功能場景的測試。

⑵ 在進行性能測試的過程中，常規的測試次序為負載測試、壓力測試、穩定性測試、 強度測試[4]。

⑶ 逐步加壓。例如前3分鐘，測試15個用戶，接著每隔3分鐘，增加15個用戶，以此類推。不僅比較真實的模擬現實環境，而且在性能指標比較模糊且不知道服務器處理能力的情況下，可以確定出一個大致基準，通過分析可以能得出服務器大致處理能力，供后續測試參考。

⑷ 單點并發。如使用集合點，單獨針對某個環節的并發測試，通常是針對某個環節的性能調優時使用。

2.9 測試執行

⑴ 創建測試自然環境。在進行測試用例以后，就逐漸構建測試環境。創建測試環境包含硬件配置、系統軟件環境的構建，系統配置主要參數的調節等內容[5]。

⑵ 制作測試腳本和情景。制作測試腳本和情景活動主要根據自動化測試專用工具來完成。

⑶ 實行測試和結果記錄。在自動化測試專用工具的協助下，執行測試，獲取相關性能測試參數。

2.10 性能測試分析

性能測試分析用于分析測試結果，根據結果給出測試結論。常用的分析方法如下。

⑴ 不同的測試環境下，分析硬件設備的性能指標與預期的性能指標，確定是否達到了我們需要的結果。針對沒有達到預期的指標，分析具體的瓶頸點，系統性能拐點，系統在可接受的性能指標下最大的處理能力，系統在不同配置下的性能表。

⑵ 不同的測試環境下，分析應用服務器、數據庫服務器、中間件等組件的性能指標。在性能測試執行過程中，可能會發現某些功能上的不足或存在的缺陷，根據確定的問題進行具體詳細的分析出現問題的原因，分析需要優化的地方。

3 性能測試實踐

3.1 性能測試工具

JMeter是一個開源的自動化性能測試工具，主要用于測試B/S架構的系統性能。本次采用jmeter作為測試工具，通過jmeter代理服務器錄制腳本生成http請求腳本，并由http協議通過get方式發送訪問請求，收集服務器吞吐能力、響應時間等性能指標的情況。

3.2 測試場景設計

被測的商業網站系統采用B/S架構，測試頁面是購物的搶購場景。搶購活動時會有優惠券產生，客戶拿到優惠券后才能參加搶購。首先客戶不停的刷搶購活動，一直刷出一個正在進行有優惠券的搶購活動，然后馬上請求使用優惠券。無論是否成功，客戶會稍后查詢已經擁有的優惠券是否已經出現在賬號里。

假設測試場景為200客戶，每隔一秒啟動一個新客戶;系統每隔10秒發出一個搶購活動，一共發布160次，每個搶購活動包含50張優惠券，即一共投放8000張優惠券。整個測試持續半個小時。

3.3 測試結果分析

⑴ 吞吐能力

從圖1可以看到查詢活躍的搶購活動事務處理量最高，穩定在4000左右。其他因為業務比例的原因較低，去掉查詢活躍的搶購活動事務后如圖2。

拼單和優惠券查詢之間的差值是由于存在搶購失敗造成的，測試所設置用戶行為場景是無論拼單成功與否都會進行一次優惠券查詢。

⑵ 響應時間

根據測試結果，平時響應時間和事務處理時間如圖3、圖4。

在測試過程中，70%的事務處理時間都是在15ms以內，整體平均響應時間處于50ms內。

3.4 結果分析

依據測試過程中對于測試資源的觀察，Web服務器CPU使用率低于20%，其他資源使用率很低，服務器表現出良好的性能，系統的吞吐能力和響應時間基本滿足需求。

3.5 優化方案

根據測試的結果的分析，可以適當對Web系統做出一些優化調整。

⑴ 調整網頁布局，合理使用框架集框架頁。

⑵ 刪除代碼中所有不相關的頁面元素，以及不影響頁面顯示和功能的字符集。

⑶ 刪除不必要的框架文件。

⑷ 減少代碼中對數據庫的訪問次數，優化查詢邏輯。

3.6 測試小結

使用JMeter可以靈活有效地模擬多用戶并發場景，實現Web性能測試，準確統計響應時間、吞吐量、錯誤率等性能指標，為分析系統性能和系統調優提供了參考。由于測試環境與生產環境存在差異，網絡環境復雜，根據JMeter的性能測試結果，系統開發人員需要進一步探索，找出系統性能缺陷。

4 結束語

Web性能測試是軟件測試的重要環節，提高系統性能以及解決系統在實際運行中出現的問題，是性能測試的根本目標。在性能測試過程中，按照實際性能測試需求為準則，設計合理的性能測試場景，盡量模擬用戶的實際行為，使測試用例更接近用戶實際使用情況，才能提高性能測試的效率。在充分了解了性能測試目標的情況下，制定更加合理的性能測試方案，監控性能測試流程，做出更加充分的軟件測試，才能找出瓶頸，為軟件調優提供依據。

參考文獻（References）：

[1] 黃智，宋楊.在ASP.NET中實現三層B/S結構開發探索[J].科技信息（學術研究），2008.30：225-228

[2] 唐濤.性能測試在電力信息管理系統中的應用[J].計算機光盤軟件與應用，2012.15（16）：26-27

[3] 陳佐，張懷相，方景龍.嵌入式軟件自動化測試技術[J].計算機工程與設計，2018.39（10）：3125-3131

[4] 劉紅.基于Web軟件的性能測試研究[C].中國教育發展戰略學會教育教學創新專業委員會.2019全國教育教學創新與發展高端論壇論文集（卷六）.中國教育發展戰略學會教育教學創新專業委員會：中國教育發展戰略學會教育教學創新專業委員會，2019：70-71

[5] 張秋鳳.Web應用系統性能測試研究與實踐[J].中國新通信，2016.18（14）：117-118