このツールについて
エンドポイントの異常系テストでは、1 か所だけ誤りを入れた同じボディを何度も送ります。そのバリエーションを手で書くのは時間がかかり、漏れも出がちです。JSON Schema を貼り付けると、このツールは type、required、enum、minimum/maximum、minLength/maxLength、format、items の各キーワードをたどって正しいペイロードを組み立て、ルールごとに 1 つずつバリエーションを導き出します。必須フィールドを 1 つずつ削除、各フィールドを誤った型や null に変更、文字列を長さ制限の 1 文字外に、数値を範囲の 1 ステップ外に、不正な enum 値、不正な形式のメールアドレスや日付、未知の追加プロパティ、空のオブジェクトなどです。代わりにボディの例を貼り付けた場合は、存在するフィールドをすべて必須とみなし、値からフォーマットを推測します。$ref、allOf/anyOf/oneOf、pattern は解決されないため、それらのフィールドはご自身で確認してください。
使い方
- JSON Schema か実際のリクエストボディを貼り付けるか、サンプルを読み込みます。どちらかは自動判定されますが、必要に応じて切り替えスイッチで変更できます。
- 正常系テスト用に、正しいペイロードをコピーします。
- 異常系のバリエーションをカテゴリで絞り込み、展開して内容を確認・コピーするか、{name, payload} の JSON 配列としてまとめてエクスポートし、データ駆動テストに使います。
API ペイロード生成ツール のよくある質問
API ペイロードとは何ですか？
API ペイロードとは、リクエストやレスポンスのボディで運ばれるデータのことで、REST API では通常 JSON です。たとえば POST /users リクエストでは {"name": "Asha", "email": "asha@example.com"} を送るかもしれません。メソッド、URL、ヘッダーがリクエストを説明し、ペイロードがその中身です。テストでは、リクエストのペイロードが入力、レスポンスのペイロードがアサーションの対象になるため、どちらも API のコントラクトと一致している必要があります。
API テスト用の JSON ペイロードはどう作ればよいですか？
API のコントラクトから始めます。JSON Schema や実際のリクエストボディをこのツールに貼り付けると、正しいペイロードに加えて、必須フィールドの欠落、型の誤り、範囲外の値、不正な enum など、ルールごとに 1 つの異常系バリエーションが生成されます。JSON としてエクスポートし、テストでループ処理してください。リアルな値を大量に用意するなら テストデータ生成ツール、すぐに使える例なら サンプル JSON ペイロード集をご覧ください。
POST リクエストのペイロードには何を含めるべきですか？
リソースを作成するために API のコントラクトが要求するものだけです。すべての必須フィールドを正しい型とフォーマットで含め、シナリオに関係する任意フィールドを加えます。API が期待していない限り、id や createdAt のようなサーバー側で生成されるフィールドは含めません。Content-Type: application/json ヘッダーを付けて送信します。作成に成功すると通常は 201 Created と新しいリソースまたは Location ヘッダーが返り、不正なペイロードには 400 か 422 とわかりやすいエラーが返るべきです。
異常系テスト用のペイロードはどう作ればよいですか？
正しいペイロードを 1 つ用意し、テストごとに 1 か所だけ壊します。そうすれば、失敗が 1 つのルールを指し示します。典型的なバリエーションは、必須フィールドを 1 つずつ削除する、誤った型や null を送る、長さや数値の上限を 1 だけ超える、不正な enum 値や不正な形式のメールアドレスを使う、未知のプロパティを追加する、空のオブジェクトを送る、などです。いずれも 4xx ステータスとわかりやすいエラーで拒否されるべきで、500 になってはいけません。このツールはスキーマからそれらのバリエーションを自動で導き出します。
よく使われる JSON ペイロードの形式にはどんなものがありますか？
ほとんどの REST API は JSON オブジェクトを使い、address を持つユーザーのようにネストしたオブジェクトを含むことがよくあります。ほかによくある形は、一括操作用のオブジェクトの配列、結果を data と meta フィールドで包むエンベロープ、query と variables を持つ GraphQL リクエスト、エラー用の RFC 9457 problem details（type、title、status、detail）です。リアルなリクエスト・レスポンスのボディは サンプル JSON ペイロード集で確認できます。
API テスト用にランダムなテストデータを生成できますか？
はい。ランダムなデータは手で選んだ値では見逃すバグを見つけますが、再現可能であるべきです。テストデータ生成ツールは Faker を使ってリアルな氏名、メールアドレス、住所、UUID、数値、日付を生成し、シードを固定すれば毎回同じデータが返るため、失敗したテストを再実行できます。テストコード内では、JavaScript や Python の Faker ライブラリ、Java の Datafaker で同じことができます。エッジケースの文字列には テスト文字列生成ツールを使ってください。
異常系ペイロードはどのステータスコードを返すべきですか？
通常は 400 Bad Request か 422 Unprocessable Content で、エラーボディにフィールド名が含まれます。API のドキュメントがどちらを採用していても、エンドポイント間で一貫しているべきで、これらのバリエーションで 500 が返ることがあってはなりません。
エクスポートした JSON をテストで使うには？
配列を読み込んでループします。Playwright では for (const { name, payload } of variants) test(name, ...)、JUnit 5 では JSON ソースを使った @MethodSource や @ParameterizedTest、Postman ではコレクションランナーのデータファイルとして使います。
一部のフィールドで「Null value」（null 値）が生成されないのはなぜですか？
スキーマがそのフィールドに null を許可している場合（type: ["string", "null"] や enum に null を含む場合）、null を送るのは正しい入力なので、異常系のケースにはなりません。