Web ページの読み込み速度が遅い、または応答しない場合、財務収益に直接影響します。 適切な負荷シミュレーションを使用してパフォーマンス テストを設定する ことが重要です。 正しく行われなければ、悲惨な影響を及ぼす可能性があります。 イライラしたユーザーは、自分がやっていたことは何でも放棄し、戻ってこない可能性が高いです。 チームがこの問題を解決した場合でも、遅すぎる可能性があります。 彼らはおそらくすでに別の解決策を見つけました。 そして、彼らが持っていると、彼らが戻ってくる可能性は低いです。
収益の損失を心配するだけでなく、消費者の信頼感、ブランドの完全性などの他の要因は、おそらくビジネスにとってより有害です。 問題が長く続けば続くほど、消費者の信頼を取り戻すのが難しくなります。 それだけでなく、製品、チーム、組織に対する投資に対するリターンは、実現に時間がかかります。 したがって、パフォーマンス テスト (および監視) は、ソフトウェアおよびアプリケーション開発チェーンの基本的かつ重要な部分となっています。 ユーザーのエクスペリエンスに対してパフォーマンス テストを適切かつ正確に実行できるソリューションの必要性は、高い需要があります。
パフォーマンス テスト プラットフォームは、HTTP/S、ヘッドレス、実際のブラウザ ベースのテストなど、広範なロード シミュレーション手法を提供します。 この記事では、それぞれの主な側面の概要を説明し、次に適切なシミュレーションアプローチを選択するために使用できる比較マトリックスを示します。
HTTP ベースのロード シミュレーション
私たちのデジタル時代の初期には、HTTPベースのテストは非常に人気がありました。 豊富なWebクライアント技術の台頭に伴い、このアプローチはますます時代遅れになっています (JMeterなどのツールを使用したパフォーマンステスト も少し時代遅れになっています)。 一般的な HTTP ベースのテスト ドライバーは、サービス要求を実行し、応答を解析します。 最新の web 2.0 アプリケーションは、多くのクライアント側スクリプトで構成され、この種のテスト実行では完全に無視され、測定されません。 クライアント側で生成されたセッション ID が不足しているため、複雑なユース ケースをプロトコル レベルでシミュレートすることはできません。
要求と応答ベースの性質により、負荷注入機のオーバーヘッドは非常に低いです。 一般的なロード テスト サーバーでは、最大 800 の同時セッションをシミュレートできます。 複雑なプロトコル ベースのユース ケースを実装するのは困難です。 パフォーマンス エンジニアは、Cookie、セッション ID、およびその他の動的パラメータを処理する必要があります。 テスト対象のシステムのテクノロジによっては、新しいバージョンがデプロイされると一部の ウェブ フォーム名が変更されることが多く、HTTP ベースの スクリプトが失敗します。
以下のサンプル スクリプトは、これらのスクリプトの非常に技術的な性質を示しています。 アプリケーションの技術的な属性が変更された場合は、スクリプト全体を書き直す必要があります。
//sample protocol level script
transaction TMain
var
hContext: number;
begin
WebPageUrl("https://lab3/st/", "Greetings");
WebPageStoreContext(hContext);
WebPageLink("Join the experience!", " - New Visitor");
WebPageSubmit("Continue", CONTINUE001, "Main menu");
WebPageLink("Products", "ShopIt - Products");
WebPageLink(NULL, "ShopIt - Product", 3);
WebPageSubmit("Search", SEARCH001, " - Search", 0, NULL, hContext);
end TMain;
dclform
CONTINUE001:
“名前” := “ジャック”,
“新しい名前ボタン” := “続行”;
検索001:
“検索” := “ブート”;
結局のところ、プロトコルレベルのスクリプトは、継続的 インテグレーション環境でのコンポーネントレベルのテストに適しており、ロードインジェクションマシンのフットプリントが小さいため、ストレステストに最適な設定です。
ヘッドレス ブラウザベースのロード シミュレーション
Web 2.0テクノロジーの台頭に伴い、テストビジネスは深刻な課題に直面しました。 スクリプトの再生中にクライアント側のロジックが欠落しているため、リッチ ブラウザ アプリケーションをプロトコル レベルでテストまたはシミュレートすることができなくなります。 したがって、いくつかのヘッドレスブラウザが導入されました, など, などのファントムJS, またはスリマーJS. 彼らはしばしばWebKit、クロムとサファリの背後にあるエンジンの上に構築されています。
ヘッドレスブラウザは、実際のブラウザのすべての利点を持っており、彼らは重いGUIなしで高速に実行されます。 多くのテスト自動化およびパフォーマンス テスト プラットフォームでは、ユーザーのリアルなシミュレーションが可能なため、ヘッドレス ブラウザを使用しています。
一部のプロバイダは、独自のヘッドレスブラウザエンジンを構築していますが、新しいブラウザのバージョンに追いつく必要があるため、メンテナンスの落とし穴に遭遇しています。 この状況では、 改善に取り組む幅広いコミュニティがあるため、自由に利用できるヘッドレスブラウザキットを使用することを強くお勧めします。
クライアント側レンダリングのシミュレーションは無料ではありません。 一般的な負荷注入サーバーでは、最大 8 つのヘッドレス ブラウザ セッションを同時にシミュレートできます。
テスト スクリプトの実装とカスタマイズは、それほど難しくはありません。 基本的な開発者スキルを持っている場合は、簡単なスクリプトを作成できます。 すべてのヘッドレス ブラウザがビジュアル リプレイ機能を提供するわけではないため、ビジュアルリプレイ、スクリプトのデバッグ、エラー分析が非常に難しくなるわけではありません。
以下のサンプル スクリプトでは、単純なポスト要求が実行されます。 このようなテスト・スクリプトをカスタマイズするには、Java プログラミングのスキルが必要です。
//sample phantomjs script
"use strict";
var page = require('webpage').create(),
server = 'https://posttestserver.com/post.php?dump',
data = 'universe=expanding&answer=42';
page.open(サーバー、’ポスト’、データ、機能(ステータス){
if (ステータス !== ‘成功’) {
コンソール.log(‘投稿できません!’)。
} それ以外の場合は {
コンソール.log(ページ.コンテンツ);
}
ファントム出口();
});
このことを念頭に置いて、プログラミングスキルを持っていて、ビジュアルスクリプトの再生を可能にするソリューションを使用している場合は、ヘッドレスブラウザが行く方法です。
リアル ブラウザベースのロード シミュレーション
Web 2.0 アプリケーションは、JavaScript、フラッシュ、AJAX、CSS などで満たされています。 完全なブラウザがないと、アプリケーションまたは Web ページ全体の実際のエンド ツー エンド応答時間を測定することはできません。 実際のブラウザベースのパフォーマンステストでは、エンドユーザーが認識する サイトの 機能と速度を検証できます。
一般的な実際のブラウザー パフォーマンス テスト ソリューションでは、イメージ、JavaScript、CSS などの読み込み時間を収集します。 多くの場合、これらのコンポーネントの読み込み時間を視覚化するウォーターフォール チャートを提供します。
実際のブラウザベースのブラウザのフットプリントはやや高くなります。 ヘッドレスブラウザシミュレーションでは、100%リアルな応答時間が得られるわけではないため、実際のブラウザベースのシミュレーションがテストの好ましい方法であると言えるでしょう。
テスト スクリプトの実装とメンテナンスは、ユーザーの操作が直接反映され、ビジュアル再生によってデバッグが容易になるため、簡単に行えます。 下のサンプル スクリプトでは、ブラウザーが URL を開き、ユーザーのパスワードを挿入して、ログイン ボタンをクリックします。
//sample real browser-based script
transaction TMain
begin
BrowserStart(BROWSER_MODE_DEFAULT, 800, 600);
ログイン サイトに移動する
ブラウザナビゲート(「https://demo.com/TestSite/LoginForm.html」);
セキュリティで保護されたサイトの認証を設定する
ブラウザセットテキスト(“//INPUT[@name=’ユーザー]”、”ユーザー1″);
ブラウザセットパスワード(//入力[@name=’pwd’]、”パスワード1”)。
ログイン
ブラウザクリック(“//INPUT[@value=’ログイン’]、BUTTON_Left)。
終了 TMain;
結局のところ、実際のブラウザシミュレーションは、現実的なエンドツーエンドのロードテストに役立ちます。 ただし、負荷注入サーバーのフットプリントが高すぎるため、ストレス テストには使用しないでください。
さまざまなタイプのロード テストとパフォーマンス テスト
コンポーネント速度テスト
近年、ソフトウェア開発手法はアジャイルの方向に移行しています。 短いリリースのスプリントは不可欠です。 開発者とテスト エンジニアは、品質保証とパフォーマンス チェックを自動化します。 通常、プロトコル レベルでサービス ベースのパフォーマンス テスト ( および場合によっては API テスト) を実装するか、または実際のブラウザー ベースのパフォーマンス チェックをシミュレートして、エンドツーエンドの応答時間と合意されたパフォーマンス境界を比較します。
コンポーネント速度テストの目的:
- 入出力動作を確認し、繰り返します。
- インターフェイスとエンドツーエンドのパフォーマンス チェックを自動化します。
- 応答時間と合意されたしきい値の比較。
ロード テスト
ロードは、非機能要件の検証に関して理想的な設定をテストします。 その理由の1つは、応答時間を再現可能な条件下で検証できることです。 もう 1 つは、これらのテストで応答時間しきい値の検証が可能であることです。 現実的な応答時間の測定は、ロード テストのシナリオで不可欠です。 したがって、テスト エンジニアは、ロード テストの設定にヘッドレスまたは実際のブラウザ ベースのユーザー シミュレーションを使用します。
ロード テストの目的:
- 再現可能な負荷シミュレーション。
- 応答時間しきい値の検証。
- 実稼働環境に似る負荷条件下でのボトルネックの特定
- 現実的なエンド ツー エンドのテスト シナリオを作成します。
ストレステスト
ピーク負荷条件下でアプリケーションの信頼性を証明する必要がある場合は、ストレス テストを実行してシステムのブレークポイントを特定します。
ストレステストの目的:
- ピーク時のトラフィック条件でのスケーラビリティと安定性を証明します。
- システムが故障してオンラインに戻る様子を観察します。
- 再現性は重要ではありません。
比較
明らかに、 プロトコル、ヘッドレス、および実際のブラウザベースのユーザーシミュレーションには、正当な理由と状況があります。 以下のマトリックスは、適切なテストアプローチをいつ選択するかに関するガイダンスを提供します。
| 条件 | HTTP | ヘッドレスブラウザ | リアルブラウザ |
| ユーザーシミュレーション | (1) クライアント側のレンダリングなし | (2) クライアント側の要素の一部がシミュレートされる | (3) 実際のユーザーシミュレーション |
| スクリプトの実装とカスタマイズ | (1) Webサイトが複雑な場合は困難 | (2) 堅牢なスクリプトを構築するために必要な開発者スキル | (3) 簡単なスクリプト、カスタマイズが簡単 |
| スクリプトの再生 | (1) 低レベルの分析が必要 | (2) 使用エンジンに応じてビジュアル再生が可能 | (3)あなたが得るものを見る |
| スクリプトの保守性 | (1) プログラミングスキルが必要 | (2) レンダリングされていないセクションのエラーは解決が難しい | (3) 再生中にエラーが発生するため簡単 |
| マルチブラウザのサポート | (1) ツールによっては Web ブラウザをエミュレートするものがありますが、これは比較できません | (2) はい、しかし、いくつかの要素が欠けていることが多い | (2) 他のバージョンや異なるブラウザをサポートするものもあります |
| 負荷注入機械の足跡 | (3) 低、サーバーあたり最大 800 セッション | (2) 中(サーバあたり最大8セッション) | (1) 高、サーバーあたり最大 6 セッション |
| DevOps に推奨 | (2) 実際のテストシナリオに依存 | (1) いいえ、複雑なスクリプトが多い場合 | (3)はい、使いやすく、リアルなフィギュア |
| ロード テストに推奨 | (1) いいえ、クライアント側の処理はスキップされます | (2) はい、HTTPシミュレーションより優れています | (3) はい、現実的なユーザーシミュレーション |
| ストレステストに推奨 | (3) はい、負荷発生機のオーバーヘッドが少ないため | (2) いいえ、負荷発生機のオーバーヘッドが高すぎる | (1) 負荷発生機でのオーバーヘッドが最も高い |
| コスト | (3) 低 | (2) 中程度 | (1) 高 |
| 合計スコア | 17 | 19 | 24 |
ロード シミュレーションとパフォーマンス テストの種類に関するこの記事では、パフォーマンス テストについてさらに詳しく説明しています。 ロード テストとストレス テストの実行、または 一般的な LoadView ソリューションについて質問がある場合は、 チームに連絡する か、パフォーマンス エンジニアの 1 人と デモにサインアップ してください。