LoadRunnerテストツール: Archi構造図と構成要素

⚡ スマートサマリー

LoadRunnerはエンタープライズパフォーマンステストツールで、現在は OpenTextこれは、VuGen、コントローラー、負荷発生器、分析ツール全体で数千もの仮想ユーザーをシミュレートし、実際のトラフィックが発生する前にボトルネックを明らかにするものです。

  • 🔘 起源: によって建てられた Mercury インタラクティブ社はHPに買収され、その後マイクロフォーカス社に買収され、そして現在は OpenText.
  • ☑️ 適用範囲: HTTPやAjaxから最も幅広いプロトコルライブラリの1つ SAP, Oracle そしてCitrix。
  • VuGen: クライアントとサーバーのトラフィックをVUserスクリプトに記録し、そのスクリプトがビジネスプロセスを再生します。
  • 🧪 コントローラ: シナリオを形成する ― VUser 数、立ち上げ、インジェクター、IP スプーフィング、および SLA チェック。
  • 🛠️ 負荷発電機: コントローラーが測定値を歪めないように、VUserを複数のマシンに分散させてください。
  • 📊 分析: 生の解析結果をグラフに変換し、負荷がかかった状態でシステムのボトルネックを特定します。

LoadRunnerテストツールコンポーネントと Archi構造

LoadRunner とは何ですか?

LoadRunnerは 性能試験 先駆者によって開発されたツール Mercury LoadRunnerは1999年にInteractive社に買収された。その後、2006年にHP社に買収され、HPのソフトウェア事業は2016年に発表され、2017年に完了した取引でMicro Focus社と合併した。

ブランドノート: OpenText 2023年1月にマイクロフォーカスの買収を完了した。このツールはもはやHPまたは Micro Focus LoadRunnerLoadRunner Professional は現在 OpenText プロフェッショナルなパフォーマンスエンジニアリング、LoadRunner Enterprise は OpenText エンタープライズパフォーマンスエンジニアリング、そしてLoadRunner Cloudは OpenText コアパフォーマンスエンジニアリング。以下のコンポーネント名(VuGen、コントローラー、負荷発生器、分析)は変更ありません。

LoadRunnerは、さまざまな開発ツール、テクノロジー、通信プロトコルをサポートしています。パフォーマンス テストを実施するためのプロトコル ライブラリは、市場で最も充実しているものの1つです。LoadRunner ソフトウェアで生成されたパフォーマンス テスト結果は、他のツールとの比較ベンチマークとして使用されます。

ロードランナーのビデオ

各コンポーネントの手順に進む前に、以下のビデオでLoadRunnerの簡単な概要をご覧ください。

なぜロードランナーなのか?

LoadRunnerは、パフォーマンス・テストにおける先駆的なツールであるだけでなく、パフォーマンス・テストのパラダイムにおける市場リーダーの一つであり続け、多くの企業がベンチマークとして用いる基準点となっています。

プロトコルの網羅性の高さが、チームがこの製品を選ぶ最も明確な理由であり、以下のコンポーネントマップがそれを示しています。

LoadRunnerは、エンタープライズアプリケーション向けのパフォーマンステストツールとして位置づけられています。

LoadRunnerツールは、RIA(リッチインターネットアプリケーション)、Web 2.0(HTTP/HTML、Ajax、Flex、Silverlightなど)、モバイルなど、幅広いアプリケーションをサポートしています。 SAP, Oracle、 ミズ SQL サーバー、シトリックス、RTE、 Mail そして何よりも、 Windows ソケット。以下のプロトコル一覧が示すように、単一のツールでこれほど多様なプロトコルに対応している競合ツールはほとんどありません。

LoadRunnerがサポートするアプリケーションプロトコルの範囲

ソフトウェアテストにおいてLoadRunnerを選ぶべき最も説得力のある理由は、このツールの信頼性の高さです。LoadRunnerは長年にわたり高い評価を得ており、クライアントがLoadRunnerを使ってパフォーマンスベンチマークを相互検証しているケースをよく見かけます。既にパフォーマンステストにLoadRunnerを使用している方であれば、安心してご利用いただけます。

LoadRunnerソフトウェアは、同じスイート内の兄弟ツールであるUnified Functional Testing(旧LoadRunner)と緊密に統合されています。 QTP現在は販売されています OpenText 機能テスト) と ALM (アプリケーションライフサイクル管理)、 OpenText ALM/Quality Center)は、エンドツーエンドのテストプロセスを実行できるようにするツールです。

LoadRunnerは、対象アプリケーション上で仮想ユーザーをシミュレートするという原理に基づいて動作します。これらの仮想ユーザー(VUserとも呼ばれる)は、クライアントのリクエストを複製し、トランザクションを成功させるために対応するレスポンスを待ちます。

パフォーマンス テストが必要な理由は何ですか?

以下の業界推定値は広く引用されており、2010年代初頭のものですが、それらが示す傾向は変わっていません。つまり、ページの表示速度が遅いとコストがかかるということです。

ウェブサイトのパフォーマンス不良により、年間推定4.4億ドルの収益損失が発生している。

Web 2.0 の現代では、ウェブサイトが 8 秒以内に応答しないとユーザーはすぐに離脱します。検索時に 5 秒待たされることを想像してみてください。 Google または Facebook で友達リクエストを送信する。パフォーマンスの低下による影響は、想像以上に深刻な場合が多い。バンク・オブ・アメリカのオンライン バンキングで発生したような有名な例がある。 Amazon ウェブサービス、Intuit、Blackberry。

Dun & Bradstreetによると、Fortune 500企業の59%が毎週平均1.6時間のシステム停止を経験している。従業員数1万人以上のFortune 500企業の平均時給が56ドルであることを考慮すると、そのような企業におけるシステム停止に伴う人件費は週89万6000ドルとなり、年間では4600万ドル以上になる計算だ。

わずか5分間のダウンタイムで Google2013年8月の.comドメイン取得には、検索大手企業にとって54万5000ドルもの費用がかかったと推定されている。

過去のパンデミック期間中、企業は1秒あたり1,100ドル相当の売上を失ったと推定されている。 Amazon ウェブサービスが停止しています。

組織がソフトウェア システムを導入すると、パフォーマンスの遅延につながる可能性のあるさまざまなシナリオに遭遇する可能性があります。パフォーマンスの低下を引き起こす要因は多数ありますが、その例としては次のようなものがあります。

  • データベースに存在するレコード数の増加
  • システムへの同時リクエスト数の増加
  • 過去と比較して、同時にシステムにアクセスするユーザー数が増加した。

しかし、すべての応募が候補となるわけではない。 負荷テスト クライアント/サーバー型のマルチユーザーシステムを対象としているため、下記のようなシングルユーザー向けのデスクトップユーティリティは、パフォーマンスをテストする価値がありません。

パフォーマンス テストの対象ではない、シングルユーザー向けデスクトップ ユーティリティ

ロードランナーとは Archi構造?

概して言えば、LoadRunnerのアーキテクチャは複雑ですが、理解しやすいものです。以下のLoadRunnerアーキテクチャ図は、4つのコンポーネントがどのように連携して動作するかを示しています。

LoadRunnerのアーキテクチャ図(VuGen、コントローラー、負荷発生器、分析機能を示す)

あなたがパフォーマンスをチェックするよう割り当てられたとします。 Amazon.comドメインを5000ユーザー向けに提供。

実際の状況では、これら5000人のユーザー全員がホームページに集まるわけではなく、ウェブサイトのさまざまなセクションに分散します。では、その違いをどのようにシミュレートすればよいのでしょうか?

VuGen

VuGenまたは仮想ユーザー Generator VuGenはIDE(統合開発環境)または高機能なコードエディタです。VuGenは、システム負荷時(SUL)の動作を再現するために使用されます。VuGenには、クライアントとサーバー間の通信をコード化されたスクリプト(別名:スクリプト)の形式で記録する「記録」機能があります。 VUser スクリプト.

上記の例を考慮すると、VuGenは次のようなビジネスプロセスをシミュレートするために記録することができます。

  • 製品ページをサーフィンする Amazon.com
  • 購入手続きへ進む
  • 支払処理
  • マイアカウントページを確認する

スクリプトが正常に再生されたら、動的なサーバー値は通常、 相関 規模を拡大する前に。

コントローラー

VUser スクリプトが完成したら、 コントローラー LoadRunnerの主要コンポーネントの1つであり、例えば以下のような管理によって負荷シミュレーションを制御します。

  • 各ビジネス プロセスまたは VUser グループに対してシミュレートする VUser の数
  • VUser の動作 (増加、減少、同時または並行の性質など)
  • 負荷シナリオの性質 (現実生活、目標指向、または SLA の検証など)
  • どのインジェクターを使用するか、各インジェクターに対する VUser の数
  • 結果を定期的に照合する
  • IPスプーフィング
  • エラー報告
  • 取引報告など

先の例を参考にすると、コントローラーはVuGenスクリプトに以下のパラメーターを追加します。

  1. 3500人のユーザーが製品ページを閲覧しています Amazon.com
  2. 750人のユーザーがチェックアウト中です
  3. 500人のユーザーが支払い処理を実行しています
  4. 500人のユーザーが支払い処理を完了した後、250人のユーザーがマイアカウントページを確認しています。

さらに複雑なシナリオも考えられます。

  • 5 個の VUser のロードまで 2 秒ごとに 3500 個の VUser を開始します (サーフィン Amazon 商品ページ)を実現します。
  • 30 分間繰り返します
  • 25 仮想ユーザーの反復を一時停止する
  • 20人の仮想ユーザーを再起動します
  • 毎秒 2 人のユーザー (チェックアウト、支払い処理、マイアカウント ページ) を開始します。
  • 2500 の VUser がマシン A に生成されます
  • 2500 の VUser がマシン B に生成されます

エージェントのマシン/負荷 Generatorインジェクター

LoadRunnerコントローラは、数千もの仮想ユーザー(VUser)をシミュレートする役割を担っています。これらのVUserはプロセッサやメモリなどのハードウェアリソースを消費するため、シミュレートを実行するマシンに制約が生じます。さらに、コントローラはこれらのVUserを同じマシン(コントローラが稼働しているマシン)からシミュレートするため、結果が正確でない場合があります。この問題を解決するために、すべてのVUserはロードと呼ばれる複数のマシンに分散されます。 Generators またはロード インジェクター。

一般に、コントローラーは別のマシン上に常駐し、負荷は他のマシンからシミュレートされます。 VUser スクリプトのプロトコルとマシンの仕様に応じて、完全なシミュレーションには多数のロード インジェクタが必要になる場合があります。 たとえば、HTTP スクリプトの VUser はシミュレーションに VUser ごとに 2 ~ 4MB を必要とするため、4 VUser の負荷をシミュレートするにはそれぞれ 4 GB RAM を搭載した 10,000 台のマシンが必要になります。

私たちの例えから Amazon 例えば、このコンポーネントの出力は、2つのインジェクターに分割された5000のVUserです。2500のVUserはマシンAで生成され、残りの2500はマシンBで生成されます。

分析

ロードシナリオが実行されたら、 分析 LoadRunnerのコンポーネントが登場します。

実行中、Controller は生の形式で結果のダンプを作成します。このダンプには、LoadRunner のどのバージョンがこの結果ダンプを作成したか、構成は何であったかなどの情報が含まれます。

すべてのエラーと例外は、 Microsoft output.mdbという名前のデータベースにアクセスします。分析コンポーネントはこのデータベースファイルを読み込み、様々な種類の分析を実行してグラフを生成します。

これらのグラフは、負荷がかかった状態でのエラーや障害の背後にある理由を理解するためのさまざまな傾向を示しています。したがって、SUL、サーバー (JBoss など) で最適化が必要かどうかを判断するのに役立ちます。 Oracle)またはインフラストラクチャ。

以下は、帯域幅がボトルネックとなる可能性のある例です。Webサーバーの容量が1Gbpsであるにもかかわらず、データトラフィックがこの容量を超え、後続のユーザーに悪影響を及ぼす場合を考えてみましょう。システムがこのようなニーズに対応できるかどうかを判断するには、パフォーマンスエンジニアは異常な負荷がかかった状態でアプリケーションの動作を分析する必要があります。以下は、LoadRunnerが帯域幅を測定するために生成するグラフです。

LoadRunnerの分析グラフで、帯域幅がパフォーマンスのボトルネックとなっていることが示されています。

パフォーマンス テストの方法

パフォーマンス テストのロードマップは、大きく 5 つのステップに分けられ、以下のロードマップにまとめられています。

  1. 負荷テストの計画
  2. VuGenスクリプトを作成する
  3. シナリオ作成
  4. シナリオの実行
  5. 結果分析 (その後にシステム調整が続​​く)

LoadRunnerをインストールした上で、プロセスに含まれる手順を一つずつ理解していきましょう。

計画から結果分析までの5段階のパフォーマンステストロードマップ

ステップ 1) 負荷テストの計画

パフォーマンス テストの計画は、パフォーマンス テストの計画とは異なります。 SIT (システム統合テスト) or UAT(ユーザー受け入れテスト)。 計画は、以下に示すように、さらに小さな段階に分割できます。

チームを編成する

LoadRunner Testingを開始する際には、以下のチーム構成図に示すように、プロセスに関わる各チームから誰がその活動に参加するのかを文書化しておくのが最善です。

LoadRunnerのパフォーマンステストチームのために編成された役割

  • プロジェクトマネージャー: このアクティビティを所有し、エスカレーションのポイント担当者として機能するプロジェクト マネージャーを指名します。
  • 機能エキスパート/ビジネスアナリスト: SULの利用状況分析と、ウェブサイトまたはSULのビジネス機能に関する専門知識を提供します。
  • パフォーマンス テストの専門家: 自動パフォーマンステストを作成し、負荷シナリオを実行します。
  • システム Archiテクト: SULの設計図を提供する。
  • Web 開発者および SME: ウェブサイトの維持管理、監視業務、ウェブサイトの開発、バグ修正を行います。
  • システム管理者: テストプロジェクト全体を通して、関連するサーバーを管理します。

関連するアプリケーションとビジネスプロセスの概要を説明します。

Successful: 負荷テスト 特定のビジネスプロセスの実行を計画している必要があります。 ビジネス プロセスは、負荷テストの目的を達成するために、目的のビジネス トランザクションに準拠して明確に定義されたステップで構成されます。

システム上のユーザー負荷を引き出すために、要件メトリックを準備できます。 以下は、企業における勤怠管理システムの例です。

要件メトリックマップping 1日の各時間帯における業務プロセスごとのユーザー数

上記の例では、数値は特定の時間にアプリケーションに接続しているユーザー数(SUL)を示しています。tract は、1 日のどの時間帯においても、ビジネス プロセスに接続できる最大ユーザー数であり、右端の列で計算されます。

同様に、XNUMX 日の任意の時間にアプリケーションに接続しているユーザーの総数 (SUL) を結論付けることができます。 これは最後の行で計算されます。

上記の 2 つの事実を組み合わせると、システムのパフォーマンスをテストする必要があるユーザーの総数がわかります。

テストデータ管理手順の定義

パフォーマンス テストから得られる統計と観察は、前に説明した多数の要因によって大きく影響されます。 パフォーマンス テスト用のテスト データを準備することは非常に重要です。 場合によっては、特定のビジネス プロセスがデータ セットを消費し、別のデータ セットを生成することがあります。 以下の例を見てみましょう。

  • ユーザー「A」が金融契約を作成するtract して、審査のために提出します。
  • 別のユーザー「B」が200件のコメントを承認しましたtracユーザー「A」によって作成された日です
  • 別のユーザー「C」は約150のコインを支払いますtracユーザー「B」によって承認された日です

この状況では、ユーザーBは200の契約を必要としますtractsはシステム内で「作成」されました。さらに、ユーザーCは150のconを必要とします。trac150人のユーザーの負荷をシミュレートするために、tsを「承認済み」として扱います。

これは暗黙のうちに、少なくとも 200+150 = 350 のコンテンツを作成する必要があることを意味します。tracTS。

その後、150件の承認を行います。tracユーザーCのテストデータとして使用されるts – 残りの200contractsはユーザーBのテストデータとして使用されます。

アウトラインモニター

システムのパフォーマンスに影響を与える可能性のあるあらゆる要因を推測してください。例えば、ハードウェアを削減すると、SUL(システム負荷時)のパフォーマンスに影響を与える可能性があります。

すべての要素を収集し、それらを評価できるようにモニターを設定します。 以下にいくつかの例を示します。

  • プロセッサ (Web サーバー、アプリケーション サーバー、データベース サーバー、およびインジェクター用)
  • RAM (Web サーバー、アプリケーション サーバー、データベース サーバー、およびインジェクター用)
  • Web/アプリケーションサーバー (IIS、JBoss、Jaguar サーバー、Tomcat など)
  • DB サーバー (PGA および SGA のサイズ) Oracle MSSQL サーバー、SP など)
  • ネットワーク帯域幅の使用率
  • クラスタリングの場合の内部および外部 NIC
  • ロードバランサ(クラスタのすべてのノードに負荷を均等に分散していること)
  • Rescale データ flux (クライアントとサーバー間でやり取りされるデータ量を計算し、次にNICの容量がX人のユーザーをシミュレートするのに十分かどうかを計算します。)

ステップ2)VuGenスクリプトを作成する

計画の次のステップは、VUser スクリプトを作成し、追加することです。 パラメータ化、トランザクション、および実行時設定 脚本が成熟するにつれて。

ステップ3) シナリオ作成

次のステップは、コントローラーでロードシナリオを作成することです。手動シナリオと目標指向シナリオのどちらかを選択してください。

ステップ4) シナリオの実行

シナリオ実行では、複数の VUser に同時にタスクを実行するように指示することで、サーバー上のユーザー負荷をエミュレートします。

同時にタスクを実行する仮想ユーザーの数を増減することで、負荷のレベルを設定できます。

この実行により、サーバーがダウンする可能性があります。 ストレス そして、異常な動作を示す。これこそがパフォーマンス テストの目的である。得られた結果は、詳細な分析と根本原因の特定に用いられる。

ステップ 5) 結果分析 (その後にシステム調整が続​​く)

シナリオ実行中、LoadRunnerはさまざまな負荷条件下でのアプリケーションのパフォーマンスを記録します。テスト実行から得られた統計情報は保存され、詳細な分析が実行されます。分析ツール(このチュートリアルが作成されたリリースでは「HP Analysis」という名称)は、システムパフォーマンスの低下やシステム障害の根本原因を特定するのに役立つさまざまなグラフを生成します。

取得されるグラフには次のようなものがあります。

  • 最初のバッファまでの時間
  • トランザクション応答時間
  • 平均トランザクション応答時間
  • XNUMX 秒あたりのヒット数
  • Windows 資料
  • エラー統計
  • トランザクション概要

よくあるご質問

パフォーマンス テストは、クライアント サーバー、マルチ ユーザー システムを対象としています。スタンドアロン デスクトップ ユーティリティとしては、 Microsoft 電卓は1人のユーザーのみを対象とし、サーバー層を持たないため、パフォーマンス テストの対象にはなり得ません。

パフォーマンス テストは、アプリケーションが負荷を受けた状態でどのように動作するかを測定し、報告します。パフォーマンス エンジニアリングは、このテストとチューニングを組み合わせることで、必要なユーザー エクスペリエンスが達成されるまで、システムを測定および最適化します。

いいえ。 OpenText 2023年1月にマイクロフォーカスの買収を完了し、現在はファミリーは OpenText プロフェッショナル、エンタープライズ、およびコアパフォーマンスエンジニアリング。

Professionalは1台のマシンで1つのチームに適しており、Enterpriseは組織全体で共有されるプロジェクトベースのテストを追加し、Coreはローカルインジェクターを使用せずにクラウドホスト型の負荷生成を実行します。

目標とするVUser数をプロトコルのメモリ使用量で割ります。上記のHTTPの例では、VUserあたり2~4MBなので、4GBのマシンが約4台あれば10,000人のVUserを処理できることになります。

IPスプーフィングによって各VUserに固有の送信元アドレスが割り当てられるため、ロードバランサー、キャッシュ、サーバーは、シミュレートされたトラフィックを1台のマシンが飽和状態になるのではなく、多数の独立したクライアントとして扱います。

機械学習は、正常な応答時間を基準値として設定し、異常な実行を自動的に検出し、関連するエラーをクラスタリングするため、エンジニアはグラフを読む時間を減らし、根本的なボトルネックの修正に時間を費やすことができます。

副操縦士 C言語スタイルのVuGenヘルパーコードとパラメータ化ロジックをドラフトしますが、記録された相関値を知ることができないため、生成されたすべてのスクリプトには依然として再生チェックが必要です。