2.7 APIテスト (API Testing)

「APIテスト」 は、GUI（グラフィカル・ユーザー・インターフェース）を介さず、システム同士がデータをやり取りするための接続口である「API（Application Programming Interface）」を直接呼び出して動作を検証するテストです。

近年、マイクロサービスアーキテクチャやクラウドネイティブな開発が主流となる中で、REST、GraphQL、gRPC、SOAPといったAPIの品質がシステム全体の品質を左右するようになりました。

APIテストは、システムの内部構造やデータモデルの知識を必要とするため、純粋なブラックボックスではなく「グレーボックス」または「ホワイトボックス」のテスト技法としてテクニカルテストアナリスト（TTA）の重要な担当領域となります。

---

TTAがAPIテストで検証すべき「5つの重要ポイント」

APIは、人間ではなく「他のプログラム」が利用するものです。そのため、TTAはプログラムが予期せぬ挙動を示した際のリスクを想定し、以下の観点で厳密なテストを設計します。

1. 入力値の妥当性確認とデータ型（Schema Validation）

APIのエンドポイントに対して、仕様通りにデータ（JSONやXMLなど）を送受信できるかを検証します。

• ポジティブテスト: 正しいデータ型（文字列、整数、ブール値など）や、必須パラメータを含めたリクエストが正常に処理されるか。
• ネガティブテスト: 仕様外のデータ型（数値の項目に文字列を入れる）、文字数オーバー、必須項目の欠落、不正なフォーマット（壊れたJSON）を送信し、APIがクラッシュせずに適切に弾く（バリデーション機能）を確認します。

2. ステータスコードとエラーハンドリング

APIの応答（レスポンス）が、状況に応じた正しいHTTPステータスコードを返しているかを検証します。

• 正常系: 200 OK や 201 Created など。
• 異常系: クライアント側のミスには 400 Bad Request や 404 Not Found を、サーバー側のエラーには 500 Internal Server Error を返すか。
• エラーメッセージの安全性: エラー時に、データベースの構造やスタックトレースといった「ハッカーに悪用される機密情報」をレスポンスに含めてしまっていないか（情報漏洩の防止）を確認します。

3. 状態の遷移とトランザクション（CRUDシーケンス）

APIが「状態（ステート）」を持つ場合、単一の呼び出しだけでなく、連続した呼び出し（シーケンス）が正しく処理されるかをテストします。

• 典型的な CRUD（作成・読み取り・更新・削除） のシナリオを実行します。
  1. POST でリソースを新規作成し、IDを取得する。
  2. GET でそのIDを指定し、作成したデータが正しく取得できるか確認する。
  3. PUT/PATCH でデータを更新し、反映されているか確認する。
  4. DELETE で削除し、その後 GET しても 404 Not Found になることを確認する。

4. 認証（Authentication）と認可（Authorization）

APIエンドポイントが適切に保護されているかを検証します。

• 有効なトークン（APIキーやJWTなど）がない場合、401 Unauthorized で拒否されるか。
• 一般ユーザーの権限で、管理者用APIや他人のデータを操作しようとした場合、403 Forbidden で正しくブロックされるか（認可制御のテスト）。

5. バージョン管理と後方互換性

APIは一度公開されると、既存のクライアント（連携先のシステム）に影響を与えないようにバージョン管理（v1, v2 など）が行われます。

• 古いバージョンのAPIが、仕様変更後もこれまで通り（後方互換性を保って）正常に動作し続けるかを回帰テスト（リグレッションテスト）で保証します。

---

APIテストにおける自動化の重要性

APIテストはGUIテストに比べて**「実行速度が非常に速い」「UIの変更によるテストの破損（Flaky tests）が起きにくい」**という大きなメリットがあります。

そのためTTAは、Postman、SoapUI、RestAssured などのツールを活用してAPIテストを**早期に自動化（シフトレフト）**し、継続的インテグレーション（CI/CD）パイプラインに組み込むことで、バグの早期発見と開発サイクルの高速化に貢献することが求められます。