API テスト ツール: ロード テスト API オンラインの究極のガイド
ほとんどすべてのタイプのシステムまたはインフラストラクチャで動的 API ロード テストを実施します。
実行可能なロード テスト データを取得する – 問題がどこにあるかを確認し、迅速に解決します。
API テストとは何ですか?
多くの ウェブ ベースプラットフォームおよびサービスとしてのソフトウェア (SaaS) 組織では、顧客がプラットフォームのデータを独自の条件で操作したり、使用したりできるように、さまざまな API (アプリケーション プログラミング インターフェイス) を作成しています。 API は通常、業界標準言語またはファイル形式を使用してマシン間の通信を可能にします。 API は、エンド ユーザーを既定のインターフェイスの使用の制限から解放します。 さらに、ユーザーはコントロールと出力をダッシュボードやカスタム アプリケーションに統合できるほか、一般的な機能や手順を自動化することもできます。
API は、インターネットを介してさまざまなソフトウェア プラットフォーム間でデータを共有するための素晴らしいツールとなっています。 企業が高度化し、より多くのデータにリアルタイムでアクセスする必要がなくなってきており、多くの企業は、顧客やパートナーがニーズに最も適した方法でデータを操作して使用できるように API を構築していますが、API ロード テストとは何ですか。
API ロード テスト サービスがテスト全体のニーズにどのように適合するかを理解するには、まず、API テストの内容、API テストが必要な理由、および API テストの実行方法に関する基本的な理解を確立する必要があります。
API が XML または JSON を使用する RESTful アプリケーションであるか、SOAP ベースの XML コンテナーであるかに関係なく、サービスの応答時間と精度をチェックするテスト スクリプトを作成する必要があります。 API の応答性と精度を確立したら、システム上で API 負荷テストとストレス テストという 2 つの追加テストを実行することが重要です。
ロード テスト API
API のロード テストは、API と基盤となるインフラストラクチャが、予想される数の同時要求を処理できることを証明します。 ボリューム テストとも呼ばれるロード テストでは、システムが定義済みのトラフィック量を処理できることを確認します。
ストレス テスト API
ストレス テスト API は、サービスの理論上の容量を超える要求数を増やすことで、同時ユーザーの上限をテストします。 ストレス テストでは、システムが回復を処理する方法を確認するために、リソースが過負荷になるまで負荷が増加します。
複数の API テスト シナリオを設計し、システムの全体的なパフォーマンスに関する洞察を得ます。
ロードビュー API ロード テスト – レストフル、SOAP、SaaS、および動的
ほとんどすべてのタイプのシステムまたはインフラストラクチャで動的 API ロード テストを実施します。
API をテストする理由
ネットワーク内から API をテストすることは、理論的にはシステムの問題を発見するのに役立ちますが、ネットワークの外部からエンド ユーザー エクスペリエンスをエミュレートする追加のテストを実行することをお勧めします。 API を外部でテストすると、エンド ユーザーまたはサードパーティのシステムの観点から応答時間の平均を識別できます。 これらの平均応答時間は、将来の応答性を比較できるベースライン パフォーマンス メトリックとしてサーバーを値します。 通常、外部テストの結果は、ファイアウォール内からの低待機時間テストよりも、顧客のエクスペリエンスを表す方が多いものです。 外部 API テストは、ファイアウォールの背後でテスト中に発生しない問題を特定するのにも役立ちます。
API パフォーマンステストに関する質問
API パフォーマンス テストをセットアップする際に、次のようないくつかの質問に答える必要があります。
• エンドユーザーまたはターゲットオーディエンスは誰ですか。
• なぜ API を使用しているのですか。
• ユーザーは API を使用して何を達成しようとしているのか。
• ユーザーにとって API はどのくらい重要ですか。
• API が使用できない場合や信頼性が低い場合はどうなりますか。
• ユーザーは API からフィードバックを受け取ることを期待していますか。
• これらの各前提をどのようにテストしますか。
質問に答えたら、API テストケースを作成しましょう
これらの質問に答えたら、API テスト ケースをビルドして、各テスト ケースのニーズが満たされていることを確認します。 これらの質問の答えに応じて、テスト ケースの前提条件を検証するためにさまざまな種類のテストが必要になる場合があります。 たとえば、データを API に送信すると、API からの 「成功」 応答のみが検索される場合があります。 同様に、クエリを送信すると、サーバーからの応答の特定のキーワードや値が引き出される可能性があります。 また、API テストの結果も、テストの理由によって異なります。 開発プロセス中、さらにはポストプロダクションでは、API をテストする場合にも、さまざまな時間があります。 これらのインスタンスはそれぞれ異なる設定が必要な場合があります。
API で何をテストしますか?
要件に関する最初の質問に答えた後、APIが成功したか失敗したかをどのように知るのでしょうか? 次のようなパラメーターを指定して、テスト ケースを設計する必要があります。
• 入力パラメータ
• 期待される出力
• 応答を受信する最大時間
• 入力の解析
• エラー処理
• 適切な応答の書式設定
新しいコード ビルドのたびに、テスト スクリプトに各テスト ケースを含め、正常に実行されることを確認します。 また、各テスト ケースをスケジュールされたロード テストに含めると、API が同時読み込みを処理できることを確認できます。
API のテスト方法: API パフォーマンス テストの種類
以下に示すように、追加の API テスト目標を達成できるテストおよびテストの種類に関する追加の名前が多数あります。 LoadView プラットフォームの性質上、機能テストとロードテスト API やストレス テストに重点を置きます。
統合テスト
統合テストでは、API に対する新しい変更によって、他のモジュールやシステムに問題やバグが発生しないことが保証されます。
ロードテスト
ロード テストにより、運用インフラストラクチャは、システムにアクセスするユーザーの予想数を処理できます。
回帰テスト
回帰テストでは、既存の機能のテストが成功した場合に、新しい変更が悪影響を及ぼすかどうかを判断します。
スケーラビリティテスト
スケーラビリティ テストを使用して、同時ユーザー数の変化に対するシステムの応答方法を確認します。 同時ユーザー数に応じてシステムのスケールアップやスケールダウンが予想され、一貫性のある安定したユーザーエクスペリエンスのために利用されるリソースを調整します。
セキュリティテスト
セキュリティ テストは、システムまたは基盤となるフレームワークの潜在的な脆弱性を悪用しようとします。
UI テスト
UI テストでは、GUI を使用して可能な限りすべてのケースをテストして、正常に機能するようにユーザー インターフェイスのあらゆる側面が期待どおりに機能することを確認します。
機能テスト
機能テストでは、システム要件とユーザー ストーリーを取り、各ユース ケースをテストして、システムが必要なすべてのシナリオを処理できることを確認します。
ストレステスト
ストレス テストは、一般的なユース ケースを使用して、同時にケースの多くの同時インスタンスを実行する可能性があるという点で負荷テストのようなものです。 ストレス テストでは、システムが障害点に達するまで、追加の同時ユーザーをシステムにプッシュし続けるため、負荷テストよりも 1 つのステップ進みます。 システム全体のレベルと、システムの特定のコンポーネントの両方でストレス テストを実行します。 負荷テストとストレステストの違いを調べる素晴らしい記事があります。
REST API をテストする方法
REST API は、リソース記述フレームワーク (RDF) の標準により一般的です。 その後、あるシステムと別のシステムを統合するために、より多くの API を使用できます。 最も単純な REST API は、GET、POST、DELETE などの URI 要求で構成されます。 特定の API の複雑さは単一の GET 要求と同じくらい単純ですが、認証にセキュリティで保護された資格情報を必要とし、複数の変数を持つさまざまなコマンドのリストを提供します。
基本的な API テストでは、GET コマンドと POST コマンドを使用して、認証のスクリプト化、システムからのデータの読み取り、システムへの新しいデータの POST、および予期される応答の確認を行います。 作成後、ユーザーは、ロード テストだけでなく、単独のテストに再利用できます。
SOAP API をテストする方法
ソフトウェア アーキテクチャ スタイルと見なされる REST API とは異なり、SOAP API はプロトコルの一種と見なされます。 SOAP API は、ウェブ サービス記述言語 (WSDL) を使用して、使用可能なエンドポイントとデータ形式を指定できます。 HTTP/S 要求内で GET パラメーターと POST パラメーターを定義することにより、SOAP API をロード テストします。 SOAP API のロード テストでは、ロード カーブのユーザー数を増やすことで、1 人のユーザーから数千の同時ユーザーにスケール アップできます。
ウェブ API のテスト方法
ウェブ API は、外部システムが毎日既存のアプリケーションに結び付くようになっています。 たとえば、一般的なソーシャル メディア プラットフォームの多くは、ある ウェブ アプリケーションのユーザーを別の ウェブ アプリケーションに接続するために使用される API を持っています。 多くのプラットフォームでは、複数の API を使用して、他のアプリケーションの開発者が独自のシステムと対話できるようにします。
ウェブ API でテストを実行するために使用できるツールは多数あります。 ネットワークの外部のサーバーから外部コマンドを生成し、API の応答性と有効性を検証できるソリューションを見つけることが重要です。 数十万人の同時ユーザーが存在すると予想されるアプリケーションでは、同時ユーザーロードテストは、ウェブ APIテストプロセスの非常に重要なコンポーネントです。
地域からの API テスト
API を社内でテストしてコマンドや要求に適切に応答するようにすることができますが、社内テストでは、API がインターネット上の外部要求に効果的に応答できることを保証するものではありません。 API をデプロイしたら、ターゲット市場の地理的領域にノードが分散された外部負荷テスト サービスを使用して、理想的にテストされます。
ロードビューを使用したロード テスト API
Loadview API プラットフォームでは、API の速度、応答時間、およびスケーラビリティを確保するための包括的な API ロード テストを実行できます。 このプラットフォームでは、毎秒何千人ものユーザーが API をヒットし、負荷テスト セッションごとにサーバーに対して 100,000 以上の呼び出しを生成するシミュレーションを行うことができます。 ほとんどすべてのタイプのシステムまたはインフラストラクチャで動的 API ロード テストを実行し、実行可能なロード テスト データを取得して、問題のどこにあるのかを確認して、迅速に解決できるようにします。
要件に応じてオンデマンドおよび構成可能な API テスト
LoadView は、一定の変数や動的な変数を API 要求に入力し、世界中の場所から同時ユーザー数を簡単に、オーバーヘッドを少なくまで拡張できる、強力なオンデマンド API テスト ソリューションをユーザーに提供します。 LoadView は、存在する API の事実上すべての種類をテストできます。 必要に応じて、カスタム C# スクリプトを作成して、ランダム変数を生成したり、API ロード テストの 1 つのステップから次のステップにパラメーターを渡したりして、ロード テストを支援できます。
API テスト用の複数のロード カーブ テスト
API テストの要件に応じて、LoadView プラットフォームでは複数の荷重曲線から選択できます。 システムを適切にテストするために必要な同時ユーザー数を増やすロードカーブを実装して、必要なペースでトラフィックをシミュレートする API ロード テストを定義します。
荷重ステップ曲線
[ステップ カーブの読み込み]オプションは、事前に定義された数の同時ユーザーで負荷を生成し、指定した時間に同時に実行するユーザーの数が増加する際の応答時間を確認できるようにします。目標に基づく曲線
目標に基づく曲線を使用すると、ユーザが必要なトランザクションレートに達するように自動的に調整できます。 この種類のテストは、通常、運用環境でサービス レベル アグリーメント (SLA) を検証するために使用されます。
ダイナミック調整可能曲線
動的調整可能曲線を使用すると、テスト中にリアルタイムでユーザー負荷を変更できます。 事前に決定された同時ユーザー数から始め、定義された最小と最大の間で調整できます。
世界各国の API ロード テスト オプション
世界中のさまざまな地域からの負荷が高い場合、API の可用性をテストします。 LoadView を使用すると、20 以上の地理的地域から任意の方法で負荷を分散できます。 たとえば、ほとんどの顧客が米国の東海岸にいる場合、ロード テストの 60% を東海岸のサーバーから送信し、その他の 40% を他の Google の場所に分散するように選択できます。 なぜあなたはこれをするのですか? 速度が重要であり、実際の顧客に最も近い場所を選択すると、ロード テスト中に実際のユーザーの最も効果的なエミュレーションが提供されるためです。
API ロード テスト オプション: ファイアウォールの内側
「なぜ API をテストする」セクションでこれについて簡単に触れましたが、LoadView プラットフォームには、ファイアウォールの内側から、一般に公開されていない API をテストするために利用できる柔軟性もあります。 プラットフォームには、ビジネスの要件に応じて、いくつかの異なるオプションが用意されています。 たとえば、一般的なロード テストでは、ロード インジェクタは動的に開始されるため、IP アドレスは静的ではなく、ロード テストによって異なります。 ただし、ファイアウォールの背後で API ターゲットをテストする必要がある場合、LoadView には、追加の将来のテストのためにこれらのホワイトリストを維持するという利点を備えた静的 IP アドレスを使用してテストを実行するプロキシ オプションが用意されています。
また、内部セキュリティ ポリシーにより、組織がネットワークを外部の負荷インジェクタに開放できない場合、LoadView は、組織が外部トラフィックにネットワークをアクセスできるようにする必要のない、独自のネットワーク内からロード テストを実行するオンサイト エージェント機能を提供します。 ファイアウォールの背後からロード テストを設定および構成する方法の詳細については、 サポート技術情報のページを参照 してください。
負荷の下での API パフォーマンス テスト
ほとんどの API は、正確さと柔軟性についてテストされていますが、API がサポートできる同時接続または同時接続の数を知っていますか。 この質問は、API の結果の正確性を検証するよりも、多くの場合、答えるのが難しくなります。 同時データベース ユーザー、RAM の可用性、ページ ファイル管理、CPU 使用率などの制約により、同時ユーザー数を許容できない場合があります。
LoadView を使用した API のロード テストは、API に複数の呼び出しを連続して送信するスクリプトを作成し、同時ユーザー数を予想されるトラフィックの上限までスケールアップするのと同じくらい簡単です。 スクリプトは再利用可能であり、サービス期間を通じてシステムを監視するために使用できます。 そして、これは間違いなく JMeterのようなツールではできないものです!
API パフォーマンスのボトルネックを見つける
ボトルネック状態を生成できたら、システムが停止する理由を特定できます。 LoadView をメトリックスビューと組み合わせて使用することは、このような減速の原因を特定する優れた方法です。
API キーワードの検証
API サーバーから期待されるキーワードを指定して、成功した応答を確立することもできます。 期待されるキーワードが応答に見つからない場合、個々のテスト セッションにエラーのフラグが付けられます。 最大応答しきい値のタイムアウトを設定することもできるため、API が設定されたしきい値よりも長くかかる場合、テストはエラーを返します。
API 応答時間
ロード テストでは、400 および 500 サーバー エラー応答コードなどのサーバー応答コードも記録されます。 ロード テストの結果を確認すると、グラフに表示される平均テスト応答時間と、レポートを詳しい方法で確認して個々のテスト セッションを確認できます。 これにより、同時ユーザー数を増やすと、平均応答時間がどのように影響を受けるかを視覚化できます。
API レポート データへのドリルダウン
個々のロード テスト セッションを調べて、エラー コードを確認し、DNS traceroute やウォーターフォール チャートなどの追加のトラブルシューティング ツールを使用して、特定の期間内の単一デバイスまたはタスクに対して、サーバー応答のメトリックを使用します。
API パフォーマンスメトリック
API サーバーを監視できるシステム上のファイアウォールの内側に MetricsView プライベート エージェントをインストールすると、API 機能に関連する Windows パフォーマンス カウンターを監視できます。 CPU 使用率、使用可能なメモリ、帯域幅の使用率、SQL データベース トランザクション、ストレージ I/O などのメトリックを測定すると、API がトランザクションをより効率的に完了できないハードウェアまたはソフトウェアのボトルネックがあるかどうかを判断するのに役立ちます。 各セッションの応答時間と、API が各応答で期待される結果を返す検証から構成されるパフォーマンス メトリックを収集します。
ロードビューを使用した RESTful API ロード テスト
REST アプリケーションの LoadView テストでは、RESTful API サーバーまたは URL に対する一連の GET/POST 要求を通じて、API と対話するときに実行するステップのリストを定義できます。 一連の API 要求は、Dotcom-Monitor クラウドにスクリプトとして保存され、世界中の数百または数千のロード インジェクタによって同時に実行されるようにキューに登録できます。
複数のリージョンのノードを使用してロード テストを実行すると、ロード テストでの同時接続を、API が平均応答時間の速度を低下し始める時点まで増やすことができます。 さらに、API ロード テストに同時に複数のユーザーを追加すると、最終的には、RESTful 要求がタイムアウトし始める時点で API サーバーに負荷がかかります。 API が一貫してタイムアウトを開始すると、システムのボトルネックを特定できます。
LoadView を使用した API のロード テストは、API に複数の呼び出しを連続して送信するスクリプトを作成し、同時ユーザー数を予想されるトラフィックの上限までスケールアップするのと同じくらい簡単です。 スクリプトは再利用可能であり、サービス期間を通じてシステムを監視するために使用できます。
異なる地域ゾーン間の仮想ユーザー割り当てを簡単に調整できます。
ロードビューを使用して ウェブ API をテストする方法
ウェブ API でテストを実行するために使用できるツールは多数あります。 LoadView は、ネットワーク外のサーバーから外部コマンドを生成し、API の応答性と有効性を検証することに重点を置いています。 数十万人の同時ユーザーが存在すると予想されるアプリケーションでは、同時ユーザーロードテストは、ウェブ APIテストプロセスの非常に重要なコンポーネントです。
ロード テスト SaaS API
SaaS 製品の人気が高まるほど、ユーザーは API を通じてサービスへの直接アクセスを要求し始めます。 ユーザーが API にアクセスするとすぐに、ユーザーは、リアルタイムのデータ フィードを自分の環境に作成するために、できるだけ速く、複数の要求を送信することで SaaS システムの制限のテストを開始する可能性があります。
API を積極的にテストすることが重要
このような要求を頻繁に実行することを顧客が期待しているかどうかにかかわらず、最終的にはシステムが過負荷になる可能性があります。 API を定期的に設定して実行した後、顧客が API を使用する前に、システムの限界を事前に把握する方法です。 多くの場合、API マネージャーは IP アドレスからの要求の数を 1 分あたりに制限したり、ユーザー アカウントに基づいて要求の数を制限したりします。 LoadView を使用すると、テスト SaaS API を簡単にロードできます。
動的 API ロード生成
LoadView では、コンテキスト パラメーターを使用して、ロード テスト中に後続の API 呼び出しで使用する変数の動的な一覧を指定できます。 必要に応じて、C# を使用して、指定した制約内にランダムに生成された値を作成することもできます。 LoadView サポートは、スクリプトの問題を解決し、動的変数のスクリプトを生成するのに役立つ 24 時間 365 日利用可能です。
API テスト自動化
API のテストは、ソフトウェアと ウェブ サイトの両方にとって明らかに不可欠ですが、見落とされがちです。 API はサイバー攻撃者にとって簡単なターゲットであるため、継続的なテストが重要です。 たとえば、API が不正なクエリや送信を防止しているとします。 他のユーザーの認証トークンを推測できないのは確かですか? APIは、問題がある場合や、問題が適切に隠されている場合にエラーメッセージを提供しますか? API の使用に関しては、セキュリティに関する考慮事項が多数あります。 テストの自動化に失敗した場合、ユーザーデータが危機に瀕している可能性があります。
API セキュリティを忘れないで
企業は、API の負荷と容量のテストに加えて、組織のセキュリティ プロトコルの一部として API セキュリティ テストを実施することをお勧めします。 API のエラーにより、組織の内部とシステムの API に依存するユーザーの外部の両方で、ネットワーク インフラストラクチャ全体がダウンする可能性があります。
API モニタリング
この問題を解決するにはどうすればよいでしょうか。 API テストを自動化するだけで、 これにより、手動でテストすることを覚えておく必要なく、セキュリティの問題をチェックすることができます。 Postmanは最も人気のあるオープンソースオプションの1つであり、これを行うための様々なソリューションがあります。 真のエンタープライズ API テストに必要なすべてのベルとホイッスルに付属している、堅牢で市販のオプションを探している場合は、LoadView と Dotcom-Monitor の完全な一連の自動化された API テストおよび監視ツールを検討する必要があります。
API を監視する理由
API は、アプリケーション・ユーザーがシステムと対話するためのセカンダリ・インターフェースを提供します。 たとえば、システムがオンラインの 24 時間 365 日である場合、関連付けられた API は同様のサービス レベル アグリーメント (SLA) に準拠する必要があります。 サード パーティの 外部 API 監視 は、API が SLA 要件内で実行されていることをバイアスされていない検証を提供する最も簡単な方法です。 API が機能していることを確認するテストを構築して実行した後でも、継続的なサービスを検証するために継続的な監視を設定することをお勧めします。
API SLA が満たされていることを確認する
SLA レポートは、プラットフォーム内での特別レポートで、指定した期間 (たとえば、日単位、週単位、月単位) で単一のデバイスの SLA ステータスを確認できるため、プロバイダーの SLA 要件の遵守を追跡できます。 1 つのインターフェイスでレポートを表示すると、SLA の目標が満たされていない理由と、そこからの情報が表示されます。 これらのレポートは、サービス プロバイダーと共有することもできます。
LoadView API ロード テスト – 最先端を超えて
現在市販されている他のツールとは異なり、ユーザーはLoadViewを使用して特定のハードウェアやソフトウェアの要件について心配する必要はありません。 完全にクラウドベースなので、開発者やエンジニアは、APIテストの作成、実行、分析に集中できます。 LoadView は、SOAP API や REST API から、他の ウェブ API レベルのテストと検証の実行まで、優れた API テスト ツールです。
Dotcom-Monitor スイートは、REST、SOAP、およびその他の API をカバーするだけでなく、ほぼ無限の設定オプションとレポートツールを使用できます。 LoadViewのようなパフォーマンステストツールにアクセスすると、ウェブサイトやビジネスの運営方法が文字通り変わる可能性があります。
今すぐ無料で LoadView を試してみて、API テストを数分で自動化する方法をご覧ください。
ロードビュー API ロード テスト
LoadViewは平均的な負荷テストツールではなく、革新的な動的テストソフトウェアです
これにより、システムやインフラストラクチャの見方が変わります。