Multistep API テスト

Multistep API テスト

概要

Multistep API テストを使用すると、**HTTP テスト**をチェーンして、主要なサービスの高度なジャーニーがいつでもどこからでも利用できることを事前に監視できます。

  • 認証を必要とする API エンドポイントで HTTP リクエストを実行します (たとえば、トークンを介して)
  • API レベルで主要なビジネストランザクションを監視します
  • エンドツーエンドのモバイルアプリケーションのジャーニーなどをシミュレートします

サービスの 1 つが応答遅延を起こしたり、予期しない方法 (たとえば、予期しない応答本文、ステータスコードなど) で応答を開始した場合、テストはチームに警告するCI パイプラインをブロックする、または障害のあるデプロイをロールバックすることができます。

Multistep API テストは、Datadog 管理ロケーションおよびプライベートロケーションから実行できるため、外部と内部の両方でシステムを完全にカバーできます。

: Multistep API テストを使用すると、1 つのテストで複数の HTTP リクエストをリンクできます。サービスに対する単一のリクエストを実行する場合は、API テストを利用できます。

コンフィギュレーション

テストに名前を付けてタグを付ける

  1. Multistep API テストに名前を付けます。
  2. Multistep API テストに env タグとその他のタグを追加します。次に、これらのタグを使用して、Synthetic Monitoring ホームページで Synthetic テストをすばやくフィルタリングできます。

ロケーションを選択する

Multistep API テストを実行するロケーションを選択します。Multistep API テストは、ネットワークの外部または内部のどちらからテストを実行するかによって、管理ロケーションプライベートロケーションの両方から実行できます。

リクエストを定義する

Create Your First Request を押して、テストのリクエストの設計を開始します。

注: デフォルトでは、最大 10 個のステップを作成できます。Datadog サポートチームに連絡して増やしてください。

リクエストを定義する

  1. ステップに名前を付けます。
  2. HTTP Method を選択し、クエリする URL を指定します。使用可能なメソッドは、GETPOSTPATCHPUTHEADDELETEOPTIONS です。httphttps の両方の URL がサポートされています。
  3. Advanced Options を使用して HTTP リクエストを加工します (オプション)。
  • Follow redirects: チェックマークを付けると、リクエストを実行するときに HTTP テストで最大 10 個のリダイレクトをフォローします。
  • Request headers: HTTP リクエストに追加するヘッダーを定義します。デフォルトのヘッダー (たとえば、user-agent ヘッダー) をオーバーライドすることもできます。
  • Cookies: HTTP リクエストに追加するクッキーを定義します。<COOKIE_NAME1>=<COOKIE_VALUE1>; <COOKIE_NAME2>=<COOKIE_VALUE2> の形式を使用して複数のクッキーを設定します。
  • HTTP Basic Auth: HTTP 基本認証資格情報を追加します。
  • Body type: HTTP リクエストに追加するリクエスト本文のタイプ (text/plainapplication/jsontext/xmltext/html、または None) を選択します。
  • Request body: HTTP リクエスト本文のコンテンツを追加します。: リクエスト本文は最大サイズ 50 キロバイトに制限されています。
  • Ignore server certificate error: チェックマークを付けると、SSL 証明書の検証時にエラーが発生した場合でも、HTTP テストが接続を続行します。
  • Client certificate: クライアント証明書と関連する秘密キーをアップロードして、mTLS を介して認証します。
  • Proxy URL: HTTP リクエストが通過する必要があるプロキシの URL (http://<YOUR_USER>:<YOUR_PWD>@<YOUR_IP>:<YOUR_PORT>) を指定します。
  • Proxy Header: プロキシへの HTTP リクエストに含めるヘッダーを追加します。
  • Do not save response body: レスポンスの本文が実行時に保存されないようにするには、このオプションを選択します。テスト結果に機密データを含めたくない場合に有用です。障害発生時のトラブルシューティングに影響を及ぼす可能性があるため、慎重に使用してください。セキュリティに関する詳細は、こちらでご確認ください。

Test URL をクリックして、リクエストのコンフィギュレーションをテストします。応答プレビューが表示されます。

アサーションの追加

アサーションは、期待されるテスト結果が何であるかを定義します。Test URL を押すと、response timestatus codeheadercontent-type の基本的なアサーションが、取得された応答に基づいて追加されます。Multistep API テストでは、アサーションはオプションです。

タイプ演算子値の型
本文containsdoes not containisis not
matchesdoes not match
jsonpath
String
Regex
StringRegex
ヘッダーcontainsdoes not containisis not
matchesdoes not match
String
_Regex
response timeis less than整数 (ms)
ステータスコードisis not整数

: HTTP テストでは、brdeflategzipidentitycontent-encoding ヘッダーを使用して本文の圧縮を解除することが可能です。

New Assertion をクリックするか、応答プレビューを直接クリックすることで、ステップごとに最大 20 個のアサーションを作成できます。

失敗動作

Continue with test if this step fails (このステップが失敗した場合にテストを続行する) 設定により、ステップが失敗した場合でも、マルチステップ API テストを後続のステップに進めることができます。これは、テストが自動的にクリーンアップできることを確認するのに特に役立ちます。たとえば、テストでは、最初にリソースを作成し、そのリソースに対していくつかのアクションを実行し、そのリソースの削除で終了する場合があります。中間ステップの 1 つが失敗した場合でも、テストの最後にリソースを削除して、誤検知の生成を回避する必要があります。これは、すべての中間ステップで Continue with test if this step fails (このステップが失敗した場合にテストを続行する) を使用して行うことができます。

また、中間ステップで Consider entire test as failed if this step fails (このステップが失敗した場合、テスト全体を失敗と見なす) 設定をアクティブにして、エンドポイントの 1 つが期待どおりに応答しない場合でも、テスト全体でアラートが生成されるようにする必要があります。

同様に、マルチステップ API テストがさまざまなエンドポイントで実行される場合、2 つの失敗動作設定により、1 つまたは複数の API エンドポイントで問題が発生した場合でも、テストがすべてのリクエストを確実に実行できるようになります。

応答から変数を抽出する

オプションで、応答ヘッダーまたは本文をパースすることにより、HTTP リクエストの応答から変数を抽出することもできます。変数の値は、HTTP リクエストステップが実行されるたびに更新されます。

変数をパースするには

  1. Variable Name を入力します。変数名に使用できるのは大文字、数字、アンダースコアのみです。また、3 文字以上にする必要があります。

  2. 変数を応答ヘッダーから抽出するか、本文から抽出するか決定します。

    • 応答ヘッダーから値を抽出: HTTP リクエストの応答ヘッダー全体を変数値に使用するか、正規表現によりパースします。
    • 応答本文から値を抽出: HTTP リクエストの応答本文全体を変数値に使用し、正規表現または JSONPath によりパースします。

作成されたこの変数は、Multistep API テストの次の手順で使用できます。

テストの頻度を指定する

Multistep API テストは次の頻度で実行できます。

  • On a schedule: 最も重要なエンドポイントにユーザーが常にアクセスできるようにします。Datadog で Multistep API テストを実行する頻度を選択します。
  • Within your CI/CD pipelines: 欠陥のあるコードがカスタマーエクスペリエンスに影響を与える可能性があることを恐れずに出荷を開始します。
  • On-demand: チームにとって最も意味のあるときにいつでもテストを実行します。

アラート条件を定義する

アラート条件で、テストが失敗しアラートをトリガーする状況を設定します。

アラート設定規則

アラートの条件を An alert is triggered if any assertion fails for X minutes from any n of N locations に設定すると、次の 2 つの条件が当てはまる場合にのみアラートがトリガーされます。

  • 直近 X 分間に、最低 1 個のロケーションで失敗 (最低 1 つのアサーションが失敗)、
  • 直近 X 分間に、ある時点で最低 n 個のロケーションで失敗。

高速再試行

テスト結果が失敗した場合、テストによって再試行をトリガーすることができます。デフォルトでは、再試行は最初に失敗したテスト結果の 300 ミリ秒後に実行されます。この間隔は API を介して構成できます。

ロケーションのアップタイムは、評価ごとに計算されます (評価前の最後のテスト結果がアップかダウンか)。合計アップタイムは、構成されたアラート条件に基づいて計算されます。送信される通知は、合計アップタイムに基づきます。

チームへの通知

以前に定義されたアラート条件に基づいて、テストによって通知が送信されます。このセクションを使用して、チームに送信するメッセージの方法と内容を定義します。

  1. モニターと同様、メッセージに @notificationを追加するか、ドロップダウンボックスでチームメンバーと接続されたインテグレーションを検索して、通知を受信するユーザーやサービスを選択します。

  2. テストの通知メッセージを入力します。このフィールドでは、標準のマークダウン形式のほか、以下の条件付き変数を使用できます。

    条件付き変数説明
    {{#is_alert}}テストがアラートを発する場合に表示します。
    {{^is_alert}}テストがアラートを発しない限り表示します。
    {{#is_recovery}}テストがアラートから回復したときに表示します。
    {{^is_recovery}}テストがアラートから回復しない限り表示します。
  3. テストが失敗した場合に、テストで通知メッセージを再送信する頻度を指定します。テストの失敗を再通知しない場合は、Never renotify if the monitor has not been resolved オプションを使用してください。

Save をクリックしてテストを保存し、Datadog にテストの実行を開始させます。

変数

ローカル変数を作成する

抽出された変数

Multistep API テストの任意のステップから変数を抽出してから、テストの後続のステップでその値を再挿入することができます。

パターンからの変数

テストコンフィギュレーションフォームの右上隅にある Create Local Variable をクリックすると、ローカル変数を作成できます。以下の利用可能なビルトインのいずれかから値を定義できます。

{{ numeric(n) }}
n 桁の数字列を生成します。
{{ alphabetic(n) }}
n 文字のアルファベット文字列を生成します。
{{ alphanumeric(n) }}
n 文字の英数字文字列を生成します。
{{ date(n, format) }}
テストが開始された日付 + n 日の値を使用して、許容される形式のいずれかで日付を生成します。
{{ timestamp(n, unit) }}
テストが +/- n 選択単位で開始されたタイムスタンプの値を使用して、許容される単位のいずれかでタイムスタンプを生成します。

変数を使用する

HTTP テストの URL、高度なオプション、アサーションで、Settings で定義されたグローバル変数ローカルで定義された変数を使用できます。 変数のリストを表示するには、目的のフィールドに {{ と入力します。

テストの失敗

ステップが 1 つまたは複数のアサーションを満たさない場合、またはステップのリクエストが時期尚早に失敗した場合、テストは FAILED と見なされます。場合によっては、エンドポイントに対してアサーションをテストできずにテストが実際に失敗することがあります。これらの理由には次のものがあります。

CONNRESET
接続がリモートサーバーによって突然閉じられました。Web サーバーにエラーが発生した、応答中にシステムが停止した、Web サーバーへの接続が失われた、などの原因が考えられます。
DNS
テスト URL に対応する DNS エントリが見つかりませんでした。テスト URL の構成の誤り、DNS エントリの構成の誤りなどの原因が考えられます。
INVALID_REQUEST
テストのコンフィギュレーションが無効です (URL に入力ミスがあるなど)。
SSL
SSL 接続を実行できませんでした。詳細については、個別のエラーページを参照してください
TIMEOUT
リクエストを一定時間内に完了できなかったことを示します。TIMEOUT には 2 種類あります。
  • TIMEOUT: The request couldn’t be completed in a reasonable time. は、タイムアウトが TCP ソケットの接続レベルで発生したことを示します。
  • TIMEOUT: Retrieving the response couldn’t be completed in a reasonable time. は、タイムアウトがリクエストの実行全体 (TCP ソケット接続、データ転送、アサーション) で発生したことを示します。

その他の参考資料