ロード テスト:
HTTP 対 ヘッドレス対リアル ブラウザー
問題が解決されると不満を抱いたユーザーが戻らない可能性が高いため、Web ページの読み込みが遅かったり、応答性が低くなったりすると、財務収益に影響が出ます。 したがって、パフォーマンス テストは開発チェーンの基本的な部分となり、需要は依然として高まっています。
パフォーマンス テスト プラットフォームは、HTTP、ヘッドレス、および実際のブラウザー ベースなどの広範な負荷シミュレーション方法を提供します。 本稿では、その後に比較マトリックスが続く主な側面を概説し、適切なシミュレーション手法を選択するために使用します。
デジタル時代の初期には、HTTPベースのテストは非常に人気がありました。 豊富な Web クライアントテクノロジの台頭に伴い、HTTP ベースのシミュレーション手法はますます時代遅れになっています。 一般的な HTTP ベースのテスト ドライバーは、サービス要求を実行し、応答を解析します。 最新の web 2.0 アプリケーションは、多くのクライアント側スクリプトで構成され、完全に無視され、この種のテスト実行では測定されません。 最悪の場合、クライアント側で生成された ID が不足しているため、複雑なユース ケースをプロトコル レベルでシミュレートすることはできません。
要求と応答ベースの性質により、負荷注入機のオーバーヘッドは非常に低いです。 一般的なロード テスト サーバーでは、最大 800 の同時セッションをシミュレートできます。 複雑なプロトコル ベースのユース ケースは実装が困難な場合があります。 パフォーマンス エンジニアは、Cookie、セッション ID、およびその他の動的パラメータを処理する必要があります。 テスト対象のシステムの種類によっては、新しいバージョンがデプロイされると、一部の Web フォーム名が変更されることがあり、HTTP ベースのスクリプトが失敗します。
サンプルプロトコルレベルスクリプト
トランザクション TMain
var
hコンテキスト: 数値;
始める
ウェブページル(“http://lab3/st/”、”挨拶”);
をクリックします。
ウェブページリンク(「エクスペリエンスに参加してください」、 – 新しい訪問者”)。
ウェブページ送信(「続行」、継続001、”メインメニュー”);
ウェブページリンク(「製品」「ショップイット – 製品」);
ウェブページリンク(NULL、”ショップイット – 製品”、3);
ウェブページ送信(“検索”、検索001、”- 検索”、0、NULL、hコンテキスト)。
終了 TMain;
dclform
CONTINUE001:
“名前” := “ジャック”,
“新しい名前ボタン” := “続行”;
検索001:
“検索” := “ブート”;
結局のところ、プロトコルレベルのスクリプトは、継続的な統合環境でのコンポーネントレベルのテストに適しており、負荷インジェクションマシンのフットプリントが低いため、ストレステストに最適です。
Web 2.0テクノロジーの台頭に伴い、テストビジネスは深刻な課題に直面しました。 スクリプトの再生中にクライアント側のロジックが欠落しているため、リッチ ブラウザ アプリケーションをプロトコル レベルでテストまたはシミュレートすることができなくなりました。 したがって、いくつかのヘッドレスブラウザは、このようなHtmlUnit、ファントムJSやスリマーJSとして導入されています。 彼らはしばしばWebKit、クロムとサファリの背後にあるエンジンの上に構築されています。
ヘッドレスブラウザは、GUIのない実際のブラウザに似ています。 多くのテスト自動化およびパフォーマンス テスト プラットフォームでは、ヘッドレス ブラウザを使用してトラフィックをシミュレートしています。
ヘッドレスブラウザには独自の落とし穴があります。新しいブラウザが市場に参入すると、ヘッドレスブラウザキットは、実際のブラウザのすべてのパフォーマンスと機能強化に追いつく必要があります。
のクライアント側レンダリングのシミュレーションは無料ではありません。 一般的な負荷インジェクション サーバーでは、最大 10 ~ 12 の同時ヘッドレス ブラウザ セッションをシミュレートできます。
テスト スクリプトの実装とカスタマイズは、それほど難しくはありません。 基本的なコーディングスキルがあれば、簡単なスクリプトを作成できます。 すべてのヘッドレスブラウザがビジュアルリプレイ機能を提供しているわけではないため、ビジュアルリプレイスクリプトのデバッグやエラー分析が非常に難しくなる可能性があります。
サンプルファントムスクリプト
「厳密に使用する」;
var ページ = 必要 (‘web ページ’)作成()
サーバー = ‘http://posttestserver.com/post.php?dump’
データ = ‘宇宙=展開と回答=42’。
page.open(サーバー、’ポスト’、データ、機能(ステータス){
if (ステータス !== ‘成功’) {
コンソール.log(‘投稿できません!’)。
} それ以外の場合は {
コンソール.log(ページ.コンテンツ);
}
ファントム出口();
});
ここで見られるサンプル スクリプトでは、単純なポストリクエストが実行されます。 このようなテストスクリプトをカスタマイズするには、Java プログラミングスキルが必要です。
Web2.0 アプリケーションは、JavaScript、フラッシュ、アヤックス、および CSS でいっぱいです。 完全なブラウザがないと、ウェブページ全体の実際のエンドツーエンドの応答時間を測定することはできません。 実際のブラウザベースのパフォーマンス テストを使用すると、エンド ユーザーが認識するサイトの機能と速度を検証できます。
典型的な実際のブラウザパフォーマンステストソリューションは、画像、JavaScript、CSSなどのロード時間を収集します。 多くの場合、これらのコンポーネントの読み込み時間を視覚化するウォーターフォール チャートを提供します。
実際のブラウザベースのブラウザのフットプリントはわずかに高くなります。 ヘッドレスブラウザシミュレーションが100%リアルな応答時間を提供しないことを考えると、実際のブラウザベースのシミュレーションが好ましいと言うのは公正です。 実際のシナリオでは、ヘッドレスブラウザは実際のブラウザよりもわずか20%優れています。 したがって、平均的なサイズのシングルロードインジェクタが10-12ヘッドレスブラウザセッションを実行できる場合、同じロードインジェクタは8-10の実際のブラウザセッションを実行することができます。
テスト スクリプトの実装とメンテナンスは、ユーザーの操作が直接反映され、視覚的な再生によってデバッグが容易になるため、簡単に行うことができます。 ブラウザの下にあるサンプルスクリプトでURLを開き、ユーザーとパスワードを挿入してログインボタンをクリックします。
実際のブラウザベースのスクリプトのサンプル
トランザクション TMain
始める
ブラウザスタート(BROWSER_MODE_DEFAULT、800、600)。
ログイン サイトに移動する
ブラウザナビゲート(“http://demo.com/TestSite/LoginForm.html”);
セキュリティで保護されたサイトの認証を設定する
ブラウザセットテキスト(“//INPUT[@name=’ユーザー]”、”ユーザー1”);
ブラウザセットパスワード(//入力[@name=’pwd’]、”パスワード1″)。
ログイン
ブラウザクリック(“//INPUT[@value=’ログイン’]、BUTTON_Left)。
終了 TMain;
結局のところ、実際のブラウザシミュレーションは現実的なエンドツーエンド負荷テストに役立ちますが、負荷注入サーバーのフットプリントが高すぎるため、ユーザーの大量のストレステストにコストがかかる場合があります。
パフォーマンス テストの種類
コンポーネント速度テスト
近年、ソフトウェア開発方法はアジャイル方向に移行しています。 短いリリースのスプリントは不可欠です。 開発者とテスト エンジニアは、品質保証とパフォーマンス チェックを自動化します。 通常、プロトコル レベルでサービス ベースのパフォーマンス テストを実装するか、実際のブラウザー ベースのパフォーマンス チェックをシミュレートして、エンドツーエンドの応答時間と合意されたパフォーマンス境界を比較します。
目標
+繰り返し性
+ 自動インターフェースとエンドツーエンドのパフォーマンスチェック
+ 合意されたしきい値と応答時間を比較
ロード テスト
いくつかの理由から、ロード テストは、機能していない要件の検証に関して理想的なテスト方法です。 1つは、応答時間が再現可能な条件下で検証できることです。 もう 1 つは、これらのテストで応答時間しきい値の検証が可能であることです。 現実的な応答時間の測定は、ロード テストのシナリオで不可欠です。 したがって、テスト エンジニアはロード テストの設定にヘッドレスまたは実際のブラウザ ベースのユーザー シミュレーションを使用します。
目標
+再生可能な負荷シミュレーション
+ 応答時間しきい値の検証
+ 負荷条件のような生産下のボトルネックを特定
+ 現実的なエンドツーエンドのテストシナリオ
ストレステスト
負荷のピーク時にアプリケーションの信頼性をテストする必要がある場合は、ストレス テストを実行します。 このタイプのテストでは、主に最大ユーザー数と、アプリケーション上でランプアップと定常状態負荷が必要な時間を指定します。 目標は、テスト対象のアプリケーションのブレークポイントを特定することです。
目標
+ 確かなスケーラビリティと安定性
+ピーク負荷条件をシミュレート
+正確な再現性は重要ではありません
比較
明らかに、プロトコル、ヘッドレス、または実際のブラウザベースのユーザーシミュレーションには正当な理由があります。 以下のマトリックスは、適切なアプローチを選択するためのガイダンスを提供します。
条件
HTTP
ヘッドレスブラウザ
リアルブラウザ
ユーザーシミュレーション
クライアント側レンダリングなし
一部のクライアント側要素はシミュレートされます。
実際のユーザーシミュレーション
スクリプト
の実装とカスタマイズ
Web サイトが複雑な場合は困難
堅牢なスクリプトを構築するために必要な開発者スキル
シンプルなスクリプト、カスタマイズが簡単
S
クリプトリプレイ
低レベルの分析が必要
使用するエンジンに応じて、ビジュアル再生が可能
あなたが得るものを見る
スクリプトの保守性
必要なプログラミングスキル
レンダリングされていないセクションのエラーは解決が難しい
再生中にエラーが発生するため簡単
マルチブラウザのサポート
一部のツールは Web ブラウザーをエミュレートしますが、これは比較できません
はい、しかし、いくつかの要素が欠けていることが多いです
他のバージョンと異なるブラウザをサポートするものもあります
負荷注入機械のF ootprint
低
、サーバーあたり最大 800 セッション
中
(
サーバーあたり最大 10 ~ 12
セッション)
高
い 、サーバーあたり最大 6 セッション
DevOps
に推奨
実際のテスト シナリオに依存
いいえ、多くの場合、複雑なスクリプト
はい、使いやすく、リアルなフィギュア
ロード テストに推奨
いいえ
、クライアント側の処理はスキップされます
はい、HTTPシミュレーションよりも優れています
はい、現実的なユーザーシミュレーション
ストレステストに推奨
はい、負荷発生器のマシンに低いオーバーヘッドがあるため
いいえ、負荷発生器のオーバーヘッドが高すぎます
いいえ、
負荷発生機のオーバーヘッドが最も高い
コスト
低い
高い
高い
大容量、低コストのテストウェブサーバーストレステスト(可能な場合)
推奨されません
現実の複雑なアプリケーションシミュレーションに推奨されます。
ストレステスト
負荷のピーク時にアプリケーションの信頼性をテストする必要がある場合は、ストレス テストを実行します。 このタイプのテストでは、主に最大ユーザー数と、アプリケーション上でランプアップと定常状態負荷が必要な時間を指定します。 目標は、テスト対象のアプリケーションのブレークポイントを特定することです。
目標
+ 確かなスケーラビリティと安定性
+ピーク負荷条件をシミュレート
+正確な再現性は重要ではありません
比較
明らかに、プロトコル、ヘッドレス、または実際のブラウザベースのユーザーシミュレーションには正当な理由があります。 以下のマトリックスは、適切なアプローチを選択するためのガイダンスを提供します。
| 条件 | HTTP | ヘッドレスブラウザ | リアルブラウザ |
| ユーザーシミュレーション | クライアント側レンダリングなし | 一部のクライアント側要素はシミュレートされます。 | 実際のユーザーシミュレーション |
| スクリプトの実装とカスタマイズ | Web サイトが複雑な場合は困難 | 堅牢なスクリプトを構築するために必要な開発者スキル | シンプルなスクリプト、カスタマイズが簡単 |
| スクリプトの再生 | 低レベルの分析が必要 | 使用エンジンに応じて視覚的な再生が可能です | あなたが得るものを見る |
| スクリプトの保守性 | 必要なプログラミングスキル | レンダリングされていないセクションのエラーは解決が難しい | 再生中にエラーが発生するため簡単 |
| マルチブラウザのサポート | 一部のツールは Web ブラウザーをエミュレートしますが、これは比較できません | はい、しかし、いくつかの要素が欠けていることが多いです | 他のバージョンと異なるブラウザをサポートするものもあります |
| 負荷注入機械の足跡 | サーバーあたり 800 セッションまで低 | サーバーあたり最大 10 ~ 12 セッションの中 | 高、サーバーあたり最大 6 セッション |
| DevOps に推奨 | 実際のテスト シナリオに依存 | いいえ、多くの場合、複雑なスクリプト | はい、使いやすく、リアルなフィギュア |
| ロード テストに推奨 | いいえ、クライアント側の処理はスキップされます | はい、HTTPシミュレーションよりも優れています | はい、現実的なユーザーシミュレーション |
| ストレステストに推奨 | はい、負荷発生器のマシンに低いオーバーヘッドがあるため | いいえ、負荷発生器のオーバーヘッドが高すぎます | いいえ、負荷発生機のオーバーヘッドが最も高い |
| コスト | 低い | 高い | 高い |
| 大容量、低コストのテストウェブサーバーストレステスト(可能な場合) | 推奨されません | 現実の複雑なアプリケーションシミュレーションに推奨されます。
|
- https://developers.google.com/web/tools/chrome-devtools/device-mode/testing-other-browsers
- https://watirmelon.blog/2015/12/08/real-vs-headless-browsers-for-automated-acceptance-tests/
- http://news.softpedia.com/news/what-is-a-headless-browser-and-what-s-it-good-for-485162.shtml
- https://github.com/dhamaniasad/HeadlessBrowsers
- https://circleci.com/
