APIエンドポイントを一度テストすることは簡単です。リクエストを送信し、レスポンスを確認し、すべてが期待どおりに動作することを確認します。本当の課題は、数十、あるいは数百もの異なるデータセットに対して同じテストを実行する必要があるときに始まります。パラメーターを手動で更新し、リクエストを繰り返し送信する作業は、時間がかかるだけでなく、間違いも起こりやすく、規模を拡大することも不可能です。
ここでデータ駆動型APIテストの出番です。手作業でリクエストを書き直したり再送信したりする代わりに、単一のテストケースを定義し、複数の入力データセットで自動的に実行します。これにより、より広範なカバレッジ、高い精度、そしてはるかに少ない手作業でテストが可能になります。
これを効率的に行うには、適切なツールが必要です。Apidogは、CSVおよびJSONファイルを使用したデータ駆動型テストのネイティブサポートを提供することで際立っています。オールインワンのAPI開発・テストプラットフォームとして、Apidogは外部データファイルをテストシナリオにバインドし、繰り返し実行することで、各レスポンスを自動的に検証することを可能にします。
異なるユーザーでのログインフローのテスト、様々なクエリでの検索APIのテスト、あるいは複数のパラメータの組み合わせでのリソース作成のテストなど、Apidogは反復作業を排除し、信頼性が高く包括的なAPIテストをはるかに短い時間で実現するのに役立ちます。
さて、ApidogでCSVとJSONを使用したデータ駆動型APIテストを習得するための完全なステップバイステップガイドを掘り下げていきましょう。
CSVとJSONを使用したデータ駆動型APIテストのステップバイステップガイド

セットアップから実行までの全プロセスを、具体的な例を使って見ていきましょう。ユーザー登録APIエンドポイントをテストします。
ステップ1:ベースAPIリクエストを定義する
まず、テストテンプレートとして機能するAPIリクエストを作成します。
- Apidogで、ユーザー登録エンドポイント(例:
POST /api/v1/users)への新しいリクエストを作成します。 - ヘッダー(例:
Content-Type: application/json)を設定します。 - 「Body」タブでJSONペイロードを作成します。値をハードコードする代わりに、Apidogの動的変数構文
{{}}を使用してプレースホルダーを作成します。
{
"username": "{{username}}",
"email": "{{email}}",
"password": "{{password}}",
"role": "{{role}}"
}
プレースホルダー:{{username}}、{{email}}などに注目してください。Apidogは実行中にこれらをデータファイルからの実際の値に置き換えます。
ステップ2:テストデータファイルを作成する(CSVまたはJSON)
次に、プレースホルダーにデータを供給する外部ファイルを作成します。
オプションA:CSVファイルを使用する
CSVは表形式のデータに最適です。user_data.csvファイルを作成します。
username,email,password,role,expected_status
john_doe,john@example.com,SecurePass123!,user,201
jane_smith,jane@example.com,AnotherPass456!,admin,201
bad_user,not-an-email,short,user,400
duplicate_user,john@example.com,SomePass789!,user,409- 最初の行は、プレースホルダーに一致する変数名(
username、emailなど)と、検証用の追加のexpected_statusを定義します。 - それ以降の各行は、その実行用のデータを含むテストケースです。
オプションB:JSONファイルを使用する
JSONは、ネストされたデータ構造やより複雑なデータ構造に最適です。user_data.jsonファイルを作成します。
[
{
"username": "john_doe",
"email": "john@example.com",
"password": "SecurePass123!",
"role": "user",
"expected_status": 201
},
{
"username": "jane_smith",
"email": "jane@example.com",
"password": "AnotherPass456!",
"role": "admin",
"expected_status": 201
},
{
"username": "bad_user",
"email": "not-an-email",
"password": "short",
"role": "user",
"expected_status": 400
}
]
ステップ3:Apidogでデータ駆動型テストを設定する
ここでApidogの統合ワークフローが真価を発揮します。
- ダッシュボード内の「テスト」タブに移動します(またはテストスイートで新しいテストケースを作成します)。

2. クリックして新しいテストステップを追加し、POST /api/v1/usersリクエストを選択します。

3. テストデータをアップロードする:「テストデータ」>「+新規」をクリックして、user_data.csvまたはuser_data.jsonファイルをアップロードします。Apidogはこれを解析し、データ行のプレビューを表示します。


4. 変数をマッピングする(必要に応じて):Apidogは、列名(CSV)またはプロパティキー(JSON)をリクエスト内の{{variable}}プレースホルダーに自動的にマッピングします。マッピングが正しいことを確認してください。
ステップ4:データ変数を使用してアサーションを記述する
本当の力は、入力データに基づいて異なる期待される結果を検証することにあります。「テスト」タブで、アサーション(「アサート」または「チェック」とも呼ばれます)を記述します。
重要なことに、アサーション内でファイルからの同じデータ変数を参照できます。
例えば、レスポンスステータスコードのアサーションを追加します。
- 期待値:
{{expected_status}}
これは、「最初のテスト実行(john_doe)ではステータスコードが201であることをアサートし、3回目の実行(bad_user)では400であることをアサートする」という意味です。アサーションは各イテレーションで動的に変化します。
ApidogのスクリプトセクションでJavaScriptを使用して、より複雑なアサーションを追加できます。
// 例:成功した作成に対するレスポンスボディを検証する
pm.test("Status code is " + pm.variables.get("expected_status"), function () {
pm.response.to.have.status(pm.variables.get("expected_status"));
});
// 成功した作成を期待する場合のみユーザーIDをチェックする
if (pm.variables.get("expected_status") === 201) {
pm.test("Response has user ID", function () {
var jsonData = pm.response.json();
pm.expect(jsonData.id).to.be.a('number');
pm.expect(jsonData.username).to.eql(pm.variables.get("username"));
});
}
ステップ5:テストを実行し、結果を分析する
「実行」ボタンをクリックします。Apidogは、データファイル内の各行に対して一度、単一のテストステップを複数回実行します。
レポートですべてがまとまります。
Apidogは、以下の内容を示す明確で集計されたレポートを提示します。
- 総イテレーション数:(例:「4/4 Passed」)
- 各データ行の内訳:展開すると、送信された正確なリクエスト(実際の置換された値を含む)と、その特定のイテレーションで受信されたレスポンスを確認できます。
- 失敗は、問題の原因となった特定のデータ行に特定されます。
duplicate_userがステータス409ではなかったために失敗しましたか?すぐにわかります。
これにより、デバッグが信じられないほど効率的になります。どのテストケースが失敗したかを推測する必要はなく、特定のデータセット {"username": "duplicate_user", ...} を持つイテレーションであったことがわかります。
データ駆動型APIテストのベストプラクティス
- 環境固有のデータ:データ駆動型テストとApidogの環境を組み合わせます。環境内にステージングから本番に変化する
base_url変数を持つことができ、CSVファイルには両方に適用可能なテストケースを含めることができます。 - 再利用可能なテストデータ:CSV/JSONファイルをApidogプロジェクト内の中央の場所に保存します。複数のテストスイートが同じデータファイルを参照でき、一貫性が確保されます。
- データファイルをプログラムで生成する:複雑なシナリオの場合、スクリプト(Python、Node.js)を使用して
test_data.csvファイルを生成します。これは、ランダムデータや広範囲の値(例:100種類のpageとlimitの組み合わせでのページネーションテスト)でテストするのに優れています。 - テストのセットアップ/クリーンアップ:データ駆動型テストと組み合わせて、Apidogの事前リクエストスクリプトとテストティアダウン機能を使用します。例えば、
DELETEテストの各イテレーションの前に、削除されるリソースを作成するために事前リクエストスクリプトを使用できます。
まとめ:APIテストのワークフローを変革する
ApidogでのCSV/JSONファイルを使用したデータ駆動型テストは、手動で反復的なチェックから、自動化された包括的な検証へと移行させます。これは、優れたテストの核心原則である「効率性を犠牲にすることなく徹底的であること」を体現しています。
テストデータを外部化することで、チームの誰もが簡単に読み、更新し、理解できるテストシナリオの「生きたドキュメント」を作成できます。Apidogがこの方法論をシームレスに統合しているため、複雑なセットアップは不要で、より信頼性の高いAPIへのまっすぐな道筋が提供されます。
APIを一度に1ケースずつテストするのはやめましょう。今すぐ無料でApidogをダウンロードし、最初のCSVファイルをインポートして、APIテストがいかに強力で効率的であるかを体験してください。
