APIテストとは何か？REST APIテストの正攻法 Vol.3
DXのデータ連携を実現するREST APIのテスト手法についてご紹介する記事です。
「APIテストとは何か？REST API テストの正攻法」ページへ自動的に遷移します。
はじめに
この記事は、「Vol.2 APIテストとは何か？REST API テストの正攻法」の続きです。ここでは、REST APIのさまざまなテスト手法について、使いどころや利点なども含めて説明します。
前の記事を読む：
REST API のコントラクトテスト
REST API は、２つ以上のシステムやデバイス間のデータ連携をコントラクト（APIの仕様を記述した設計書のようなもの）に基づいて行います。コントラクトには、インターフェイスとの連携方法、利用可能なサービス、呼び出し方法などが記述されており、コミュニケーション（データ連携）の基礎となります。コントラクトに誤りがある場合、どうしようもありません。
最初に行う最も基本的なタイプの REST API テストは、サービスコントラクト自体（Swagger、RAML、WSDL、XMLスキーマなど）をテストするコントラクトテストです。このタイプのテストでは、コントラクトが正しく書かれており、クライアントによって解読できることを検証します。このテストでは、コントラクトを読み込んで以下を検証するテストを作成します：
- サービスコントラクトが仕様に従って記述されている
- メッセージ要求と応答のセマンティクスが正しい（スキーマ検証）
- エンドポイントが有効である（HTTP、MQ/JMSトピック/キューなど）
- サービスコントラクトが変更されていない
これらは最初に行うテストです。これらのテストが失敗した場合、そのサービスを引き続きテストする意味はありません。これらのテストに合格してはじめて、REST API の機能テストを開始できます。
REST API のコンポーネントテスト（単機能テスト）
コンポーネントテストは、REST API に対する単機能テスト（ユニットテスト）のようなものです。つまり、REST API として提供する個々のメソッドを個別にテストします。コンポーネントテストを作成するには、サービスコントラクトで利用可能な各メソッドまたはリソースに対応するテストステップを作成します。
コンポーネントテストを作成する最も簡単な方法は、サービスコントラクトを読み込んで自動的にテストドライバーを作成することです。その後、正常系と異常系のデータを使用して個々のテストケースをデータ駆動し、REST API のレスポンスが次のような特性を持つことを検証します。
- リクエストのペイロードが整形式である（スキーマの検証）
- レスポンスのペイロードが整形式である（スキーマの検証）
- レスポンスのステータスコードが期待通りである（200 OK、SQL結果セットが返される、またはエラーが期待される場合はエラーが返される）
- レスポンスエラーペイロードに期待するエラーメッセージが含まれている
- レスポンスが期待されるベースラインと一致する。これには２つの検証方法があります。
- 回帰/差分 – レスポンスのペイロードが、過去のテスト結果と全く同じであること（過去のレスポンス全体のスナップショットを取得し、それと比較してレスポンス全体を検証するアプローチ）。これは、REST API の変更を検出するための有効な手段であり、回帰テストで効果を発揮します（詳細は後で説明します）。
- アサーション – レスポンスに含まれる個々の項目の値が期待通りであること（レスポンスの特定の項目の値に対する期待値を設定し、それと比較して検証するアプローチです）。
- サービスが期待された時間内に応答する
関連ページ
REST API のシナリオテスト
シナリオテストは、REST API テストと言ったときに、ほとんどの人が思い浮かべるテストです。このテスト手法では、「APIテストとは何か、REST APIテストの正攻法 Vol.1」の ショッピングサービスの例と同様に、個々のコンポーネントテストを一連のシーケンスに組み立てます。
シーケンスを検証するには2つの方法があります：
- ユーザーストーリーを確認して、個々の REST API 呼び出しを特定する
- UI を操作し、バックエンドとのデータ連携で用いられる REST API のトラフィックを取得する
シナリオテストでは、異なるデータポイント（REST API で取得したデータを用いて、異なる REST API からデータを取得するなど）を組み合わせたときに欠陥がないかどうかを検証できます。
シナリオテストは非常に重要です。たとえば、顧客の財務プロフィール、利用可能なアカウント、クレジットカード、および最近の取引を呼び出すのに、一連のサービス（REST API）を使う必要がある場合、個々の REST API テスト結果が正しくてもシーケンスにまとめると失敗する事がよくあります。たとえば、その理由がタイムスタンプであったとします。１つの REST API 呼び出しから返されたタイムスタンプが、後続のリクエストで期待される形式とは異なる形式であったことが原因であり、コンポーネントテスト（単機能テスト）やスモークテストでは、形式を指定せずにタイムスタンプが返されたことだけをアサーションしていたため、問題を捕捉できませんでした。全体的な REST API のシナリオテストを実行して初めて、ある呼び出しから別の呼び出しにタイムスタンプを渡すと、エラーの原因になることが明らかになるような、テスト間のデータの受け渡しなども含めた検証が可能になります。
シナリオテストのもう１つの利点は、想定していない方法で REST API が利用された時の動作を検証できることです。REST API をリリースするということは、システムを構築するための材料となるブロックを世界中（または特定の範囲）に提供するということです。ブロックを組み合わせる方法を規定しておいたとしても、REST API の利用者は予想外の発想を持っている事があり、想定していない方法で REST API を一連のシーケンスとして組み合わせ、利用し、結果としてシステムの不具合を露呈させる事があります。これを防止するためにも、REST API をさまざまに組み合わせて多数のシナリオテストを作成し、システムを致命的なエラーから防護する必要があります。
シナリオテストを構成する要素としてコンポーネントテスト（単機能テスト）が存在しているため、通常、シナリオテストの数は多くなります。シナリオテストは、新しい機能が導入されたときに構築され、新しい機能に関するユーザーの動線をモデル化します。
関連ページ
REST API のパフォーマンステスト
REST API のパフォーマンステストは、通常、パフォーマンステスト専用の環境で、テストプロセスの最後に実施される傾向があります。これは、パフォーマンステストソリューションが高価で、特殊なスキルセットを必要とし、特定のハードウェアと環境を必要とする場合が多いためです。一方で、REST API には SLA（サービス品質保証）が設定されており、アプリケーションをリリースするにはこれを満たす必要があります。もし、ぎりぎりまでパフォーマンステストの実施を保留し、SLA を満たすことができなかった場合、大幅にリリースが遅延する可能性があります。
開発プロセスのより早い段階で REST API のパフォーマンステストを行うことで、早期にパフォーマンス関連の問題を発見できます。REST API のコンポーネントテスト（単機能テスト）やシナリオテストを実行済みである場合、パフォーマンステストを行うために必要なテストケース（テスト資産）が既にすべてそろっているため、実はかなり簡単にパフォーマンステストを実行できます。作成済みのシナリオテストを REST API のパフォーマンステストツールにロードし、同時接続ユーザー数を増やして実行するだけです。マネージャーは、このテスト結果の情報に基づいて、アプリケーションをリリースするかしないかについて決断を下すことができます。
関連ページ
REST API のセキュリティテスト
REST API のセキュリティテストは、組織内のすべての関係者にとって重要です。セキュリティ上の脆弱性が公開され、悪用されると、深刻なイメージダウンと金銭的ペナルティが発生する可能性があるためです。ユーザーが誤って予想外の方法で REST API を使用する可能性があるように、ユーザーは意図的に REST API を悪用しようとする可能性があります。ハッカーは REST API を入手し、脆弱性を発見し、それらを利用することができます。
この種の動作を防ぐためには、悪質な攻撃をシミュレートする REST API のテストケースを作成する必要があります。REST API のシナリオテストはアプリケーションへ故意に攻撃するシナリオとしても流用できるため、既存のテストケースをセキュリティテストに活用することができます。たとえば、さまざまなタイプのパラメーターファジングまたは SQL インジェクション攻撃をシナリオテストに組み込むのが良い例です。
関連ページ
まとめ
適切な REST API のテスト戦略で開発に臨む事は、データ連携が欠かせないアプリケーションが「今日も昨日と同じように動く」ことを保証する上で非常に価値のある事です。REST API に限らず、SOAP, MQ, MQTT, Kafka, protobuf, WebSocket などを含む API のテストは、アプリケーションのレイヤー毎の品質を確保（欠陥を検出）するために欠かせません。また、API テストは UI テストよりもはるかに変更が生じにくく、一貫性があるため、既に作成した API のテスト資産を今後も長期間にわたって利用（運用）しやすいのも特徴です。Jenkins などの CI/CD パイプラインで、これらの API テストの実行をすべて自動化し、アプリケーションの品質を継続して確保する仕組みを構築する事もよくあるテストプラクティスです。
このページは、「Vol.2 APIテストとは何か？REST API テストの正攻法」の続きです。Vol.1からVol.3をまとめて読む場合は、資料ダウンロードいただけます。
イベント・セミナー
APIのテスト自動化とサービス仮想化を1ツールで SOAtest/Virtualizeに
関するお問い合わせ
テクマトリックス株式会社
東京本社ソフトウェアエンジニアリング事業部
03-4405-7853
- メールでのお問い合わせ
- parasoft-info@techmatrix.co.jp
