ロードテスト
ロード テストとは何か 、 ロード テストが重要な理由
ロード テストは、ソフトウェア、Web サイト、Web アプリケーション、API、またはシステム上で実際の使用状況や負荷をシミュレートして、応答性、劣化、スケーラビリティなどの要因を分析および特定する方法です。
ロード テストとは
定義ロード テストは、一般に、テストをソフトウェア パフォーマンス テスト プロセスのサブセットとして指し、通常は、ストレス テスト、スパイク テスト、耐久テスト、ボリューム テスト、スケーラビリティ テストなど、他の種類のテストなど、他のいくつかの種類のテストも含まれます。
パフォーマンスの低いサイトやアプリケーションは、コンバージョン、トランザクション、そして最も重要な収益に悪影響を及ぼす可能性があります。 数秒のダウンタイムでも、企業の収益に大きな影響を与える可能性があります。 バックアップおよびデータ管理の分野でグローバルリーダーであるVeeamが最近実施した調査では、1,500人以上のITプロフェッショナルが、優先度の高いアプリケーション のダウンタイムが1時間のコスト が84,000ドルを超えていることがわかりました。 さらに、ダウンタイムの平均時間は 79 分でした。
金融サービスや大規模なオンライン小売業者など、大量の取引に依存する特定の業界を考慮すると、影響がより大きくなる可能性があります。 また、調査では、顧客信頼の低下、ブランドの完全性の低下、株価の下落など、顧客や訪問者への影響も示されています。 したがって、ご覧のとおり、パフォーマンスの要求を満たすためにアプリケーションをテストすることの重要性は誇張できません。
ロード テストは、サイト、アプリケーション、およびシステム上の実際のシナリオをシミュレートします。 開発者は、負荷テスト中およびロード テスト後に収集された情報を通じて、制限を測定し、次のような質問に答えるうえで役立つメトリックについて洞察を得ることができます。
- ユーザー数はパフォーマンスにどのような影響を与えますか?
- Web サイト、アプリケーション、またはシステムが処理できる同時ユーザー数はいくつですか。
- ボトルネックはどこにあるのか?
- 特定の期間に処理できるトランザクションの数はいくつですか。
- ブレークポイントは何ですか? リソースが不足する場合はいつになりますか?
以前は、 ロード テスト は開発プロジェクトの完了に向けてのみ実行されていましたが、アジャイル ソフトウェア開発プロセスに再び重点を置いているため、開発チームはテストを左にシフトしています。 サイト、アプリケーション、システム、API (アプリケーション プログラミング インターフェイス) がどの程度処理できるかを正確に把握すると、コードがステージング環境にコミットされる前に、バグやデータベースの速度低下など、さまざまな問題を特定して発見するのに役立ちます。 たとえば、クライアント側のすべてのアプリケーションは、さまざまなテストを実行して制限を判断し、ユーザー エクスペリエンスの向上を支援する必要があります。 アプリケーションのパフォーマンスの問題が運用環境で検出されない場合、必要なコスト、時間、およびリソースは、問題の場所を特定しようとする必要があります。
ロードビューを使用したロードテスト
LoadView はオンデマンドのクラウドベースのロード テスト プラットフォームであり、サイト、Web アプリケーション、モバイル アプリケーション、API がさまざまなトラフィックにどのように対応するかを決定します。 負荷テストは時間のかかるプロセスになる可能性があります。 LoadViewは、ジェネレータのインスタンス化やグローバル分散エージェントの設定など、面倒なタスクを管理します。 これにより、開発者はテストの設計、実行、分析に時間を与えます。
テスト対象のシステムのニーズ、ユース ケース、またはテクノロジに応じて、LoadView プラットフォームは、HTTP/S や実際のブラウザベースのシミュレーションなど、さまざまな種類のユーザー シミュレーションを実行できます。
HTTP/Sベースのシミュレーション: プロトコルベースのシミュレーションは、最新の Web アプリケーション フレームワークとテクノロジによりロード テストの従来のアプローチと考えられていますが、プロトコル レベルのスクリプトは CI/CD 環境でのコンポーネント レベルのテストに最適で、インジェクション マシンのフットプリントが低くなります。
実際のブラウザベースのシミュレーション: 実際のユーザーの動作を模倣する必要がある場合や、Angular、AJAX (非同期 JavaScript と XML)、JavaScript、 フラッシュ、反応など、特定の動的な Web アプリケーションフレームワークとテクノロジを使用する Web アプリケーションを使用する必要がある場合。 実際のブラウザを使用することが重要です。 このシミュレーションを使用すると、開発者は、ユーザーが認識するサイトの機能と速度を検証できます。 実際の運用環境ではなく、エラーやボトルネックを検出してテスト環境で修正する必要があります。
EveryStep Web レコーダー – Web サイトおよびアプリケーション用のカスタムロードテストスクリプトを作成する
EveryStep Web Recorderは、Web トランザクションのすべてのステップを記録し、実際のブラウザーを使用してスクリプトを再生する、無料の Web ベースのスクリプトツールです。 ボタンのクリック、メニューの選択、フォームの送信、ショッピング カート プロセス、テキスト入力、画像やテキストの検証など、ユーザーが行う重要かつ複雑なアクションの複数ステップのテスト スクリプトを記録します。
40以上のデスクトップ(Chromeとインターネットエクスプローラ)とモバイルブラウザ(iPhone、iPad、Google、サムスンなど)と互換性があり、EveryStepウェブレコーダーは、AJAX、Angular、JavaなどのWebアプリケーション技術やフレームワークに関係なく、ブラウザでレンダリングされる事実上のすべてをサポートしています。 HTML5、フラッシュ、PHP、ルビー、および他の多くの。
さらに、EveryStep Web Recorder では、特定のロード テスト要件に応じて、独自の C# コードを使用してスクリプトを手動で編集でき、環境内の他の繰り返しタスクのテスト実行を自動化するために再利用できます。 これらのスクリプトは LoadView プラットフォームにアップロードされ、実質的に無制限の同時ユーザーによって再生されます。 また、特定の間隔で実行されるスクリプトをセットアップし、エラーが発生した場合にチームに警告を表示し、すべてがスムーズかつ適切に実行されるようにすることができます。
クレジットカードなし、契約なし。
ロード テストの利点
ロード テストの目的は、Web サイト、アプリケーション、またはシステムが定期的に適切に管理する必要がある、大きな劣化を経験することなく、予想されるトラフィックをシミュレートすることです。 予期しないユーザーの増加によってシステムが時折減速する場合がありますが、システムは予想される時間内に通常の操作を回復して再開する必要があります。
- ページの読み込み時間を短縮する: ユーザーエクスペリエンスに関してはスピードが重要であり、遅いサイトやアプリケーションは顧客をせっかちにしたり、サイトを完全に離れたりします。 収益を促進するために重要なページがある場合、 負荷テスト は特定の問題を特定するのに役立ち、WebOps チームが影響を受けるページを優先して問題を解決し、潜在的な悪影響を最小限に抑えることができます。
- ボトルネックの発見:開発段階でアプリケーションやサイトを ロード テスト すると、CPU、メモリ、ネットワーク使用率などの一般的なボトルネックが見つかり、開発者はコードやアプリケーションを運用環境に移行する前にこれらの問題に対処できます。
- 地理的な場所:ほとんどの顧客がどこから来たかわかっている場合は、それらの場所からテストを設定すると、それらの訪問者に影響を与える特定の問題を特定できます。 これにより、どの地域からアクセスしても誰でもサイトにアクセスでき、世界中で一貫した体験が得られます。
- サービス レベル アグリーメント (SLA) の確立: 容量計画は、事前定義された要件のセット内で、アプリケーションを実行するために必要なハードウェアリソースとソフトウェア リソースを決定するのに役立ちます。 負荷テストは、負荷の大きい環境下でアプリケーションがどのように実行されるか、また将来追加のインフラストラクチャへの投資が必要かどうかを予測するのに役立ちます。
ロード テストに LoadView を使用する利点
顧客とユーザーは、信頼性が高く、高速な Web ページとアプリケーションを期待します。 そうでなければ、彼らはすぐに代替案を見つけるでしょう。 組織は、堅固なカスタマー エクスペリエンスを提供することの重要性を理解しており、負荷 テスト の価値が収益に対してどれほど重要であるかを把握しますが、すべての企業が、これらのタスクを実行するために必要なリソース、チーム、インフラストラクチャ、または時間を持っているわけではありません。
LoadView プラットフォームは、オンデマンドのクラウドベースのロード テスト ソリューションであり、追加のインフラストラクチャへの投資を必要とし、世界中の複数のポイントから仮想負荷インジェクタを作成するという時間のかかる課題を排除します。
その他の機能は、次のとおりです。
- プロトコル レベルと実際のブラウザー ベースのテスト。
- EveryStep Web レコーダーを使用した実際のブラウザーベースのスクリプト。
- 40以上のデスクトップ/モバイルブラウザとデバイスの高度なスクリプトサポート。
- 荷重曲線オプション – 荷重ステップ、ゴールベース、およびダイナミック調整可能曲線。
- 複数のグローバルな場所からテストします。
- 数十から数千の仮想ユーザーにスケールします。
- ユーザーが認識する応答時間を測定します。
- アップタイム監視用に ロード テスト スクリプトを再利用します。
- あなたが使用するもののために支払う、長期契約なし。
- サポートは24時間、週7日利用可能です。
これらの利点は、現在市場に出回っている他の 負荷テスト ソリューションとは別にLoadViewを設定し、 ロードテスト の制御をユーザーの手に委ねています。
ロード テストのベスト プラクティス
Web サイトとアプリケーションは、ビジネスの成功に不可欠です。 これは通常、顧客が最初に見るものであり、それが低迷またはクラッシュした場合、彼らはすぐに代替案を見つけるでしょう。 ページの読み込みが速いほど、顧客は滞在し、将来戻ってくる可能性が高くなります。Web サイトやアプリケーションの 負荷テスト により、予想されるレベルのユーザーの下で機能し、プロセスに影響を与える可能性のあるエラーに関する洞察を得ることができます。 ユーザーに優れたエクスペリエンスを維持するために実装できるベスト プラクティスの 5 つについて説明します。
- ビジネス目標と目的を特定する。 マーケティング、運用、プロジェクト マネージャーなど、組織内の他の部門が Web サイトやアプリケーションのパフォーマンス目標をどう信じているかを考えてみましょう。 また、 ロード テスト の目的をどう思うかを、別々に質問します。 プロジェクトの範囲内で重要と思われるものと、質問や懸念が一致しているか、または一致していないかを確認できますが、それでも、あなたの基盤をカバーし、優れたユーザーエクスペリエンスを提供しています。
2. 測定したい指標を決定します。 アプリケーション、使用するテクノロジ、環境の組み合わせによって異なりますが、一般的な基準には、ユーザーの認識応答時間、特定の地域別の応答時間、リソース使用率 (CPU、メモリ、ディスク、帯域幅)、エラー数、最大ユーザー数、その他のビジネス パフォーマンス メトリックが含まれます。
3. ロード テストを設計します。 テストを設計する場合は、テストする負荷、特定のユーザー トランザクション、およびテストの組み合わせや順序など、いくつかの重要な要素を決定します。 テストを開始する場所がわからない場合は、IT 部門やマーケティング部門など、以前のアプリケーションや類似のアプリケーション (同時ユーザー数、特定の時間のピーク セッション、ページ ビューなど) から履歴テスト データを収集するために、分析ツールから参加します。 情報のためのもう一つの素晴らしいスポット? あなたの競争。 業界の競合他社が、特定の顧客指標に関する情報や公開プレスリリースを公開している場合があります。 これにより、テストを開始できるベースラインが得られた場合があります。 特に Web アプリケーションの場合、考慮すべきその他の要因としては、特定のナビゲーション パス、遅延、使用されているブラウザー/デバイス、および地理があります。 要するに、ユーザーの環境に最も適したテスト スクリプトを作成します。
4. アジャイル開発プロセスの負荷テストを一部にします。 以前は、パフォーマンス テストは通常、開発プロジェクトの終了に向けて行っていました。 その結果、プロセスの後半でエラーと問題が検出され、開発者はコードを再び実行して問題を修正し、通常はリリースが遅れました。 アジャイル方式は、開発サイクルの早い段階で実施される小規模なインクリメンタル テストに焦点を当てており、プロセス中に問題を解決できます。
5. 常にユーザーエクスペリエンスを念頭に置いてください。 顧客満足度は、ビジネスの成功にとって重要です。 これは、 ロードテスト やAPIがウェブサイトやアプリケーションを 監視 する際の全体のポイントです。 前述のように、サイトやアプリケーションのパフォーマンスを高くするほど、顧客がサイトに再訪したり、アプリケーションを再入力したりする可能性が高くなります。
ロード テスト ツールの選択方法
今日の市場では、さまざまな機能を備えたツールやプラットフォームの量と多様性に終わりはありません。 BlazeMeterのようなオープンソース専用ツールを活用するプラットフォームから、ファントムJSのようなヘッドレスブラウザのみのソリューション、またはLoadViewのような複数のユーザーシミュレーションを提供するプラットフォームまで。 ニーズや要件に最適な ロード テスト プラットフォームを選択します。
実際には、ビジネスニーズ、目的、環境、予算によって異なります。 このことを念頭に置いて、少なくとも、サイトまたはアプリケーションが実際の状況で立ち上がるかを判断する必要があります。 ロード テストツールを選択する際に、次のような質問と条件を満たす必要があります。
- 使い方は簡単ですか? このツールには複雑なセットアップ手順が必要ですか。
- テスト スクリプトを迅速に作成し、テストを実行します。
- 最も頻繁に使用されるブラウザーやデバイスのサポート。
- 実際のブラウザベースのユーザシミュレーションを利用します。
- 実稼働環境でのサイトやアプリケーションの監視用に ロード テスト スクリプトを再利用します。
- 長期契約なし、あなたが必要とし、使用するものだけを支払います。
- 特定した指標を収集して報告します。
- 必要な負荷量を生成します。
- 実際のユーザー ベースのトランザクションをシミュレートします。
- 専用のサポートおよび/またはナレッジ ベース。
前に述べた主な考慮事項の 1 つは、クライアント側のアクティビティ、より具体的には Web 2.0 テクノロジを測定する場合です。 ナビゲーション、ボタンのクリック、フォーム内での日付の入力など、ユーザーの操作をシミュレートする際には非常に重要です。 この場合、選択したツールは、実際のブラウザを使用してできるだけ近い方法で複製する必要があります。 また、ほとんどのユーザーがどこにいるかも考慮してください。 地理的な場所は、顧客体験の大きな部分を果たしており、無視すると、ユーザー エクスペリエンスに悪影響を及ぼします。 LoadViewソリューションは、世界中から40以上のロードインジェクタサーバーから選択するオプションを提供します。
EveryStep Web レコーダーを使用したロード テスト スクリプトの作成
ここで、LoadView プラットフォームは他のツールとは別に設定されます。 その強さは、複数のユーザーシミュレーションをシミュレートすることから来ています。 主に、AJAX、Flash、HTLM5、JavaScript、およびその他のリアなどの今日の Web アプリケーションの実際のブラウザベースのユーザーシミュレーション用のロードテストスクリプトを作成するために使用されますが、プロトコルベースのテストもシミュレートできます。 さらに、プラットフォームは、特定の地理的位置を通じてパフォーマンスを評価するために、複数のクラウドの場所を迅速にスピンアップできます。 さらに、テスト用に作成したスクリプトは、サイトまたはアプリケーションが本番環境に移行した後、定期的な稼働時間監査のために監視プラットフォームに統合できます。
シフトレフトテストとロードビュー
今日のアプリケーションは、サードパーティのプロバイダとCDNの広大なネットワークに依存して、複数の技術で構築されています。 さらに、エンド ユーザーは、さまざまなブラウザ、オペレーティング システム、モバイル デバイスを使用して、さまざまな接続速度を使用して、世界中のどこからでもサイトやアプリケーションにアクセスできます。 応答時間、品質、可用性は、アプリケーションを運用環境に移行する前に評価する必要がある重要な要素です。
開発段階とテスト段階でサイト、アプリケーション、API がどの程度処理できるかを正確に把握することで、アプリケーションを運用環境に移行する前に、バグ、ハードウェアのボトルネック、データベースの速度低下など、さまざまな問題を特定して発見できます。
これらのパフォーマンスメトリックは、顧客とクライアントの要求を満たすことができるように、容量計画を支援するために必要です。 パフォーマンスの低いサイトやアプリケーションは、コンバージョンに影響を与え、最終的には収益に影響を与えます。
シフトレフトテスト、LoadView によるロードテスト、および DevOps プラクティスの意味について詳しくお読みください。
1つの便利なロードテストソリューションからすべて。
What is load testing software?
How do you load test a software?
What are the types of load testing?
Why do we do load testing?
How long should a load test run?
負荷テストに関する FAQ – すべての質問に回答
目次
- ストレス テストはロード テストと同じか。
- ソフトウェアの負荷テストとは何ですか?
- NET と Java のロード テストとは何ですか。
- QA での負荷テストとは何ですか。 ソフトウェア テストにおけるパフォーマンス テストとは
- パフォーマンス テストにおけるスループットの意味は何ですか。
- JMeterの負荷試験とは何ですか? ロードランナーでのロードテストとは何ですか?
- SoapUIでの負荷テストとは何ですか? スパイクテストとは何ですか?
- ロード テストの責任者は誰ですか。 ロード テストを実行するユーザー
- どの負荷テストツールを使用する必要がありますか? 最適なロード テスト ツールはどれですか。
- ロード テストを開始する必要がある場合 ロード テストはいつ行われますか。
- ロード テストを実行する理由 ロード テストが重要なのはなぜですか。
- ロード テストの目的は何ですか。
- パフォーマンス テストとは
- さまざまな種類のパフォーマンス テストを行う方法
- パフォーマンス テストを使用するタイミング
- パフォーマンス テストが必要ないのはいつですか。
- パフォーマンス テスト プロセスとは何ですか。
- パフォーマンス テストはどのように自動化できますか。
- パフォーマンス テスト ツールのしくみ
- パフォーマンス テストを自動化する必要がある理由
- パフォーマンス テストのライフ サイクルとは何ですか。
- モバイル アプリケーションのパフォーマンス テストを実装する方法
- ロード テストの実行方法
- デスクトップ アプリケーションをロード テストする方法
- ロード テストは手動で行えますか?
- Web サイトのロード テストの実行方法
- ロード テストのユース ケース
- セレン&JMeterを使用してロードテストを行う方法
- ロード テスト ツールのしくみ
- テストシングルページアプリケーションをロードする方法
ストレス テストはロード テストと同じか。
ストレス テストは、システムを制限を超えてシステムをプッシュし、システムが何らかの方法で中断するロード テストです。 ストレス テストは負荷テストのサブグループと見なされます。 すべてのロード テストがストレス テストと見なされるわけではありません。 容量計画を目的としたロード テストは、Web サイト インフラストラクチャが処理できる同時ユーザーの最大数を知って実行できるため、Web サイトインフラストラクチャの障害が発生しない可能性があります。
Web サイトの ロード テスト の定義は、Web サイトに指定された負荷量を生成しています。 通常、テストは、ウェブサイトを訪問する実際のユーザーを模倣する方法で実行されます。 より高度なテストでは、主要な要素、ボタン、フィールドをクリックしてサイト内を移動するなど、Web サイト上で一連の手順を実行できます。
ソフトウェアの負荷テストとは何ですか?
ロード テスト ソフトウェアは、ソフトウェア システム上でユーザー負荷を生成するから成ります。 ソフトウェア システムが複雑になり、多くの層とコンポーネントが存在する場合 、Postman ロード テストを含むさまざまな種類のテストで構成される可能性があります。 ソフトウェア ロード テストは、システム上でも実行することも、ソフトウェア アーキテクチャの 1 つ以上のコンポーネントを分離することもできます。 このようなコンポーネントには、ユーザー インターフェイス、API、データベース接続、またはサーバー、ルーター、ファイアウォール、ロード バランサーなどの基盤となるハードウェアを含めることができます。
ソフトウェアは、従来の Windows フォームから Java アプレット、Web アプリまで、さまざまなプラットフォーム上に構築できます。 Web アプリが公開 Web サイト上にある場合は外部環境からテストできますが、Windows フォームは通常、1 台以上のローカル コンピューターからインストールおよびテストする必要があります。 一部のローカル アプリの場合、ユーザー インターフェイスをバイパスして、基になる API、データベース、またはデータ アクセス 層に直接呼び出しを行うだけで、テストを実行できます。 ロード テスト ソフトウェアを最終的にどのように選択するかは、テスト時にどのような側面を懸念しているかによって決まります。
NET と Java のロード テストとは何ですか。
.NET (通常は C#) は、Windows フォーム アプリケーションまたはデスクトップ アプリケーションと Web アプリケーションの両方でバックエンドで使用されるため、ロード テストの .NET アプリケーションは、いくつかの異なる種類のテストを参照できます。
Java のロード テストは、Java 仮想マシン上のさまざまな環境でネイティブに実行できるため、いくつかの異なる種類のテストを参照することもできます。 Java アプレットは、Web サイトからも実行できます。
NET と Java の 両方のロード テストでは、さまざまな設定で繰り返し実行できるさまざまなテストを設定するためのテスト スイートが必要になる場合があります。 このようなソフトウェアスイートやサービスは、多くの場合、 ジェンキンスのようなコード管理と自動化ソフトウェアと統合します。
QA での負荷テストとは何ですか。 ソフトウェア テストにおけるパフォーマンス テストとは
QA での負荷テストとは、品質保証中にソフトウェア システムに一定数の同時ユーザーを適用することを意味します。 品質保証のロード テストでは、ソフトウェアの各イテレーションが、少なくとも最小同時ユーザー数を処理できることを保証し、最大でソフトウェア システムが処理できる同時ユーザーの最大数を特定します。 QA ロードテストは、継続的インテグレーションを使用して環境内で Jenkins のようなソフトウェア自動化を使用して実行されることがよくあります。
パフォーマンス テストにおけるスループットの意味は何ですか。
パフォーマンス テストを実行する場合、スループットとは、アプリのフロントエンドとバックエンド間で一定期間にわたって転送されるデータの量を指します。 具体的には、テストのスループットは、ネットワーク帯域幅、データベース I/O、同時ユーザー、最大メモリの制約、ディスクの読み取りと書き込みなどの要素を意味します。 これらのコンポーネントは、理論的には、クライアントからサーバーへのデータのスループットのボトルネックになる可能性があります。 負荷が増大するに従ってこれらのさまざまなボトルネックのスループットを監視すると、システム速度低下の原因を特定できます。
JMeterの負荷試験とは何ですか? ロードランナーでのロードテストとは何ですか?
JMeterは、ウェブアプリをテストするためのApacheによるオープンソースアプリケーションです。 JMeter は、Web アプリ、Web サービス、データベース クエリなど、さまざまな種類のアプリに大きな負荷を生み出す可能性があります。 JMeterについて覚えておくべきことの1つは、プロトコルレベルでのみ動作することです。 つまり、クライアント側の対話を含むパフォーマンス テストを実行する場合、JMeter はこのジョブのツールではありません。 JavaScript または AJAX 要求を実行できません。 さらに、JMeterはローカルデバイスにインストールする必要があるため、テストを特定のポイントまでしか拡張できません。 大規模なテストは実行できません。 これらの理由から、JMeter を避け、Web アプリケーションフレームワークやテクノロジー、実際のブラウザ、および完全に管理された負荷インジェクタをサポートする LoadView のようなソリューションを検討する必要があります。
LoadRunner は、アプリをテストするためのツールです。 LoadRunner は、サービスに直接メッセージを生成したり、マウスの動きやボタンの押下やキーボード エントリのスクリプトを記録して UI とユーザー操作をシミュレートすることによって、アプリのさまざまなレイヤーをテストするために使用できます。 LoadRunner は 、Microsoft .NET アプリや Java アプリなど、さまざまなアプリをテストできます。 LoadRunnerは、データベースやネットワークプロトコルと直接インターフェースを組み合うことも可能です。
しかし、ロードビューは、ほぼすべての方法でJMeterとロードランナーの両方よりも優れています。
SoapUIでの負荷テストとは何ですか? スパイクテストとは何ですか?
SoapUI は、API の機能テストを実行するために使用されます。 SOAPUI は、SOAP と REST APIの両方のテストに使用されます。 API のロード テストでは、複数の接続 (要求) が API に作成され、SOAP または REST API サーバーを介して異なる数の同時要求でパフォーマンスを測定します。
スパイク テストは、システム上のトラフィックの大きなスパイクをシミュレートするために、急速に増加する同時要求数を実行する特定の種類のパフォーマンス テストです。 スパイク テストは、急速に増加する時期や同時ユーザー数が多い時間帯に、API またはアプリのボトルネックをロード テストするために使用できます。 スパイクテストの目的は、需要が急激に増加または減少するにつれて、ソフトウェアまたはアプリ内の異常を検出して分析することです。 多数の同時ユーザーが Web サイトやアプリをヒットする前にスパイク テストを実行すると、サイトやアプリの速度低下やクラッシュの原因となるボトルネックを特定できます。 スパイク テストでは、アクティビティのスパイク間でプログラムやアプリがどのように反応するかについての洞察も得られます。
LoadView は API をテストでき、SoapUI より多くの点で優れています。
ロード テストの責任者は誰ですか。 ロード テストを実行するユーザー
多くの場合、QA チーム、DevOps、あるいはマーケティングが、Web サイトや Web アプリのロード テストを担当しています。 QA は通常、テスト環境でのソフトウェアおよび Web アプリのテストの大半を処理しますが、DevOps はソフトウェアが運用ハードウェアで正しく動作しているかどうかを確認します。 マーケティングは、ウェブサイトの訪問者の数が多いのを担当しているので、ウェブサイトのインフラストラクチャが製品の発売や販売促進などのイベントからの高い訪問者のトラフィックを処理できるかどうかに関心があります。
ロード テスト は通常、QA と DevOps という同じグループによって実行されます。 時には、負荷テストは 、開発者や開発チームによっても実行することができ、アプリが重い需要の下でスケールアップされることを確認します。 ただし、開発チームが適切なテストを行うのに十分なマシンを回転させるアクセスやリソースを持っていない可能性もあります。
どの負荷テストツールを使用する必要がありますか? 最適なロード テスト ツールはどれですか。
さまざまな ロード テスト ツールが用意されており、基本的に無料と有料の 2 つのカテゴリに分類されます。 有料のツールは明らかに堅牢で、より幅広いデータと機能を備えていますが、無料のツールはしばしばオープンソースであり、無償で利用できます。
LoadViewは、包括的なロードテストスイートであり、市場で最高のロードテストツールです。
ロード テストを開始する必要がある場合 ロード テストはいつ行われますか。
必要に応じてロード テストを開始します。 多くの人がロード テストを開始する時点では、必要な変更を行ったり、追加のテストを処理するためのヘルプを得るための十分な時間がありません。
開発プロセスの主要なマイルストーンでテストを実行し、適切な先見性を持つ場合、Web インフラストラクチャは、運用段階での負荷の大きなスケーリングと処理の問題を大幅に減らします (テストの結果としてインフラストラクチャを最適化するためのアクションが実行されると仮定します)。
ロード テスト は、Web サイトに大量の同時トラフィックをもたらす可能性のある主要なイベントの前に実行する必要があります。 理想的には、新しいコード、または Web サイトや Web アプリの更新の公開前に、オフピーク時に運用環境でテストを実行する必要があります。 これは、テストが失敗した場合に直前のシステム調整を可能にし、公開リリースの前に十分に完了する必要があります。
多くの場合、ロード テストは、新しい製品、新しいキャンペーン、主要なイベント、またはシステムの更新のリリースの直前に実行されます。 ロード テストの目的は、Web サイト インフラストラクチャが予想される数のユーザーを処理できるようにすることなので、ロード テストの結果に応答するのに十分な時間が得られていない可能性があります。
ロード テストを実行する理由 ロード テストが重要なのはなぜですか。
実際の需要がウェブサイトに置かれたときに不意を突かないように、ロードテストを実行します。 サーバーが処理できる同時ユーザーの最大数を知る必要があり、その数に達した場合は準備する必要があります。 あなたが大量のトラフィックに備えていない場合は、あまりにも多くの訪問者が同時にあなたのサイトをヒットしたときに、あなたのウェブサイトが遅い場合、あるいはクラッシュした場合にビジネスを失うことになる可能性が高いです。
ロード テスト は、システムの障害点を特定し、同時ユーザーが追加される際にサイトがどのように劣化するかを示すため、重要です。 ピーク時のトラフィックがどのようなものになるかが分かっている場合、ロード テストを実行すると、そのレベルのトラフィックに到達した後に Web アプリやサイトがどのように実行されるのかを詳しく把握できます。
ロード テストの目的は何ですか。
ロード テスト は、通常、次の 3 つの理由で実行されます。
- キャパシティプランニング
Web サイトで処理するトラフィックのサイズと量が大まかにある場合は、その制限に達するまで負荷をゆっくり増やすテストを設定できます。 このタイプのロード テストは、Web サイトの予想容量を計画するのに役立ちます。
- 重大な障害ポイントの特定
多くの場合、重大な障害が発生するまで、同時に Web アプリをヒットできるユーザーの数を探しているだけかもしれません。 この時点で、障害のトラブルシューティングを行い、根本原因を特定し、障害が発生したコンポーネントを軽減するか、少なくとも将来の修正のためにボトルネックにフラグを立てることができます。
- 新しい変更によって スケーラビリティ のバグやその他の予期せぬ結果が生じるかどうかをテストする
運用環境で何かを更新するたびに、バグやその他の意図しない変更が発生する可能性があります。 ロード テストは、コードやコンテンツの更新ごとにテストを実行することで、これらの潜在的な負債の一部を排除するのに役立ちます。
パフォーマンス テストとは
パフォーマンス テスト では、通常、Web サイトまたは Web アプリケーションのパフォーマンスに関連するさまざまなメトリックを測定します。 Web サイトのテストでは、ページの読み込み速度、最初のバイトまでの時間、対話までの時間、およびその他のメトリックスを測定します。 パフォーマンス テストは、ロード テストに関連して、通常、システムに需要を追加することによってこれらのメトリックがどのように影響を受けるかを記録します。 複数のアプリ監視ツールを使用している場合でも、システムを実行している基盤となるハードウェア (CPU、RAM、ディスク I/O など)、使用可能な帯域幅、データベースの読み書き、およびシステムで使用されるコードの複雑さなど、テスト結果に影響を与える可能性のある変数がいくつか存在します。 テストを実行した後、結果に影響を与えたコンポーネントを特定し、それらのコンポーネントを調整して Web サイトのパフォーマンスを向上させることができます。 これは、さまざまな種類の Web アプリにも当てはまります。
さまざまな種類のパフォーマンス テストを行う方法
パフォーマンス テストの種類には、次のものがあります。
- 煙のテスト
スモーク テストは低レベルバックグラウンド テストを実行し、システムが最低限の要件を処理できることを確認します。 煙のテストは、ソフトウェア開発の初期段階で行われることがよくあります。 サイクル内のエラーや欠陥を早期に特定することで、チームはより効率的な方法でソフトウェアをリリースし、コストがかかる(そして時間のかかる)最後の欠陥を回避できます。
- ベースライン速度テスト
ベースライン速度テストでは、標準ベースラインメトリックが確立されます。 これらのベースラインは、負荷の高いパフォーマンスでパフォーマンスの違いを監視する場合に、より高度なテストを比較するためによく使用されます。
- スケーラビリティテスト
スケーラビリティ テスト では、通常、負荷の増加に応じてシステムをスケールアップできるかどうかを測定するために、時間の経過とと同時にシステムに多くのユーザーが導入されます。
- 安定性試験
安定性テストには、システムが変更された後でも常に動作する必要があるいくつかの異なるシナリオが含まれる場合があります。 安定性テストが失敗した場合、システムが不安定になったか、システムの変更を処理するために安定性テストを調整する必要があります。
- 容量テスト
容量テストでは、可能な限り最高の数の同時要求をテストすることで Web サイトの最大容量を特定し、時間の経過とともにユーザーを増やすことでその数を増やします。 システムが必要時間内にすべての要求に正常に応答した場合、システムは容量テストに合格しました。
- ストレステスト
スパイク テストと同様に、ストレス テストでは、容量テストをさらに一歩進めて、システムが低下するか完全に障害が発生するまで同時ユーザー数を増やし続けます。
- スパイクテスト
スパイク テストは技術的には”ロード テスト”のカテゴリに該当しますが、両者の間にはいくつかの違いがあります。 スパイク テストは、大量のトラフィックを Web サイトに送信し、サーバーがトラフィックのバーストを処理できるかどうかを確認します。 従来のロード テストは、トラフィック量が異なる場合でも、通常のユーザーの状況のガイドラインの範囲内で、トラフィックの急激な増加や減少だけでなく、さまざまな時間にわたって実行されます。
- 耐久試験
耐久テストは、Web アプリで長期間にわたってさまざまなトラフィックを送信し、システム リソースの使用が延長されたために異常が発生していないかどうかを確認します。 たとえば、メモリ オーバーフローやガベージ コレクションの不適切な理由により、耐久テスト中にバグが発生することがあります。
- 個々のコンポーネントテスト
個々のコンポーネント テストでは、Web サービスやデータベース呼び出しなど、システムの個々の部分を分離し、そのコンポーネントのその他のシステムの外部でさまざまなテストを実行します。 コンポーネントのテストでは、データベース検索やデータベースの書き込みなど、システムの 1 つの側面のみをテストすることもできます。
パフォーマンス テストを使用するタイミング
いつもです。 テストは、Webアプリの開発中、品質保証中、新しいリリース後、新製品リリースやマーケティングイニシアチブの前、システムの変更に関するほとんどすべての時間に使用する必要があります。 今日の市場のさまざまな監視ツールの詳細については、 トップ 15 のアプリケーション監視ツールを比較する記事を参照してください。
パフォーマンス テストが必要ないのはいつですか。
ユーザー エクスペリエンスの質を気にする必要がない場合、Web サイトに多数のユーザーがアクセスしていない場合、または Web サイトがアップまたはダウンしているかどうかに関係がない場合。 ユーザー インターフェイスが絶えず変化している場合、テスト自体を常に変更するため、自動テストのセットアップと実行には実用的でない場合があります。
パフォーマンス テスト プロセスとは何ですか。
テストプロセスは、ウェブサイトをテストする方法によって異なります。 Web ページの読み込み速度を確認したり、ビジネスで最も高速な Web ホスティング オプションを決定したり、更新プログラムがシステムにチェックインされるたびに実行されるソース コード管理プラットフォームに組み込まれている一連のテストを自動化したりする、1 回限りのテストと同じくらい簡単です。 大量のトラフィックが発生する Web サイトの場合、パフォーマンス テストは、同時ユーザー数の増加を適用する定期的なロード テストでも構成されます。 これにより、トラフィックの増加に伴う容量の問題の予測、ボトルネックの特定、および非常に負荷の大きいイベントでのシステムの制限の理解が可能になります。
パフォーマンス テストはどのように自動化できますか。
パフォーマンス テストは、複数のサードパーティソリューションを使用して自動化できます。 これらのソリューションでは、通常、定期的にスケジュールされたオカレンスからコードチェックインによってトリガーされる自動インスタンスまで、多くの要因に基づいてテスト ケースを構築およびスケジューリングできます。 多くのソフトウェア開発ツール (Microsoft Visual Studio チーム ファンデーション サーバーなど) には、自動テストの実行に使用されるコンポーネントも含まれています。
パフォーマンス テスト ツールのしくみ
パフォーマンス テスト ツール は、Web サイトまたはアプリでアクションを実行し、結果を記録することによって機能します。 ページの読み込み時間、対話する時間、ユーザーの応答性など、テスト ツールでは、さまざまなメトリックを記録できます。 測定する 
アプリの部分に応じて、データベースからのデータの読み取り、JavaScript の実行、ファイル ストアからのイメージの読み込みなど、特定の要素に重点を置くさまざまなテストを実行できます。
パフォーマンス テストを自動化する必要がある理由
テストの自動化により、テストを解放して、より高度なテストを実行し、結果の分析に多くの時間を費やすことができます。 自動テストは、ユーザーの操作を最小限に抑えて、コードが変更されるたびに繰り返し実行できます。 自動テストは常に実行されているため、エンド ユーザーが問題を発生する前に、自動テストで問題を検出することがよくあります。
パフォーマンス テストのライフ サイクルとは何ですか。
パフォーマンス テストのライフ サイクルでは、アプリケーションのメトリックを時間の経過とでも測定するために実行する必要がある一連のテストの 1 つ以上に到達するプロセスを記述します。
パフォーマンス テストのライフ サイクルは、Web サイトまたはアプリケーションがまだ開発中の間に開始されます。
最初に、アプリケーションの目標を決定し、対象ユーザーを特定し、対象ユーザーのサイズを決定します。 製品を同時に使用する可能性のある理想的な平均ユーザー数を特定し、重いストレスイベントの発生時に同時に使用できるユーザーの最大数を特定します。
次に、平均的なユーザーがアプリケーションをどのように使用するかを特定し、ユーザーの一般的なパスのスクリプトを記述します。 最も要求の厳しい使用をシナリオの 1 つとして含めます。
次に、理想的な条件下で個々のテストの結果を実行し、記録するだけで、各シナリオのベンチマークを確立します。
アプリケーションのプロトタイプまたは最初のドラフトが作成されるとすぐに、できるだけ早くシステムの制限を検出するためのテストを実行する必要があります。 製品が成熟し、運用環境に展開される場合、負荷の急増、トラフィックの着実な増加、および極端な耐久負荷 (長期間にわたる負荷) など、さまざまなシナリオでの平均パフォーマンス メトリックを測定するテストを実行する必要があります。 テストは、システムの変更ごとに継続して行う必要があり、システムの劣化がないことを確認します。
各シナリオの結果を分析する際、テストは、システムのボトルネックを特定して排除することで、予想される最も極端な需要をサポートするためのインフラストラクチャの進化に役立ちます。
モバイル アプリケーションのパフォーマンス テストを実装する方法
パフォーマンス テスト モバイル アプリは、デスクトップまたは Web ベースのアプリケーションのテストと同じ方法で実行できます。 通常、テストは実際のモバイル デバイスから実行されません。 代わりに、多くの場合、エミュレーターによってシミュレーションで実行されます。 アプリが単にローカルで、ネットワーク接続を必要としない場合、ロード テストは、モバイル アプリのテストの非常に有効な形式ではない可能性があります。
リモート バックエンドに接続するアプリでは、モバイル アプリで同時に数人のユーザーをスピンすると負荷が発生し、システムの速度が低下する可能性があります。 モバイルパフォーマンステストでは、ユーザー接続の種類と品質により、パフォーマンスメトリックにカーブボールを投げ込むこともあります。 ユーザーが高速データが使用できない地理的ゾーンにいる場合は、テストの速度も制限される可能性があります。 LoadView などの一部のロード テスト システムでは、テスト用の接続タイプをエミュレートできます。 これは、アプリが使用する帯域幅を人為的に制限することによって行われます。
ロード テストの実行方法
ロード テスト は、サーバーからの要求を生成したり、システム内の実際のユーザーをシミュレートしたりするための自動化システムを使用して実行されることがよくあります。 ロード テストは、独自のネットワーク内のハードウェアとソフトウェアを使用して内部的に実行することも、サードパーティ製のテスト システムで外部から実行することもできます。 このテストでは、システムの需要が増加するにつれて、システムのパフォーマンスと応答時間を測定します。 テストは、シミュレーション条件下でシステムの実際の応答性を測定し、生産で行う場合に最も適切です。 テストはオンデマンドでスケジュールまたは実行できますが、通常、トラフィックが少ない時間帯にテストが計画されるため、トラフィックの多い問題が最も少ない顧客に影響を与えます。
デスクトップ アプリケーションをロード テストする方法
デスクトップ アプリケーションの負荷テストは、Web ベース アプリケーションのロード テストとは若干異なる場合があります。 デスクトップ アプリケーション全体がユーザーのコンピュータ上にあり、中央のサーバーやデータベースに接続していない場合、複数のユーザーを一度に実行しても、アプリケーションのパフォーマンスに大きな影響を与えない可能性があります。
アプリケーションがサーバーまたはデータベースと通信する場合、ロード テストはパフォーマンスをテストする実行可能な手段である可能性があります。 テストの種類によっては、フロントエンド GUI を実行せずに要求を送信するだけで、デスクトップ アプリケーションをシミュレートする場合があります。 クライアント マシン上のシステム リソースの必要性が低いため、これらのテストは複数の GUI のインスタンス化よりもはるかにスケーラブルです。
ロード テストは手動で行えますか?
ロード テストは、システム内で多数の実際のユーザーを一度にアクティブにするだけで、手動で行うことができます。 ただし、手動ロード テストでは、システムのすべてのメトリックを収集および集計できる自動ロード テストほど重要なデータが返されない可能性があります。 また、手動テストを実行するために必要な個人のコストと時間を考慮すると、LoadViewのようなクラウドベースのロードテストソリューションを使用する場合よりもはるかに大きい可能性があります。
Web サイトのロード テストの実行方法
まず、システムのテスト対象を設定します。 これらの要件に基づいて、実行するテストのあらゆる側面を実行できるロード テスト プラットフォームを選択します。 選択したテスト プラットフォームを理解したら、定義されたユース ケースを正確にシミュレートするスクリプトまたはシナリオを設計できます。 システム内の実際のユーザーをシミュレートするシナリオもあれば、大量の同時 GET 要求を生成するシナリオもあります。 テストの種類は、最終目標によって異なります。 将来の容量計画のためにシステム内の実際のユーザーをシミュレートする場合、システムが故障する前に処理できるユーザーの数を特定するユーザーとは、負荷テストが非常に異なる可能性があります。
ロード テストのシナリオを確立したら、ターゲットの負荷数と、負荷の発生元と場所を決定します。 一部のシステムでは、ローカル マシンから負荷が生成されます。 同時に多数のユーザーを生成するために複数のマシンが必要な場合もあります。 多くのシステムでは、コンピューターごとに複数のシナリオをスピンアップすることができ、クラウド内の複数のマシンをスピンアップするのにも役立ちます。
テストを開始したら、Web サイトをホストしているサーバーのパフォーマンス カウンターを記録し、注意を払います。 ここで、CPU、RAM、ディスク I/O、帯域幅などの一般的なボトルネックが発生します。 一部のロード テスト システムには、このデータをキャプチャし、サイトにアクセスする同時ユーザーの数と、それらのユーザーの平均応答時間を関連付けるために、サーバーにインストールできるコンポーネントが組み込まれています。 応答時間の大きな増加またはスパイクは、何かがシステム内で最適以下で実行されていた良い指標かもしれません。 これらの指示は、多くの場合、ドリルダウンと減速の正確な原因を見つけるために使用できます。
ロード テストのユース ケース
ソーシャルエンタープライズ – ウェブページ
: 子どもの貧困を終わらせるためのよく知られた年次キャンペーンは、キャンペーンを見越してウェブサイトのホームページと寄付ページにアクセスする最大1ミリオン同時ユーザーをロードする必要があります。 HTTP ベースのユーザーロードでは、この規模のテストは、合理的な価格で簡単に達成され、組織のキャンペーンを成功に導きました。
オンライン車両市場 – Web アプリケーション: テスラを販売するためのオンラインアプリケーションでは、1日あたり最大1,000件の新しいリスティングをテストする容量テストが必要で、プラットフォーム全体で同時に50万以上のリスティングを検索できます。 ここで、LoadView の Web アプリケーションスクリプトは、動的なフィルタリングでアプリケーションをステップ実行する機能を提供し、過度のユーザーシミュレートされた負荷の下でデータベースをロード テストします。 広範な国際地理分布は必要とされていませんでしたが、より現実的なキャパシティ テスト シナリオを実現するために、米国の 5 つのデータセンターに負荷を分散しました。
SaaS プラットフォーム – Web サービス / API: サードパーティ製アプリを接続するための B2B SaaS プラットフォームは、プライベート ネットワーク、プレベータ リリースから、ファイアウォールの背後にある API コネクタをロード テストする必要があります。 LoadView は、ネットワーク セキュリティ チームと協力して、プライベート エージェントを内部ネットワークにインストールし、ホワイトリストに登録された静的プロキシ IP を介してロード テストを実行しました。 QA チームは新しいプラットフォームのベンチマークを成功に導き、パブリックベータリリースに対する信頼を確保しました。
セレン&JMeterを使用してロードテストを行う方法
セレンとJMeterは、ロードテストを実行するために使用されるソフトウェアの2つの例です。 Selenium は、ブラウザー内でユーザーのアクションを記録し、それらを再生できます。 Selenium ロードテスト スクリプトは、異なるプログラミング言語やテストプラットフォームを使用して編集することもできます。 セレングリッドは、一度に複数のマシンから複数のテストを実行することができます。 Selenium はロード テスト専用に設計されていませんが、複数のテスト プラットフォームと直接統合するスクリプトの生成に使用できます。
JMeterは、ロードテストウェブアプリケーション用に特別に設計されたApacheによるオープンソースのパフォーマンステストプラットフォームです。 JMeterは、ブラウザレベルでは動作しません、それは単にプロトコルレベルで動作します。 Web サーバーの観点からはブラウザーのように見えますが、実際にページをレンダリングして JavaScript を実行するなど、ブラウザーが実行できるすべてのアクションを実行することはできません。 JMeterは、負荷テスト中に多くの同時ユーザーからウェブサイト上の要求を生成するために良いです。 JMeterの重要な違いは、仮想ユーザーを自分のコンピュータからウェブサイトやWebアプリケーションに送信するため、LoadViewのように実際のトラフィックデータを収集することはできません。 LoadViewには世界中に複数のデータセンターがあるため、ユーザーが配置されている場所からテストすることができます。
ロード テスト ツールのしくみ
ほとんどのロード テスト ツールを使用すると、Web サイトやアプリケーションと対話するスクリプトを記録または記述できます。 これらのスクリプトは、テスト シナリオまたはスケジュールされたテストに配置されます。 次に、テストに必要なスコープとユーザーの数量、およびテストを実行する時間の長さを特定します。 時間の経過に合ったユーザーのスケールアップを可能にするテストもあれば、テスト内の同時ユーザーの最大数を特定して一度にスピンアップするテストもあります。
テストシングルページアプリケーションをロードする方法
単一ページ アプリケーション (SPA) は、ユーザーが操作を実行するたびにページを必ずしも再読み込みするわけではないため、KPI の測定に関してテストするのが難しい場合があります。 多くの一般的なクライアント側およびクライアントサーバー側の JavaScript フレームワークは、SPA を作成するために使用されます。 Angular、次.js、反応、Vueなどのフレームワークは、すべて、SPAの開発に使用することができます。 単一ページアプリケーションは、毎回新しいページを読み込むのではなく、単一ページに「適合」し、動的に更新します。 これにより、ユーザーはよりスムーズで、より反応的なエクスペリエンスを提供します。 ロード テスト プラットフォームによっては、ボタンクリックなどのアクション間の時間を計測し、結果のデータを画面に表示し、他のシステムではスクリプトの完了にかかった合計時間しか測定できません。
LoadView プラットフォームは、他の Web サイトや Web アプリケーションと同じ方法で SPA をテストできます。 ただ、EveryStep Webレコーダーでユーザーエクスペリエンスをスクリプトし、実際のブラウザから負荷の下でタスクを実行する仮想ユーザーを実行します。 ブレイズメーターやフラッドなどの他の負荷テストツールは、JMeterを利用します。 前に述べたように、JMeterは、JavaScriptを実行することができないプロトコルレベルで動作するため、ブラウザやユーザーが実行できるすべてのアクションをテストすることはできません。 JMeterの詳細については 、JMeter負荷試験ガイドをご覧ください。
ロードビューを使用すると、ロード テストが簡単になります
LoadView での私たちの使命は、負荷テストのすべてのことについて、クライアントにとって頼りになるパートナーになることです。 この記事でご覧のとおり、私たちはこの分野に関する包括的な理解と専門家の視点を持っており、私たちのチームは市場で入手可能な最高のロードテストツールスイートを提供するために残業しています。 LoadView は単なるプラットフォームではなく、世界中の DevOps チームのロード テスト パートナーです。
開発者は、手間のかかるテストを実行するよりも、Web サイトやアプリケーションの改善やアップグレードに時間を費やすことを好むため、LoadView は、技術ユーザーと非技術ユーザーの両方のストレスと困難な負荷テストを取り除くために開発しました。
これを超えて、LoadViewでは、常に革新し、クライアントに新しく改善されたリソースを提供することを目指しています。 負荷テストプラットフォームは、急速に変化するデジタルリアリティの変化する需要に合わせて進化する必要があります。 LoadView では、オンデマンドと予算内で、クライアントの成功したロード テストに唯一の焦点を当てています。 LoadView を使用したロード テストの改善により、Web サイトと Web アプリケーションが改善され、ユーザーがパフォーマンスの高い ウェブ サイトとアプリケーションが必要なときに例外なく完璧に動作することを期待していることを知っている企業にメリットがあります。 無料の LoadView 試用版で今すぐテストを開始してください。
次のレベル
無限のスケーラビリティで比類のない機能を体験できます。 クレジットカードなし、契約なし。