プロジェクト内のエンドポイントテストケースとテストシナリオが増え続けると、それらを個別に管理および実行するコストが急激に上昇します。品質を保護することを目的とした自動テストが、それ自体メンテナンスの負担となる可能性があります。
従来、チームはテストケースを手動で選択していました。プロジェクトに多くのテストケースとテストシナリオが蓄積されると、回帰テストにどのケースを含め、どれを実行するかを手動で決定することは、重い手作業となります。
Apidogのテストスイートは、動的なアプローチでこれに対応します。厳密にIDを保存する代わりに、スイートはフィルタリングルールのセットを保存します。例えば、フォルダ、タグ、優先度、または条件の組み合わせによってフィルタリングします。
各実行の前に、テストスイートはこれらのルールに一致するすべてのテストケースとテストシナリオを自動的に組み立てます。テストの作成とタグの適用に集中でき、新しいテストアセットは自動的に選択され、CI/CDパイプラインに組み込まれ、真に自動化された継続的インテグレーションが実現します。
すべての実行結果は、分析とトラブルシューティングを容易にするために、単一の集計レポートにまとめられます。
最初のテストスイートを作成し、オーケストレーションする
Apidogを最新バージョンに更新した後、Testsモジュールを開き、Test Suiteセクションを見つけます。その横にある...メニューをクリックし、Create Test Suiteを選択します。
ポップアップで、説明的な名前を入力し、優先度やタグなどのオプションを設定します。空のテストスイートが作成されます。
次に、スイートにコンテンツを追加します。テストスイートには、個別のエンドポイントテストケースまたは複数のテストステップで構成されるテストシナリオを含めることができます。
テストコンテンツの追加: 静的と動的
Add Endpoint Test CaseまたはAdd Test Scenarioをクリックすると、StaticまたはDynamicモードを選択できます。これらのモードは、スイートが何を起動するかを決定する方法を定義し、異なるメンテナンスおよびテスト目標に適しています。
静的モードは、実行する項目の正確なセットを固定します。静的モードで特定のケースを選択すると、システムはそのケースの一意のIDを保存します。新しいケースが後で同じフォルダに追加されたり、ケースが移動されたりしても、スイートの実行範囲は変更されません。動作は決定的であり、すべての実行で同じです。
動的モードは異なります。特定のケースIDを保存せず、例えば「特定のフォルダ内のすべてのケース」や「'semantic-valid'タグを持つすべてのケース」、または「P0優先度のすべてのテストシナリオ」といったフィルタリングルールを保存します。
動的モードでは、テストスイートが実行されるたびに、システムはこれらのルールを使用してプロジェクトを再スキャンし、現在一致するすべてのケースを含めます。属性（フォルダ、タグ、優先度）がルールに一致するテストケースまたはシナリオは、すべて自動的に含まれます。
静的モード vs 動的モード: 選択方法
どちらのモードも一概に優れているわけではなく、それぞれ異なるニーズに対応します。選択は、スイートが時間の経過とともにどのように動作することを望むかにかかっています。
厳密に範囲を限定した専用テスト（例: 固定のリグレッションセット）の場合、静的モードはより予測可能です。継続的なイテレーションや「自動オンボード」のリグレッションまたはスモークテストの場合、動的モードはメンテナンスを大幅に削減します。
2つのモードの簡単な比較については、以下の表を参照してください。
| 側面 | 静的モード | 動的モード |
|---|---|---|
| コアロジック | 特定のケースIDを保存 | フィルタリングルールを保存（フォルダ、タグ、優先度など） |
| 時間経過によるコンテンツ | 手動で変更しない限り固定 | 一致するケースが追加または削除されると自動的に更新 |
| メンテナンスコスト | 高い。新しいケースは手動で追加する必要がある | 低い。一度ルールを設定すれば、実行は同期を保つ |
| 典型的な使用例 | バグ修正検証、コアパスの安定性、互換性テスト | フルリグレッション、スモークテスト、リリース受け入れ |
実行順序と高度な設定
コンテンツを追加した後、オーケストレーションリスト内の項目をドラッグして並べ替えることができます。
各実行項目（例: テストシナリオ）について、右側のオプションを通じて実行動作をより詳細に制御できます。
例えば、エラー時のオプションでは、ステップが失敗した場合に続行するか、現在のラウンドをスキップするか、または全体の実行を停止するかを選択できます。繰り返しでは、簡単な安定性チェックのためにスイート全体を複数回実行できます。これらのオプションを組み合わせることで、テストスイートは単なるケースの集まりではなく、制御可能な実行フローとなります。
テストスイートの実行
テストスイートが設定されると、ステージや環境に応じて、ローカルでの手動実行からクラウドベースの自動化まで、いくつかの方法で実行できます。
テストスイートをローカルで実行する
最も直接的な方法は、ApidogクライアントでRunをクリックすることです。実行はローカルマシンから行われ、開発およびデバッグ中の小規模で迅速なチェックに適しています。実行設定で、実行環境を切り替えたり、実行完了時に通知を設定したりできます。
実行が完了すると、Apidogはテストレポートを生成し、UIに表示します。レポートには、各エンドポイントテストケースとテストシナリオが実行順に、明確な合格/失敗ステータスとともにリストされます。個々の項目を開いて詳細を確認できます。
CLI経由でテストスイートを実行する
より大規模なテストセットやヘッドレス環境（例: GUIを持たないサーバー）には、Apidog CLIがより良い選択肢です。Apidogのテスト実行をあらゆるターミナルに提供します。
CLI経由で実行するには、Apidog CLIをインストールし、最新の状態であることを確認してください。その後、テストスイートのCI/CDタブで、生成されたコマンドを使用します。
そのコマンドをターミナルにコピーしてスイートを実行すると、UIと同じフローと結果を確認できます。
実行が完了すると、現在のディレクトリにapidog-reports/という名前のフォルダが作成され、HTMLテストレポートが含まれます。
CLI経由での実行は、CI/CD統合の基盤となります。このコマンドをJenkins、GitLab CI、またはGitHub Actionsに組み込み、コードマージなどの重要な時点でリグレッションテストをトリガーできます。
スケジュールタスク経由でテストスイートを実行する
Apidogはスケジュールタスクをサポートしています。テストスイートのスケジュールタスクタブで、タスクを作成し、その実行スケジュールと実行環境を設定します。
ローカル実行とは異なり、スケジュールタスクはセルフホスト型ランナー上で実行する必要があります。
ランナーは、チームが内部サーバーにデプロイできる軽量プログラムです。ランナーを使用すると、ローカルマシンがオフになっている場合やアクセスできない場合の失敗を回避し、大規模なテスト実行にサーバーのリソースを使用できます。
スケジュールタスクが設定されると、Apidogは指定された時間にランナー上でテストスイートを実行し、実行履歴とレポートをアップロードします。また、問題が発生した際に適切な担当者に迅速に通知されるように、失敗通知を設定することもできます。
まとめ
静的および動的オーケストレーションにより、専用テストの範囲を厳密に保ちつつ、プロジェクトの成長に合わせてリグレッションスイートを自動的に拡張でき、継続的な手動更新は不要です。ローカル実行、CLI統合、スケジュールタスクと組み合わせることで、テストスイートは開発中の迅速なチェックからCI/CDにおける自動リグレッション、本番環境でのスケジュールされたチェックまで、ワークフローのあらゆる段階に適合します。
テストスイートの詳細については、Apidogドキュメントを参照してください。最初のテストスイートを作成し、既存のテストをオーケストレーションし、持続可能な自動リグレッション設定を段階的に構築してみてください。