APIテストとは？

「APIをテストする」と一口に言っても、世の中には様々な手法があり、何をどういう観点で検証するかによって、適したテストの手法は異なります。基本に立ち戻ってAPIテストを整理することで、自分たちのAPIはちゃんと検証できているか、を振り返ることができます。API初心者にも役に立つ内容です。Postman API Night Tokyo 2026 Late Springでの発表資料です。

Transcript

1. All rights reserved by Postman Inc 草薙 昭彦 テクノロジーエバンジェリスト API テストとは？ #APINight
2. テクノロジーエバンジェリスト Postman 株式会社 草薙 昭彦 @postman_japan @nagix
3. はじめに • API テストの全体像と、重要性を知っていただきたい！ • みなさんが作っているシステムの API の品質を高めるとともに、効率よくテストを計画、実施 して楽をしていただきたい！ • 対象者 ◦ API テストにこれから取り組む初学者の方 ◦ なんとなく API テストは整備したほうがいい気がしているけど、手が足りていない、か つ周りを説得する理由が見つからず、なかなか手をつけられずにいる開発者の方 @postman_japan
4. さまざまな API テスト 目的・内容で分類 @postman_japan 範囲・粒度で分類 実行するアプローチ・タイミングで分類 コントラクトテスト 機能テスト パフォーマンステスト （負荷テスト） セキュリティテスト コンポーネントテスト （API ユニットテスト） エンドツーエンドテスト （シナリオテスト） 探索的テスト リグレッションテスト （回帰テスト）
5. なぜ API テストを行うのか？ API は複雑なシステム間の「境界線」である @postman_japan
6. なぜ API テストを行うのか？ API は複雑なシステム間の「境界線」である @postman_japan 異なるシステム間の「契 約（規約）」を担保する • 仕様変更による連鎖 障害を防ぐ • バージョンアップ時 に、接続先に影響を 与えない（互換性があ る）ことを保証 責任分界点を明確に し、原因究明を高速化 する • 問題が「内」か「外」か を切り分ける 境界線を越えてくる「不 正な侵入・攻撃」を防ぐ • 悪意のあるリクエスト を正しくブロックできる か検証
7. API テストで向上させる品質とは？ @postman_japan 機能適合性 性能効率性 互換性 使用性 信頼性 セキュリティ 保守性 柔軟性 ISO/IEC 25010 Product Quality Model より
8. API テストで向上させる品質とは？ @postman_japan 機能適合性 性能効率性 互換性 使用性 信頼性 セキュリティ 保守性 柔軟性 ISO/IEC 25010 Product Quality Model より
9. 自分のサービスにはどのテストが重要なのか？ すべての特性を100%網羅してテストすることはできない 。限られたリソースで効果的なテスト 計画を立てるために、優先順位・トレードオフを考慮 @postman_japan • 個人情報・金融データ：「セキュリティ」。認証・認可や、不正値の検証など 扱うデータの機密性（何が流れるか） • 決済やコア業務：「信頼性」と「機能適合性」。境界値テストや負荷テストなど • 情報参照やマーケティング：「性能効率性」 ビジネスへのインパクト（止まったらどうなるか） • 公開 API：「使用性」「互換性」を重視。ドキュメントやエラーの明確さ • 社内 API：「保守性」「信頼性」を重視。頻繁な仕様変更に耐える自動テスト APIの提供先と利用目的（誰が使うか）
10. さまざまな API テスト 目的・内容で分類 @postman_japan 範囲・粒度で分類 実行するアプローチ・タイミングで分類 コントラクトテスト 機能テスト パフォーマンステスト （負荷テスト） セキュリティテスト コンポーネントテスト （API ユニットテスト） エンドツーエンドテスト （シナリオテスト） 探索的テスト リグレッションテスト （回帰テスト）
11. コントラクトテスト ✅ リクエスト／レスポンスの構造 : JSON のキー名が一致している か、余計なデータが含まれていないか ✅ データ型 : 値が文字列か、数値か、配列か ✅ 必須項目 : 必ず返すべきデータ（ ID など）が含まれているか ✅ HTTPステータスコード : 成功時に 200、エラー時に 400 や 401 が正しく返るか @postman_japan • 「ドキュメントと実装のズレ」を 自動で検知できる • 結合テストのコストを削減 • チームが独立して開発を進 められる API を提供する側と利用する側の間で交わされた インターフェース の仕様（契約）を双方が満たしているか を検証 従来の結合テストのようにシステム全体を起動することなく、 API の 「形」が正しいかどうかを高速に検証できる
12. 機能テスト ✅ 正常系: 正しいパラメータを送ると期待通りの結果が返るか ✅ 異常系・境界値 : 限界値や不正な値を送った際、適切なエラー メッセージとエラーコードが返るか ✅ 状態の変更 : 登録する API（POST/PUT）を叩いた後、データ ベースに正しくデータが保存・更新されているか ✅ ビジネスルールの適用 : 例:「在庫が0の時は購入できない」 @postman_japan • 画面がなくてもビジネスロ ジックを100%検証できる • E2E に比べて高速で安定 • 変化に強いリグレッション（回 帰）テストが作れる API がビジネスロジックや要求仕様通りに正しく処理を行い、期 待されたデータを返すか どうかを検証 コントラクトテストが API の「形（データ構造）」を見るのに対し、機能 テストは API の「中身（処理結果やデータの内容）」が正しいかを厳 格にチェック
13. パフォーマンステスト（負荷テスト） ✅ レスポンスタイム : 許容範囲内（例：平均 2秒以内）か ✅ スループット : 例：1秒あたり何回処理できるか（ RPS） ✅ エラー率 : 負荷が高まった際に、タイムアウトや 500 系のサー バーエラーがどの程度発生するか ✅ リソース利用率 : サーバーの CPU 使用率、メモリ消費量、ネット ワーク帯域などが限界に達していないか @postman_japan • 本番環境でのシステムダウ ンを未然に防げる • UX 低下による離脱を防ぐ • キャパシティプランニング（コ スト最適化）ができる API が特定の負荷状況下において、どれだけの処理能力（ス ループット）や応答速度（レスポンスタイム）を維持できるか を検証 システムが本番環境で大量のリクエストに耐えられるか、ユーザー 体験を損なわないかを事前に確認できる
14. パフォーマンステストの種類 @postman_japan テストタイプ テストの目的 備考 ロードテスト （負荷テスト） アプリケーションが実際の使用状況に近 い負荷のもとでどのように動作するかを 理解する 可用性、並行処理、スループット、レスポ ンスタイムの性能目標を満たしているか どうかを評価 ストレステスト プロダクトを限界まで追い込んで限界が どこにあるかを探る アプリケーションの許容負荷や、 DDoS にどれだけ抵抗できるかなどを明らかに する ソークテスト 長時間にわたって少量の負荷を与え続 ける メモリリークやサーバーデータの許容量 超過などがないかを確認 ベースラインテスト 単一の仮想ユーザーでの負荷の情報を 得る ロードテストやストレステストといったほか のタイプのテストと併用されるのが普通
15. セキュリティテスト ✅ 認証と認可の不備 : 他人のデータや管理者機能へのアクセス ✅ 入力値の検証 : 不正な文字列を送信した際、データベースが改 ざんされたり不正にデータが抜き取られたりしないか ✅ データの過剰な露出 : レスポンスの中に機密情報がないか ✅ レート制限 : サーバーに負荷をかけたり、パスワードを総当たり で破ったりできないか @postman_japan • 情報漏洩や不正アクセスに よるセキュリティ事故防止 • 早期発見による修正コストの 削減 • コンプライアンスへの対応 API に潜む脆弱性（セキュリティ上の欠陥）や設定ミス、不正アク セスへの耐性を検証 機密データの漏洩やシステムの乗っ取りなど、サイバー攻撃による 重大な被害を未然に防ぐために不可欠なプロセス
16. コンポーネントテスト ✅ ビジネスロジックの正当性 : 期待通りの結果が得られるか ✅ 異常系・エッジケースの処理 : 不正な文字列を送信した際、デー タベースの改ざんや不正なデータ抜き取りがないか ✅ カバレッジ : すべてのパスが漏れなく実行されるか ✅ モック／スタブとの連携 : 外部依存関係を擬似的なデータに置 き換えた際、API 内部の処理がスムーズに流れるか @postman_japan • 情報漏洩や不正アクセスに よるセキュリティ事故防止 • 早期発見による修正コストの 削減 • コンプライアンスへの対応 API の最小単位（特定の関数や、単一のエンドポイント） が、デー タベースや他の外部 API などの外部システムから完全に独立した 状態で、意図通りに正しく動作するかを検証 他のシステムや環境と切り離した上で、プログラム内部のロジック や条件分岐が正しいかを高速かつ確実に検証できる
17. エンドツーエンドテスト（シナリオテスト） ✅ 一連の業務フローの整合性 : エラーなく実行できるか ✅ データの永続性と状態変化 : 前の API で行った処理の結果が、 後ろの API に正しく反映されているか ✅ 外部システム連携 : 実際の決済・通知サービス等と連携 ✅ エラーのリカバリー : エラーが発生した際、前の状態にロール バックされるか、適切なエラー画面へ誘導できるか @postman_japan • システム全体の不整合を本 番前に発見できる • リアルなユースケースの品 質を保証できる • 外部環境や設定のミス検知 複数の API、データベース、外部サービスがすべて接続された本番 に近い環境で、ユーザーの実際の利用の流れ （ビジネスロジック のシナリオ）が最後まで正しく機能するかを検証 個々の API の成否だけでなく、システム全体のデータのつながりや 状態の遷移が正しいかを本番さながらに検証できる
18. 探索的テスト ✅ 想定外のパラメーター : 極端な値がエラーになるか ✅ 呼び出し順序の変更 : 順序を崩したりスキップした際に、データ の不整合やクラッシュが起きないか ✅ 境界値やエッジケース : ひらめきに基づく疑問の検証 ✅ エラーメッセージの適切性 : 異常な操作をした際、システム内部 のエラー（スタックトレースなど）が露出していないか @postman_japan • 自動テストや仕様書の死角 にあるバグを発見できる • テスト設計の時間を省く • テストの実行を通じて製品へ の理解が深まる テスターの知識、経験、直感を頼りに、 その場で API を操作しなが らリアルタイムにテストを設計・実行していく手法 自動テストや固定のテストケースではすり抜けてしまうような、想定 外のバグや仕様の盲点を人間の手で臨機応変に暴き出す
19. リグレッションテスト（回帰テスト） ✅ 後方互換性 : 仕様変更によって、既存のクライアントが通信エ ラーを起こしたり、動作しなくなったりしていないか ✅ 副作用: 認証 API を修正することで、関係ないはずの商品検索 API が動かなくなるといった、予期せぬ不具合がないか ✅ 修正したバグの再発防止 : 過去に修正されたはずのバグが、新 しいコードの追加によって再び復活していないか @postman_japan • 開発者が既存のシステムを 壊す恐怖から解放される • デグレの本番流出を阻止 • アジャイルや高頻度なリリー スを支える土台になる APIのコード修正、新機能の追加、バグ修正、またはライブラリの アップデートなどを行った際に、既存の正常に動いていた機能が意 図せず壊れていないかを検証 システムに変更を加えた後、過去にパスしたテストを再び自動実行 することで、副作用による問題を即座に検知できる
20. 比較 @postman_japan テストタイプ 主な検証内容 タイミング 主なメリット コントラクトテスト インターフェースの「契約」 結合前 ドキュメントとの乖離防止 機能テスト 処理の結果や内容 実装時 ビジネスロジックの正確性 パフォーマンステスト スループット・応答速度 負荷試験時 システム障害の回避 セキュリティテスト 脆弱性・認可不備 継続的 情報漏洩リスクの低減 コンポーネントテスト 単一エンドポイントの内部ロジック 実装時 原因の特定が容易 エンドツーエンドテスト 一連の業務フロー 結合後 全体的な不整合の検知 探索的テスト 状況に応じた様々な項目 随時 臨機応変に対応 リグレッションテスト 既存機能の維持 変更時 デグレードの早期発見
21. よくある議論 @postman_japan
22. UI の E2E テストがあるから API のテストは不要？ • UI は API のレスポンスを表示する「窓」にすぎない • UI 上はデータが正しく表示されていても、バックエンドの API でセキュリティの脆弱性や データ不整合、パフォーマンスの劣化が起きていることがある @postman_japan
23. API テストとその他のテストの棲み分けは？ • テスト自動化の構成比率として、 UI を介したE2E （エンドツーエンド）テストを多く作るべきか、それ とも API テストを主軸にすべきかという議論 • E2E テストはコストと時間がかかるため、現在は API テストを中心（ピラミッドの中層）に据えるア プローチが業界の主流となっている @postman_japan テスト数 API テスト このあたり ユニットテスト E2E テスト
24. 複数の API が関わるテストで依存関係がある時は？ • 複数の API が関わるシステムでは、依存先 API を本物のサービスではなく、制御可能な API モックに置き換える ◦ 外部 API（依存している社内 API）の影響をなくし、テスト対象に集中 ◦ 異常系やエッジケースを、モックレスポンスで再現できる ◦ 確定的なレスポンス出力により自動テストが安定化する @postman_japan テストコード サービス A サービス B エンド ポイント モック サーバー エンド ポイント テスト対象
25. テストはできる限り自動化するのがいいの？ • どこまで自動化すべきかは常に議論になる • 一度作って何度も実行するコンポーネントテストやリグレッションテストは自動化が必須 • 一方で、探索的テストや、イレギュラーで複雑なエラーシナリオの検証は、人の目による手 動テストが有効とされている @postman_japan
26. API テストは開発の最終段階に行うもの？ • API テストは「シフトレフト（早期実施）」が鉄則 • API の仕様（スキーマ）が固まった段階でテストケースを作成し、開発の初期段階から API モック（仮のレスポンスを返す API サーバー）を用いてテストを行うことで、手戻りを大幅に 削減できる @postman_japan
27. API ファーストアプローチでテストはどう変わる？ • 仕様書から自動生成したモックサーバーを使うことで、 バックエンドの実装完了を待たずにフロントエンドや連 携システムのテストを即座に開始 • API 仕様を正としてテストを組み立てるため、「ドキュメ ントと実際の挙動が違う」という手戻りが防げる • コントラクトテストが鍵 ◦ バックエンドとフロントエンドの開発を並行して進 めるため、インターフェースのズレを即座に検知 するために必須 @postman_japan
28. まとめ • 目的に応じた適切なテストの組み合わせを ◦ 1つの手法に固執せず、契約・性能・安全の多角的な検証を優先度 をつけて行うことで、API の品質と信頼を高めていく • シフトレフトによる品質の作り込み ◦ 結合テストを待たず、開発の「左側」でバグを潰す文化を定着させ る • CI/CD によるテストの自動化 ◦ テストを儀式から「自動的なガードレール」へ昇華させる @postman_japan
29. ありがとうございました @postman_japan