對話動作已於 2023 年 6 月 13 日淘汰。詳情請參閱「對話動作已淘汰」。

本頁面由 Cloud Translation API 翻譯而成。

測試最佳做法 (Dialogflow)

針對 Actions on Google 平台開發動作通常包括實作 Dialogflow 來實現自然語言理解 (NLU) 和 Dialogflow 執行要求，負責處理動作的邏輯。在程式碼集中進行測試，可確保動作能正常運作。

為動作導入單元、整合或端對端測試時，應將您的 Dialogflow 代理程式和執行要求視為個別元件。

流程圖從使用者查詢前往 Actions on Google、Dialogflow
和執行要求 Webhook，最終會傳回使用者

圖 1. 說明應考慮測試的系統的流程圖

測試 Dialogflow 虛擬服務專員

Dialogflow 代理程式和執行要求會視為獨立元件進行測試。以下子節說明如何將 Dialogflow 概念化和測試為您的 Action 安裝代理程式

使用 Dialogflow 做為查詢和意圖系統

您的 Dialogflow 代理程式會負責執行使用者查詢，並將查詢與，並從查詢中擷取任何預先定義的實體。你的虛擬服務專員系統會傳送含有相符比對結果的訊息，以便與執行要求互動意圖、其參數和 Actions on Google 中繼資料。

開發人員可以控制 Dialogflow 代理程式的設定，例如意圖和實體的結構Actions on Google 中繼資料來自 Actions on Google，可假設包含正確的測試資料。

測試時，請著重於讓代理程式能夠正確擷取意圖參數和查詢與意圖的比對這種做法用於評估代理程式效能的可量化指標。你可以要計算這項指標，準備及使用個別測試案例驗證集。

Dialogflow 虛擬服務專員可透過文字查詢做為輸入內容，
將意圖加上擷取的意圖參數做為輸出內容

圖 2. 將 Dialogflow 表示為查詢中和意圖導向系統

單元測試

針對 Dialogflow 代理程式，您可以編寫測試，每個案例預期都會有文字並產生意圖中繼資料做為輸出內容。這項中繼資料至少應包含相符意圖的名稱和清單參數。

Dialogflow API 的 detectIntent 端點將文字查詢做為輸入內容，並產生包含下列內容的結構化輸出內容：已解析的意圖和擷取的參數名稱。這項輸出內容很實用，評估代理程式的意圖比對效能。如需完整的其他實用欄位的參照，請參閱 QueryResult 參考資料。

範例測試如下所示：

it('choose_fact', async function() {
  // The `dialogflow` variable is an abstraction around the API that creates
  // and sends payloads to Dialogflow.
  const resJson = await dialogflow.detectIntent(
    'Tell me about the history of Google');
  expect(resJson.queryResult).to.include.deep.keys('parameters');
  // Check that Dialogflow extracted required entities from the query.
  expect(resJson.queryResult.parameters).to.deep.equal({
    'category': 'history',
    // Put any other parameters you wish were extracted
  });
  expect(resJson.queryResult.intent.displayName).to.equal('choose_fact');
});

這段程式碼使用 Mocha 和 Chai。查看完整以 Node.js 編寫的 Dialogflow 單元測試工作範例關於 Google 的資訊。

由於 Dialogflow API 接受 sessionId 做為引數。因此，您可以，同時使用單一 Dialogflow API 用戶端。

因為您是對 Dialogflow API 提出要求，因此可能需要付費就會產生這類費用。查看配額與限制瞭解詳情

整合測試

Dialogflow API 的 detectIntent 端點觸發第三方執行要求。因此，您可以撰寫測試案例當中介紹了 Dialogflow 代理程式與 Dialogflow 之間的整合作業執行要求

為 Dialogflow 編寫整合與單元測試的主要差異在於在整合測試中，您可以斷言來自 Webhook 的回應以及 Dialogflow 意圖和實體擷取作業

如需查看以 Node.js 編寫的整合測試完整範例，請參閱關於 Google 存放區的事實。

測試 Dialogflow 執行要求 Webhook

系統會分別測試 Dialogflow 代理程式和 Dialogflow 執行要求元件。以下子節將說明如何建立概念和概念測試執行要求。

以 JSON 格式與 JSON 輸出系統執行要求

您的 Dialogflow 執行要求程式碼會預期要求，並在下列位置產生回應：以及 JSON 格式因此，您可以思考請匯出 YAML 檔案此要求同時包含來自 Dialogflow 和 Actions on Google，因此具備觸發尤其是在執行要求中。

如要測試意圖處理常式的觸發條件，請將 JSON 要求 (輸入) 傳送至你的動作。系統會將這項要求傳遞至您的執行要求，您可在以下位置存取：網際網路執行要求接著會產生 JSON 回應 (輸出)，進行驗證。

執行要求可以使用 JSON 要求輸入內容和 Webhook JSON 來表示
回應輸出結果。

圖 3. 以 JSON 傳入和 JSON 輸出系統表示執行要求

單元測試

請將執行要求 Webhook 程式碼視為接受 JSON 輸入內容的系統。這個外掛程式能產生 JSON 輸出內容接著，測試動作的程序會簡化會向執行要求提供要求，並檢查結果輸出的 JSON。

這樣您就能在本機自由代管執行要求及傳送 HTTP 以便進行測試如果您使用 Actions on Google Node.js 也可以直接將 JSON 要求傳送至用戶端程式庫中介軟體層

如果您使用 JSON 輸入內容來測試 Webhook 程式碼，並收到預期的 JSON 接著可以合理確信控管的各部分就能正常運作您可以假設 Dialogflow 和 Actions on Google 運作正常以便正確產生 JSON 酬載這個隔離機制提供了簡化的程式設計模型以撰寫測試。

以下是測試程序的概要說明：

使用動作主控台中的模擬工具取得具體而言請將這些檔案儲存為 JSON 檔案。此外，也可以建立這類要求 Webhook 參考說明文件。
編寫測試以透過這些酬載叫用 Webhook。
確認每項測試的回應 JSON 都包含預期項目。

此外，這個模型可讓您持續整合設定，因為執行要求端點可以在本機執行且 Dialogflow API 內建工作階段概念。

範例測試如下所示：

it('yes-history', function() {
  expect(jsonRes.payload).to.have.deep.keys('google');
  expect(jsonRes.payload.google.expectUserResponse).to.be.true;
  expect(jsonRes.payload.google.richResponse.items).to.have.lengthOf(3);
  expect(jsonRes.payload.google.richResponse.suggestions).to.have
    .deep.members([
      {'title': 'Sure'}, {'title': 'No thanks'},
    ]);
});

上述程式碼片段使用 Mocha 和 Chai。詳情請參閱參閱《關於 Google》以 Node.js 撰寫的完整工作範例 Cloud Storage 也提供目錄同步處理功能

設計可單元測試的執行要求

Webhook 程式碼通常包含應用程式所需的自訂商業邏輯以滿足其需求此外，Webhook 程式碼也可以包含處理常式中的指示操作。

如果想改善執行要求程式碼的單元測試精細程度，因此您能練習妥善整理程式碼與意圖處理處理常式分離。也就是建立意圖處理常式和商業邏輯，因此每個部分都能測試以便獨立作業

如需範例，請參閱 GitHub 上的防護範例動作。在此範例中，functions/index.js 和 functions/shiritori/*.js 分別包含意圖處理常式和商業邏輯，可讓測試更完善例如 1、21、11、414 以及

整合測試

用於編寫涵蓋 Dialogflow 與執行要求 Webhook 程式碼，請參閱 Dialogflow 整合測試一節。

載入測試

將動作部署至實際工作環境之前，建議您先進行負載測試 Webhook 執行要求可以顯示效能問題，避免發生效能降低服務中斷。

以下列舉幾個負載測試時可能會發現的效能問題：

有限的運算能力和記憶體
供應商的配額限制
資料讀取和寫入速度緩慢
程式碼中的並行問題

負載測試情境取決於您的動作，但在典型的測試情境中，負載突然增加 (激增) 和持續負載 (浸泡) 的情況。

找出呼叫 Webhook 且執行時資源密集型作業典型資源密集型作業包括查詢資料庫、呼叫其他 API、執行運算以及記憶體必須進行大量處理，例如算繪音效檔

在這些情況下，您可以擷取 Actions on Google 伺服器傳送的要求從您的 Webhook 記錄或 Stackdriver 記錄寫入 Webhook。你也可以使用 Actions 主控台模擬工具擷取要求。

取得要求後，就可以使用負載測試工具來瞭解 Webhook 會在不同的負載測試情境下回應。下列子節會提供一些範例，說明如何進行激增測試 ApacheBench。

高點測試

您必須傳送固定數量的要求給 Webhook 測試，才能進行尖峰測試突然增加負載例如，您可以設定測試，每秒發出 10 次查詢 (QPS)，但每秒會發出 60 次 QPS 的負載。

您可以執行下列 ApacheBench 指令，傳送 60 個並行要求傳送至 Webhook：

ab -n 60 -c 60 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName

假設 ActionRequest.json 檔案包含已傳送的要求酬載附加至 Webhook

過量測試

您需要向 Webhook 傳送固定數量的要求，才能進行過渡量測試並觀察回應舉例來說，您可以設定測試，將一個持續載入 10 至 20 QPS，並持續幾分鐘，確認回應時間是否正常。

您可以執行下列 ApacheBench 指令，傳送 1200 個要求 (編號 10 個) 每秒並行要求數：

ab -t 120 -n 1200 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName

假設 ActionRequest.json 檔案包含已傳送的要求酬載附加至 Webhook

分析負載測試結果

執行負載測試後，分析 Webhook 回應時間的結果。 Webhook 實作中的問題指標通常都是每次測試執行都會增加的回應時間中位數，或者最壞情況動作不接受的回應時間。

端對端測試

將動作送審前的端對端測試會使用動作控制台模擬工具。你可以查看相關端對端步驟使用「動作模擬工具」中的動作控制台模擬工具進行測試說明文件。進行這些測試有助於消除潛在的不確定性以及 Actions on Google 基礎架構元件