唐承玲 王 虎 李光平 唐春蓬
(汽車噪聲振動與安全技術國家重點實驗室,重慶 401122)
隨著互聯網的飛速發展、計算機的普及,Web 應用系統已滲透到人們的生活及工作中。隨著網絡的發展,用戶對計算機、網絡的依賴性越來越大,在使用Web應用強大、便捷的功能同時,用戶也更加關注Web應用的良好性能。用戶期望能獲得更快、更高的服務品質。軟件的性能測試已成為衡量軟件質量的重要標準之一。
性能測試的價值就是保障系統的性能,提供良好的用戶體驗;盡可能地找出系統性能薄弱環節,幫助進行性能優化。
Apache JMeter是Apache組織開發的基于Java的壓力測試工具,用于對軟件做壓力測試。它最初被設計用于Web應用測試,后來擴展到其他測試領域。它可以用于測試靜態和動態資源,例如靜態文件、Java 小服務程序、CGI 腳本、Java對象、數據庫、FTP服務器等等[1]。
JMeter 的工作原理是通過線程組來驅動多個線程運行測試腳本對被測服務器發起負載,每一個負載機上都可以運行多個線程組[1]。
在Web性能測試中,JMeter軟件被當作Web服務器與瀏覽器之間的一個代理網管,模擬在服務器、網絡或者其他對象上附加高負載以測試他們提供服務的受壓能力,或者分析他們提供的服務在不同負載條件下的總性能情況。
使用JMeter 進行性能測試具有以下優勢:開源免費,文件小安裝方便,不受軟件界面改動的影響,操作簡單易上手,可進行功能定制或擴充,不需要關注對象是否被識別的問題,可以通過其自帶的配置元件及其他元件的組合來處理復雜的業務邏輯,測試腳本維護方便[1]。
Web性能測試是指在各種負載條件下,利用測試工具模擬運行被測系統,以此獲得該系統的各種性能指標,并對所得結果加以分析的一種測試活動。性能測試的目的主要體現在以下5點[2]:
(1)驗證系統是否達到用戶預期的性能目標。
(2)尋找系統的最優配置,獲取最小的系統成本。
(3)挖掘存在的性能缺陷和瓶頸,以此優化系統。
(4)驗證系統是否具有穩定性、可靠性。
(5)預測未來性能。當用戶數和業務量增加時能否及時應對?如何調整?是增加應用服務器,還是數據庫服務器,還是要優化代碼邏輯?
性能測試是在軟件可靠性和正確性的基礎上側重效率方面的驗證,是在功能測試的基礎上測試軟件在集成系統中的運行性能。Web性能測試一般包含以下6項[2]:
(1)負載測試:通過不斷加壓直到系統性能測試瓶頸或資源達到飽和。
(2)壓力測試:系統在一定的負載下長時間運行的穩定性,關注大業務量下系統長時間運行時性能的變化,確定在什么負載條件下,系統性能處于失效狀態。
(3)配置測試:通過對被測系統的軟硬件環境的調整,找到系統各項資源的最優分配原則。
(4)并發測試:模擬多用戶并發訪問同一應用的測試,記錄是否存在線程鎖、資源爭用、內存泄漏等問題。
(5)容量測試:運行一種或多種業務場景在一定虛擬用戶數量的情況下,獲取不同數量級別的性能指標,從而得到數據庫能夠處理的最大會話能力、最大容量等。
(6)可靠性測試:給系統加載一定的業務壓力,讓其持續運行一段時間,測試系統是否可以穩定運行。
軟件的性能從不同角度來看會有不同的結果,以下從3個不同的角度來看待軟件的性能[3]:
(1)用戶角度:他們關心的是應用程序的單步響應時間,也就是數據流經過服務器/服務器集群經過網絡傳輸后往返的時間總和。例如當用戶點擊“查詢”按鈕后多長時間能獲得結果。
(2)軟件開發者的角度:他們關注的是功能的代碼實現,數據庫的設計,框架設計是否合理,系統里內存的使用方法是否合理,線程使用方式是否合理,系統資源是否存在不合理競爭。
(3)運維人員的角度:他們關注的是系統所有服務器是否正常運行,數據庫、中間件等服務器的硬件資源利用率情況,內存是否有可用空間,CPU 是否超過70%,網絡是否順暢,I/O是否存在瓶頸。
體現軟件性能的數據我們稱之為性能指標[4],常見的Web性能指標如下:
(1)響應時間:用戶從客戶端發出請求,并得到響應,以及展示出來的整個過程的時間。
(2)吞吐量:每秒鐘系統能夠處理的請求數/事務數。
(3)資源利用率:系統中不同資源的使用程度,如CPU、內存、磁盤、網絡帶寬等。
(4)并發用戶數:系統能同時處理的請求數/事務數。
(5)錯誤率:一段時間內出錯的請求在總請求數中的占比。
(6)平均傳輸帶寬:計算服務端的數據傳輸量。
性能測試實施流程能夠加強測試工作的控制,明確測試各階段應完成的工作,主要流程如下:
(1)性能測試準備工作:組建團隊,需求調研,選擇工具。
(2)性能測試計劃:分析測試背景、用戶場景,確定性能指標,制定性能測試實施計劃。
(3)性能測試設計:測試環境設計,測試場景設計,測試用例設計,編寫或錄制測試腳本。
(4)性能測試執行:部署測試環境,執行測試腳本,性能監控和記錄。
(5)性能測試報告:根據執行結果,整理編寫性能測試報告。
(6)性能測試總結:根據執行結果對比性能指標,分析并統計系統的性能瓶頸,給出系統調優建議。
文章以某個項目管理系統為例,該項目管理系統主要包括項目管理、協議管理、市場拓展、維修改造、接管項目五個模塊。其中項目信息填報列表的查詢是最為重要的,使用頻率最高,因此以查詢項目信息填報列表接口為例使用JMeter軟件進行Web性能測試。系統頁面如圖1所示。

圖1 項目管理系統
(1)小組準備3個人參加,與項目經理、產品經理一起對需求進行調研。
(2)搭建測試環境,將此系統安裝到與線上環境相似的測試環境服務器上。
(3)準備數據,新增10萬條項目管理填報數據。
(4)根據接口文檔詳細信息,打開JMeter工具,將服務器地址、端口號、路徑等參數填入HTTP請求中。
(5)添加監聽器來記錄測試結果,在線程組或HTTP請求下添加“察看結果樹”“聚合報告”“響應時間圖”“圖形結果”“PerfMon Metrics Collector”。在“PerfMon Metrics Collector”界面上添加需要監控的服務器對應的CPU、Memory、Disks I/O。對腳本所做的設置如圖2所示。

圖2 腳本設置
根據項目管理系統的需求,首先并發用戶數從100開始,逐漸增加100,最大并發用戶數為500,制定性能指標如表1所示。

表1 測試系統性能指標
在腳本中線程組界面,對屬性“線程數”“Ramp-Up Period(in seconds)”“循環次數”“調度器配置”設置不同的屬性值,可實現系統在不同負載下的性能測試。結合本實例系統的性能指標,計劃如表2所示。

表2 性能測試計劃
根據測試計劃,運行腳本,可看到測試結果如表3所示。

表3 性能測試結果
測試執行時監控的資源利用率結果如圖3-圖7所示。

圖3 測試計劃1的資源利用率結果

圖4 測試計劃2的資源利用率結果

圖5 測試計劃3的資源利用率結果

圖6 測試計劃4的資源利用率結果

圖7 測試計劃5的資源利用率結果
對上述測試結果,分析如下:
(1)當并發用戶數為100 時,平均響應時間是0.502 秒,CPU 使用率比較低,平均值在36%左右,內存使用率保持平穩,平均在43%左右,磁盤讀寫速度正常,系統各項結果數據都滿足性能指標。
(2)當并發用戶數為200 時,平均響應時間是0.692 秒,CPU 使用率最高是54%,平均值在30%左右,內存使用率保持平穩,平均在40%左右,磁盤讀寫速度正常,系統各項結果數據都滿足性能指標。
(3)當并發用戶數為300 時,平均響應時間是1.345 秒,CPU使用率有些波動,最高是69%,平均值在40%左右,內存使用率保持平穩,平均在40%左右,磁盤讀寫速度正常,系統各項結果數據都滿足性能指標。
(4)當并發用戶數為400時,平均響應時間是2.597滿足指標,CPU 使用率有些波動,最高是91%,平均值在43%左右,內存使用率保持平穩,平均在35%左右,磁盤讀寫速度正常,最長響應時間、吞吐量、CPU使用率均未滿足性能指標。
(5)當并發用戶數為500時,平均響應時間是5.06,對服務器的CPU消耗比較大,小部分時間使用率達到了100%,部分時間磁盤讀寫速度比較快。系統各項結果數據都未滿足性能指標。
對上述測試結果做出風險判斷和建議如下:
風險一:在查詢時,篩選條件同時具備了分區和索引性質,查詢語句只走了分區,沒有走索引。
建議:采用全局索引。
風險二:當并發用戶數為500時,會大量報錯,查看日志顯示外部通信異常。
建議:建立管理線程池,支持大量并發,避免線程異常拒絕。
風險三:當并發用戶數>=400時,對服務器的CPU消耗比較大,可能會造成服務器宕機。
建議:對線程隊列做限制,不能無限制地消耗服務器資源。
Web性能測試是系統開發的重要環節,它能保障系統性能,給用戶提供良好體驗。文章以某項目管理系統為例,給出了基于JMeter測試工具的性能測試方案,根據測試需求制定了性能指標,根據測試計劃設置了不同場景下的性能測試,根據測試的執行結果,分析了該項目管理系統的性能瓶頸,給出了風險判斷及優化策略。