利益:
- ステータスコード、スキーマ/コントラクト、ビジネスルール、ネガティブ/認可レイヤーでの人工知能のサポートにより、徹底的なAPIテストを実施する機能
- サンプル応答から JSON スキーマを生成し、型と命令的検証を使用してステータス コードのみを確認するという疑似信頼感を回避する機能
- 合成データを使用した認可や IDOR などのセキュリティ シナリオを、認可内でのみ防御目的でテストする機能
最新のソフトウェアのほとんどは、API (アプリケーション プログラミング インターフェイス - 2 つのソフトウェアが特定の契約に従って通信するインターフェイス) を介してバックグラウンドで相互に通信します。モバイル アプリがカートに商品を追加すると、実際にはサーバー上の API にリクエストが送信されます。 API テストでは、インターフェイスに関係なく、この会話が正しく、安全で、一貫性があることを確認します。 UI テストよりも高速で安定しており、より詳細です。人工知能 (AI) は API テストにおいて非常に効率的です。人工知能 (AI) は API 定義からテストを生成し、応答スキーマ (データの構造を定義する規約) を抽出し、エッジ ケースをリストします。ただし、ここでも重要な注意事項が当てはまります。AI は API の実際のビジネス ルールを知りません。 「200 が返された」ことを確認するだけの表面的なテストが生成される傾向があります。あなたの仕事は、テストによって実際の契約とビジネス ロジックが検証されていることを確認することです。
この単元では、Postman、REST Assured、スキーマ検証などのアプローチを使用して、AI サポートの詳細な API テストを設定する方法を学習します。
API テストの層
AI が各層で異なる支援を行い、いくつかの深さで API テストを行うことを検討してください。
1. ステータスコードと基本的な応答。リクエストは予期した HTTP ステータス コード (成功の場合は 200/201、エラーの場合は 400/401/404) を返しますか?これは最も表面的な層です。 AI は簡単に生成しますが、単独では誤った信頼を与えます。
2. スキーマ/契約の検証。応答の構造は契約に適合していますか? 予期されるフィールドは存在しますか、そのタイプは正しいか、必須フィールドは欠落していますか? AI はサンプル応答から JSON スキーマ (JSON ドキュメントの構造を定義する標準) を生成でき、テストはそのスキーマに対して検証できます。これは、フィールドベースのアサートを手動で記述するよりもはるかに堅牢です。
3. ビジネスルールの検証。本当の価値はここにあります: 「1000 TL の注文の場合、割引フィールドは 100 である必要があります」、「キャンセルされた注文は再度キャンセルすることはできません」。 AI は、ルールを指定した場合にのみこれらを検証します。与えないと飛び跳ねてしまいます。
4. ネガティブとセキュリティ。無効なトークンの場合は 401、他人のデータへのアクセスの場合は 403、不正なボディの場合は 400 をクリアします。認可テスト (ユーザーが自分のデータのみにアクセスできることを確認する) は API セキュリティの核心であり、防御目的で行われます。
ヒント: AI に「ステータス コードだけでなく、応答スキーマとそれらのビジネス ルールも検証する」ように指示せずにテストをリクエストしないでください。そうしないと、「200 が返され、合格しました」というテストが残りますが、API が破損したデータを返していることに気付かないことになります。
弱いプロンプト / 強いプロンプト
弱: 「この API のテストを作成します。」
Strong: 「POST /order エンドポイントの REST Assured (Java) テストを作成します。契約: productId と数量は本文で必須です。成功すると 201 と {orderId、合計、割引、ステータス} が返されます。ビジネス ルール: 1000 TL を超えると 10% 割引。数量<=0 の場合は 400。トークンが無効な場合は 401。別のユーザーの注文を確認した場合は 403。テスト: (1) ステータス コード、(2)応答 JSON スキーマの検証、(3) 割引ビジネス ルール、(4) すべてのアサーションを明示的なビジネス ルールにバインドする、200/201 をチェックするだけではありません。
強力なプロンプトにより、契約、ビジネス ルール、セキュリティ シナリオ、スキーマ検証の期待が得られます。
契約テスト: チーム間の分裂を防ぐ
マイクロサービス アーキテクチャ (アプリケーションが互いに独立し API と通信する小さなサービスに分割される構造) では、サービスの応答形式を変更すると、それに接続されている他のサービスが静かに中断されます。コントラクト テスト (プロバイダー サービスとコンシューマー サービスの間の API コントラクトが両側で破られていないことを検証するテスト) は、そのような破棄を早期に発見します。考え方は次のとおりです。消費者は、生産者から期待する応答の形式を「契約」として定義します。変更を加えるたびに、製造元はこの契約に準拠しているかどうかをテストします。したがって、フィールドの名前またはタイプが変更されると、コンシューマーはパイプラインがクラッシュする前にパイプラインに通知します。
AI は、この文脈で 2 つのタスクを加速します。それは、既存の API 応答からの消費者の期待を反映する契約の草案を作成することと、変更によってどの契約条項が破られる可能性があるかを事前にマークすることです。しかし、契約自体はビジネス上の決定です。専門家は、どの領域が本当に重要で、どの変更が下位互換性を損なうのかを判断します。古い消費者は引き続き動作します。 AI が契約書を作成します。それを承認するのはあなたです。
ヒント: API でのフィールドの削除またはフィールド タイプの変更は、ほとんどの場合、重大な変更です。通常、新しいフィールドを追加するのは安全です。 AI に変更を「破壊的または安全」に分類させることで、リリース前のセキュリティ チェックを迅速に行うことができます。
郵便配達員ですか、それともコードベースですか?
基準
郵便配達員/ニューマン
REST保証/コード(Java、C#、JS)
学習
簡単、ビジュアル
コードの知識が必要
バージョン管理
コレクションJSON
ソースコード内で直接
複雑なロジック
制限付き (JS スクリプト)
完全なプログラミング能力
CI/CDの統合
ニューマンと
ビルドに直接依存
スキーマの検証
テストスクリプトあり
ライブラリで強力
チーム規模
小/中
大きい、成熟した
AI は両方のコードを生成します。どちらが欲しいのかを明確にしてください。
コピー可能な 4 つのテンプレート
1) 契約ベースの API テスト:
あなたの役割: シニア API テスト エンジニア。[ツール/言語]: [メソッド + パス] を使用して次のエンドポイントのテストを作成します。契約: [必須フィールド、成功コード、応答構造]。ビジネス ルール: [ルール]。テスト層: (1) ステータス コード (2) 応答スキーマ検証 (3) 各ビジネス ルール (4) ネガティブ + 承認。各アサートを関連するルール/契約条項にリンクします。
2) サンプル応答からのスキーマ生成:
以下のサンプル API 応答から JSON スキーマを生成します。必須フィールド、タイプ、形式制約 (日付、電子メール、数値範囲) を指定します。次に、このスキーマに対して検証するテスト例を示します。応答例: [JSON を貼り付け]
3) ネガティブシナリオと認可シナリオ:
エンドポイント[エンドポイント]のネガティブ テスト ケースとセキュリティ テスト ケースを生成します。含まれるもの: フィールドの欠落/必須、間違ったタイプ、大きすぎる値、無効/期限切れのトークン、未承認のリソースへのアクセス (IDOR - ID 変更による他人のレコードへのアクセス)、レート制限。シナリオごとに予期されるステータス コードとエラー本文を指定します。注: 承認された独自の API でのみテストされます。
4) 擬似信頼制御:
この API テストを確認してください。このテストは、サーバーが正しいステータス コードを返したものの FALSEbody/data を返した場合にキャッチされますか?そうでない場合は、スキーマとビジネス ルールの検証を追加します。テスト: [テストを貼り付け]
ミニケース3個
ケース 1 — スキーマ検証の力。あるチームは、AI を使用して作成したテストのステータス コードをチェックするだけでした。あるバージョンでは、API が誤って合計フィールドをテキスト (「1200」) として返すようになりました。まだ 200 を返していたため、テストは緑色のままでした。モバイル アプリケーションがクラッシュしました。 「サンプル応答からのスキーマ生成」テンプレートを使用して型検証を追加すると、同じエラーがすぐに捕捉されました。
ケース 2 — 権限ギャップ (IDOR)。専門家は、AI によって生成された「ネガティブ シナリオと承認シナリオ」の間で IDOR テストを実行しました。彼は、ユーザー A のトークンを使用してユーザー B の注文 ID を要求しました。API は 200 と B のデータを返しました。これは、深刻な承認の脆弱性です。この防御テストにより、データ漏洩が本番になる前に阻止されました。
ケース 3 — ビジネス ルールのバイパス。 AI は割引エンドポイントに対して 8 つのテストを生成しました。全員が 200 をチェックしていましたが、誰も割引額を確認していませんでした。専門家はプロンプトにビジネス ルールを追加し、それを再現させました。新しいテストにより、割引が 1000 TL 制限で誤って計算されていたことが判明しました (割引は 999 TL にも適用されました)。契約管理だけでは十分ではありません。ビジネスルールの管理は必須です。
よくある間違い
- ステータスコードを見るだけです。 「200が戻ってきました」と言うには破損した本体が表示されない (誤った信頼)。
- スキーマ検証をバイパスします。フィールドのタイプと義務をチェックしない。型の変更はサイレントに渡されます。
- ビジネスルールを提供せずにテストを要求する。 AI はルールを知りません。それは技術的な制御のみを生み出します。
- 否定的なシナリオと権利のシナリオを忘れます。セキュリティの脆弱性 (IDOR、不正アクセス) は、これらのテストによってのみ検出されます。
- 実際の/実稼働トークンとデータを使用します。テストには専用のメディアと合成データを使用します。本物のキーを車両に差し込まないでください。
- 無許可のセキュリティテスト。認可テストは、許可を得て独自の API に対してのみ実行してください。
要約すれば
API テストでは、インターフェイスに関係なく、ソフトウェアの動作を迅速かつ詳細に検証します。 AI;コントラクト テストは、サンプル応答から JSON スキーマとネガティブ/セキュリティ シナリオを生成する際に非常に効率的です。しかし、ステータス コードをチェックするだけの表面的なテストでは、疑似的な信頼感が得られます。ステータス コード、スキーマ検証、ビジネス ルール、ネガティブ、承認の 4 つのレイヤーすべてが必要です。ビジネスルールと契約をプロンプトに入力します。合成データを使用し、認可された場合のみセキュリティ テストを実行します。
アプリケーションタスク
独自のプロジェクトから API エンドポイントを選択します。 AI に「契約ベースの API テスト」テンプレートを使用して 4 層のテストを作成させます。次に、「サンプル応答からのスキーマ生成」によるタイプ/強制検証を追加し、「疑似信頼チェック」を適用します。独自のテスト環境で少なくとも 1 つの IDOR/認可シナリオを実行します。契約違反やビジネスルール違反を見つけたら報告してください。何も見つからない場合は、意図的に文字化けした応答に対してテストを実行して、応答が検出されたことを証明します。
チェックリスト
- [ ] テストの 4 つの層 (ケース、スキーマ、ビジネス ルール、否定/承認) について説明しました。
- [ ] 契約書やビジネスルールを明確にAIに与えました。
- [ ] 応答スキーマ (フィールド、タイプ、命令型) を検証するテストを設定しました。
- [ ] 防御的に少なくとも 1 つの認証/IDOR シナリオを試しました。
- [ ] 実際のトークン/データの代わりにテスト環境と合成データを使用しました。
- [ ] 私は「疑似信頼性チェック」を使用して、すべてのテストが破損した応答を検出することを証明しました。