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

LoadRunner とは何ですか?

LoadRunner は、 Mercury LoadRunner は 1999 年に HPE に買収されました。2006 年に LoadRunner は MicroFocus に買収されました。

LoadRunner は、さまざまな開発ツール、テクノロジー、通信プロトコルをサポートしています。 実際、これは、これほど多くのプロトコルをサポートする市場で唯一のツールです。 性能試験。 LoadRunner ソフトウェアによって生成されたパフォーマンス テストの結果は、他のツールに対するベンチマークとして使用されます

ロードランナーのビデオ

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

LoadRunner は、パフォーマンス テストのパイオニア ツールであるだけでなく、今でもパフォーマンス テスト パラダイムの市場リーダーです。 最近の評価では、LoadRunner はパフォーマンス テスト業界で約 85% の市場シェアを獲得しています。

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

ソフトウェア テストで LoadRunner を選択するのにさらに説得力があるのは、このツールの信頼性です。 LoadRunner ツールは、よく見かけるように長い間評判を確立してきました。 クライアントは、LoadRunner を使用してパフォーマンス ベンチマークを相互検証します。 パフォーマンス テストのニーズにすでに LoadRunner を使用している場合は安心です。

LoadRunner ソフトウェアは、統合機能テスト (QTP) や ALM (アプリケーション ライフサイクル管理) などの他の HP ツールと緊密に統合されており、エンドツーエンドのテスト プロセスを実行できるようになります。

LoadRunner は、対象アプリケーション上で仮想ユーザーをシミュレートするという原則に基づいて動作します。 これらの仮想ユーザーは VUser とも呼ばれ、クライアントのリクエストを複製し、トランザクションの通過に対する対応する応答を期待します。

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

推定 収益4.4億ドルの損失 Web パフォーマンスの低下により、毎年記録されます。

今日のWeb 2.0の時代では、ウェブサイトが8秒以内に応答しない場合、ユーザーはクリックして離れます。Googleで検索したり、Facebookで友達リクエストを送信したりするときに5秒間待つことを想像してみてください。パフォーマンスのダウンタイムの影響は、想像以上に壊滅的です。最近、Bank of America Online Bankingで発生した例があります。 Amazon Web サービス、Intuit または Blackberry。

Dunn & Bradstreet によると、Fortune 59 企業の 500% が毎週推定 1.6 時間のダウンタイムを経験しています。従業員数が 500 人以上の Fortune 10,000 企業の平均時給が 56 ドルであることを考えると、このような組織のダウンタイム コストの人件費は毎週 896,000 ドルとなり、年間 46 万ドル以上になります。

Google.com のわずか 5 分間のダウンタイム (19 年 13 月 545,000 日) で、この検索大手には XNUMX 万 XNUMX ドルもの損害が発生すると推定されています。

最近の影響により、企業は 1100 秒あたり XNUMX ドル相当の売上を失ったと推定されています。 Amazon Web サービスの停止。

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

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

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

大まかに言えば、HP LoadRunner のアーキテクチャは複雑ですが、理解しやすいものです。

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

実際の状況では、これら 5000 人のユーザー全員がホームページには存在せず、Web サイトの別のセクションに存在することになります。 どうすれば別の方法でシミュレーションできるでしょうか。

VUGen

VUGen または仮想ユーザー Generator IDE (統合開発環境) またはリッチ コーディング エディターです。 VUGen は、System Under Load (SUL) の動作を複製するために使用されます。 VUGen は、クライアントとサーバー間の通信をコード化されたスクリプト (VUser スクリプトとも呼ばれる) の形式で記録する「記録」機能を提供します。

したがって、上記の例を考慮すると、VUGen は次のビジネス プロセスを記録してシミュレートできます。

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

コントローラー

VUser スクリプトが完成すると、Controller は主要な LoadRunner コンポーネントの XNUMX つとなり、以下を管理することで負荷シミュレーションを制御します。

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

サンプルコントローラから類推すると、VUGenスクリプトに次のパラメータが追加されます。

1) 3500 ユーザーは 製品ページをサーフィンする Amazon.com

2) 750 人のユーザーがいます 購入手続きへ進む

3) 500 ユーザーは 支払い処理の実行

4) 250 ユーザーは 500 ユーザーが支払い処理を行った後にのみ MyAccount ページを確認する

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

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

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

HP LoadRunner コントローラは、数千の VUser をシミュレートする責任があります。これらの VUser は、プロセッサやメモリなどのハードウェア リソースを消費するため、それらをシミュレートするマシンに制限を設けます。 さらに、コントローラーは同じマシン (コントローラーが存在する) からこれらの仮想ユーザーをシミュレートするため、結果が正確ではない可能性があります。 この問題に対処するために、すべての VUser は、と呼ばれるさまざまなマシンに分散されます。 負荷 Generators またはロード インジェクター。

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

私たちの考えから類推すると、 Amazon たとえば、このコンポーネントの出力は次のようになります。

分析

ロードシナリオが実行されると、「分析” LoadRunner のコンポーネントが入ってきます。

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

すべてのエラーと例外は、 Microsoft アクセス データベース (名前は、output.mdb)。 「分析」コンポーネントは、このデータベースファイルを読み込んで各種分析を行い、グラフを生成します。

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

以下は、帯域幅がボトルネックになっている可能性がある例です。 Web サーバーの容量が 1GBps であるのに、データ トラフィックがこの容量を超えて後続のユーザーに影響を与えているとします。 システムがそのようなニーズを満たすかを判断するには、パフォーマンス エンジニアは異常な負荷によるアプリケーションの動作を分析する必要があります。 以下は、帯域幅を引き出すために LoadRunner が生成するグラフです。

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

パフォーマンス テストのロードマップは、大きく 5 つのステップに分けることができます。

• 負荷テストの計画
• VUGen スクリプトの作成
• シナリオ作成
• シナリオの実行
• 結果分析 (その後にシステム調整が続​​く)

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

パフォーマンス テスト プロセスに含まれる手順

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

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

チームを編成する

LoadRunner テストを開始するときは、プロセス中に関与する各チームの誰がアクティビティに参加するかを文書化することが最善です。

プロジェクトマネージャー：

このアクティビティを所有し、エスカレーションのポイント担当者として機能するプロジェクト マネージャーを指名します。

機能エキスパート/ビジネスアナリスト:

SUL の使用状況分析を提供し、Web サイト/SUL のビジネス機能に関する専門知識を提供します

パフォーマンス テストの専門家:

自動パフォーマンス テストを作成し、負荷シナリオを実行します。

システム Archiテクト:

SUL の青写真を提供します

Web 開発者および SME:

• ウェブサイトを保守し、監視機能を提供します
• ウェブサイトの開発とバグ修正

システム管理者：

• テストプロジェクト全体を通じて関係するサーバーを保守します

関連するアプリケーションとビジネス プロセスの概要:

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

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

上の例では、数値は特定の時間にアプリケーション (SUL) に接続しているユーザーの数を示しています。 右端の列で計算された、XNUMX 日の任意の時間にビジネス プロセスに接続している最大ユーザー数を抽出できます。

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

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

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

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

• ユーザー「A」は金融契約を作成し、レビューのために送信します。
• 別のユーザー「B」は、ユーザー「A」が作成した 200 日あたり XNUMX 件の契約を承認します。
• 別のユーザー「C」は、ユーザー「B」によって承認された 150 日あたり約 XNUMX 件の契約を支払います。

この状況では、ユーザー B はシステム内に 200 件の契約を「作成」する必要があります。 さらに、ユーザー C が 150 ユーザーの負荷をシミュレートするには、150 件の契約が「承認済み」である必要があります。

これは暗黙的に、少なくとも 200+150= 350 の契約を作成する必要があることを意味します。

その後、ユーザー C のテスト データとして機能する 150 件の契約を承認します。残りの 200 件の契約はユーザー B のテスト データとして機能します。

アウトラインモニター

システムのパフォーマンスに影響を与える可能性のあるあらゆる要因を推測します。 たとえば、ハードウェアを削減すると、SUL (System Under Load) のパフォーマンスに潜在的な影響が生じます。

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

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

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

計画の次のステップは作成です。 VUser スクリプト。

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

次のステップは、負荷シナリオを作成することです。

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

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

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

この実行により、サーバーにストレスがかかり、異常な動作が発生する可能性があります。 これがまさにパフォーマンス テストの目的です。 抽出された結果は、詳細な分析と根本原因の特定に使用されます。

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

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

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

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

FAQ