1. 文檔用途
本報告是為了XX系統的XX模板的性能表現,檢查在多用戶並發訪問的情況下系統的表現情況。
本次測試從事務響應時間、並發用戶數、系統資源使用等多個方面,以專業的性能測試工具,分析出當前系統的性能表現,以實際測試數據與預期的性能要求比較,檢查系統是否達到既定的性能目標。
2. 測試目的
對系統的哪些業務進行性能測試,作為XX項目上線第一次性能測試,本輪測試的目的定義如下:
- 保障系統多用戶情況下系統的可靠性:通過實施不同的性能測試場景,評估並驗證系統在高負載下核心功能的可靠性。
- 提供一輪系統性能測試情況,為下一輪生產環境的性能測試提供基線數據。
- 評估系統部署資源的合理性:不斷搜集和分析性能測試過程數據,對接下來的系統部署所需的系統資源進行評估和建議。
- 優化和解決系統性能問題:在測試過程中,優化系統各項參數和解決發現的系統性能問題。
本測試報告為XXXX網站的性能測試報告,目的在於總結測試階段的測試以及分析測試結果,描述網站是否符合需求。
3. 測試范圍
按照數據量最大、高頻率使用的頁面的策略,確定功能場景包含登錄...等核心業務場景,測試范圍具體涉及可參考測試用例設計。
4. 測試環境與架構圖
系統環境
描述 |
OS |
台數 |
CPU |
Mem |
IP |
|
|
|
|
|
|
描述 |
OS |
DB |
CPU |
Mem |
IP |
|
|
|
|
|
|
客戶端環境
描述 |
OS |
台數 |
CPU |
Mem |
IP |
|
|
|
|
|
|
業務場景描述。Control中的場景設計策略描述。
5. 性能測試需求
5.1 業務量需求
根據客戶提供的業務數據,按照高峰期持續時間,高峰期處理業務數,推算出每秒業務量的預期值,tps=(業務量*80%)/(業務完成時間*20%)
5.2 系統資源需求
高峰期,要求CPU利用率<80%,內存<80%
5.3 基礎數據需求
關鍵圖表分析,截圖和文字結合分析
6. 測試場景
6.1 測試類型
性能測試場景通常包括單業務基准測試、單業務壓力測試、單業務負載測試、綜合業務基准測試、綜合業務壓力測試、綜合業務負載測試、綜合業務穩定性測試等7種測試場景。
- 單業務基准測試:測試某個具體業務是否滿足系統設計或用戶期望的性能指標。比如用戶期望首頁查詢支持300個用戶並發查詢,如果滿足了,則認為基准測試完成,否則失敗。
- 單業務壓力測試:測試某個具體業務在最大負載下,持續服務的時長,以此驗證被測業務的穩定性。壓力測試過程中所涉及的負載,是以系統基准負載為標准,如系統基准負載為50個並發用戶,則壓力測試的負載設為50個,通過運行時長的變化,驗證服務器在系統預設負載下持續服務的能力。
- 單業務負載測試:測試某個具體業務能夠承受的最大負載,驗證被測業務能夠承受的最大負載數,在最佳負載下,系統仍需滿足各項性能指標。
- 綜合業務基准測試:與單業務基准測試類似,但綜合業務需考慮業務與業務間的聯系,如果相互之間存在資源爭用,則需單獨組合測試。假設系統需測試的業務有三個:A、B、C,綜合業務基准測試是將ABC一起運行,那么加上ABC三個基准測試,共計4個基准測試場景,分別是ABC、A、B、C,但A與C存在資源爭用,則需單獨將A與C組合,構成一個單獨的測試場景,則一共為ABC、A、B、C、AC5個基准測試場景。
- 綜合業務壓力測試:與單業務壓力測試類似。
- 綜合業務負載測試:與單業務負載測試類似。
- 綜合業務穩定性測試:綜合業務穩定性測試通常為核心業務在基准負載的基礎上運行相對長的時間,驗證服務器持續提供穩定服務的能力。穩定性場景測試的時間由需求方設定,一般為7*24小時不間斷執行。
6.2 場景設計
根據xxx系統確定本次性能測試的場景主要為首頁查詢並發基准測試、首頁查詢負載基准測試、登錄並發基准測試、登錄負載基准測試、訂閱並發基准測試、訂閱負載基准測試六個場景。
場景名稱 |
場景類型 |
壓測類型 |
用例組成 |
監控線SLA |
備注 |
1.單用戶持續運行該業務場景10分鍾 |
混合場景 |
基線 |
1.查詢首頁 |
CPU<80% |
單用戶執行測試用例,並對測試數據進行采集 |
2.300並發用戶持續運行該核心業務場景20分鍾 |
混合場景 |
負載1 |
1.查詢首頁 |
CPU<80% |
|
7. 測試用例
用例名稱 |
事務名稱 |
步驟描述 |
事務響應可接受時間 |
1.登錄 |
用戶登錄退出 |
步驟1:用戶輸入用戶名和密碼點擊登錄 |
<3 |
2.查詢首頁 |
查詢首頁 |
步驟1:游客用戶打開系統首頁 |
<3 |
3.提交申報信息 |
提交申報信息 |
步驟1:登錄進入系統,點擊管理列表 |
<3 |
4.審核通過申報流程 |
審核通過申報流程 |
步驟1:登錄進入系統,點擊管理列表 |
<3 |
5.提交機構解除申請 |
提交機構解除申請 |
步驟1:登錄進入系統,點擊管理列表 |
<3 |
6.提交數據填報 |
提交數據填報 |
步驟1:在每季末登錄進入系統,點擊數據填報 |
<3 |
7.審核通過數據填報流程 |
審核通過數據填報流程 |
步驟1:登錄進入系統,點擊數據填報 |
<3 |
8.提交數據填報 |
提交企業數據填報 |
步驟1:在每季末登錄進入系統,點擊數據填報 |
<3 |
8. 測試工具
8.1 腳本開發工具
在被測系統中通過抓包,將真實用戶的操作步驟和使用數據全部記錄下來,然后通過關聯和參數化,編寫形成可以多次重復並發運行的測試腳本,由jmeter執行腳本,並發執行業務,從而模擬真實生產系統的壓力,形成對被測系統的加壓,並監控和記錄被測系統在這樣的壓力狀況下表現出來的各種特征。
8.2 性能監控工具
通過jmeter在性能測試中的記錄測試結果及其系統的運行狀況,並將這些數據記錄在測試報告的附件中,需要測試原紀錄的內容主要包括以下幾項:
運行前的系統配置、運行前的參數或者軟件調整情況、運行過程中的內存使用情況、對比測試中的對比配置信息。
在性能測試過程中,需要通過azbbix或者其他監控工具監控主機、數據庫、應用服務取的相關資源占用情況,主要包括如下幾項:
網絡級別的監控內容:單位時間內網絡傳輸數據量
服務器系統級別的監控內容:CPU利用率、內存占用率
數據庫級別的監控內容:數據庫的並發連接數、數據庫的SQL處理速率、數據鎖資源的使用數量、top事件監控等。
性能測試完成以后,收集測試數據,這些數據包括以下內容:事務響應時間、事務成功率、tps等。
9. 場景執行計划
工作內容 |
起日期 |
止日期 |
狀態 |
人員 |
1、性能測試准備 |
2020/1/1 |
2020/1/1 |
完成 |
|
1.1 測試討論 |
2020/1/2 |
2020/1/2 |
完成 |
A,B |
1.2 測試方案制定 |
2020/1/3 |
2020/1/3 |
完成 |
A,B |
2、基礎環境准備 |
2020/1/4 |
2020/1/4 |
完成 |
|
2.1 根據資源需求完成硬件環境准備 |
2020/1/5 |
2020/1/5 |
完成 |
A,B |
2.2基礎軟件(操作系統、數據庫等)安裝 |
2020/1/6 |
2020/1/6 |
完成 |
A,B |
2.3 平台數據庫創建 |
2020/1/7 |
2020/1/7 |
完成 |
A,B |
3、測試前准備 |
2020/1/8 |
2020/1/8 |
完成 |
|
3.1 數據庫造數、清數腳本准備和驗證 |
2020/1/9 |
2020/1/9 |
完成 |
A,B |
3.2 測試場景准備 |
2020/1/10 |
2020/1/10 |
完成 |
A,B |
3.3 平台腳本准備及調試 |
2020/1/11 |
2020/1/11 |
完成 |
A,B |
4、測試執行 |
2020/1/12 |
2020/1/12 |
完成 |
|
4.1 混合場景測試 |
2020/1/13 |
2020/1/13 |
完成 |
A,B |
4.2 登錄單場景測試 |
2020/1/14 |
2020/1/14 |
完成 |
A,B |
4.3 提交申報單場景測試 |
2020/1/15 |
2020/1/15 |
完成 |
A,B |
4.4 審核通過申報流程單場景測試 |
2020/1/16 |
2020/1/16 |
完成 |
A,B |
4.5 提交異常名錄解除申請單場景測試 |
2020/1/17 |
2020/1/17 |
完成 |
A,B |
4.6 提交數據填報單場景測試 |
2020/1/18 |
2020/1/18 |
完成 |
A,B |
4.7 審核通過數據填報流程單場景測試 |
2020/1/19 |
2020/1/19 |
完成 |
A,B |
4.8 提交數據填報單場景測試 |
2020/1/20 |
2020/1/20 |
完成 |
A,B |
4.9 復測 |
43851 |
43851 |
完成 |
A,B |
5、測試分析 |
2020/1/22 |
2020/1/22 |
完成 |
|
5.1 測試結果整理與分析 |
2020/1/23 |
2020/1/23 |
完成 |
A,B |
5.2 測試報告編寫與評審 |
2020/1/24 |
2020/1/24 |
完成 |
A,B |
10. 交付物