テストのベスト プラクティス（Dialogflow）

Actions on Google プラットフォーム用のアクションの開発には、多くの場合、以下が含まれます。 自然言語理解のために Dialogflow を実装する （NLU）、および Dialogflow フルフィルメントです。これらは、アクションのロジックを処理します。 コードベースにテストを行うことで、アクションが期待どおりに動作することを確認できます。 必要があります

アクションの単体テスト、統合テスト、またはエンドツーエンド テストを実装する場合、 Dialogflow エージェントとフルフィルメントを別々のコンポーネントとみなす必要があります。

フローチャートは、ユーザークエリから Actions on Google、Dialogflow、 最終的にユーザーに返されます。

図 1. テストで考慮するシステムに関するフローチャート

Dialogflow エージェントのテスト

Dialogflow エージェントとフルフィルメントは、別々のコンポーネントとしてテストされます。「 以降のサブセクションでは、Dialogflow の 作成します。

クエリが入り、インテントが出るシステムとして Dialogflow を捉える

Dialogflow エージェントは、ユーザーのクエリを受け取り、 クエリから事前定義されたエンティティを抽出するエージェントは、一致したインテント、そのパラメータ、および Actions on Google メタデータを含むメッセージを渡すことによって、フルフィルメントとやり取りします。

デベロッパーは、インテントやエンティティの構造と同様に、Dialogflow エージェントの構成を制御します。Actions on Google メタデータは、Actions on Google から取得され、テスト用の正しいデータが含まれていると想定できます。

テストの際はエージェントがインテントを正しく抽出できるようにすることに重点を置く パラメータやクエリをインテントに一致させることが できるようになりますこのアプローチにより、 エージェントのパフォーマンスを評価するための定量化可能な指標。Google Chat では 個々のテストケースや 検証セットを渡します。

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 クライアントを使用しながら、会話ごとに 1 つの会話を作成できます。

Dialogflow API に対してリクエストを行うため、料金が発生する可能性があります。 無料呼び出しの割り当て量に達した場合に発生する可能性があります。割り当てと上限をご覧ください。 をご覧ください。

統合テスト

Dialogflow API の detectIntent エンドポイントには、 サードパーティフルフィルメントをトリガーしますそのため、テストケースを作成して では、Dialogflow エージェントと Dialogflow のインテグレーションを扱います。 受け取ります

Dialogflow の統合テストと単体テストの作成の主な違いは、統合テストでは、Dialogflow インテントとエンティティの抽出だけでなく、Webhook からのレスポンスもアサートできることです。

Facts About Google リポジトリの Node.js で作成された統合テストの完全に機能する例をご覧ください。

Dialogflow フルフィルメント Webhook のテスト

Dialogflow エージェントと Dialogflow フルフィルメントは、それぞれ別個のものとしてテストされる 説明します。以降のサブセクションでは、インフラストラクチャを テスト フルフィルメントを作成します。

JSON が入り、JSON が出るシステムとしてフルフィルメントを捉える

Dialogflow フルフィルメント コードは、リクエストを想定し、レスポンスを生成するために、 JSON 形式で返されます。その結果、以下について検討することでフルフィルメント コードをテストできます。 JSON 入出力システムとして実装できます。リクエストには、Cloud Storage バケットの Dialogflow と Actions on Google が統合されているため、 特定のインテント ハンドラを指定できます。

インテント ハンドラのトリガーをテストするには、アクションに JSON リクエスト（入力）を送信します。このリクエストは、インターネット上でアクセス可能なフルフィルメントに渡されます。その後で、フルフィルメントが、検証用として評価可能な JSON レスポンス（出力）を生成します。

フルフィルメントは JSON リクエスト入力と Webhook JSON で表すことができる レスポンス出力。

図 3. JSON が入り、JSON が出るシステムとして Dialogflow を表現

単体テスト

フルフィルメント Webhook を、JSON 入力を受け取って JSON 出力を生成するシステムと考えます。そうすれば、アクションのテストプロセスが、リクエストをフルフィルメントに提供し、結果の出力 JSON を確認するだけに簡略化されます。

これにより、自由に、フルフィルメントをローカルでホストし、テスト用に HTTP リクエストをローカルで送信できます。Actions on Google Node.js クライアント ライブラリを使用している場合は、JSON リクエストをクライアント ライブラリ ミドルウェア レイヤに直接送信することもできます。

JSON 入力を使用して Webhook コードをテストし、想定される JSON 出力を受け取れば、制御する部分が正しく機能することを保証できます。正しい JSON ペイロードが生成されるため、Dialogflow と Actions on Google が正しく機能していると考えることができます。この分離によって、テストを作成するための簡略化されたプログラミング モデルが提供されます。

テストプロセスの概要を以下に示します。

  1. Actions Console のシミュレータを使用して、ユースケースの各ステップで JSON リクエストを取得します。それらを JSON ファイルとして保存します。別の方法として、 API のリクエストの情報を使用して自分でリクエストを Webhook リファレンス ドキュメントをご覧ください。
  2. これらのペイロードを使って Webhook を呼び出すテストを作成します。
  3. テストごとに、レスポンス JSON に想定されたアイテムが含まれていることを確認します。

さらに、このモデルでは、Dialogflow フルフィルメントを フルフィルメントのエンドポイントをローカルで実行できるため、 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 を使用しています。詳しくは、 Facts About Google の Node.js で記述された完全な動作例 できます。

単体テスト可能なフルフィルメントの設計

Webhook コードの多くには、アプリケーションのニーズを満たすために必要なカスタム ビジネス ロジックが含まれています。加えて、Webhook コードには、インテント ハンドラも含めることができます。

フルフィルメント コードの単体テストの粒度を高めるには、ビジネス ロジックをインテント処理ルーチンから切り離すような方法でコードを整理することをおすすめします。つまり、インテント ハンドラとビジネス ロジックを別々のモジュールに含めることで、それぞれを個別にテストできます。

例については、GitHub の shiriuri サンプル アクションをご覧ください。 このサンプルでは、functions/index.js と functions/shiritori/*.js を個別に指定します。 インテント ハンドラとビジネス ロジックが含まれているため、より堅牢なテストが可能 スイートです。

統合テスト

Dialogflow とデベロッパーのインテグレーションをカバーするテストケースを作成する フルフィルメント Webhook コードについては、Dialogflow の統合テスト セクションをご覧ください。 ご覧ください。

負荷テスト

アクションを本番環境にデプロイする前に、負荷テストを行うこともおすすめします。 Webhook フルフィルメントを使用して、パフォーマンスの低下や フルフィルメントサービスの中断

負荷テストで発見できるパフォーマンス上の問題の例を以下に示します。

  • コンピューティング能力とメモリが限られている
  • プロバイダからの割り当て制限
  • データの読み込みと書き込みが遅い
  • コード内の同時実行の問題

負荷テストのシナリオは、負荷テストの予想される使用パターンや過去の使用パターンによって テストの典型的なシナリオは、負荷の急増（急増） 負荷（ソーク）を表します。

Webhook が呼び出され、実行されるシナリオを特定する オペレーションを自動化できます。リソースを大量に消費する処理の例としては、 データベースのクエリ、別の API の呼び出し、コンピューティング、メモリ 長時間かかるオペレーションです

このようなシナリオでは、Actions on Google サーバーから送信されたリクエストをキャプチャできます。 Webhook ログまたは Stackdriver ログから Webhook への接続を確立できます。また、 Actions Console シミュレータからリクエストをキャプチャします。

リクエストを取得したら、負荷テストツールを使用して Webhook がさまざまな負荷テストのシナリオで応答することを確認します。次の を使用して、スパイクテストとソークテストの例を ApacheBench。

スパイクテスト

スパイクテストでは、一定数のリクエストを Webhook に送信する必要がある 負荷が急増する場合があります。たとえば、テストを設定して これは、60 QPS の急増と 10 秒間クエリ数（QPS）の負荷を送信するというものです。

次の ApacheBench コマンドを実行すると、60 個の同時リクエストを送信できます。 Webhook に送信します。

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

ActionRequest.json ファイルに、送信されたキャプチャされたリクエスト ペイロードが含まれていると仮定します。 Webhook に追加します。

ソークテスト

ソークテストでは、一定数のリクエストを Webhook に送信する必要がある レスポンスを確認します。たとえば、1 つのサーバーに送信されるテストを設定して、 10 ～ 20 QPS の負荷を数分間かけて一定負荷をかけ、応答時間を確認する 増加します。

次の ApacheBench コマンドを実行すると、1, 200 件のリクエストを送信できます。 1 秒あたりの同時リクエスト数:

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

ActionRequest.json ファイルに、送信されたキャプチャされたリクエスト ペイロードが含まれていると仮定します。 Webhook に追加します。

負荷テストの結果の分析

負荷テストを実施した後、結果を分析して Webhook の応答時間を確認します。 Webhook の実装の問題を示すインジケーターは、通常、 テスト実行のたびに増加する応答時間の中央値、または最悪のケース レスポンス時間が許容されません。

エンドツーエンドのテスト

承認のためにアクションを送信する前のエンドツーエンド テストでは、Actions Console シミュレータが使用されます。Google Cloud Platform 上の Actions Console シミュレータを使用した Actions シミュレータによるテスト ご覧くださいこれらのテストを実施することで、潜在的な不確実性を排除できます。 Actions on Google インフラストラクチャ コンポーネントからデプロイできます。