このチュートリアルでは、APIテスト、Webサービス、および組織でAPIテストを導入する方法についてのすべてを説明します：
この入門チュートリアルでは、APIテスト、シフトレフトテスト、Webサービスの概念について深く理解することができます。
このチュートリアルでは、Web APIの概念、APIの仕組み（実例付き）、Webサービスとの違いについて、例を挙げながら丁寧に説明しています。
APIテストチュートリアルの一覧
チュートリアルその1： APIテストチュートリアル：初心者のための完全ガイド
チュートリアルその2： Webサービスチュートリアル：コンポーネント、アーキテクチャ、種類と例
チュートリアルその3： トップ35 ASP.Net And Web API Interview Questions With Answers
チュートリアルその4： POSTMANチュートリアル：POSTMANを使ったAPIテスト
チュートリアル第5弾： Apache HTTP Clientを用いたWebサービステスト
このAPIテストシリーズにおけるチュートリアルの概要
| チュートリアル # | 何を学ぶか |
|---|---|
| Tutorial_#1です： | APIテストチュートリアル：初心者のための完全ガイド このチュートリアルでは、APIテストとウェブサービスについて詳しく説明し、組織でAPIテストを導入する方法についても学びます。 |
| Tutorial_#2です： | Webサービスチュートリアル：コンポーネント、アーキテクチャ、種類と例 このチュートリアルでは、Webサービスのアーキテクチャ、種類、コンポーネント、重要な用語、SOAPとRESTの違いについて説明します。 |
| Tutorial_#3です： | トップ35 ASP.Net And Web API Interview Questions With Answers このチュートリアルでは、最も人気のある頻繁に尋ねられるASP.NetとWeb APIのインタビューの質問のリストと答え＆amp; 初心者と経験豊富な専門家のための例を探ることができます。 |
| Tutorial_#4です： | POSTMANチュートリアル：POSTMANを使ったAPIテスト このチュートリアルでは、POSTMANを使用したAPIテストについて、POSTMANの基本、コンポーネント、サンプルリクエストとレスポンスとともに、簡単に理解できるように説明します。 |
| Tutorial_#5です： | Apache HTTP Clientを用いたWebサービステスト このAPIチュートリアルでは、Webサービスに対する様々なCRUD操作の実行と、Apache HTTP Clientを使ったWebサービスのテストについて説明します。 |
APIテストチュートリアル
このセクションでは、WebサービスとWeb APIの基本的な理解を深めることができ、ひいてはこのAPIテストシリーズの今後のチュートリアルで主要な概念を理解するのに役立つことでしょう。
API（Application Programming Interface）とは、オペレーティングシステムやプラットフォームのデータや機能にアクセスしてアプリケーションを作成するためのすべての手順や機能の集合です。 このような手順をテストすることをAPIテストと呼びます。
シフトレフトテスト
APIテストの面接で最近聞かれるようになった重要なテストの種類の1つがShift Left Testingです。 このタイプのテストは、アジャイル手法に従うほぼすべてのプロジェクトで実践されています。
Shift Left Testingが導入される以前は、コーディングが完了し、コードがテスターに渡された後にソフトウェアテストが実施されていました。 このやり方では、納期に間に合わせるために直前まで奔走することになり、製品の品質を大きく阻害することになりました。
それとは別に、本番前の最終段階で不具合が報告されると、開発者は設計とコーディングの両方をやり直さなければならないため、その努力は大変なものでした。
ソフトウェア開発ライフサイクル（SDLC） ビフォア・シフト・レフト・テスト
従来のSDLCの流れは、要件 -> 設計 -> コーディング -> テストでした。
従来のテストのデメリット
- テストは極端な話、ギリギリでバグを発見すると、多くのコストが発生する。
- バグを解決し、本番に昇格させる前に再テストするために消費される時間は膨大です。
そこで、テストフェーズを左に移すという新しいアイデアが生まれ、それが「Shift Left Testing」につながった。
お勧めの読み物 =>； Shift Left Testing: ソフトウェアを成功させるための秘密のマントラ。
レフトシフトテストのフェーズ
左遷テストは、「欠陥検出」から「欠陥防止」への移行を成功させ、また、ソフトウェアの高速フェイルファーストと、すべての不具合を早期に修正することを可能にしました。
ウェブAPI
一般的に、Web APIとは、クライアントシステムからWebサーバーへのリクエストを受け、Webサーバーからクライアントマシンにレスポンスを返すものと定義できます。
APIの仕組みは？
複数の航空会社の情報を集約したオンライン旅行サービスであるwww.makemytrip.com、航空券を予約するというごく一般的なシナリオを考えてみましょう。航空券を予約する際には、出発日/帰国日、クラスなどの情報を入力し、検索をクリックすることになります。
この場合、アプリケーションは複数の航空会社のAPIと対話することで、航空会社のデータにアクセスできるようになります。
例えば、ある都市のホテルの価格や空室状況などを比較・表示する「www.trivago.com」は、複数のホテルのAPIと通信してデータベースにアクセスし、各ホテルのウェブサイトから価格や空室状況などを表示する。
このように、Web APIは「クライアントマシンとWebサーバーの間の通信を容易にするインターフェース」と定義することができます。
ウェブサービス
Webサービスとは、（Web APIと同様に）あるマシンから別のマシンへサービスを提供するものですが、APIとWebサービスの間に生じる大きな違いは、Webサービスがネットワークを利用することです。
すべてのWebサービスはWeb APIですが、すべてのWeb APIはWebサービスではありません（後述）。 したがって、WebサービスはWeb APIのサブセットです。 Web APIとWebサービスの詳細については、下図を参照してください。
Web APIとWebサービスとの比較
ウェブサービスとウェブAPIの比較
Web APIもWebサービスも、クライアントとサーバーの間の通信を円滑にするために使用されます。 大きな違いは、通信の方法だけです。
それぞれ、特定の言語で受け入れられるリクエストボディが必要であること、安全な接続を提供するための違い、サーバーへの通信とクライアントへの返答の速度などです。
Web サービスと Web API の違いを以下に示しますので、ご参考にしてください。
ウェブサービス
- ウェブサービスは一般的にXML（Extensible Markup Language）を使用しているため、より安全です。
- Web Servicesは、WebサービスもAPIもデータ転送時にSSL（Secure Socket Layer）を提供するのでより安全ですが、WSS（Web Services Security）も提供されます。
- Web Serviceは、Web APIのサブセットです。 例として、 ウェブサービスは、3つの利用スタイル（すなわち、3つのスタイル）にのみ基づいています。 SOAP、REST、XML-RPC。
- Webサービスの運用には、必ずネットワークが必要です。
- Webサービスは「One Code different applications」をサポートします。 これは、異なるアプリケーション間で、より汎用的なコードが記述されることを意味します。
ウェブAPI
- Web APIは一般的にJSON（JavaScript Object Notation）を使用するため、Web APIは高速です。
- JSONはXMLと違って軽量なため、Web APIは高速です。
- Web APIは、Webサービスの上位概念です。 例として、 Webサービスの3つのスタイルは、Web APIにも存在しますが、それとは別に、JSON - RPCのような他のスタイルも使用します。
- Web APIは、必ずしもネットワークを必要としません。
- Web APIは、システムやアプリケーションの性質によって、相互運用性をサポートする場合としない場合があります。
組織におけるAPIテストの導入
日々の生活の中で、私たちはAPIを使ってアプリとやりとりすることに慣れていますが、根本的な機能を駆動するバックエンドのプロセスについては考えもしません。
例として、 例えば、Amazon.comで商品を見ていて、気に入った商品があり、それをFacebookのネットワークで共有したいと考えたとしましょう。
ページの共有セクションにあるFacebookのアイコンをクリックし、Facebookアカウントの認証情報を入力して共有した瞬間、AmazonのウェブサイトとFacebookをシームレスに接続しているAPIと対話することになります。
APIテストへのフォーカスシフト
APIテストについて詳しく説明する前に、APIベースのアプリケーションが最近人気を博している理由について説明しましょう。
企業がAPIベースの製品やアプリケーションに移行する理由はいくつかありますが、参考までにそのいくつかを以下に列挙しておきます。
#1) APIベースのアプリケーションは、従来のアプリケーションやソフトウェアと比較して拡張性が高く、コード開発の速度が速く、コードやインフラを大きく変更することなく、同じAPIでより多くのリクエストを処理することができます。
#2) 開発チームは、機能やアプリケーションの開発に着手するたびにゼロからコーディングを始める必要はありません。 APIは、多くの場合、既存の繰り返し使える関数、ライブラリ、ストアドプロシージャなどを再利用するため、このプロセスによって全体的に生産性が向上します。
例として、 もしあなたがeコマースサイトの開発者であり、Amazonを決済手段として追加したい場合、ゼロからコードを書く必要はありません。
Integration keysを使用してWebサイトとAmazon APIを連携させ、チェックアウト時にAmazon APIを呼び出して決済処理を行うだけです。
#3) APIは、スタンドアロンのアプリケーションだけでなく、APIベースのソフトウェア製品でも、他のシステムとの容易な統合を可能にします。
例として トロントからニューヨークへ荷物を送りたい場合、インターネットで有名な貨物や物流のウェブサイトを開き、必要な情報を入力します。
必須情報を提供した後、「料金取得」ボタンをクリックすると、バックエンドで、この物流ウェブサイトは、複数のキャリアやサービスプロバイダーのAPIやアプリケーションに接続して、出発地から目的地の組み合わせに対する動的な料金を取得することができます。
APIテストのフルスペクトル
APIのテストは、APIにリクエストを送り、レスポンスを解析して正しさを確認するだけにとどまりません。 APIは、脆弱性がないか、異なる負荷での性能をテストする必要があります。
詳しく解説していきましょう。
(i) 機能テスト
機能テストは、GUIインターフェースがないため、困難な作業となることがあります。
APIの機能テストは、GUIベースのアプリケーションとどのように違うのか、また、その周辺の例について説明します。
a) 最も明確な違いは、GUIがないことです。 通常、GUIベースの機能テストを行うテスターは、すでにGUIに慣れている人に比べて、非GUIアプリケーションテストに移行するのが少し難しく感じます。
APIのテストを始める前に、まず、認証プロセスそのものをテスト・検証する必要があります。 認証方法はAPIごとに異なり、認証のために何らかのキーやトークンを使用することになると思います。
このプロセスは、標準的なアプリケーションのユーザー認証に相当し、アプリケーションにログインして使用するために有効な認証情報が必要であると考えることができます。
b) 実際のフォームベース（GUI）のインターフェースがあれば、フロントエンドやバックエンドにフィールドバリデーションを実装し、ユーザーが無効なフィールド値を入力できないようにすることができます。
例として、 アプリケーションで日付形式がDD/MM/YYYYである必要がある場合、アプリケーションで有効な日付を受信して処理していることを確認するために、情報を収集するフォームでこの検証を適用することができます。
しかし、APIアプリケーションの場合はそうはいきません。 APIが適切に記述され、これらの検証をすべて実施し、有効なデータと無効なデータを区別し、ステータスコードと検証エラーメッセージを応答としてエンドユーザーに返すことができることを確認する必要があります。
c) テストAPIからのレスポンスとしてステータスコード200（オールOKの意味）が返ってきても、レスポンステキストに「エラーが発生しました」とあれば、それは不具合です。
さらに、エラーメッセージ自体が正しくない場合、このAPIと統合しようとしているエンドカスタマーにとって、非常に誤解を招くことになります。
下のスクリーンショットでは、ユーザーが許容範囲である2267Kgsを超える無効な重量を入力しました。 APIはエラーステータスコードとエラーメッセージを応答します。 しかし、エラーメッセージでは重量単位がKGではなくlbsと誤って記載されています。 これはエンドユーザーを混乱させる可能性のある欠陥です。
(ii) 負荷テストと性能テスト
APIは設計上、スケーラブルであることが前提です。
特に、設計中のシステムが、要件に応じて毎分または毎時何千ものリクエストに対応することが予想される場合、このことが、負荷テストと性能テストを不可欠にします。 APIに対して負荷テストと性能テストを定期的に実行することで、性能、ピーク負荷、限界点のベンチマークに役立ちます。
このデータは、アプリケーションのスケールアップを計画しているときに役立ちます。 この情報があれば、特に組織がより多くの顧客を追加することを計画している場合、より多くの受信要求を意味する、意思決定と計画のサポートに役立ちます。
組織でAPIテストを導入する方法
APIテストを組織に導入するプロセスは、他のテストツールやフレームワークを導入したり展開したりするプロセスと同様です。
以下の表は、主なステップと、各ステップで期待される結果をまとめたものです。
| フェーズ | ステップ | 期待される成果 |
|---|---|---|
| ツールセレクション | 要件を収集し、制約条件を特定する | 適切なAPIテストツールの市場を調査するための要件を理解する。 例 テストされるAPIはどのようなものですか - SOAPですか、RESTですか？ この役割のためにテスターを雇う必要があるのか、既存のテスターを訓練する必要があるのか。 機能テスト、性能テストなど、どのようなテストを行うか。 実施に必要な予算は？ |
| 利用可能なツールを評価する | 利用可能なツールを比較し、要件を最もよく満たす1～2個のツールをショートリスト化する。 | |
| プルーフオブコンセプト | 候補に挙がったツールでテストのサブセットを実施する。 ステークホルダーに調査結果を発表する。 導入するツールの最終決定を行う。 | |
| インプリメンテーション | はじめに | 選択したツールによって、PC、仮想マシン、サーバーのいずれかに必要なツールをインストールする必要があります。 選択したツールがサブスクリプションベースの場合、必要なチームアカウントを作成します。 必要であれば、チームをトレーニングする。 |
| ゲットゴーイング | テストの作成 テストの実行 不具合報告 |
一般的な課題とその解決方法
APIテストフレームワークを組織に導入しようとする際に、QAチームが直面する一般的な課題について説明しましょう。
#その1）正しいツールの選択
APIテストツールは、市場に出回っているものの中で、最も一般的な課題である。
最新で高価なツールを導入するのはとても魅力的ですが、それが期待通りの結果をもたらさないのであれば、そのツールは役に立ちません。
したがって、組織のニーズに基づいて「必ず必要な」要件に対応するツールを常に選択する必要があります。
以下は、利用可能なAPI Toolsのツール評価マトリックスの例です。
| ツール | 価格設定 | 備考 |
|---|---|---|
| ソープUI | SoapUIオープンソースの無償版提供（機能検証中） | * REST、SOAP、その他一般的なAPIやIoTのプロトコルを使用。 * 無料版に含まれるもの SOAPとRESTのアドホックテスト メッセージアサーション ドラッグ＆ドロップでテスト作成 テストログ テストコンフィギュレーション 録音からのテスト 単位で報告する。 * 機能一覧は、同社ホームページでご覧いただけます。 |
| ポストマン | ポストマンアプリを無料で利用できる | * RESTに最も多く使用されている。 * 特徴は、同社のホームページで確認できます。 |
| パラソフト | 有償のツールであり、ライセンスの購入が必要で、その後、ツールを使用する前にインストールが必要です。 | * 総合的なAPIテスト：機能テスト、負荷テスト、セキュリティテスト、テストデータ管理 |
| ブイレスト | ユーザー数ベース | * REST APIテストの自動化。 * 録画・再生が可能です。 * モックAPIを利用したフロントエンドとバックエンドの依存関係を解消。 * 強力なレスポンス・バリデーション。 * localhost/intranet/internetに配置されたテストアプリケーションで動作します。 * JIRA Integration、Jenkins Integration Swagger、Postmanからインポートする。 |
| HttpMaster | エクスプレス版：ダウンロード無料 プロフェッショナル版：ユーザー数に応じて | * WebサイトのテストやAPIのテストを支援します。 * その他、グローバルパラメーターの定義や、豊富なバリデーションタイプを利用したデータレスポンス検証のためのチェック機能などを備えています。 |
| ランスコープ | ユーザー数、プランの種類に応じて | * APIの監視・テスト用。 * 正しいデータが返されるように、データ検証に使用することができます。 * APIトランザクションの失敗を追跡し、通知する機能を備えています（アプリケーションで決済の検証が必要な場合、このツールは良い選択であることを証明できます）。 |
| ロードフォーカス | ユーザー数、プランの種類に応じ | * APIの負荷テストに使用可能 - APIがサポートできるユーザー数を調べるためにいくつかのテストを実行することができます。 * 簡単な操作で、ブラウザ上でテストを実行することができます。 |
| PingAPI | 1プロジェクト（1,000リクエスト）までは無料です。 | * 自動化されたAPIテストとモニタリングに有益です。 |
#その2）テスト仕様書の欠落
テスターとして、アプリケーションを効果的にテストするためには、期待される結果を知る必要があります。 期待される結果を知るためには、明確で正確な要件が必要ですが、そうではないため、しばしば困難が伴います。
例として は、以下の要件を満たしている必要があります：
"アプリケーションは有効な出荷日だけを受け入れ、無効な要件はすべて拒否されるべきである"
これらの要件には、重要な詳細が欠けており、非常にあいまいです。 有効な日付をどのように定義するのか、形式はどうするのか、エンドユーザーに拒否メッセージを返すのか、などです。
明確な要求事項の例：
1) アプリケーションは、有効な出荷日だけを受け入れる必要があります。
であれば、出荷日は有効であると判断されます。
- 過去にない
- 本日の日付より大きいか等
- 形式：DD/MM/YYYY です。
2)
応答ステータスコード = 200
メッセージ：OK
3) 上記の条件を満たさない出荷日は、無効とみなす。 お客様が無効な出荷日を送信した場合、以下のエラーメッセージ（複数可）で応答する必要があります：
3.1
応答ステータスコード NOT 200
エラー：入力された出荷日は無効です。日付がDD/MM/YYYYフォーマットであることを確認してください
3.2
応答ステータスコード NOT 200
エラー：提供された出荷日が過去になっている
#その3）ラーニングカーブ
前述したように、APIテストのアプローチは、GUIベースのアプリケーションをテストする際のアプローチと比較すると、異なります。
APIテストのために社内やコンサルタントに専門家を雇っている場合、APIテスト手法やAPIテストツールの学習曲線は最小限かもしれません。 この場合、学習曲線は、製品やアプリケーションの知識の習得に関連するものでしょう。
既存のチームメンバーがAPIテストを学ぶことになった場合、選択したツールによっては、テストアプローチの変更とともに、学習曲線は中～高になるかもしれません。 製品やアプリケーション自体の学習曲線は、そのテスターが以前にそのアプリケーションをテストしたことがあるかどうかによって、低～中程度かもしれません。
#その4）既存のスキルセット
これは、先ほどの「学習曲線」の話と直結しています。
テスターがGUIベースのテストから移行する場合、テスターはテストアプローチを変更し、必要に応じて新しいツールやフレームワークを学習する必要があります。 例 APIがJSON形式でリクエストを受け付ける場合、テスターはテストの作成を開始するために、JSONとは何かを学ぶ必要があります。
ケーススタディ
タスク
既存のアプリケーションをスケールアップするために、ある企業は標準的なGUIアプリケーションだけでなくAPIでも製品を提供したいと考えました。 QAチームは、通常のGUIベースのテストに加えてAPIテストにも対応できるように、テストカバレッジプランを提供するよう求められました。
挑戦すること
- そのため、APIを使ったテストを行うためには、APIテストプロセスをゼロから構築する必要がありました。 つまり、ツールの評価、候補の選定、最終決定、テストのためのチームトレーニングが必要でした。
- そのため、無料またはオープンソースのAPIテストツールを選択し、既存のチームからこのタスクを担当する人をトレーニングする必要がありました。
- APIフィールドやデータバリデーションに関する要件はなく、「対応するGUIアプリケーションと同じように動作すること」が要件でした。
リスクを軽減し、課題を回避するためにチームがとったアプローチについて
- QAチームは、プロジェクトチームと協力して、以下の要件を確認しました：
- APIタイプ（REST/SOAP ）： REST
- 必要なテスト（機能、負荷、セキュリティ）： 機能テストのみ
- 自動テストが必要（はい/いいえ）： 今のところオプション
- テストレポート（Yes/No）： 必須
- QAチームは、必須要件に基づき、利用可能なAPIテストツールの評価を行いました。 Postman API Toolは、無料で使いやすく、学習曲線を最小限に抑え、テストを自動化する可能性があり、優れた内蔵レポートが付属していたため、最終的に選択したツールに決定しました。
- アプリケーションをテストした同じテスターが、Postmanを使って初期テストを作成するトレーニングを受け、製品知識のギャップをなくすことに成功しました。
- このため、プロジェクトチームはSwaggerを使用してフィールドレベルのドキュメントを作成しましたが、許容されるデータ形式の点でいくつかのギャップがあり、プロジェクトチームと話し合い、期待される形式を合意して文書化しました。
結論
APIベースのアプリケーションは、従来のアプリケーションやソフトウェアに比べて拡張性が高く、他のAPIやアプリケーションとの統合が容易なことから、近年人気を博しています。
このチュートリアルでは、APIテスト、Shift Leftテスト、Webサービス、Web APIについて詳しく説明しました。 また、WebサービスとWeb APIの違いについて、例を挙げながら探りました。
チュートリアルの第2部では、APIテストの全容、組織におけるAPIテストの導入方法、このプロセスにおける一般的な課題とその解決策について説明しました。
Webサービスについては、今後のチュートリアルで、例題とともに詳しくご紹介します！
NEXTチュートリアル