成功的Web應用系統效能測試案例

2021-05-06 15:48:14 字數 3222 閱讀 1711

1 引言
基於web伺服器的應用系統由於提供瀏覽器介面而無須安裝,大大降低了系統部署和公升級成本,得以普遍應用。目前,很多企業的核心業務系統均是web應用,但當web應用的資料量和訪問使用者量日益增加,系統不得不面臨效能和可靠性方面的挑戰。因此,無論是web應用系統的開發商或終端使用者,都要求在上線前對系統進行效能,科學評價系統的效能,從而降低系統上線後的效能風險。

在很多效能測試專案中,由於不能合理定義系統的效能測試需求,不能建立和真實環境相符的負載模型,不能科學分析效能測試結果,導致效能測試專案持續時間很長或不能真正評價系統效能並提出效能改進措施。

本文在總結許多web應用系統效能測試實踐經驗和教訓的基礎上,從與效能測試工具無關的角度介紹web應用系統效能測試的方法和實施過程,以及如何定義合理的效能測試需求。

1.1 術語定義

效能測試:通過模擬大量瀏覽器客戶端同時訪問web伺服器,獲得系統的效能資料。

虛擬使用者:模擬瀏覽器向web伺服器傳送請求並接收響應的乙個程序或執行緒。

請求成功率:web伺服器正確處理的請求數量和接收到的請求數量的比。

吞吐量:單位時間內web伺服器成功處理的http頁面或http請求數量。

1.2 web應用系統技術架構

web應用系統的前端為瀏覽器,後台為web伺服器(如apache,microsoft internet information server),瀏覽器和web伺服器之間的互動基於http協議。http協議本身是無連線的,web伺服器通過session機制來建立乙個瀏覽器所發出的先後連線之間的關聯。通過實驗證明,當瀏覽器客戶端在首次訪問web伺服器後,如果該瀏覽器客戶端不傳送後續請求,伺服器維持該瀏覽器客戶端的session變數所消耗的系統資源非常小。

2 web應用系統效能測試過程

標準的web應用系統效能測試過程包括確定效能測試需求,開發效能測試指令碼,定義效能測試負載模型,執行效能測試和形成效能測試報告。本章將分別介紹上述過程,並通過舉例說明如何完成每一環節。

2.1 確定效能測試需求

科學定義web應用系統效能測試需求對乙個成功的效能測試非常重要。通常,web應用系統的效能測試需求有如下兩種描述方法。

2.1.2 基於吞吐量的效能測試需求

2.3 建立效能測試負載模型

效能測試負載模型定義了測試工具如何向web應用系統提交請求,包括向web應用系統傳送請求的虛擬使用者數,每個虛擬使用者傳送請求的速度和頻率。針對前面介紹的網上購物系統的效能測試需求,在效能測試工具中定義的效能測試負載模型應包括如下資訊:

虛擬使用者數:效能測試不僅僅是執行一次,而且每次執行時虛擬使用者數也不固定,因此在效能測試負載模型中定義的虛擬使用者數將在測試執行時進行設定。

虛擬使用者啟動模式:在現實中,web應用系統的使用者不太可能同時做相同的操作,因此為了讓web應用系統所承擔的壓力隨時間均勻分布,建議虛擬使用者依次啟動,同時也避免大量使用者同時登入造成系統阻塞。以10個虛擬使用者模擬下定單為例,可設定每個虛擬使用者間隔30秒啟動,這樣10個虛擬使用者可在5分鐘後完成啟動,並保證10個虛擬使用者不會在同一時刻下定單,從而更符合實際情況。

2.4 執行效能測試

執行效能測試是指通過多次執行效能測試負載模型,獲得系統的效能資料。在執行過程中,需利用測試工具、作業系統、系統軟體(如web server或db server)提供的資源監控手段對資源進行監控和分析,幫助發現資源瓶頸,並在系統層面進行優化。同時,還需對應用進行效能分析,幫助定位應用**中的效能問題,切實解決系統的效能問題。

2.5 形成效能測試報告

效能測試專案的最後階段就是向相關人員提交效能測試報告,匯報效能測試結果。在向相關人員匯報效能測試結果時,並不是效能測試報告越豐富、效能資料越多越好。好的效能測試報告是能準確、簡單地傳遞效能測試結論,而不需太多的技術細節。

針對基於吞吐量的效能測試需求,可通過下圖的曲線來描述效能測試結果。以網上購物系統為例,下圖描述下定單的併發使用者、下定單響應時間以及吞吐量(伺服器每秒處理定單筆數)之間的關係,從而快速判斷系統是否能滿足效能測試需求。從下圖中可看出,併發使用者增加,請求的響應時間也增加。伺服器的吞吐量是先隨併發使用者數增加而增加,當吞吐量到達一定峰值後,再增加併發使用者數,吞吐量會減少。原因在於當併發使用者數少時,向web伺服器提交的請求量不大,伺服器處理能力還有富餘,所以吞吐量逐步增大;但當併發使用者數超過某一值時,由於向伺服器提交的請求太多,造成伺服器阻塞,反而導致吞吐量減少。

圖二:響應時間、吞吐量和併發使用者數的趨勢圖

3 如何獲取合理的效能測試需求

前一章介紹了web應用系統的效能測試過程,確定效能測試需求是整個效能測試的起點和成功的重要因素。效能測試需求定義得過高,雖然確保系統上線後能滿足效能需求,但可能會造成硬體資源的浪費;效能測試需求定義得過低,系統上線後可能會出現效能問題。如何通過分析系統上線後可能的使用者訪問行為,來獲得合理的效能測試需求指標呢?

假設現有乙個基於web的辦公自動化系統(簡稱oa系統),該系統提供公文收發和查詢功能。在部署該系統前,將對該系統進行效能測試。下面將詳細介紹如何分析該oa系統的使用情況,定義合理的效能測試需求。

3.2 如何確定oa系統的效能測試用例

由於時間和資源限制,不可能對web應用系統的所有功能進行效能測試,而是從業務的角度(如某一功能操作的使用者多)和技術的角度(如某一功能雖然訪問使用者不多,但內部處理邏輯複雜或處理資料量大)來選擇web應用系統的特定功能作為效能測試用例。

以oa系統為例,由於所有使用者都經常公文查詢功能,因此確定的效能測試用例為公文查詢。

3.3 如何確定oa系統的響應時間

響應時間的快慢直接影響了系統使用使用者的滿意度,採用平均響應時間來描述系統系統效能測試需求是不科學的,因為無法直接和客戶的滿意度掛鉤。而且,在做效能測試,如果某一請求的響應時間過長或過短,將導致平均響應時間和實際情況偏離。

3.4 如何確定oa系統的交易吞吐量

單位時間內web應用系統需處理多少筆特定的交易可通過統計獲得。以oa系統為例,假設每個使用者每天(一天按8小時計算)平均會查詢公文4次,那oa應用的web伺服器平均每分鐘要能處理8000 * 4 / ( 60 * 8 ) = 66.67筆查詢公文交易,考慮到峰值因素,要求每分鐘能處理66.7 * 3=200筆查詢公文交易。

3.5 oa系統效能測試需求描述

通過前面的分析,能明確定義合理的效能測試需求。oa系統效能測試需求定義如下:

基於吞吐量的效能測試需求:oa系統在每分鐘內需處理200筆查詢公文操作,交易成功率為100%,而且90%的請求響應時間不大於8秒。

4 總結

web應用效能測試專案成功的關鍵不在於效能測試工具,而在於有效的效能測試分析方法和實踐。只有切實掌握效能測試需求分析方法,效能測試實踐經驗,才能保證乙個web應用效能測試的成功。

Web系統效能優化系列 Web系統效能指標

效能評估是進行系統設計以及系統優化的重要事項,進行正確地效能評估才能有效地規劃系統容量,保證系統地穩定執行。在效能評估過程中常見的效能指標有以下幾種 tpstransactions per second,每秒傳輸的事務處理個數,即伺服器每秒處理的事務數量。tps是系統效能的乙個重要指標。系統整體處理...

系統效能測試方案 模板

1引言 1.1編寫目的 編寫本方案的目的是用於指導 x系統的效能測試,主要從測試環境 測試工具 測試策略 測試具體執行方法 任務與進度表等事先計畫和設計。1.2適用範圍 x系統效能測試組 x系統開發組 x系統效能優化組 1.3參考資料 系統效能測試指南 1.4術語和縮寫詞 縮寫 術語 解 釋 效能測...

檔案系統效能測試

1 衡量指標 iops 隨機小i o讀寫能力 頻寬 順序大i o連續讀寫能力 2 效能關鍵點 順序 隨機讀寫 sequential random 目錄操作 檔案建立 刪除 查詢 更新 大量小檔案讀寫 lots of small files 大檔案讀寫 large file 3 其他指標 cpu佔用率...