テストスイートを作成した後、テスト内容を追加する必要があります。Apidog は、さまざまなテスト管理のニーズに対応するために、柔軟な「静的」モードと「動的」モードを提供しています。テスト内容のインポート#
テストスイート詳細ページの Orchestration タブで、+ Add Endpoint Test Case または + Add Test Scenario をクリックします。ポップアッ プの選択ウィンドウで、Static モードまたは Dynamic モードを切り替えることができます。1. 静的モード#
静的モードは、実行するテスト項目を正確に指定するために使用します。システムは、選択した特定のテストケースの ID を記録します。ソースカテゴリに新しいテストケースが追加された場合でも、このスイートの実行範囲は変更されないため、テスト結果の制御性が確保されます。バグ修正検証（ホットフィックス）: バグに強く関連する 3〜5 件のテストケースを選択して「検証パッケージ」を作成し、無関係なケースの実行に時間を浪費することなく、修正結果を迅速に検証します。
コアビジネスの安定化（コアパス）: 「注文・支払い」のような非常に重要で安定したプロセスに適しています。新人が未完成のテストケースを誤って追加したことにより、監視アラートが発生することを防ぎたい場合に使用します。
旧バージョン互換性テスト: 旧バージョンのクライアント互換性を検証するために、古いエンドポイントテストケースをまとめて選択します。
高いメンテナンスコスト: 新しいケースをこの専用テストに含める必要がある場合は、手動で追加する必要があります。
2. 動的モード#
動的モードは、ルールによって実行するテスト項目を自動的にフィルタリングするために使用します。システムは 「フィルタルール」（Scope & Filter） を保存します。実行するたびに、システムはプロジェクト全体をリアルタイムでスキャンし、条件を満たすすべての最新ケースを実行計画に含めます。モジュールレベルのリグレッションテスト: 「Trading Center」フォルダをソースフォルダとして設定します。テスターはそのフォルダ内に新しいケースを作成するだけで、スイートは実行時にそれらを自動的に含めます。
スモークテスト: Priority = P0 というルールで動的スイートを作成します。各リリース前に実行することで、P0 としてマークされたすべての重要ケースを自動的にカバーします。
バージョン反復検証: タグ機能を使用し、ルールを Tag = v2.5.0 に設定します。開発完了後、このスイートを実行して、このバージョンのすべての新機能を検証します。
メンテナンスコストなし: ルールを設定すると、その後はスイート自体をメンテナンスする必要はなく、ケース属性（場所、タグ、優先度）のみをメンテナンスします。
実行順序の調整#
インポートされた内容はリストに表示され、リスト項目を ドラッグ して実行順序を調整できます。「静的」に追加された項目については、Edit を使用 してテストケースを個別に削除するか、グループ全体を削除できます。「動的」に追加されたグループについては、グループ全体の削除またはフィルタ条件の編集のみが可能で、グループ内の個別項目は削除できません。詳細設定#
テストスイート設計ページの右側で、Advanced Config を展開すると、テストスイートの実行方法をより細かく制御できます。定義: デフォルトでは、テストスイートですでに設定されている実行環境を継承します。ここで環境を指定した場合、実行時にはその環境設定が優先されます。
ユースケース: 同じ一連のテストステップを異なる環境で再利用する必要があるシナリオに適しています。
テストデータ#
実行時にテストデータを使用するかどうかを指定するために使用します。テストデータなし: テストステップは 1 回のみ実行され、データ駆動テスト は実行されません。 テストデータを使用: テストデータに基づいて複数回実行します。一般的にパラメータ化テストで使用されます。
エラー発生時#
テストがエラーをどのように処理するかを設定します。エラーには、アサーション失敗、データ形式検証失敗、エンドポイントリクエスト例外、サーバーエラーなどが含まれます。無視: エラーが発生しても、現在の実行を中断せずに後続ステップの実行を継続します。
続行: エラーが発生した場合、現在のラウンドの残りのステップをスキップし、次の実行ラウンドに直接進みます。
実行を終了: エラーが発生すると、後続ステップを直ちに終了します。
反復回数#
定義: 各スレッドがすべてのステップをループする回数です。
ユースケース: 安定性検証や簡易的なストレステストのシナリオで一般的に使用されます。
定義: 各テストステップの完了後、次のステップを実行するまでに待機するミリ秒数（ms）を設定します。
ユースケース: リクエスト頻度が高いことによりターゲットサーバーのレート制限やサーキットブレーカー機構がトリガーされるのを防ぎ、テスト実行を円滑にします。
リクエスト/レスポンスの保存#
定義: テストレポートにリクエストとレスポンスの詳細データ（Header、Body など）を含めるかどうかを制御します。
すべて: 成功/失敗に関係なく、すべてのステップの完全な詳細を保存します。データ量は大きくなりますが、詳細なデバッグに適しています。
失敗のみ: 実行中に失敗したステップの詳細のみを保存します。推奨設定であり、ストレージ容量を節約し、失敗原因を迅速に特定しやすくなります。
保存しない: 詳細を一切保存せず、成功/失敗の状態と所要時間のみを記録します。
環境/グローバル変数値#
環境/グローバル変数値では、このテストシナリオで環境/グローバル変数に使用する実際の値を指定します。選択肢は 2 つあります。詳細情報は こちらで確認できます。Runner に保存された変数値を使用することを選択した場合は、さらに使用する変数スコープを選択する必要があります。このスコープの目的は、実際のニーズに応じてユーザーが変数をより適切に分離できるようにすることであり、あるスケジュールタスクの実行によって変数が変更され、他のタスクが失敗する状況を回避することです。スコープを選択した後、製品インターフェースに表示される入口から、このスコープ内の変数値を確認することもできます。 | Runner 内の変数スコープ | 環境/グローバル変数の読み取り/書き込み | 説明 |
|---|
| 現在のテストシナリオ内でのみ共有 | - 現在指定されている Runner 内で、このテストシナリオには環境/グローバル変数を永続的に保存するための専用ファイルがあります。
- 現在のテストシナリオのみが、このファイル内の変数を読み取りおよび書き込みできます。
| 影響が最小の最小変数スコープです。このテストシナリオの前回実行結果を次回実行で使用する必要がある場合に適しています。
テストシナリオ、タスク、タスクフォルダの変数ファイルはすべて、Runner コンテナパス /opt/runner/variables に保存されます。 |
| 現在のスケジュールタスク内のすべてのテストシナリオで共有 | - 現在指定されている Runner 内で、スケジュールタスクには、そのすべてのテストシナリオで使用できる環境/グローバル変数を保存するためのファイルがあります。
- 現在のスケジュールタスク内のす べてのテストシナリオが、このファイル内の変数を読み取りおよび書き込みできます。
| 影響が中程度の推奨される変数スコープです。同じスケジュールタスク内の異なるテストシナリオ間でデータを共有する必要がある場合に適しています。 |
| 現在のスケジュールタスクフォルダ内のすべてのスケジュールタスクで共有 | - 現在指定されている Runner 内で、スケジュールタスクフォルダには、そのすべてのスケジュールタスクおよびテストシナリオで使用できる環境/グローバル変数を保存するためのファイルがあります。
- 現在のフォルダ内のすべてのスケジュールタスクに含まれるすべてのテストシナリオが、このファイル内の変数を読み取りおよび書き込みできます。
| 影響が最も大きい最大の変数スコープです。特定のスケジュールタスクの実行によって変数値が変更され、他のスケジュールタスクが失敗する可能性があります。同じフォルダ内の複数のタスク間でデータを共有する必要がある場合に適しています。 |
Modified at 2026-06-11 07:06:02
