課程：B站大學
記錄軟件測試-性能測試學習歷程、掌握前端性能測試、后端性能測試、服務端性能測試的你才是一個專業的軟件測試工程師

---

# 基準測試 建立系統性能的基線數據，用于后續優化或版本對比。 關鍵特點??：

??標準化場景??：在固定硬件、軟件配置和測試條件下運行。
??量化指標??：測量響應時間、吞吐量、CPU/內存占用等。
??對比性??：常用于比較不同版本、配置或競品的性能差異。
??典型場景??：

數據庫查詢速度對比（如MySQL vs PostgreSQL）。
新版本API接口的響應時間是否優于舊版本。
硬件選型時測試不同服務器的處理能力。
??工具舉例??：

??Sysbench??（數據庫基準測試）
??Geekbench??（CPU/GPU性能測試）
??JMeter??（HTTP請求基準測試）

負載測試

評估系統在預期或更高負載下的性能表現，識別瓶頸。
關鍵特點??：
??模擬真實用戶??：逐步增加并發用戶數或請求量。
??關注閾值??：測試系統在峰值負載下的表現（如最大支持1000并發用戶）。
??性能指標??：TPS（每秒事務數）、錯誤率、資源利用率等。
??典型場景??：
電商網站在促銷期間能否承受10萬用戶同時訪問。
API服務在每秒5000請求時的延遲是否達標。
數據庫在大量寫入操作時的吞吐量極限。
??工具舉例??：
??JMeter??、??Locust??（模擬用戶負載）
??Gatling??（高并發測試）
??k6??（云原生負載測試）

穩定性測試

驗證系統在長時間運行下的可靠性，發現內存泄漏、資源耗盡等問題。
關鍵特點??：
??長時間運行??：持續施壓數小時甚至數天。
??監控異常??：關注內存增長、線程阻塞、日志錯誤等。
??恢復能力??：測試故障后是否自動恢復。
??典型場景??：
服務器連續運行7天后是否出現內存泄漏。
數據庫在持續寫入后是否因連接池耗盡崩潰。
微服務在長時間高負載下是否產生未處理的異常。
??工具舉例??：
??JMeter??（長時間壓力測試）
??Prometheus + Grafana??（監控資源泄漏）
??Chaos Mesh??（注入故障測試恢復能力）

維度	基準測試	負載測試	穩定性測試
目標	建立性能基線	找出系統負載極限	驗證長期可靠性
測試時長	短（分鐘級）	中（小時級）	長（天級）
關鍵指標	響應時間、吞吐量	最大并發數、錯誤率	內存/資源泄漏、錯誤累積
適用階段	開發早期/版本迭代	上線前性能驗證	上線前/運維期

負載測試曲線圖

• ??橫軸（X軸）??：??并發用戶數??（負載量），從低到高遞增。
• ??縱軸（Y軸）??：
• ??Utilization (U)??：系統資源利用率（如CPU、內存），綠色曲線。
• ??Throughput (X)??：系統吞吐量（每秒處理請求數），紫色曲線。
• ??Response Time ???：請求響應時間，紅色曲線。

區域	特征	性能表現
輕載區	并發用戶數較少（左側）	- 資源利用率（U）線性增長 - 吞吐量（X）快速上升 - 響應時間（R）穩定低位
最佳并發點	The Optimum Number of Concurrent Users（圖中標注點）	- 吞吐量（X）達到理想值 - 響應時間（R）仍可控 - 資源利用率（U）未飽和
重載區	并發用戶數超過最佳點（Heavy Load）	- 資源利用率（U）接近瓶頸 - 吞吐量（X）增速放緩 - 響應時間（R）明顯上升
最大并發點	The Maximum Number of Concurrent Users（圖中臨界點）	- 吞吐量（X）達到峰值 - 響應時間（R）陡增 - 資源利用率（U）飽和（100%或更高）
瓶頸區	超過最大并發點（右側Buckle Zone）	- 資源飽和：系統過載 - 吞吐量下降：請求堆積/超時 - 用戶體驗惡化：高延遲或錯誤
??故障表現??：
超過最大并發點后，系統可能出現：

1. 錯誤率上升（如HTTP 503）
2. 資源耗盡（數據庫連接池滿、線程阻塞）
3. 響應時間不可接受（用戶流失）。

測試策略：

1. 通過逐步增加并發用戶數，定位圖中的??最佳點??和??最大點??。

??監控指標??：

1. 重點關注吞吐量拐點和響應時間突變位置。

其他測試策略

并發測試

驗證系統在??多用戶同時操作??時的功能正確性和資源競爭問題（如死鎖、數據臟讀）。
關鍵特點??
??模擬真實并發??：多個線程/用戶同時執行相同或不同操作。
??關注點??：
數據一致性（如庫存超賣）
資源競爭（如數據庫連接池耗盡）
線程安全（如全局變量沖突）
??測試場景??：
100個用戶同時提交訂單
多線程并發修改同一數據庫記錄
??工具示例??
??JMeter??（線程組模擬并發用戶）
??LoadRunner??（虛擬用戶并發控制）
??Gatling??（高并發場景設計）

壓力測試

評估系統在??超過正常負載??時的表現，定位崩潰臨界點及恢復能力。
??關鍵特點??
??極端條件??：持續施壓直至系統崩潰（如CPU 100%、內存耗盡）。
??關注點??：
系統崩潰閾值（如最大支持5000并發）
錯誤處理機制（如熔斷降級）
故障恢復時間（如自動重啟后恢復速度）
??測試場景??：
短時間內涌入10倍正常流量
強制關閉服務后驗證自愈能力
??工具示例??
??JMeter??（階梯式加壓）
??k6??（混沌工程壓力注入）
??Chaos Mesh??（模擬網絡中斷、資源枯竭）

容量測試

確定系統在??長期運行??下的最大承載能力，為擴容提供數據支撐。
關鍵特點??
??可持續負載??：長時間維持高負載（如24小時80%資源占用）。
??關注點??：
資源泄漏（如內存泄漏、線程堆積）
性能衰減（如數據庫查詢變慢）
擴展性建議（需增加多少服務器）
??測試場景??：
持續7天模擬2000并發用戶
數據庫每日寫入100萬條記錄后的性能變化
??工具示例??
??Locust??（長時間穩定負載模擬）
??Prometheus + Grafana??（監控資源泄漏）
??阿里云PTS??（云環境容量規劃）

性能指標的介紹

響應時間

定義：
響應時間指用戶從客戶端發起一個請求開始，到客戶端接收到從服務器端返回的結果，整個過程所耗費的時間。

【組成】：
響應時間 = 網絡時間 + 應用程序處理時間

并發用戶數據

并發測試的用戶數（并發：同時運行請求）

• 系統用戶數??：系統注冊的總用戶數據
• 在線用戶數??：某段時間內訪問系統的用戶數，這些用戶并不一定同時向系統提交請求
• 并發用戶數??：某一物理時刻同時向系統提交請求的用戶數

吞吐量

定義：吞吐量（Throughput）指的是單位時間內處理的客戶端請求數量，直接體現軟件系統的性能承載能力。

1. 從業務角度來看，吞吐量也可以用“業務數/小時”、“業務數/天”、“訪問人數/天”、“頁面訪問量/天”來衡量。
2. 從網絡角度來看，還可以用“字節數/小時”、“字節數/天”等來衡量網絡的流量。
3. 從技術指標來看，可以用每秒事務數（TPS）和每秒查詢數（QPS）來衡量服務器具體性能處理能力。

吞吐量TPS

TPS:每秒事務數：單位時間內系統處理的客戶端請求的事務次數
計算??：
TPS = 并發數 / 平均響應時間
??事務??：
事務即業務請求，對應界面上一個或多個操作。以支付請求為例：

• 包含服務器查詢用戶余額
• 支付安全校驗等多個請求
• 最終定位到服務器對應的業務請求代碼（可能為單段或多段代碼）
  在jmeter中可以用事務控制器組合一系列接口請求為一個事務，子事務上有父事務等。
  jmeter示例：
  測試計劃
  └── 事務控制器（名稱：完整下單事務）
  ├── HTTP請求 1 (登錄接口)
  ├── HTTP請求 2 (添加購物車)
  └── HTTP請求 3 (提交訂單)

吞吐量QPS

TPS:每秒查詢數：一個QPS是一個接口請求
應用場景：
控制服務器每秒處理指定請求數。如：控制服務器達到每秒60QPS，服務器的性能各項性能指標是否正常（服務器處理能力一個重要指標）。

點擊數

定義：點擊數是衡量Web服務器處理能力的一個重要指標。
??提示??

• 點擊數不是通常認為的訪問一個頁面就是1次點擊數，而是該頁面包含的元素（圖片、鏈接等）向服務器發出的請求數量。
• 通常用每秒點擊次數（Hits per Second）指標來衡量Web服務器的處理能力。
  大白話：靜態資源請求數量==點擊數
  ??注意??
  只有Web項目才有此指標。
  主要用于衡量web服務器： Apache HTTP Server?，Nginx?，LiteSpeed?，Caddy?， Tomcat (Apache Tomcat)?
  目前主流的有老項目：Tomcat，新項目專用：Nginx。

錯誤率（異常率）

定義：錯誤率指系統在負載情況下，失敗業務的概率。
計算公式為：
??錯誤率 = (失敗業務數 / 業務總數) × 100%??
??提示??
不同系統對錯誤率要求不同，但一般不超過千分之五（≤0.5%）；
穩定性較好的系統中，錯誤率應由超時引起（即表現為超時率）。
錯誤率大多數是超時，資源耗光導致，所以有資源，擴容，搭建好的集群環境非常重要。

資源利用率

定義：是指系統各種資源的使用情況，一般用“資源的使用量/總的資源可用量×100%”形成資源利用率的數據。
大多數情況下：一個服務器上的基準
通常，沒有特殊需求的話：
建議CPU不高于80%（±5）；
內存不高于80%；
磁盤不高于90%；
網絡不高于80%。
若高于以上數值，則可能存在問題

性能測試流程

• 性能測試需求分析
• 性能測試計劃及方案
• 性能測試用例
• 測試腳本編寫/錄制
• 建立測試環境
• 執行測試腳本
• 性能測試監控
• 性能分析和調優
• 性能測試報告總結
  性能測試流程：無他，唯手熟爾

性能測試需求分析

第一要點：
● 熟悉被測系統
○ 熟悉系統的業務功能
○ 熟悉系統的技術架構
第二要點
● 明確性能測試內容
○ 從業務角度，挑選核心業務進行測試
○ 從技術角度，挑選邏輯復雜度高、數據量大的業務進行測試
第三要點
● 確定測試策略
○ 負載測試、穩定性等
第四要點
● 確定性能測試指標
○ 有需求：按照需求來測試
○ 沒有需求：同類型軟件對比，對未來數據進行預估

性能測試計劃及方案

性能測試實施文檔也是一份重要的文檔
主要內容：

• 項目背景 – 簡介
• 測試目的
• 測試范圍 – 對于需求分析中的性能測試內容
• 測試策略–對應需求分析中的測試策略
• 風險控制–技術風險
• 交付清單
• 進度與分工

性能測試用例

要素：用例標題、用例編號、用例預制條件、用例步驟、用例預期結果、用例實際結果

測試腳本編寫/錄制

1、測試腳本編寫/錄制??
說明：性能測試用例編寫完成以后，接下來就需要結合用例的需要，進行測試腳本的編寫工作。
提示：錄制或編寫，根據不同的工具要注意代碼冗余。

?2、建立測試環境??
說明：在進行性能測試之前，需要先完成性能測試環境的搭建工作，測試環境一般包括硬件環境、軟件環境及網絡環境。
提示：一般情況下可以要求運維和開發工程師協助完成。

??3、 執行測試腳本??
說明：先保證腳本調試通過之后，才能進入正式壓測階段。
執行測試腳本時，要先進行性能運行場景的設置，再運行腳本。

性能測試報告

報告無需多說，文檔，但也很重要，做為性能最終結果也是優化的重要依據

性能測試類型：

總結下性能測試理論知識:

• 響應實踐：從客戶端發送請求到服務器響應的全部時間=應用程序處理時間和網絡事件之和=
• 并發數：同一時刻在向服務器發送請求的用戶數
• 吞吐量：單位時間內服務器處理請求的數量
• QPS:每秒查詢數（每秒請求數）
• TPS：每秒事務數，TPS=并發數（在同一秒內發送的請求數）/響應時間（所有請求的平均響應時間）
• 錯誤率：超時，資源耗盡導致的500請求（性能負載的場景下，失敗事務數占總的事務數的比例）
• 點擊數：web項目，靜態資源請求web服務器(nginx、tomact)的次數等
• 資源利用率：主要是指CPU均值，磁盤IOPS峰值，內存增長值

實踐是檢驗真理的唯一標準