API Testing

APIテスト 定義

APIテストは、単にいくつかのテストケースを実行するだけでなく、多様な側面を含みます。テストはできるだけ早い段階から開始し、製品リリースまで継続する必要があります。この記事では、架空の機能を例に、そのソフトウェア開発ライフサイクルを追って説明します。

APIテストは要求仕様という出発点から始める必要があります。要求仕様はテスターの視点で十分に確認し、境界条件やシステムを壊す可能性を探ることが求められます。要求仕様の見直しの際は、その点を考慮してください。

要求仕様がすべての関係者に承認された後、テストケースの作成が始まります。この段階では、テスターがテストケースを設計し、テストスイートにまとめます。また、新たな機能のリスクや優先度に応じ、正常動作確認のチェックリストに追加する必要がある場合もあります。

次に、テスト仕様書を作成します。テスト仕様書は、各テストケースの期待される結果や、テスト開始・終了の条件、すなわちエントリーおよびイグジット基準を記述する文書です。

すべての文書が提供され、ソフトウェアがテスト可能な状態になると、テスト実行と報告のフェーズが始まります。テスト管理ツールを用いてレポートが作成され、各機能に対して実施されたテスト結果や、テストを中断した可能性のある問題点がまとめられます。

これらのテストに加え、十分なテスト自動化戦略を導入することも有効です。正しく実施できれば、コストを大幅に削減でき、SoapUI、JMeter、Selenium、Postmanなどのオープンソースツールで実現可能です。

なぜAPIテストが重要か？

APIがなぜ重要なのか疑問に思うかもしれません。開発費用が高額で直接的な投資効果がすぐに現れるわけではありませんが、適切にテストを実施しないと、テスト費用以上に欠陥対応のコストが膨らむ恐れがあります。

APIはシステムの中心に位置しており、大量のトラフィックを処理します。不具合が予期せぬ形で発生すると、サービスの停止やプロセスの不具合、さらにはアクセスしてはならないデータへのアクセスを許すことにもなりかねません。

また、APIはユーザー向け機能だけでなく、他のサービスやサードパーティとの連携も行っているため、すべてがAPIの正しいデータ連携に依存します。

例えば：

input=ReadFromQuotesApi();
ProcessData(input);

このコードは一見安全に見えますが、入力の検証が行われていないため、Quotes Apiから予期しないデータが渡されると、システムがエラーを起こすか、最悪の場合クラッシュする可能性があります。

APIテストの利点

APIテストの大きな利点の一つは、早期にテストを実施できる点です。APIはUIよりも先に開発されることが多いため、迅速なフィードバックが得やすく、API連携部分やAPI自体の改善にも役立ちます。

また、APIテストはエンドツーエンドの手動テストやUI自動テストに比べ、より詳細なコンポーネントテストを実施できるため、コストを大幅に削減できます。

これらの利点により、効果の高いAPIレベルでセキュリティテストに十分なリソースを割くことが可能となります。全レベルでのセキュリティテストは有用ですが、予算に限りがあるため、優先順位を適切に設定する必要があります。

APIを十分にテストし、文書化しておくことで、統合もスムーズになり、APIを利用する側に対して検証済みであることをしっかりと伝えることができます。

‍

APIテストの種類‍

‍単体テスト

単体テストは、アプリのビルドごとに自動実行されるテストとして作成され、コードに近い位置で記述されます。必要なコードカバレッジはAPIのリスクや機能に依存し、良い単体テストは堅固な土台として後続のテストを支えるため、十分に検討する必要があります。

統合テスト

APIはシステムの独立した部品ではなく、各要素を統合する役割を担っています。そのため、正しいパラメータや制約条件でデータを受け渡すこと、さらに受信トラフィックの適切な検証も必要です。

パフォーマンステスト

パフォーマンステストは、非機能要件の中で見落とされがちで、問題を引き起こす可能性があります。テスト環境は本番環境のデータ量の一部しか保持しないため、実際の処理には時間がかかる場合があります。トラフィックの急増や複数の重いプロセスの同時動作も考慮し、テスト環境は本番に近い状態で実施する必要があります。

負荷テスト

負荷テストはパフォーマンステストに類似しており、急激なトラフィックではなく通常の一定の流れを模倣します。これにより、長時間動作時のメモリリークなどの欠陥を防止できます。

実行時エラー検出

これらのテスト全体を通じて、実行時エラー検出機能を有効にしておく必要があります。この機能により、APIは稼働中に発生した欠陥を報告できます。

セキュリティテスト

セキュリティテストは非常に重要ですが、十分な予算が割かれないことも多いです。リスク分析に基づいた適切なセキュリティテストを、専門知識を持つプロにより実施する必要があります。また、各開発者もAPIに関しては一定のセキュリティ意識を持つべきです。

セキュリティテストは、ペンテスト、PENテスト、侵入テストなどとも呼ばれ、APIテストにおいてはエントリーポイント、データの流れ、そして稼働中の不要なシャドウAPIも対象となります。

相互運用性テスト

サードパーティ製のソフトウェアや旧バージョンとの連携は当然ではありません。テスト計画の中で、どのテストを実施するか明記し、過去の経験に基づいて潜在的な欠陥の重大度と優先順位を検討する必要があります。

ファズテスト

アプリの検証前の最終テストとして、APIのすべてのエンドポイントに対してファズテストを実施します。ファズテストではランダムなデータを送信し、結果を入念に確認します。予期しないトラフィックでサーバがクラッシュしたり異常な挙動を示さないか確認してください。リスク分析に応じ、ファズテストの実施方法は構造化された方法となる場合もあり、場合によっては実施しないこともあります。

検証テスト

検証テストでは、ソフトウェアがビジネス要求を満たしているか確認します。テスターは、テスト結果がテスト計画で期待される内容と一致しているかを評価し、その後、ユーザー受入テスト（UAT）で事前に作成されたシナリオを実行し、期待値との差異が報告されるよう案内します。

テストの種類については、記事「How to hack API」で詳しく解説しています。

手法：手動テスト vs 自動テスト

自動テストを考える際、テストの作成や保守に費用がかかる点に注意する必要があります。アプリの処理フローが変わると、APIコールの順序やパラメータが適切でなくなる可能性があり、その都度自動化フレームワークの変更が求められます。しかし、毎日または各リリース毎に多数のテストを実行する場合、その投資は十分に見合うものとなります。一般的には、10回以上テストするものは自動化すべきだと考えます。

APIテスト自動化には多くの利点があります。テストシナリオを迅速に作成でき、多くの境界条件をカバーするテストケースを容易に作成できます。さらに、手動でのテスト実行が減り、ビルドパイプラインに組み込むことが可能です。ビルド時に多数のエラーが発生した場合、エラー修正前に通知を受けることができるため、有用です。

WallarmのFASTによるアプリセキュリティテストのフレームワークを試してみてください。

‍

APIテストの始め方

1. APIの要求仕様を定義する: 良い要求仕様の作成は難しいです。関係者全員から有益な意見を得るため、オープンなコミュニケーションが重要です。開発者、テスター、システムアーキテクト、アナリスト、プロダクトオーナーなど、各専門分野の知識を活かして要求仕様を作成してください。

• このAPIは何に利用されるのか？
• アプリはデータをどのように扱うのか？
• システムは障害時にどう対応するのか？
• システムは出力をどのように処理するのか？
• システムは予期せぬ入力にどう対応するのか？
• APIが送受信するフィールドの要求仕様は？
• 他のAPIとの連携方法、使用するプロトコルなどは？
• 開始・終了基準
• APIや機能の合否基準

2. 次に、本番環境に近いテスト環境を整備します。
3. 文書のレビューも実施してください。これは、実行されない文書を確認する静的APIテストとして行います。
4. APIの詳細なテストやスクリプト設定に入る前に、1つのAPIコールを実行してProof Of Concept（概念実証）を作成します。
5. この段階で、ファズテストやその他未特定の機能テスト、各レベルで実施するテストの計画を立てます。
6. 必要に応じてスタブやドライバーを開発し、完全な環境との統合を待たずにテストを開始できるようにします。
7. APIを完全な環境と統合し、エンドツーエンドのテストシナリオを実行します。
8. テスト結果が要求仕様に合致しているか確認します。テストケースの失敗が必ずしも機能全体の本番リリースを否とするわけではありません。根本原因分析後に慎重なリスク評価を行ってください。
9. 必要な修正を実施し、失敗した機能を再テストします。
10. すべての要求が満たされたら、ユーザー受入テスト（UAT）を開始します。
11. 必要に応じて修正を実施し、再度失敗した機能をテストします。
12. すべての文書が提供され、要求が満たされたら、機能を承認して本番リリースを進めます。
13. 本番リリース前に簡易確認を行い、問題がないかチェックします。
14. リリース後は、ログやサービスデスクの報告などでフォローアップを実施します。

例えば、ユーザーがログインできる機能について、どのようなテストが必要か見てみましょう。

‍

‍

APIテストのベストプラクティス

• テストケースを機能ごとに整理することで、保守性が向上し、アプリの状態を把握しやすくなります。
• APIのワークフロー、アプリ内での位置付け、境界条件を要求仕様に盛り込み、すべての関係者を巻き込んで作成してください。
• 本番環境に近いテスト環境でAPIリクエストをテストしてください。スタブやドライバーでのテストは初期開発に有用ですが、エンドツーエンドのテストはサンドボックス環境で実施する必要があります。
• テストトライアングルに従い、単体テストや統合テストでカバーできない部分は自動化してください。自動化はコスト削減に大きく、早期の問題検出にも役立ちます。