テストスイート作成後は、テスト内容を追加する。Apidog では、テスト管理の要件に応じて柔軟に使い分けられる「静的」「動的」の2モードを用意している。テスト内容の取り込み#
「オーケストレーション」タブ内のテストスイート詳細ページで、「＋ エンドポイントテストケースを追加」または「＋ テストシナリオを追加」をクリックする。表示される選択ウィンドウで「静的」または「動的」モードを切り替えられる。1. 静的モード#
実行対象のテスト項目を厳密に指定する用途に用いる。🎯 コアロジック
選択したテストケースのIDをシステムが記録する。元のカテゴリに新規ケースが追加されても、このスイートの実行範囲は変わらないため、結果のコントロール性が担保される。
バグ修正確認（ホットフィックス）：バグに強く関連する3〜5件のテストケースを選び「検証パッケージ」を構成。関係のないケースを走らせずに修正結果を素早く確認する。
コア業務の安定化（コアパス）：注文→決済のような極めて重要で安定したプロセスでは、新人が不完全なテストケースをうっかり追加して監視アラートを鳴らす事態を避けたい。
旧バージョン互換性テスト：旧クライアントの互換確認に特化した旧APIテストケース群を選定して実施する。
保守コスト高：この専用スイートに新たなケースを含める場合、 手動で追加する必要がある。
2. 動的モード#
ルールによって実行対象のテスト項目を自動抽出する用途に用いる。🎯 コアロジック
システムに「フィルタルール（Scope & Filter）」を保存する。実行のたびにプロジェクト全体をリアルタイムに走査し、条件に合致する最新のケースをすべて実行計画に取り込む。
モジュール単位の回帰テスト：「Trading Center」フォルダーをソースフォルダーに設定。テスターは当該フォルダーに新規ケースを作成するだけで、実行時に自動で取り込まれる。
スモークテスト：「優先順位＝P0」というルールで動的スイートを作成。各リリース前に実行し、P0にマーキングされた重要ケースを自動で網羅する。
バージョン更改の検証：タグ機能を使い、ルールを「タグ＝v2.5.0」に設定。開発完了後、このスイートを実行して当該バージョンの新機能を一括で確認する。
保守コストゼロ：一度ルールを設定すれば、以後はスイート自体のメンテナンスは不要。ケースの属性（配置、タグ、優先度）のみを管理すればよい。
実行順序の調整#
取り込んだ内容は一覧表示され、ドラッグで実行順序を並べ替えられる。「静的」に追加した項目は、「編集」から個別のテストケースを削除するか、グループごと削除できる。「動的」に追加したグループは、グループ全体の削除またはフィルター条件の編集のみ可能で、グループ内の個別項目は削除できない。詳細設定#
テストスイートの設計ページ右側にある「詳細設定」を展開すると、実行方法をより細かく制御できる。実行環境#
定義：既定では、テストスイートで設定済みの実行環境を継承する。ここで環境を指定した場合は、その設定が実行時に優先される。
用途：同一のStep群を異なる環境で再利用したい場合に有効。
テストデータ#
実行時にテストデータを使用するかどうかを指定する。テストデータなし：Stepは1回のみ実行し、データ駆動テスト（こちら）は行わない。 テストデータを使用：テストデータに基づき複数回実行する。パラメータ化テストに用いられる。
エラーの処理#
エラーの扱いを設定する。アサーション失敗、データ形式の検証失敗、APIリクエストの例外 、サーバーエラーなどが含まれる。無視：エラーが発生しても中断せず、後続のStepを続行する。
継続：エラー発生時、そのラウンドの残りStepをスキップし、次の実行ラウンドへ進む。
実行終了：エラーが発生した時点で後続のStepを直ちに終了する。
反復回数#
遅延時間#
定義：各テストStep完了後、次のStepを実行するまでに待機するミリ秒（ms）を設定する。
用途：高頻度のリクエストにより対象サーバーのレート制限やサーキットブレーカーを誘発しないようにし、テストの円滑な実行を確保する。
リクエスト／レスポンスの保存#
定義：テストレポートに、リクエストやレスポンスの詳細（Header、Body など）を含めるかを制御する。
すべて：合否に関わらず全Stepの詳細を保存する。データ量が大きく、深いデバッグに向く。
失敗のみ：実行中に失敗したStepの詳細のみを保存する。推奨。ストレージ節約と失敗原因の迅速な特定に有効。
保存しない：詳細は保存せず、合否と所要時間のみを記録する。
環境変数／グローバル変数の値#
環境／グローバル変数の実値として、当該テストシナリオで使用する値を指定する。選択肢は2通り。詳細はこちらを参照。Runner に保存された変数値を使用する場合は、さらに使用する変数スコープを選択する必要がある。このスコープ指定の目的は、実運用の必要に応じて変数を適切に分離し、あるスケジュール実行での変数変更が他のタスクの失敗を招く事態を避けることにある。スコープを選択すると、プロダクト画面に表示される入口から当該スコープ内の変数値を参照できる。| Runner 内の変数スコープ | 環境変数／グローバル変数の読み書き | 説明 |
|---|
| 現在のテストシナリオ内のみで共有 | - 指定した Runner において、当該テストシナリオ専用の永続化ファイルに環境／グローバル変数を保存する。
- このファイルの変数を読み書きできるのは当該テストシナリ オのみ。
| 影響範囲が最小のスコープ。前回実行の結果を次回実行で利用するようなケースに適する。テストシナリオ、タスク、タスクフォルダーの各変数ファイルは、Runner のコンテナパス「/opt/runner/variables」に保存される。 |
| 現在のスケジュールタスク内の全テストシナリオ間で共有 | - 指定した Runner において、当該スケジュールタスク専用の環境／グローバル変数ファイルを用意する。
- 現在のスケジュールタスク内のすべてのテストシナリオが、このファイルの変数を読み書きできる。
| 影響が中程度の推奨スコープ。同一スケジュールタスク内の異なるテストシナリオ間でデータ共有が必要な場合に適する。 |
| 現在のスケジュールタスクフォルダー内の全スケジュールタスク間で共有 | - 指定した Runner において、当該タスクフォルダー専用の環境／グローバル変数ファイルを用意する。
- 現在のフォルダー配下にあるすべてのスケジュールタスクとテストシナリオが、このファイルの変数を読み書きできる。
| 影響範囲が最大のスコープ。あるスケジュールタスクの実行が変数値を変更し、他のタスクが失敗する可能性がある。フォルダー内の複数タスク間で広くデータを共有する必要がある場合に適する。 |
Modified at 2026-01-15 05:56:39
