性能測試

您已經建構了您的 API，並且它通過了所有功能測試。但是當 100 個使用者試圖在完全相同的秒數內註冊時會發生什麼？它會變慢嗎？它會崩潰嗎？

效能測試 (Performance Testing) 是模擬高流量場景，以便在您的使用者發現之前識別瓶頸的藝術。Apidog 透過將您現有的測試場景重新用作效能測試，使得這變得極其容易。

什麼是效能測試？

與功能測試（它能工作嗎？）不同，效能測試問的是：它在負載下工作得如何？

我們關注的關鍵指標：

Concurrency (並發)：有多少虛擬使用者 (VU) 同時處於活動狀態。

Response Time (延遲)：請求花費多長時間（例如平均值、P99）。

Throughput (TPS/RPS)：每秒交易/請求數。

Error Rate (錯誤率)：失敗請求的百分比。

配置效能測試

在 Apidog 中，您不需要編寫新腳本。您只需獲取一個「測試場景」並在 Performance Mode（效能模式）下運行它。

步驟

打開您的 Test Scenario（例如「使用者生命週期」）。

運行場景，但這次將分頁切換到 Performance Test 而不是 Functional Test。（或者點擊「Performance」圖標）。

配置負載參數：

Virtual Users (concurrency)：有多少同時執行緒？从小開始（例如 20）。

Duration：運行多長時間？（例如 1 分鐘）。

Ramp-up Period：啟動使用者的速度？（例如 10 秒內 0 到 20 個使用者）。

查看詳情：效能測試

運行和監控

點擊 Run。Apidog 將生成虛擬使用者並根據您的場景邏輯開始錘擊您的 API。

您將看到一個即時儀表板：

TPS Chart：吞吐量是穩定還是波動？

Response Time Chart：延遲是否隨時間增加？（記憶體洩漏或資料庫鎖定的跡象）。

Error Rate：我們是否看到 500 錯誤？

分析報告

一旦完成，您將獲得詳細報告。

關鍵指標

Avg Response Time：如果這高於 500ms，您的 API 可能會感覺「遲鈍」。

99th Percentile (P99)：這至關重要。這意味著「99% 的請求都比這快」。如果 Avg 是 200ms 但 P99 是 5s，您有穩定性問題。

Transactions Per Second (TPS)：這是您系統的容量「速限」。

真實案例：使用者註冊 + 登入

想像我們想要在負載下測試整個入職流程。

場景：

POST /users (註冊)

POST /user/login (登入)

配置：

並發：50 個虛擬使用者。

時長：5 分鐘。

結果與分析：

TPS：500（良好的容量）。

錯誤率：0.5%（可接受嗎？也許不行）。

發現瓶頸：我們注意到 POST /login 比 POST /users 慢 3 倍。

修復：我們發現在登入期間使用的 email 欄位缺少資料庫索引。新增後，延遲下降了 90%。

最佳實踐

重複使用場景：不要建構單獨的效能腳本。使用您的整合測試。

從小開始：從 1 個使用者開始，然後 10 個，然後 50 個。不要立即跳到 1000。

隔離環境：除非您確切知道自己在做什麼，否則 永遠不要 在生產環境中運行效能測試。使用 Staging 環境。

注意依賴項：瓶頸通常不是您的程式碼，而是您正在呼叫的資料庫或第三方 API（如 Stripe/Twilio）。

關鍵重點

了解效能指標 (RPS, Latency)

使用虛擬使用者配置負載測試

分析報告以尋找瓶頸

下一步

我們已經進行了手動測試、自動測試和負載測試。最後一塊拼圖是隨時間分析結果並與團隊分享。

在下一章中，我們將查看 測試報告和分析。

繼續閱讀 → 測試報告和分析

什麼是效能測試？#

配置效能測試#

步驟#

運行和監控#

分析報告#

關鍵指標#

真實案例：使用者註冊 + 登入#

最佳實踐#

關鍵重點#

下一步#