負荷テストの種類とシミュレーション

最終更新日:2024年5月17日

負荷テストとパフォーマンス テストが重要な理由

今日のペースの速いデジタル世界では、オンラインプレゼンスが企業にとって最も重要であるため、WebサイトとWebアプリケーションのパフォーマンスと信頼性を確保することは交渉の余地がありません。 非効率なWebページは、読み込みが遅かったり、応答がなかったりすると、財務収益に直接影響します。 潜在的な災害を回避するために、適切な負荷シミュレーションでパフォーマンステストを実施することが重要です。 正しく実行されないと、不満を抱いたユーザーは、問題が後で解決されたとしても、タスクを放棄し、別の解決策を探す可能性があります。 このエンゲージメントの喪失は、収益に影響を与えるだけでなく、消費者の信頼とブランドの完全性を損ない、間違いなくビジネスにとってより有害です。 解決が遅れると、消費者との信頼関係を再構築するという課題が悪化し、製品、チーム、組織への投資収益率の実現が長引くことになります。 したがって、パフォーマンスのテストと監視は、ソフトウェアおよびアプリケーション開発の不可欠なコンポーネントになっています。

負荷シミュレーションのパフォーマンステストは、このプロセスにおいて極めて重要な役割を果たし、組織がさまざまな条件下でシステムのスケーラビリティと応答性を測定できるようにします。 利用可能な多数の負荷シミュレーション手法の中で、パフォーマンステストプラットフォームは、HTTP/S、ヘッドレス、実際のブラウザベースのテストなど、幅広い負荷シミュレーション手法を提供します。 この記事では、それぞれの主な側面の概要を説明し、次に適切なシミュレーションアプローチを選択するために使用できる比較マトリックスを示します。

さまざまなタイプのロード テストとパフォーマンス テスト

負荷テスト: 負荷テストでは、システムに予想される負荷をかけ、その応答を評価します。 主な目的は、通常の負荷条件とピーク負荷条件下でシステムがどのように動作するかを判断することです。 負荷を徐々に増やすことで、テスト担当者は、応答時間の遅さやリソースの制限など、パフォーマンスのボトルネックを特定できます。

ストレステスト:ストレステストは、システムを限界まで押し上げることで、負荷テストにとどまりません。 目標は、システムに障害が発生するブレークポイントまたはしきい値を特定することです。 テスターは、非常に高い負荷や予期しないシナリオを適用して、システムが極端な条件をどのように処理するかを観察します。 ストレステストは、大きなプレッシャーの下で脆弱性、弱点、および潜在的な障害点を明らかにするのに役立ちます。

ソーク試験:耐久試験とも呼ばれるソーク試験は、持続的な負荷の下で長期間にわたるシステムの安定性を評価します。 即時のパフォーマンス メトリックに重点を置いた他のテストとは異なり、ソーク テストでは、長期的なパフォーマンス、リソース リーク、およびメモリの問題が評価されます。 このタイプのテストは、ミッションクリティカルなシステムにとって特に重要であり、長期間にわたって最適なパフォーマンスを劣化させることなく維持できることを確認します。

スパイクテスト:スパイクテストでは、トラフィック量の急激な急増や変動に対してシステムがどのように対応するかを評価します。 これには、フラッシュセールやバイラルコンテンツなどの実際のシナリオをシミュレートするために、負荷を急速に増減することが含まれます。 スパイクテストは、クラッシュやダウンタイムを経験することなく、トラフィックの急激な急増に対応するためにシステムを動的に拡張できるかどうかを判断するのに役立ちます。

ボリュームテスト:ボリュームテストでは、大量のデータの下でのシステムのパフォーマンスを評価します。 パフォーマンスや安定性を損なうことなく、大規模なデータセット、トランザクション、またはユーザー操作を処理することに重点を置いています。 ボリュームテストでは、システムがデータの保存、取得、処理をどのように管理しているかを分析することで、データ量の増加に伴うスケーラビリティと効率性を確保します。

コンカレンシー テスト: コンカレンシー テストでは、システムが複数の同時ユーザーまたはトランザクションを処理する方法を評価します。 同時実行制御メカニズム、データベース ロック戦略、およびリソース割り当てを評価して、競合を防ぎ、データの整合性を確保します。 同時アクセスのシナリオをシミュレートすることで、テスト担当者は並列処理とリソース競合に関連するボトルネックを特定できます。

スケーラビリティ テスト: スケーラビリティ テストでは、リソースの追加や水平方向のスケーリングによって、増加する負荷を処理するシステムの能力を評価します。 これには、システムの拡張に伴って応答時間、スループット、リソース使用率などのパフォーマンス指標がどのように変化するかを分析することが含まれます。 スケーラビリティ テストは、組織がインフラストラクチャのアップグレード、リソース割り当て、および容量計画について十分な情報に基づいた意思決定を行い、増大するユーザーの需要をサポートするのに役立ちます。

HTTPベースの負荷シミュレーションの説明

HTTP ベースの負荷シミュレーションは、プロトコル レベルのテストとも呼ばれ、HTTP 要求を生成して、ユーザーとシステムとの対話をシミュレートします。 このアプローチは、Webトランザクションで使用される通信プロトコルを直接エミュレートすることにより、Webサーバー、API、およびバックエンドインフラストラクチャのパフォーマンスを評価することに重点を置いています。

デジタル時代の黎明期には、HTTPベースのテストが広く支持されていました。 ただし、最新の Web 2.0 アプリケーションで使用されているような高度な Web クライアント テクノロジの出現により、この方法は時代遅れになりました。 同様に、JMeterのような従来のパフォーマンステストツールも関連性を失っています。 クライアント側のスクリプトに大きく依存する最新のアプリケーションとは異なり、HTTPベースのテストではこれらのスクリプトが見落とされるため、パフォーマンスを正確に測定するには効果がありません。 さらに、クライアント側で生成されたセッションIDがないため、プロトコルレベルでの複雑なユースケースのシミュレーションが制限されます。

HTTPベースのテストは、負荷注入マシンのオーバーヘッドを最小限に抑え、最大800の同時セッションを処理できますが、複雑なプロトコルベースのシナリオでは苦労します。 パフォーマンスエンジニアは、CookieやセッションIDなどの動的パラメータに対処する必要があり、テストの実装を複雑にする可能性があります。 さらに、システムの更新時にWebフォーム名を変更すると、HTTPベースのスクリプトで失敗することがよくあります。

サンプル スクリプト

以下のサンプル スクリプトは、これらのスクリプトの非常に技術的な性質を強調しています。 アプリケーションの技術的な属性が変更された場合は、スクリプト全体を書き直す必要があります。

プロトコル・レベル・スクリプトのサンプル
トランザクション TMain
var
hContext: 数値;
始める
WebPageUrl(“https://lab3/st/”, “挨拶”);
WebPageStoreContext(hContext);
WebPageLink(“エクスペリエンスに参加!”, ” – 新しい訪問者”);
WebPageSubmit(“続行”, CONTINUE001, “メインメニュー”);
WebPageLink(“商品”, “ShopIt – 商品”);
WebPageLink(NULL, “ShopIt – 商品”, 3);
WebPageSubmit(“検索”, SEARCH001, ” – 検索”, 0, NULL, hContext);
終了 TMain;

dclform
CONTINUE001:
“名前” := “ジャック”、
“new-name-button” := “続行”;

検索001:
“検索” := “ブート”;

プロトコルレベルレベルのスクリプトは、継続的インテグレーション環境でのコンポーネントレベルのテストに適しており、負荷注入マシンではフットプリントが小さいため、ストレステストに最適な設定です。

利点

軽量で効率的: HTTP ベースのロード テストはネットワーク通信のみに重点を置いているため、ブラウザーベースのアプローチに比べてリソースの消費が少なくなります。

スケーラビリティ テスト: これらのテストでは、Web ページのレンダリングのオーバーヘッドなしに大量の HTTP 要求を処理するサーバーの能力を評価できます。

ヘッドレス ブラウザベースのロード シミュレーション

ヘッドレスブラウザベースの負荷シミュレーションは、フロントエンドレベルでユーザーインタラクションをエミュレートすることで、より包括的なアプローチを採用しています。 バックエンド インフラストラクチャに重点を置いた HTTP ベースのテストとは異なり、この手法では、JavaScript コードをレンダリングして実行することで、実際のユーザーが Web アプリケーションと対話する方法を再現します。

Web 2.0 で Web 技術が進化するにつれて、テストは大きな課題に直面しました。 従来のテストでは、クライアント側のロジックをシミュレートできなかったため、リッチなブラウザアプリケーションを処理するのに苦労していました。 そこで登場したのが、HtmlUnit、PhantomJS、SlimerJSなどのヘッドレスブラウザで、重いGUIを使わずにリアルなブラウザの利点を享受できるようになったのです。

これらのヘッドレスブラウザは、現在、テスト自動化とパフォーマンステストで広く使用されています。 独自に構築した企業もありますが、ブラウザの更新に追いつくために、コミュニティがサポートするオプションに頼る方が簡単です。 ヘッドレスブラウザの使用にはコストがかかり、一般的なサーバーでは最大8つの同時セッションを処理できます。

テストスクリプトの作成とカスタマイズは、特に基本的なコーディングスキルを持つ人にとっては、それほど難しいことではありません。 しかし、すべてのヘッドレスブラウザが視覚的なリプレイを提供するわけではないため、視覚的なフィードバックがないとデバッグが難しくなります。

サンプル スクリプト

以下のサンプル スクリプトでは、単純なポスト要求が実行されます。 このようなテストスクリプトをカスタマイズするには、Java プログラミングスキルが必要です。

PhantomJSスクリプトのサンプル
“strict を使用する”;
var page = require(‘webpage’).create(),
サーバー= ‘https://posttestserver.com/post.php?dump’、
データ=’ユニバース=エキスパンディング&answer=42’;

page.open(server, ‘post’, data, function (status) {
if (status !== ‘success’) {
console.log(‘投稿できません!’);
} それ以外の場合は {
コンソール.log(ページ.コンテンツ);
}

ファントム出口();
});

このことを念頭に置いて、プログラミングスキルを持っていて、ビジュアルスクリプトの再生を可能にするソリューションを使用している場合は、ヘッドレスブラウザが行く方法です。

利点

現実的なシミュレーション:ヘッドレスブラウザベースのテストは、ユーザーインタラクションをより正確に表現し、フロントエンドのパフォーマンスのボトルネックとユーザーエクスペリエンスの問題を特定できるようにします。

エンドツーエンドのテスト:これらのテストは、フロントエンドとバックエンドの両方のコンポーネントを網羅し、ユーザーの視点からシステムのパフォーマンスの全体像を提供します。

リアル ブラウザベースのロード シミュレーション

実際のブラウザベースの負荷シミュレーションは、実際のWebブラウザを使用してユーザー操作をシミュレートするため、パフォーマンステストにおけるリアリズムの頂点を表しています。 このアプローチは、ユーザーの行動とフロントエンドのパフォーマンスを再現する際に比類のない精度を提供します。

Web 2.0 アプリケーションは、JavaScript、Flash、AJAX、CSS などのさまざまなテクノロジーを利用します。 エンドツーエンドの応答時間を正確に測定するには、完全なブラウザが必要です。 実際のブラウザベースのパフォーマンステストにより、サイトの機能と速度がユーザーの期待に沿うことが確認されます。

このテストソリューションは、画像、JavaScript、CSSなどの読み込み時間をキャプチャし、多くの場合、ウォーターフォールチャートでデータを表示してコンポーネントの読み込み時間を視覚化します。 実際のブラウザベースのテストでは、わずかに多くのリソースが必要ですが、ヘッドレスブラウザと比較して、より現実的なシミュレーションを提供します。 したがって、これはテストに推奨される方法です。 テストスクリプトの実装と保守は、ユーザーのアクションが正確に反映され、視覚的な再生がデバッグに役立つため、簡単です。

サンプル スクリプト

下のサンプル スクリプトでは、ブラウザーが URL を開き、ユーザーのパスワードを挿入して、ログイン ボタンをクリックします。

実際のブラウザベースのスクリプトのサンプル
トランザクション TMain
始める
BrowserStart(BROWSER_MODE_DEFAULT, 800, 600);

ログイン サイトに移動する
BrowserNavigate(“https://demo.com/TestSite/LoginForm.html”);
セキュリティで保護されたサイトの認証を設定する
BrowserSetText(“//INPUT[@name=’user’]”, “user1”);
BrowserSetPassword(“//INPUT[@name=’pwd’]”, “パスワード1”);
//Login
BrowserClick(“//INPUT[@value=’ログイン’]”, BUTTON_Left);
終了 TMain;

結局のところ、実際のブラウザシミュレーションは、現実的なエンドツーエンドのロードテストに役立ちます。 ただし、負荷注入サーバーのフットプリントが高すぎるため、ストレス テストには使用しないでください。

利点

本物のユーザーシミュレーション:実際のブラウザベースのテストは、実際のユーザーの行動を厳密に模倣し、さまざまなブラウザやデバイス間でのフロントエンドのパフォーマンスとユーザーエクスペリエンスに関する洞察を提供します。

包括的なテスト: 実際のブラウザーを活用することで、組織はブラウザーの互換性、レンダリングの不整合、およびクライアント側のスクリプトの実行に関連する問題を発見できます。

負荷テストの種類の比較

明らかに、プロトコル、ヘッドレス、および実際のブラウザベースのユーザーシミュレーションには、正当な理由と状況があります。 以下のマトリックスは、適切なテストアプローチをいつ選択するかに関するガイダンスを提供します。

この記事が、負荷シミュレーションとパフォーマンス テストの種類をよりよく理解するのに役立つことを願っています。 負荷テストとストレス テストの実行について質問がある場合、または LoadView ソリューションに興味がある場合は、お気軽にチームに連絡するか、無料試用版にサインアップしてください。 LoadView の無料試用版にサインアップすると、すぐに開始できるように、いくつかの補完的なロード テストが提供されます。