效能測試核心定義
效能測試屬於系統級測試，旨在驗證軟體在整合環境下的效能指標（併發處理能力、批量業務吞吐量、響應時間等），及早發現架構層面的效能瓶頸。
效能測試四大子類型
- 併發測試：驗證系統承受大量同時連線/請求的能力。
- 負載測試：固定配置下，持續高負載（用戶數、交易數）的穩定性表現。
- 配置測試：不同軟硬體配置下的效能基準線。
- 健壯性測試：極端資源不足、突發故障下的系統生存能力。
實戰案例：金融分散式支付系統
系統架構
- 表現層：Java Applet 終端，TCP/HTTP 與前置機通訊。
- 業務邏輯層：
- 交易應用服務：Tuxedo 中介軟體 + DB2 C API。
- 交易/查詢前置服務：Tuxedo Jolt / WebLogic + JReport + JDBC。
- 資料層：DB2 資料庫主機。
部署拓撲：資料庫/交易主機在交易中心城市，前置機在各分中心，終端覆蓋城域網。
效能指標與測試分解
| 指標 | 目標 | 測試場景 |
|---|
| 併發登入 | 750 用戶/分，響應 ≤30秒 | 漸增壓力：每秒 13 用戶，持續 1 分鐘 |
| 交易吞吐 | 300 筆/秒 | Goal-Oriented 場景，目標 300 TPS |
| 查詢吞吐 | 400 筆/秒（基礎資料 30 萬筆） | Goal-Oriented 場景，目標 400 QPS |
| 綜合測試 | 交易+查詢同時進行 | 前兩項通過後執行 |
壓力流程線分析
兩條獨立但共享資料庫的壓力鏈：
- 交易鏈：終端 → 交易前置 → Tuxedo → 交易主機 → DB2（寫入）。考驗 Socket 連線、Tuxedo 響應、主機運算、DB2 鎖機制。
- 查詢鏈：終端 → WebLogic → JDBC → DB2（讀取）。考驗 WebLogic 處理、DB2 索引優化。
綜合測試時，讀寫衝突對 DB2 形成雙重衝擊。
腳本開發策略
- 交易/登入：繞過 UI，直接嵌入 Java Socket 程式碼至 LoadRunner 腳本，直擊前置機。
- 查詢：利用 LoadRunner HTTP 錄製功能生成 Web 腳本。
- 腳本包含：資料池、檢測點、異常處理、事務標記（
lr_start/end_transaction）。
測試執行與監控
- 工具：HP LoadRunner (Controller + VU Generator + Analysis)。
- 同步監控：Unix 系統資源、WebLogic、DB2 計數器，合併生成分析圖表。
關鍵測試結果與瓶頸定位
| 測試項目 | 結果 | 瓶頸定位 |
|---|
| 併發登入 | 1 分鐘僅接受 ~490 用戶，未達 750 目標 | 前置機 Socket 連線建立能力不足 |
| 瞬時併發 | 極限 ~122 用戶 | 同步點測試確認 |
| 交易流程 | 後台處理正常，但終端 UI (Java Applet) 大量資料刷新時凍結 | 客戶端渲染效能，非伺服器端 |
| 查詢流程 | 基本達標 | 索引優化有效 |
| 綜合測試 | 因交易流程未通過，未執行 | — |
效能測試標準五步驟
- 系統分析：掌握架構、業務流、壓力鏈，制定實施方案。
- 建立虛擬用戶腳本：精準模擬單一用戶行為，控制模擬誤差。
- 創建測試場景：依指標設定併發模型、節奏、資料參數化。
- 執行並同步監控：全鏈路資源監控，即時發現瓶頸。
- 結果分析與評價：統計規律、定位瓶頸、驗證調優成效。
核心心得
工具只影響執行複雜度，**人的分析與思考決定測試成敗**。精準模擬真實世界是效能測試有效性的前提。
- 上一篇文章： C 語言 fprintf 與 fwrite 差異深度解析：文字 vs 二進制寫入
- 下一篇文章： C 語言記憶體分配三大方式：靜態區、堆疊、堆完整解析
Copyright ©
程式碼之家 All Rights Reserved
