使用 Copilot Studio 建立的對話式代理運行於一個能自動擴展以支援需求與負載增加的平台上。 然而，對話式代理常使用自訂邏輯或呼叫後端 API，這會帶來延遲，因為自訂邏輯效率低，或底層 API 與後端系統無法良好擴展。
效能測試評估代理在不同負載模式下的表現與穩定性。 隨著用戶群成長，它能識別潛在問題，確保代理保持功能正常且反應迅速。 如果你不在負載下測試對話代理，它在開發和測試時可能運作良好，但在真實使用者流量下卻會失敗。
在處理效能測試的技術層面之前，先定義能捕捉期望使用者體驗的接受標準，並識別產生不同負載模式的對話式使用案例。 本文簡要介紹效能測試的規劃階段，並提供關於如何為您的對話代理產生負載的技術細節指引。
規劃你的表現測試
績效測試計畫應有明確目標與具體的接受標準。 例如，有些測試測量系統在標準負載下的表現，而另一些測試則產生更極端的壓力，故意讓系統變得無反應。 在評估使用 Copilot Studio 建立的對話式代理的效能時，應設計測試以衡量代理的基線效能或預期的重負載，但不要設定測試產生過大壓力。
警告
產生的負載超出預期的使用者行為可能導致訊息使用過剩及環境不受歡迎的限速。 為避免限速和過度用電，請確保：
- 你的測試模擬了真實的使用者行為。
- 您的租戶和環境已分配足夠的授權和帳單政策。
了解使用者行為
開始你的測試計畫時，先分析使用者在不同對話應用情境下預期的行為。 從負載測試的角度來看，使用者行為可能因使用情境而異，例如使用者說什麼或問什麼（例如「我想訂機票」或「你的退貨政策是什麼？」）、驅動特定使用情境的使用者數量，以及使用者的互動模式（例如，中午同時連線，或是一天中逐漸累積）。
下表描述了銀行對話代理的預期用戶行為。
| 用例 | 常用使用者語句 | 交戰模式 |
|---|---|---|
| 貸款申請 | 我需要一筆新貸款， 我想申請新的貸款 ...... |
一天平均有 1,000 名同時使用用戶 |
| 平衡調查 | 我的帳戶餘額是多少？ 顯示我的帳戶餘額 ...... |
10,000 名同時在線用戶，全部在中午左右連線 |
| 其他應用情境 | … | … |
建立測試計劃
在你以使用案例和互動模式定義使用者行為後，再思考你的效能測試計畫的具體細節。 至少，對話代理的效能測試計畫應明確目標、測試情境、關鍵績效指標、詳細測試數據及成功標準。
如果你的團隊已經定義了用於評估的對話情境，無論是透過 產品內建建立測試案例 或使用 Copilot Studio 套件，你可以重複使用這些情境來開始制定測試計畫。
以下範例測試計畫是針對銀行對話代理人。 該計畫利用先前識別的對話式使用案例，定義基線測試情境與負載測試情境。 測試基線可評估正常效能，識別日常使用時的問題，而負載增加則可能揭示系統如何處理高峰使用者活動。
| 章節 | 詳細資訊 |
|---|---|
| Objective | 評估銀行對話客服在基線及負載條件下的表現。 |
| Scope |
範圍：基線與負載測試。 超出範圍：壓力測試。 |
| 關鍵效能指標 (KPI) |
|
| 測試情境 |
基線測試
|
| 測試資料 |
|
| Tools |
|
| 成功準則 |
|
與技術及業務利害關係人合作，制定符合組織需求的測試計畫。 同意範例中列出的關鍵參數。 在 效能測試參考範例與指引中，了解如何使用 Apache JMeter 等工具來建立測試腳本。
模擬多回合對話
計畫中指定的測試數據意味著計畫中的效能測試驅動會進行多回合對話。 多回合對話是模擬使用者與對話代理之間來回傳送的一系列訊息。 效能測試應該推動多回合對話，讓產生的負載更接近真實使用者行為。 此外，有些長期執行的動作或 API 呼叫，只有在使用者做出特定選擇或在對話中發送特定訊息模式時才會被調用。
以下範例中，銀行的後端 API 只有在使用者選擇 儲蓄帳戶後才會啟動。 第一則訊息的回應時間比一秒還短，因為只有代理的意圖識別引擎參與。 最後一則訊息等待後端 API 的回應，這會帶來額外的延遲。 若不模擬多回合對話，效能問題就不會出現。
模擬多回合對話需要在準備測試資料時與撰寫測試腳本時進行規劃。 在測試資料中包含一系列使用者發言，以觸發完整的對話流程，如範例所示。 確保你的測試腳本在一次對話中傳送多句話語。