ロードテスト

ロード テストとは何か 、 ロード テストが重要な理由

ロード テストは、ソフトウェア、ウェブ サイト、ウェブ アプリケーション、API、またはシステム上で実際の使用状況や負荷をシミュレートして、応答性、劣化、スケーラビリティなどの要因を分析および特定する方法です。

ロード テストとは

 

定義ロード テストは、一般に、テストをソフトウェア パフォーマンス テスト プロセスのサブセットとして指し、通常は、ストレス テスト、スパイク テスト、耐久テスト、ボリューム テスト、スケーラビリティ テストなど、他の種類のテストなど、他のいくつかの種類のテストも含まれます。

パフォーマンスの低いサイトやアプリケーションは、コンバージョン、トランザクション、そして最も重要な収益に悪影響を及ぼす可能性があります。 数秒のダウンタイムでも、企業の収益に大きな影響を与える可能性があります。 バックアップおよびデータ管理の分野でグローバルリーダーであるVeeamが最近実施した調査では、1,500人以上のITプロフェッショナルが、優先度の高いアプリケーション のダウンタイムが1時間のコスト が84,000ドルを超えていることがわかりました。 さらに、ダウンタイムの平均時間は 79 分でした。

金融サービスや大規模なオンライン小売業者など、大量の取引に依存する特定の業界を考慮すると、影響が大きくなる可能性があります。 また、調査では、顧客信頼の低下、ブランドの完全性の低下、株価の下落など、顧客や訪問者への影響も示されています。 したがって、ご覧のとおり、パフォーマンスの要求を満たすためにアプリケーションをテストすることの重要性は誇張できません。

ロード テストは、サイト、アプリケーション、およびシステム上の実際のシナリオをシミュレートします。 開発者は、負荷テスト中およびロード テスト後に収集された情報を通じて、制限を測定し、次のような質問に答えるうえで役立つメトリックについて洞察を得ることができます。

データグラフ

  • ユーザー数はパフォーマンスにどのような影響を与えますか?
  • ウェブ サイト、アプリケーション、またはシステムが処理できる同時ユーザー数はいくつですか。
  • ボトルネックはどこにあるのか?
  • 特定の期間に処理できるトランザクションの数はいくつですか。
  • ブレークポイントは何ですか? リソースが不足する場合はいつになりますか?

以前は、 ロード テスト は開発プロジェクトの完了に向けてのみ実行されていましたが、アジャイル ソフトウェア開発プロセスに再び重点を置いているため、開発チームはテストを左にシフトしています。 サイト、アプリケーション、システム、または API がどの程度処理できるかを正確に把握することで、コードがステージング環境にコミットされる前に、バグやデータベースの速度低下など、さまざまな問題を特定して発見できます。 たとえば、クライアント側のすべてのアプリケーションは、さまざまなテストを実行して制限を判断し、ユーザー エクスペリエンスの向上を支援する必要があります。 アプリケーションのパフォーマンスの問題が運用環境で検出されない場合、必要なコスト、時間、およびリソースは、問題の場所を特定しようとする必要があります。

ロードビューを使用したロードテスト

 

LoadView はオンデマンドのクラウドベースのロード テスト プラットフォームであり、サイト、ウェブ アプリケーション、モバイル アプリケーション、API がさまざまなトラフィックにどのように対応するかを決定します。 負荷テストは時間のかかるプロセスになる可能性があります。 LoadViewは、ジェネレータのインスタンス化やグローバル分散エージェントの設定など、面倒なタスクを管理します。 これにより、開発者はテストの設計、実行、分析に時間を与えます。

テスト対象のシステムのニーズ、ユース ケース、またはテクノロジに応じて、LoadView プラットフォームは、HTTP/S や実際のブラウザベースのシミュレーションなど、さまざまな種類のユーザー シミュレーションを実行できます。

HTTP/Sベースのシミュレーション: プロトコルベースのシミュレーションは、最新の ウェブ アプリケーション フレームワークとテクノロジによりロード テストの従来のアプローチと考えられていますが、プロトコル レベルのスクリプトは CI/CD 環境でのコンポーネント レベルのテストに最適で、インジェクション マシンのフットプリントが低くなります。

実際のブラウザベースのシミュレーション:実際のユーザーの動作を模倣し、Angular、AJAX、JavaScript、Flash、Reactなどの特定の動的なウェブ アプリケーションフレームワークとテクノロジーを利用するウェブ アプリケーションを持つ必要がある場合。 実際のブラウザを使用することが重要です。 このシミュレーションを使用すると、開発者は、ユーザーが認識するサイトの機能と速度を検証できます。 実際の運用環境ではなく、エラーやボトルネックを検出してテスト環境で修正する必要があります。

EveryStep Web レコーダー – ウェブ サイトおよびアプリケーション用のカスタムロードテストスクリプトを作成する

 

EveryStep Web Recorderは、ウェブ トランザクションのすべてのステップを記録し、実際のブラウザーを使用してスクリプトを再生する、無料の ウェブ ベースのスクリプトツールです。 ボタンのクリック、メニューの選択、フォームの送信、ショッピング カート プロセス、テキスト入力、画像やテキストの検証など、ユーザーが行う重要かつ複雑なアクションの複数ステップのテスト スクリプトを記録します。

40以上のデスクトップ(Chromeとインターネットエクスプローラ)とモバイルブラウザ(iPhone、iPad、Google、サムスンなど)と互換性があり、EveryStepウェブレコーダーは、AJAX、Angular、Javaなどのウェブ アプリケーション技術やフレームワークに関係なく、ブラウザでレンダリングされる事実上のすべてをサポートしています。 HTML5、フラッシュ、PHP、ルビー、その他多くの。

さらに、EveryStep Web Recorder では、特定のロード テスト要件に応じて、独自の C# コードを使用してスクリプトを手動で編集でき、環境内の他の繰り返しタスクのテスト実行を自動化するために再利用できます。 これらのスクリプトは LoadView プラットフォームにアップロードされ、実質的に無制限の同時ユーザーによって再生されます。 また、特定の間隔で実行されるスクリプトをセットアップし、エラーが発生した場合にチームに警告を表示し、すべてがスムーズかつ適切に実行されるようにすることができます。

 

30日間のロードビューを試してみてください!

クレジットカードなし、契約なし。

ロード テストの利点

 

ロード テストの目的は、ウェブ サイト、アプリケーション、またはシステムが定期的に適切に管理する必要がある、大きな劣化を経験することなく、予想されるトラフィックをシミュレートすることです。 予期しないユーザーの増加によってシステムが時折減速する場合がありますが、システムは予想される時間内に通常の操作を回復して再開する必要があります。

グローバルネットワーク

  • ページの読み込み時間を短縮する: ユーザーエクスペリエンスに関してはスピードが重要であり、遅いサイトやアプリケーションは顧客をせっかちにしたり、サイトを完全に離れたりします。 収益を促進するために重要なページがある場合、 負荷テスト は特定の問題を特定するのに役立ち、ウェブ チームが影響を受けるページを優先して問題を解決し、潜在的な悪影響を最小限に抑えることができます。
  • ボトルネックの発見:開発段階でアプリケーションやサイトを ロード テスト すると、CPU、メモリ、ネットワーク使用率などの一般的なボトルネックが見つかり、開発者はコードやアプリケーションを運用環境に移行する前にこれらの問題に対処できます。
  • 地理的な場所:ほとんどの顧客がどこから来たかわかっている場合は、それらの場所からテストを設定すると、それらの訪問者に影響を与える特定の問題を特定できます。 これにより、ユーザーがどこから来たかにかかわらず、誰でもサイトにアクセスでき、ユーザーエクスペリエンスは世界中で一貫しています。
  • サービス レベル アグリーメント (SLA) の確立: 容量計画は、事前定義された要件のセット内で、アプリケーションを実行するために必要なハードウェアリソースとソフトウェア リソースを決定するのに役立ちます。 負荷テストは、アプリケーションが大きな負荷の下でどのように動作するかを予測し、将来追加のインフラストラクチャへの投資が必要になるかどうかを予測するのに役立ちます。

 

ロード テストに LoadView を使用する利点

顧客とユーザーは、信頼性が高く、高速な ウェブ ページとアプリケーションを期待します。 そうでなければ、彼らはすぐに代替案を見つけるでしょう。 組織は、堅固なカスタマー エクスペリエンスを提供することの重要性を理解しており、負荷 テスト の価値が収益に対してどれほど重要であるかを把握しますが、すべての企業が、これらのタスクを実行するために必要なリソース、チーム、インフラストラクチャ、または時間を持っているわけではありません。

LoadView プラットフォームは、オンデマンドのクラウドベースのロード テスト ソリューションであり、追加のインフラストラクチャへの投資を必要とし、世界中の複数のポイントから仮想負荷インジェクタを作成するという時間のかかる課題を排除します。

その他の機能は、次のとおりです。

  • プロトコル レベルと実際のブラウザー ベースのテスト。負荷ストレスパフォーマンステスト
  • EveryStep Web レコーダーを使用した実際のブラウザーベースのスクリプト。
  • 40以上のデスクトップ/モバイルブラウザとデバイスの高度なスクリプトサポート。
  • 荷重曲線オプション – 荷重ステップ、ゴールベース、およびダイナミック調整可能曲線。
  • 複数のグローバルな場所からテストします。
  • 数十から数千の仮想ユーザーにスケールします。
  • ユーザーが認識する応答時間を測定します。
  • アップタイム監視用に ロード テスト スクリプトを再利用します。
  • あなたが使用するもののために支払う、長期契約なし。
  • サポートは24時間、週7日利用可能です。

これらの利点は、現在市場に出回っている他の 負荷テスト ソリューションとは別にLoadViewを設定し、 ロードテスト の制御をユーザーの手に委ねています。

 

ロード テストのベスト プラクティス

 

ウェブ サイトとアプリケーションは、ビジネスの成功に不可欠です。 これは通常、顧客が最初に見るものであり、それが低迷またはクラッシュした場合、彼らはすぐに代替案を見つけるでしょう。 ページの読み込みが速いほど、顧客は滞在し、将来戻ってくる可能性が高くなります。ウェブ サイトやアプリケーションの 負荷テスト により、予想されるレベルのユーザーの下で機能し、プロセスに影響を与える可能性のあるエラーに関する洞察を得ることができます。 優れたユーザー エクスペリエンスを維持できるように、実装できる 5 つのベスト プラクティスについて説明します。

ロードテスト技術

  1. ビジネス目標と目的を特定する。 マーケティング、運用、プロジェクト マネージャーなど、組織内の他の部門が ウェブ サイトやアプリケーションのパフォーマンス目標をどう信じているかを考えてみましょう。 また、 ロード テスト の目的をどう思うかを、別々に質問します。 プロジェクトの範囲内で重要と思われるものと、質問や懸念が一致しているか、または一致していないかを確認できますが、それでも、あなたの基盤をカバーし、優れたユーザーエクスペリエンスを提供しています。

 

2. 測定したい指標を決定します。 アプリケーション、使用するテクノロジ、環境の組み合わせによって異なりますが、一般的な基準には、ユーザーの認識応答時間、特定の地域別の応答時間、リソース使用率 (CPU、メモリ、ディスク、帯域幅)、エラー数、最大ユーザー数、その他のビジネス パフォーマンス メトリックが含まれます。

 

3. ロード テストを設計します。 テストを設計する場合は、テストする負荷、特定のユーザー トランザクション、およびテストの組み合わせや順序など、いくつかの重要な要素を決定します。 テストを開始する場所がわからない場合は、IT 部門やマーケティング部門など、以前のアプリケーションや類似のアプリケーション (同時ユーザー数、特定の時間のピーク セッション、ページ ビューなど) から履歴テスト データを収集するために、分析ツールから参加します。 情報のためのもう一つの素晴らしいスポット? あなたの競争。 業界の競合他社が、特定の顧客指標に関する情報や公開プレスリリースを公開している場合があります。 これにより、テストを開始できるベースラインが得られた場合があります。 特に ウェブ アプリケーションの場合、考慮すべきその他の要因としては、特定のナビゲーション パス、遅延、使用されているブラウザー/デバイス、および地理があります。 要するに、ユーザーの環境に最も適したテスト スクリプトを作成します。

4. アジャイル開発プロセスの負荷テストを一部にします。 以前は、パフォーマンス テストは通常、開発プロジェクトの終了に向けて行っていました。 その結果、プロセスの後半でエラーと問題が検出され、開発者はコードを再び実行して問題を修正し、通常はリリースが遅れました。 アジャイル方式は、開発サイクルの早い段階で実施される小規模なインクリメンタル テストに焦点を当てており、プロセス中に問題を解決できます。

5. 常にユーザーエクスペリエンスを念頭に置いてください。 顧客満足度は、ビジネスの成功にとって重要です。 これは、 ロードテスト やAPIがウェブサイトやアプリケーションを 監視 する際の全体のポイントです。 前述のように、サイトやアプリケーションのパフォーマンスを高くするほど、顧客がサイトに再訪したり、アプリケーションを再入力したりする可能性が高くなります。

ロード テスト ツールの選択方法

 

今日の市場では、さまざまな機能を備えたツールやプラットフォームの量と多様性に終わりはありません。 BlazeMeterのようなオープンソース専用ツールを活用するプラットフォームから、ファントムJSのようなヘッドレスブラウザのみのソリューション、またはLoadViewのような複数のユーザーシミュレーションを提供するプラットフォームまで。 ニーズや要件に最適な ロード テスト プラットフォームを選択します。

実際には、ビジネスニーズ、目的、環境、予算によって異なります。 このことを念頭に置いて、少なくとも、サイトまたはアプリケーションが実際の状況で立ち上がるかを判断する必要があります。 ロード テストツールを選択する際に、次のような質問と条件を満たす必要があります。成長グラフ

  • 使い方は簡単ですか? このツールには複雑なセットアップ手順が必要ですか。
  • テスト スクリプトを迅速に作成し、テストを実行します。
  • 最も頻繁に使用されるブラウザーやデバイスのサポート。
  • 実際のブラウザベースのユーザシミュレーションを利用します。
  • 実稼働環境でのサイトやアプリケーションの監視用に ロード テスト スクリプトを再利用します。
  • 長期契約なし、あなたが必要とし、使用するものだけを支払います。
  • 特定した指標を収集して報告します。
  • 必要な負荷量を生成します。
  • 実際のユーザー ベースのトランザクションをシミュレートします。
  • 専用のサポートおよび/またはナレッジ ベース。

前に述べた主な考慮事項の 1 つは、クライアント側のアクティビティ、より具体的には ウェブ  2.0 テクノロジを測定する場合です。 ナビゲーション、ボタンのクリック、フォーム内での日付の入力など、ユーザーの操作をシミュレートする際には非常に重要です。 この場合、選択したツールは、実際のブラウザを使用してできるだけ近い方法で複製する必要があります。 また、ほとんどのユーザーがどこにいるかも考慮してください。 地理的な場所は、顧客体験の大きな部分を果たしており、無視すると、ユーザー エクスペリエンスに悪影響を及ぼします。 LoadViewソリューションは、世界中から20以上のロードインジェクタサーバーから選択するオプションを提供します。

ロード テスト スクリプト

EveryStep Web レコーダーを使用したロード テスト スクリプトの作成

ここで、LoadView プラットフォームは他のツールとは別に設定されます。 その強さは、複数のユーザーシミュレーションをシミュレートすることから来ています。 主に、AJAX、Flash、HTLM5、JavaScript、およびその他のリアなどの今日の ウェブ アプリケーションの実際のブラウザベースのユーザーシミュレーション用のロードテストスクリプトを作成するために使用されますが、プロトコルベースのテストもシミュレートできます。 さらに、プラットフォームは、特定の地理的位置を通じてパフォーマンスを評価するために、複数のクラウドの場所を迅速にスピンアップできます。 さらに、テスト用に作成したスクリプトは、サイトまたはアプリケーションが本番環境に移行した後、定期的な稼働時間監査のために監視プラットフォームに統合できます。

シフトレフトテストとロードビュー

 

今日のアプリケーションは、サードパーティのプロバイダとCDNの膨大なネットワークに依存して、複数の技術で構築されています。 さらに、エンド ユーザーは、さまざまなブラウザ、オペレーティング システム、モバイル デバイスを使用して、さまざまな接続速度を使用して、世界中のどこからでもサイトやアプリケーションにアクセスできます。 応答時間、品質、可用性は、アプリケーションを運用環境に移行する前に評価する必要がある重要な要素です。

ロードビューロードテストシフト左インフォグラフ

開発段階とテスト段階でサイト、アプリケーション、API がどの程度処理できるかを正確に把握することで、アプリケーションを運用環境に移行する前に、バグ、ハードウェアのボトルネック、データベースの速度低下など、さまざまな問題を特定して発見できます。

これらのパフォーマンスメトリックは、顧客とクライアントの要求を満たすことができるように、容量計画を支援するために必要です。 パフォーマンスの低いサイトやアプリケーションは、コンバージョンに影響を与え、最終的には収益に影響を与えます。

シフトレフトテスト、LoadView によるロードテスト、および DevOps プラクティスの意味について詳しくお読みください。

フレキシブル。 スケーラブル。 強い。

1つの便利なロードテストソリューションからすべて。

負荷テストに関する FAQ – すべての質問に回答

目次

  1. ストレス テストはロード テストと同じか。
  2. ソフトウェアの負荷テストとは何ですか?
  3. NET と Java のロード テストとは何ですか。
  4. QA での負荷テストとは何ですか。 ソフトウェア テストにおけるパフォーマンス テストとは
  5. パフォーマンス テストにおけるスループットの意味は何ですか。
  6. JMeterの負荷試験とは何ですか? ロードランナーでのロードテストとは何ですか?
  7. SoapUIでの負荷テストとは何ですか? スパイクテストとは何ですか?
  8. ロード テストの責任者は誰ですか。 ロード テストを実行するユーザー
  9. どの負荷テストツールを使用する必要がありますか? 最適なロード テスト ツールはどれですか。
  10. ロード テストを開始する必要がある場合 ロード テストはいつ行われますか。
  11. ロード テストを実行する理由 ロード テストが重要なのはなぜですか。
  12. ロード テストの目的は何ですか。
  13. パフォーマンス テストとは
  14. さまざまな種類のパフォーマンス テストを行う方法
  15. パフォーマンス テストを使用するタイミング
  16. パフォーマンス テストが必要ないのはいつですか。
  17. パフォーマンス テスト プロセスとは何ですか。
  18. パフォーマンス テストはどのように自動化できますか。
  19. パフォーマンス テスト ツールのしくみ
  20. パフォーマンス テストを自動化する必要がある理由
  21. パフォーマンス テストのライフ サイクルとは何ですか。
  22. モバイル アプリケーションのパフォーマンス テストを実装する方法
  23. ロード テストの実行方法
  24. デスクトップ アプリケーションをロード テストする方法
  25. ロード テストは手動で行えますか?
  26. ウェブ ウェブ サイトのロード テストの実行方法
  27. ロード テストのユース ケース
  28. セレン&JMeterを使用してロードテストを行う方法
  29. ロード テスト ツールのしくみ
  30. テストシングルページアプリケーションをロードする方法

 

ストレス テストはロード テストと同じか。

ストレス テストは、システムを制限を超えてシステムをプッシュし、システムが何らかの方法で中断するロード テストです。 ストレス テストは負荷テストのサブグループと見なされます。 すべてのロード テストがストレス テストと見なされるわけではありません。 容量計画を目的としたロード テストは、ウェブ サイト インフラストラクチャが処理できる同時ユーザーの最大数を知って実行できるため、ウェブ サイトインフラストラクチャの障害が発生しない可能性があります。

ストレス テストと負荷テスト

ウェブ サイトの ロード テスト の定義は、ウェブ サイトに指定された負荷量を生成しています。 通常、テストは、ウェブサイトを訪問する実際のユーザーを模倣する方法で実行されます。 より高度なテストでは、主要な要素、ボタン、フィールドをクリックしてサイト内を移動するなど、ウェブ サイト上で一連の手順を実行できます。

 

 

ソフトウェアの負荷テストとは何ですか?

ロード テスト ソフトウェアは、ソフトウェア システム上でユーザー負荷を生成するから成ります。 ソフトウェア システムが複雑になり、多くの層とコンポーネントが存在する場合 、Postman ロード テストを含むさまざまな種類のテストで構成される可能性があります。 ソフトウェア ロード テストは、システム上で実行することも、ソフトウェア アーキテクチャの 1 つ以上のコンポーネントを分離することもできます。 このようなコンポーネントには、ユーザー インターフェイス、API、データベース接続、またはサーバー、ルーター、ファイアウォール、ロード バランサーなどの基盤となるハードウェアを含めることができます。

 

従来の Windows フォームから Java アプレット、ウェブ アプリまで、さまざまなプラットフォーム上にソフトウェアを構築できます。 ウェブアプリ。ウェブ アプリが公開 ウェブ サイト上にある場合は外部環境からテストできますが、Windows フォームは通常、1 台以上のローカル コンピューターからインストールおよびテストする必要があります。一部のローカル アプリの場合、ユーザー インターフェイスをバイパスして、基になる API、データベース、またはデータ アクセス 層に直接呼び出しを行うだけで、テストを実行できます。最終的にロード テスト ソフトウェアをどのように選択するかは、テスト時にどのような側面を懸念しているかによって決まります。

 

NET と Java のロード テストとは何ですか。

.NET (通常は C#) は、Windows フォーム アプリケーションまたはデスクトップ アプリケーションと ウェブ アプリケーションの両方でバックエンドで使用されるため、ロード テストの .NET アプリケーションは、いくつかの異なる種類のテストを参照できます。

Java のロード テストは、Java 仮想マシン上のさまざまな環境でネイティブに実行できるため、いくつかの異なる種類のテストを参照することもできます。 Java アプレットは、ウェブ サイトからも実行できます。

NET と Java の 両方のロード テストでは、さまざまな設定で繰り返し実行できるさまざまなテストを設定するためのテスト スイートが必要になる場合があります。 このようなソフトウェアスイートやサービスは、多くの場合、 ジェンキンスのようなコード管理と自動化ソフトウェアと統合します。

 

QA での負荷テストとは何ですか。 ソフトウェア テストにおけるパフォーマンス テストとは

QA での負荷テストとは、品質保証中にソフトウェア システムに一定数の同時ユーザーを適用することを意味します。 品質保証のロード テストでは、ソフトウェアの各イテレーションが、少なくとも最小同時ユーザー数を処理できることを保証し、最大でソフトウェア システムが処理できる同時ユーザーの最大数を特定します。 QA ロードテストは、継続的インテグレーションを使用して環境内で Jenkins のようなソフトウェア自動化を使用して実行されることがよくあります。

 

パフォーマンス テストにおけるスループットの意味は何ですか。

パフォーマンス テストを実行する場合、スループットとは、アプリのフロントエンドとバックエンド間で一定期間にわたって転送されるデータの量を指します。 具体的には、テストのスループットは、ネットワーク帯域幅、データベース I/O、同時ユーザー、最大メモリの制約、ディスクの読み取りと書き込みなどの要素を意味します。 これらのコンポーネントは、理論的には、クライアントからサーバーへのデータのスループットのボトルネックになる可能性があります。 負荷が増大するに従ってこれらのさまざまなボトルネックのスループットを監視すると、システム速度低下の原因を特定できます。

 

JMeterの負荷試験とは何ですか? ロードランナーでのロードテストとは何ですか?

JMeterは、ウェブアプリをテストするためのApacheによるオープンソースアプリケーションです。 JMeter は、ウェブ アプリ、ウェブ サービス、データベース クエリなど、さまざまな種類のアプリに大きな負荷を生み出す可能性があります。

LoadRunner は、アプリをテストするためのツールです。 LoadRunner は、サービスに直接メッセージを生成したり、マウスの動きやボタンの押下やキーボード エントリのスクリプトを記録して UI とユーザー操作をシミュレートすることによって、アプリのさまざまなレイヤーをテストするために使用できます。 LoadRunner は 、Microsoft .NET アプリや Java アプリなど、さまざまなアプリをテストできます。 LoadRunnerは、データベースやネットワークプロトコルと直接インターフェースを組み合うことも可能です。

しかし、ロードビューは、ほぼすべての方法でJMeterとロードランナーの両方よりも優れています。

 

SoapUIでの負荷テストとは何ですか? スパイクテストとは何ですか?

SoapUI は、API の機能テストを実行するために使用されます。 SOAPUI は、SOAP と REST APIの両方のテストに使用されます。 API のロード テストでは、複数の接続 (要求) が API に作成され、SOAP または REST API サーバーを介して異なる数の同時要求でパフォーマンスを測定します。

スパイク テストは、システム上のトラフィックの大きなスパイクをシミュレートするために、急速に増加する同時要求数を実行する特定の種類のパフォーマンス テストです。 スパイク テストは、急速に増加する時期や同時ユーザー数が多い時間帯に、API またはアプリのボトルネックをロード テストするために使用できます。 スパイクテストの目的は、需要が急激に増加または減少するにつれて、ソフトウェアまたはアプリ内の異常を検出して分析することです。 多数の同時ユーザーが ウェブ サイトやアプリをヒットする前にスパイク テストを実行すると、サイトがクラッシュしたり、アプリのパフォーマンスが低下したりする原因となるボトルネックを特定できます。 スパイク テストでは、アクティビティのスパイク間でプログラムやアプリがどのように反応するかについての洞察も得られます。

LoadView は API をテストでき、SoapUI より多くの点で優れています。

ロード テストの責任者は誰ですか。 ロード テストを実行するユーザー

多くの場合、QA チーム、DevOps、あるいはマーケティングが、ウェブ サイトや ウェブ アプリのロード テストを担当しています。 QA は通常、テスト環境でのソフトウェアおよび ウェブ アプリのテストの大半を処理しますが、DevOps はソフトウェアが運用ハードウェアで正しく動作しているかどうかを確認します。 マーケティングは、ウェブサイトの訪問者の数が多いのを担当しているので、ウェブサイトのインフラストラクチャが製品の発売や販売促進などのイベントからの高い訪問者のトラフィックを処理できるかどうかに関心があります。

DevOps ロード テスト

ロード テスト は通常、QA と DevOps という同じグループによって実行されます。 時には、負荷テストは 、開発者や開発チームによっても実行することができ、アプリが重い需要の下でスケールアップされることを確認します。 ただし、開発チームが適切なテストを行うのに十分なマシンを回転させるアクセスやリソースを持っていない可能性もあります。

 

 

どの負荷テストツールを使用する必要がありますか? 最適なロード テスト ツールはどれですか。

さまざまな ロード テスト ツールが用意されており、基本的に無料と有料の 2 つのカテゴリに分類されます。 有料のツールは明らかに堅牢で、より幅広いデータと機能を備えていますが、無料のツールはしばしばオープンソースであり、無償で利用できます。

LoadViewは、包括的なロードテストスイートであり、市場で最高のロードテストツールです。

 

ロード テストを開始する必要がある場合 ロード テストはいつ行われますか。

必要に応じてロード テストを開始します。 多くの人がロード テストを開始する時点では、必要な変更を行ったり、追加のテストを処理するためのヘルプを得るための十分な時間がありません。

クラウド ロード テスト

開発プロセスの主要なマイルストーンでテストを実行し、適切な先見性を持つ場合、ウェブ インフラストラクチャは、運用段階での負荷の大きなスケーリングと処理の問題を大幅に減らします (テストの結果としてインフラストラクチャを最適化するためのアクションが実行されると仮定します)。

ロード テスト は、ウェブ サイトに大量の同時トラフィックをもたらす可能性のある主要なイベントの前に実行する必要があります。 理想的には、新しいコード、または ウェブ サイトや ウェブ アプリの更新の公開前に、オフピーク時に運用環境でテストを実行する必要があります。 これは、テストが失敗した場合に直前のシステム調整を可能にし、公開リリースの前に十分に完了する必要があります。

多くの場合、ロード テストは、新しい製品、新しいキャンペーン、主要なイベント、またはシステムの更新のリリースの直前に実行されます。 ロード テストの目的は、ウェブ サイト インフラストラクチャが予想される数のユーザーを処理できるようにすることなので、ロード テストの結果に応答するのに十分な時間が得られていない可能性があります。

 

ロード テストを実行する理由 ロード テストが重要なのはなぜですか。

実際の需要がウェブサイトに置かれたときに不意を突かないように、ロードテストを実行します。 サーバーが処理できる同時ユーザーの最大数を知る必要があり、その数に達した場合は準備する必要があります。 あなたが大量のトラフィックに備えていない場合は、あまりにも多くの訪問者が同時にあなたのサイトをヒットしたときに、あなたのウェブサイトが遅い場合、あるいはクラッシュした場合にビジネスを失うことになる可能性が高いです。

ロード テスト は、システムの障害点を特定し、同時ユーザーが追加される際にサイトがどのように劣化するかを示すため、重要です。 ピーク時のトラフィックがどのようなものになるかが分かっている場合、ロード テストを実行すると、そのレベルのトラフィックに到達した後に ウェブ アプリやサイトがどのように実行されるのかを詳しく把握できます。

 

ロード テストの目的は何ですか。

ロード テスト は、通常、次の 3 つの理由で実行されます。

  • キャパシティプランニング

ウェブ サイトで処理するトラフィックのサイズと量が大まかにある場合は、その制限に達するまで負荷をゆっくり増やすテストを設定できます。 このタイプのロード テストは、ウェブ サイトの予想容量を計画するのに役立ちます。

  • 重大な障害ポイントの特定

多くの場合、重大な障害が発生するまで、同時に ウェブ アプリをヒットできるユーザーの数を探しているだけかもしれません。 この時点で、障害のトラブルシューティングを行い、根本原因を特定し、障害が発生したコンポーネントを軽減するか、少なくとも将来の修正のためにボトルネックにフラグを立てることができます。

  • 新しい変更によって スケーラビリティ のバグやその他の予期せぬ結果が生じるかどうかをテストする

運用環境で何かを更新するたびに、バグやその他の意図しない変更が発生する可能性があります。 ロード テストは、コードやコンテンツの更新ごとにテストを実行することで、これらの潜在的な負債の一部を排除するのに役立ちます。

 

パフォーマンス テストとは

パフォーマンス テスト では、通常、ウェブ サイトまたは ウェブ アプリケーションのパフォーマンスに関連するさまざまなメトリックを測定します。 ウェブ サイトのテストでは、ページの読み込み速度、最初のバイトまでの時間、対話までの時間、およびその他のメトリックスを測定します。 パフォーマンス テストは、ロード テストに関連して、通常、システムに需要を追加することによってこれらのメトリックがどのように影響を受けるかを記録します。 複数のアプリ監視ツールを使用している場合でも、システムを実行している基盤となるハードウェア (CPU、RAM、ディスク I/O など)、使用可能な帯域幅、データベースの読み書き、およびシステムで使用されるコードの複雑さなど、テスト結果に影響を与える可能性のある変数がいくつか存在します。 テストを実行した後、どのコンポーネントが結果に影響を与えたかを特定し、それらのコンポーネントを調整して ウェブ サイトのパフォーマンスを向上させることができます。 これは、さまざまな種類の ウェブ アプリにも当てはまります。

 

さまざまな種類のパフォーマンス テストを行う方法

パフォーマンス テストの種類には、次のものがあります。

  • 煙のテスト

スモーク テストは低レベルバックグラウンド テストを実行し、システムが最低限の要件を処理できることを確認します。 煙のテストは、ソフトウェア開発の初期段階で行われることがよくあります。 サイクル内のエラーや欠陥を早期に特定することで、チームはより効率的な方法でソフトウェアをリリースし、コストがかかる(そして時間のかかる)最後の欠陥を回避できます。

  • ベースライン速度テスト

ベースライン速度テストでは、標準ベースラインメトリックが確立されます。 これらのベースラインは、負荷の高いパフォーマンスでパフォーマンスの違いを監視する場合に、より高度なテストを比較するためによく使用されます。

  • スケーラビリティテスト

スケーラビリティ テスト では、通常、負荷の増加に応じてシステムをスケールアップできるかどうかを測定するために、時間の経過とと同時にシステムに多くのユーザーが導入されます。

  • 安定性試験

安定性テストには、システムが変更された後でも常に動作する必要があるいくつかの異なるシナリオが含まれる場合があります。 安定性テストが失敗した場合、システムが不安定になったか、システムの変更を処理するために安定性テストを調整する必要があります。

  • 容量テスト

容量テストでは、可能な限り最高の数の同時要求をテストすることで ウェブ サイトの最大容量を特定し、時間の経過とともにユーザーを増やすことでその数を増やします。 システムが必要時間内にすべての要求に正常に応答した場合、システムは容量テストに合格しました。

  • ストレステスト

スパイク テストと同様に、ストレス テストでは、容量テストをさらに一歩進めて、システムが低下するか完全に障害が発生するまで同時ユーザー数を増やし続けます。

  • スパイクテスト

スパイク テストは技術的には”ロード テスト”のカテゴリに該当しますが、両者の間にはいくつかの違いがあります。 スパイク テストは、大量のトラフィックを ウェブ サイトに送信し、サーバーがトラフィックのバーストを処理できるかどうかを確認します。 従来のロード テストは、トラフィック量が異なる場合でも、通常のユーザーの状況のガイドラインの範囲内で、トラフィックの急激な増加や減少だけでなく、さまざまな時間にわたって実行されます。

  • 耐久試験

耐久テストは、ウェブ アプリで長期間にわたってさまざまなトラフィックを送信し、システム リソースの使用が延長されたために異常が発生していないかどうかを確認します。 たとえば、メモリ オーバーフローやガベージ コレクションの不適切な理由により、耐久テスト中にバグが発生することがあります。

  • 個々のコンポーネントテスト

個々のコンポーネント テストでは、ウェブ サービスやデータベース呼び出しなど、システムの個々の部分を分離し、そのコンポーネントのその他のシステムの外部でさまざまなテストを実行します。 コンポーネントのテストでは、データベース検索やデータベースの書き込みなど、システムの 1 つの側面のみをテストすることもできます。

 

パフォーマンス テストを使用するタイミング

いつもです。 テストは、ウェブ アプリの開発中、品質保証中、新しいリリース後、新製品リリースやマーケティングイニシアチブの前、システムの変更に関するほとんどすべての時間に使用する必要があります。 今日の市場のさまざまな監視ツールの詳細については、 トップ 15 のアプリケーション監視ツールを比較する記事を参照してください。

 

パフォーマンス テストが必要ないのはいつですか。

ユーザー エクスペリエンスの質を気にする必要がない場合、ウェブ サイトに多数のユーザーがアクセスしていない場合、または ウェブ サイトがアップまたはダウンしているかどうかに関係がない場合。 ユーザー インターフェイスが絶えず変化している場合、テスト自体を変更する場合は常に変更されるため、自動テストのセットアップと実行には実用的でない場合があります。

 

パフォーマンス テスト プロセスとは何ですか。

テストプロセスは、ウェブサイトをテストする方法によって異なります。 ウェブ ページの読み込み速度を確認したり、ビジネスで最も高速な ウェブ ホスティング オプションを決定したり、更新プログラムがシステムにチェックインされるたびに実行されるソース コード管理プラットフォームに組み込まれている一連のテストを自動化したりする、1 回限りのテストと同じくらい簡単です。 大量のトラフィックが発生する ウェブ サイトの場合、パフォーマンス テストは、同時ユーザー数の増加を適用する定期的なロード テストでも構成されます。 これにより、トラフィックの増加に伴う容量の問題の予測、ボトルネックの特定、および非常に負荷の大きいイベントでのシステムの制限の理解が可能になります。

 

パフォーマンス テストはどのように自動化できますか。

パフォーマンス テストは、複数のサードパーティソリューションを使用して自動化できます。 これらのソリューションでは、通常、定期的にスケジュールされたオカレンスからコードチェックインによってトリガーされる自動インスタンスまで、多くの要因に基づいてテスト ケースを構築およびスケジューリングできます。 多くのソフトウェア開発ツール (Microsoft Visual Studio チーム ファンデーション サーバーなど) には、自動テストの実行に使用されるコンポーネントも含まれています。

 

パフォーマンス テスト ツールのしくみ

パフォーマンス テスト ツール は、ウェブ サイトまたはアプリでアクションを実行し、結果を記録することによって機能します。 ページの読み込み時間、対話する時間、ユーザーの応答性など、テスト ツールでは、さまざまなメトリックを記録できます。 測定するアプリの部分に応じて Web サイトのロード テスト ソフトウェア 、データベースからのデータの読み取り、JavaScript の実行、ファイル ストアからのイメージの読み込みなど、特定の要素に重点を置くさまざまなテストを実行できます。

 

 

 

パフォーマンス テストを自動化する必要がある理由

テストの自動化により、テストを解放して、より高度なテストを実行し、結果の分析に多くの時間を費やすことができます。 自動テストは、ユーザーの操作を最小限に抑えて、コードが変更されるたびに繰り返し実行できます。 自動テストは常に実行されているため、エンド ユーザーが問題を発生する前に、自動テストで問題を検出することがよくあります。

 

パフォーマンス テストのライフ サイクルとは何ですか。

パフォーマンス テストのライフ サイクルでは、アプリケーションのメトリックを時間の経過とでも測定するために実行する必要がある一連のテストの 1 つ以上に到達するプロセスを記述します。

パフォーマンス テストのライフ サイクルは、ウェブ サイトまたはアプリケーションがまだ開発中の間に開始されます。

最初に、アプリケーションの目標を決定し、対象ユーザーを特定し、対象ユーザーのサイズを決定します。 製品を同時に使用する可能性のある理想的な平均ユーザー数を特定し、重いストレスイベントの発生時に同時に使用できるユーザーの最大数を特定します。

パフォーマンス テストのライフ サイクル

次に、平均的なユーザーがアプリケーションをどのように使用するかを特定し、ユーザーの一般的なパスのスクリプトを記述します。 最も要求の厳しい使用をシナリオの 1 つとして含めます。

次に、理想的な条件下で個々のテストの結果を実行し、記録するだけで、各シナリオのベンチマークを確立します。

アプリケーションのプロトタイプまたは最初のドラフトが作成されるとすぐに、できるだけ早くシステムの制限を検出するためのテストを実行する必要があります。 製品が成熟し、運用環境に展開される場合、負荷の急増、トラフィックの着実な増加、および極端な耐久負荷 (長期間にわたる負荷) など、さまざまなシナリオでの平均パフォーマンス メトリックを測定するテストを実行する必要があります。 テストは、システムの変更ごとに継続して行う必要があり、システムの劣化がないことを確認します。

各シナリオの結果を分析する際、テストは、システムのボトルネックを特定して排除することで、予想される最も極端な需要をサポートするためのインフラストラクチャの進化に役立ちます。

 

モバイル アプリケーションのパフォーマンス テストを実装する方法

パフォーマンス テスト モバイル アプリは、デスクトップまたは ウェブ ベースのアプリケーションのテストと同じ方法で実行できます。 通常、テストは実際のモバイル デバイスから実行されません。 代わりに、多くの場合、エミュレーターによってシミュレーションで実行されます。 アプリが単にローカルで、ネットワーク接続を必要としない場合、ロード テストは、モバイル アプリのテストの非常に有効な形式ではない可能性があります。

地理分散ロードテスト

リモート バックエンドに接続するアプリでは、モバイル アプリで同時に数人のユーザーをスピンすると負荷が発生し、システムの速度が低下する可能性があります。 モバイルパフォーマンステストでは、ユーザー接続の種類と品質により、パフォーマンスメトリックにカーブボールを投げ込むこともあります。 ユーザーが高速データが使用できない地理的ゾーンにいる場合は、テストの速度も制限される可能性があります。 LoadView などの一部のロード テスト システムでは、テスト用の接続タイプをエミュレートできます。 これは、アプリが使用する帯域幅を人為的に制限することによって行われます。

 

ロード テストの実行方法

ロード テスト は、サーバーからの要求を生成したり、システム内の実際のユーザーをシミュレートしたりするための自動化システムを使用して実行されることがよくあります。 ロード テストは、独自のネットワーク内のハードウェアとソフトウェアを使用して内部的に実行することも、サードパーティ製のテスト システムで外部から実行することもできます。 このテストでは、システムの需要が増加するにつれて、システムのパフォーマンスと応答時間を測定します。 テストは、シミュレーション条件下でシステムの実際の応答性を測定し、生産で行う場合に最も適切です。 テストはオンデマンドでスケジュールまたは実行できますが、通常、トラフィックが少ない時間帯にテストが計画されるため、トラフィックの多い問題が最も少ない顧客に影響を与えます。

 

デスクトップ アプリケーションをロード テストする方法

デスクトップ アプリケーションの負荷テストは、ウェブ ベース アプリケーションのロード テストとは若干異なる場合があります。 デスクトップ アプリケーション全体がユーザーのコンピュータ上にあり、中央のサーバーやデータベースに接続していない場合、複数のユーザーを一度に実行しても、アプリケーションのパフォーマンスに大きな影響を与えない可能性があります。

負荷テストデスクトップアプリケーション

アプリケーションがサーバーまたはデータベースと通信する場合、ロード テストはパフォーマンスをテストする実行可能な手段である可能性があります。 テストの種類によっては、フロントエンド GUI を実行せずに要求を送信するだけで、デスクトップ アプリケーションをシミュレートする場合があります。 クライアント マシン上のシステム リソースの必要性が低いため、これらのテストは複数の GUI のインスタンス化よりもはるかにスケーラブルです。

 

 

 

ロード テストは手動で行えますか?

ロード テストは、システム内で多数の実際のユーザーを一度にアクティブにするだけで手動で実行できますが、手動のロード テストでは、システムのすべてのメトリックを収集して集計できる自動ロード テストほど貴重なデータが返されない可能性があります。

 

ウェブ サイトのロード テストの実行方法

まず、テストするシステムの側面を確立します。 これらの要件に基づいて、実行するテストのあらゆる側面を実行できるロード テスト プラットフォームを選択します。 選択したテスト プラットフォームを理解したら、定義されたユース ケースを正確にシミュレートするスクリプトまたはシナリオを設計できます。 システム内の実際のユーザーをシミュレートするシナリオもあれば、大量の同時 GET 要求を生成するシナリオもあります。 テストの種類は、最終目標によって異なります。 将来の容量計画のためにシステム内の実際のユーザーをシミュレートする場合、システムが故障する前に処理できるユーザーの数を特定するユーザーとは、負荷テストが非常に異なる可能性があります。

ロード テストのシナリオを確立したら、ターゲットの負荷数と、負荷の発生元と場所を決定します。 一部のシステムでは、ローカル マシンから負荷が生成されます。 同時に多数のユーザーを生成するために複数のマシンが必要な場合もあります。 多くのシステムでは、コンピューターごとに複数のシナリオをスピンアップすることができ、クラウド内の複数のマシンをスピンアップするのにも役立ちます。

負荷テストのパフォーマンスメトリック

テストを開始したら、ウェブ サイトをホストしているサーバーのパフォーマンス カウンターを記録し、注意を払います。 ここで、CPU、RAM、ディスク I/O、帯域幅などの一般的なボトルネックが発生します。 一部のロード テスト システムには、このデータをキャプチャし、サイトにアクセスする同時ユーザーの数と、それらのユーザーの平均応答時間を関連付けるために、サーバーにインストールできるコンポーネントが組み込まれています。 応答時間の大きな増加またはスパイクは、何かがシステム内で最適以下で実行されていた良い指標かもしれません。 これらの指示は、多くの場合、ドリルダウンと減速の正確な原因を見つけるために使用できます。

 

ロード テストのユース ケース


ソーシャルエンタープライズ – ウェブページ
: 子どもの貧困を終わらせるためのよく知られた年次キャンペーンは、キャンペーンを見越してウェブサイトのホームページと寄付ページにアクセスする最大1ミリオン同時ユーザーをロードする必要があります。 HTTP ベースのユーザーロードでは、この規模のテストは、合理的な価格で簡単に達成され、組織のキャンペーンを成功に導きました。

オンライン車両市場 – ウェブ アプリケーション: テスラを販売するためのオンラインアプリケーションでは、1日あたり最大1,000件の新しいリスティングをテストする容量テストが必要で、プラットフォーム全体で同時に50万以上のリスティングを検索できます。 ここで、LoadView の ウェブ アプリケーションスクリプトは、動的なフィルタリングでアプリケーションをステップ実行する機能を提供し、過度のユーザーシミュレートされた負荷の下でデータベースをロード テストします。 広範な国際地理分布は必要とされていませんでしたが、より現実的なキャパシティ テスト シナリオを実現するために、米国の 5 つのデータセンターに負荷を分散しました。

SaaS プラットフォーム – ウェブ サービス / API: サードパーティ製アプリを接続するための B2B SaaS プラットフォームは、プライベート ネットワーク、プレベータ リリースから、ファイアウォールの背後にある API コネクタをロード テストする必要があります。 LoadView は、ネットワーク セキュリティ チームと協力して、プライベート エージェントを内部ネットワークにインストールし、ホワイトリストに登録された静的プロキシ IP を介してロード テストを実行しました。 QA チームは新しいプラットフォームのベンチマークを成功に導き、パブリックベータリリースに対する信頼を確保しました。

 

セレン&JMeterを使用してロードテストを行う方法

セレンとJMeterは、ロードテストを実行するために使用されるソフトウェアの2つの例です。 Selenium は、ブラウザー内でユーザーのアクションを記録し、それらを再生できます。 Selenium スクリプトは、異なるプログラミング言語やテストプラットフォームを使用して編集することもできます。 セレングリッドは、一度に複数のマシンから複数のテストを実行することができます。 Selenium はロード テスト専用に設計されていませんが、複数のテスト プラットフォームと直接統合するスクリプトの生成に使用できます。

JMeterは、ロードテストウェブアプリケーション用に特別に設計されたApacheによるオープンソースのパフォーマンステストプラットフォームです。 JMeterは、ブラウザレベルでは動作しません、それは単にプロトコルレベルで動作します。 ウェブ サーバーの観点からはブラウザーのように見えますが、実際にページをレンダリングして JavaScript を実行するなど、ブラウザーが実行できるすべてのアクションを実行することはできません。 JMeterは、負荷テスト中に多くの同時ユーザーからウェブサイト上の要求を生成するために良いです。 JMeterの重要な違いは、あなたのウェブサイトやウェブアプリケーションで仮想ユーザーを自分のコンピュータから送信するため、LoadViewのように実際のトラフィックデータを収集することはできません。 LoadViewには世界中に複数のデータセンターがあるため、ユーザーが配置されている場所からテストすることができます。

 

ロード テスト ツールのしくみ

ほとんどのロード テスト ツールを使用すると、ウェブ サイトやアプリケーションと対話するスクリプトを記録または記述できます。 これらのスクリプトは、テスト シナリオまたはスケジュールされたテストに配置されます。 次に、テストに必要なスコープとユーザーの数量、およびテストを実行する時間の長さを特定します。 時間の経過に合ったユーザーのスケールアップを可能にするテストもあれば、テスト内の同時ユーザーの最大数を特定して一度にスピンアップするテストもあります。

 

テストシングルページアプリケーションをロードする方法

単一ページ アプリケーション (SPA) は、ユーザーが操作を実行するたびにページを必ずしも再読み込みするわけではないため、KPI の測定に関してテストするのが難しい場合があります。 多くの一般的なクライアント側およびクライアントサーバー側の JavaScript フレームワークは、SPA を作成するために使用されます。 Angular、次.js、反応、Vueなどのフレームワークは、すべて、SPAの開発に使用することができます。 単一ページアプリケーションは、毎回新しいページを読み込むのではなく、単一ページに「適合」し、動的に更新します。 これにより、ユーザーはよりスムーズで、より反応的なエクスペリエンスを提供します。 ロード テスト プラットフォームによっては、ボタンクリックなどのアクション間の時間を測定し、結果のデータを画面に表示し、他のシステムではスクリプトの完了にかかった合計時間しか測定できない場合があります。

ロード テスト シングル ページ アプリケーション

LoadView プラットフォームは、他の ウェブ サイトや ウェブ アプリケーションと同じ方法で SPA をテストできます。 ただ、EveryStep Webレコーダーでユーザーエクスペリエンスをスクリプトし、実際のブラウザから負荷の下でタスクを実行する仮想ユーザーを実行します。 ブレイズメーターやフラッドなどの他の負荷テストツールは、JMeterを利用します。 前に述べたように、JMeterは、JavaScriptを実行することができないプロトコルレベルで動作するため、ブラウザやユーザーが実行できるすべてのアクションをテストすることはできません。 JMeterの詳細については 、JMeter負荷試験ガイドをご覧ください。

ロード テストを
次のレベル

無限のスケーラビリティで比類のない機能を体験できます。 クレジットカードなし、契約なし。