独自のサーバー機器と顧客または開発者のインフラストラクチャを使用して、ローカルモードで負荷テストを自分で編成することも、クラウドソリューションを使用してプロジェクトをテストすることもできます。 クラウドからの負荷テストのコストは、従来の方法を大幅に上回ります。
負荷テストプロセスの編成で最も面倒な瞬間の1つは、必要な数のサイト使用アルゴリズム、いくつかのタイプのユーザーなどを含む負荷テストプロファイルの開発です。 つまり、人生のように、サイトの使用のばらつきをシミュレートすることです。 これは、サイトがどのように使用されるかを分析するタスクであり、それ自体は複雑ですが、質問はより創造的であり、現在はそれについて話していません。 それを処理して、Webサイトの使用シナリオのリストを作成したとします。 大規模または小規模のリスト。ただし、これらのシナリオはすべてテストスクリプトに変換する必要があり、作成するだけでなく、最新の状態に保つ必要があります。 結局のところ、テストは複数回実行され、プロジェクトを真剣に開始するため、プロジェクトのプログラムコードを変更、改善、改善するたびにテストに移ります。 これにはすべて、テストスクリプトへの並行変更が必要です。
テストの専門家がこのようなスクリプトを作成するとき、httpトラフィックキャプチャテクノロジがより頻繁に使用されます。 スクリプトが正しく機能するために、スペシャリストは、スクリプト/サーバー相互作用セッションから取得されたサーバーパラメーターにそれをバインドすることを強制されます。 このセッションは通常、仮想ユーザーと呼ばれます。 各新しい仮想ユーザーがサーバーに入るときに正しいセッションパラメーターを使用するには、サーバーからさまざまなパラメーターを受け取り、このセッション全体でそれらを再利用できるようにスクリプトを開発する必要があります。
ただし、アプリケーションに多数のサーバーパラメーターがある場合、テスターはコードレベルでスクリプトへの変更を維持するか、スクリプトを完全に書き換えてからパラメーター化を調整する必要があるため、このタスクは非常に時間がかかります。
Hewlett Packard Enterpriseは、TruClientテクノロジーを使用してブラウザーレベルでユーザーをエミュレートできるSaaS StormRunner Loadソリューションを提供します。 この場合、スクリプトはhttp-trafficのストリームではなく、ブラウザーのボタンとメニューをクリックするシーケンスです。 この場合、サーバーパラメータの監視は不要になり、ブラウザはそれらを監視します。
テストを開始すると、明らかに、仮想ユーザーごとにブラウザーが起動します。つまり、深刻なリソースが消費されますが、幸いなことに、StormRunner Loadを使用すると、負荷テストを実行するために必要なハードウェア容量を顧客が考えることができず、製品はテストリソースを管理するタスクを引き受けます自分で。 したがって、ストレステストのリソースを見つける際の頭痛がなくなります。 同時に、機器の購入に割り当てられた資金は、もちろん、会社がそれを買う余裕があれば、節約されます。
Webプログラミングから非常に離れたユーザーでも、TruClientスクリプトを独自に作成できます。これは、記録ボタンをオンにし、このスクリプトが実行する指定された一連のステップをブラウザーで個別に再現するだけで済むためです。 もちろん、TruClientテクノロジーは、さまざまなテストデータを使用するためのスクリプトのパラメーター化の操作をサポートしています。 このようなスクリプトは、アプリケーションインターフェイス自体でパラメーター化および変更するのがはるかに簡単であり、前述のようにゼロから書き直す必要がなくなりました。
HPEによる内部テスト中のHPE StormRunner Loadソリューションは、テスト対象のサーバーへの150万の同時接続でテストされました。 これは、大規模なプロジェクトであっても、負荷テストのほとんどのタスクに十分です。 しかし、数百または数千の同時接続でWebリソースをテストする必要がある場合でも、この製品は手頃な価格で使用すると便利です。
HPE StormRunner Loadはどのような実用的なタスクを支援できますか？ これは、リソースへの関心が急増しているマーケティングキャンペーンを開始する前に、サイトの信頼性をチェックしている可能性があります。 このキャンペーンが成功し、大規模な再発行が発生した場合、リソースの所有者は「habraeffect」に直面する可能性があります。 この場合、ユーザーは単にサイトを「タンブルダウン」します。 また、サイトを所有している企業が特定の日にピークダウンロードを経験する可能性もあります。 預金に非常に興味深く有利な条件を提供する銀行、別の非常に収益性の高いキャンペーンを発表する店舗、センセーショナルな情報を公開するニュースリソースなどです。 これらすべてのケースのストレステストソリューションは、Webリソースの予測負荷をシミュレートし、事前に再現して、この場合のリソースの動作を確認するのに役立ちます。
必要に応じて、予測されたセッション数でサイトの安定性を確認できるだけでなく、Webリソースが耐えられる最大負荷レベルを計算することもできます。 ユーザートランザクションの通過の分析（インターフェイスでのユーザーアクションのシーケンス）は、テストがどのように合格したかを結論付けるために使用されます。 実際、ユーザートランザクションの完了にかかる時間は、負荷テストを通過したサイトの成功または失敗のメトリックです。 特定のユーザートランザクションの完了速度を事前に決定します。StormRunnerLoadタスクは、これらのユーザートランザクションに関する統計を収集します。 最後に、このソリューションにより、テスト仮想ユーザーが「ログイン」するネットワークのタイプと品質をエミュレートできます。 これは、ネットワークチャネルの速度と遅延が異なるモバイルを含むさまざまな種類のデバイスの所有者にプロジェクトを適合させたい場合に当てはまります。
HPE StormRunner Loadを使用したテストは、たとえばインターネットバンキングなどの非常に複雑なWebアプリケーションになる場合があります。 彼らの仕事は、他の多くの銀行システムとアプリケーション（ABS、クレジットコンベヤー、カード、CRMなど）に影響を与える統合に関連しています。 この場合、顧客は各ユーザートランザクションに割り当てる時間を個別に決定し、SLAとして設定できます。 これにより、ユーザートランザクションの処理の遅延がどの段階で発生したかを判断し、ハードウェアとソフトウェアのパフォーマンスの収集されたメトリックを使用して、遅延の根本原因を分析できます。
HPE StormRunner Loadソリューションは、Hewlett Packard Enterpriseデータセンターにあり、アーキテクチャ的に2つの部分で構成されています。 1つ目はHPE側にあり、ユーザーと対話し、ユーザーのすべての情報、テスト環境、およびスクリプトを保存します。 インフラストラクチャの2番目の部分は、負荷テスト用のマシンがあるデータセンターに展開されます。 これらはAmazon、Microsoft Azureクラウド環境であり、お客様は自分に合った環境を選択できます。 お客様は、データセンターまたはサーバールームにある独自のロードスタンドを使用することもできます。
現在、HPEの現在のお客様は、自社のデータセンターのテリトリーに展開されているHPE LoadRunnerやHPE Performance Centerなどの従来の製品を使用しており、ストレステストの問題を解決するために複雑な負荷テストの問題を解決しています。 新しいHPE StormRunner Loadソリューションは、高負荷下での外部テストの問題を解決し、スタンドの機器を見つける問題を取り除きます。