LoadRunner のパラメータ化、関数、トランザクション

記録されたスクリプトは仮想ユーザーをシミュレートできます。 ただし、単なる記録だけでは「実際のユーザーの行動」を再現するには不十分な場合があります。

スクリプトが記録されると、対象アプリケーションの単一の直接的なフローがカバーされます。 一方、実際のユーザーは、ログアウトする前に任意のプロセスを複数回繰り返すことができます。 ボタンをクリックするまでの遅延 (思考時間) は人によって異なります。 実際のユーザーの中には、DSL 経由でアプリケーションにアクセスする人もいれば、ダイヤルアップ経由でアクセスする人もいる可能性があります。 したがって、エンド ユーザーの実際の感覚を得るには、実際のユーザーの動作と完全に一致するか、少なくとも非常に近い動作になるようにスクリプトを強化する必要があります。

以上が「」を行う際の最も重要な考慮事項です。性能試験」と説明しましたが、VU スクリプトにはそれだけではありません。 SUL がパフォーマンス テストを受けているときに、VUser にかかった正確な時間をどのように測定しますか? VUser が特定の時点で通過したか失敗したかをどのようにして知ることができるでしょうか? 一部のバックエンド プロセスが失敗したか、サーバー リソースが制限されていたかなど、失敗の背後にある原因は何ですか?

上記のすべての質問に答えるために、スクリプトを強化する必要があります。

トランザクションの使用

トランザクションは、あらゆる操作に対するサーバーの応答時間を測定するメカニズムです。簡単に言えば、「トランザクション」を使用すると、特定のリクエストに対してシステムが要した時間を測定できます。ボタンのクリックや、テキスト ボックスからフォーカスが外れたときの AJAX 呼び出しなど、小さなことでもかまいません。

トランザクションの適用は簡単です。 サーバーにリクエストが行われる前に XNUMX 行のコードを記述し、リクエストが終了したらトランザクションを閉じるだけです。 LoadRunner では、トランザクション名として文字列のみが必要です。

トランザクションを開くには、次のコード行を使用します。

lr_start_transaction(“Transaction Name”);

トランザクションを終了するには、次のコード行を使用します。

lr_end_transaction(“Transaction Name”, <status>);

のこの特定のトランザクションが成功したか失敗したかを LoadRunner に伝えます。 考えられるパラメータは次のとおりです。

• LR_AUTO
• LR_PASS
• LR_FAIL

例：

lr_end_transaction(“My_Login”, LR_AUTO);
lr_end_transaction(“001_オープニング_ダッシュボード名”, LR_PASS);
lr_end_transaction(“ビジネスワークフロー_トランザクション名”, LR_FAIL);

注意点：

• 忘れないでください。「C」は大文字と小文字を区別する言語です。
• トランザクション名にはピリオド (.) 文字は使用できませんが、スペースとアンダースコアは使用できます。
• コードを適切に分岐し、サーバーからの応答を確認するためのチェックポイントを追加した場合は、LR_PASS や LR_FAIL などのカスタム エラー処理を使用できます。それ以外の場合は、LR_AUTO を使用すると、LoadRunner がサーバー エラー (HTTP 500、400 など) を自動的に処理します。
• トランザクションを適用するときは、 think_time 明細書が挟まれている場合、またはそれ以外の場合は、取引には常にその期間が含まれます。
• LoadRunner はトランザクション名として定数文字列を必要とするため、トランザクションを適用する際の一般的な問題は文字列の不一致です。 トランザクションを開始するときと閉じるときに異なる名前を指定すると、少なくとも 2 つのエラーが発生します。 開いたトランザクションは閉じられていないため、LoadRunner はエラーを返します。 さらに、閉じようとしているトランザクションは開かれていないため、エラーが発生します。
• 知恵を絞って、上記のエラーのうちどれが最初に報告されるかを自分で答えてください。 自分の答えを検証するには、自分自身の間違いを犯してみてはいかがでしょうか? 正しく答えていれば、順調に進んでいます。 答えが間違っていた場合は、集中する必要があります。
• LoadRunner はリクエストとレスポンスの同期を自動的に処理するため、トランザクションを適用するときにレスポンスについて心配する必要はありません。

思考時間、ランデブーポイント、コメントについて

ランデブーポイント

ランデブーポイントとは「待ち合わせ場所」という意味です。 これは、LoadRunner に同時実行性を導入するよう指示するたった XNUMX 行のステートメントです。 ランデブー ポイントを VUser スクリプトに挿入して、サーバー上の重いユーザー負荷をエミュレートします。

ランデブー ポイントは、複数の VUser がタスクを同時に実行できるように、テスト実行中に複数の VUser が特定のポイントに到着するまで待機するように VUser に指示します。 たとえば、銀行サーバーのピーク負荷をエミュレートするには、100 人の仮想ユーザーに同時に現金を口座に入金するように指示するランデブー ポイントを挿入できます。 これは、ランデブーを使用すると簡単に実現できます。

ランデブー ポイントが正しく配置されていない場合、仮想ユーザーは、同じスクリプトであっても、アプリケーションの異なる部分にアクセスすることになります。 これは、仮想ユーザーごとに応答時間が異なるため、遅れるユーザーがほとんどいないためです。

構文: lr_rendesvous(“論理名”);

ベストプラクティス：

• コードを読みやすくするために、ランデブー ポイントの先頭に「rdv_」を付けます。 例：「rdv_Login」
• 即時の思考時間に関する記述を削除する
• スクリプトビューでのランデブーポイントの適用（記録後）

コメント

アクティビティ、コードの一部、またはコード行を説明するコメントを追加します。コメントは、将来コードを参照する人が理解しやすいようにするのに役立ちます。コメントは特定の操作に関する情報を提供し、区別のために 2 つのセクションを分離します。

コメントを追加できます

• 録音中（ツール使用）
• 録音後（コードを直接記述する）

ベスト プラクティス: 各スクリプト ファイルの先頭にコメントをマークします。

メニューから関数を挿入する

簡単なコード行を直接記述することもできますが、関数を思い出すにはヒントが必要になる場合があります。また、Steps Toolbox (バージョン 12 より前は Insert Function と呼ばれていました) を使用して、任意の関数を検索し、スクリプトに直接挿入することもできます。

ステップ ツールバーは、[表示] > [ステップ ツールボックス] の下にあります。

これによりサイド ウィンドウが開き、スナップショットを確認します。

パラメータ化とは何ですか?

A パラメーター VUGen のコンテナは、さまざまなユーザーに置き換えられる記録された値を含むコンテナです。

スクリプト (VUGen またはコントローラー) の実行中、外部ソース (.txt、XML、データベースなど) の値によって、パラメーターの前の値が置き換えられます。

パラメータ化は、たとえば、動的 (または一意の) 値をサーバーに送信する場合に役立ちます。 ビジネス プロセスは 10 回の反復を実行する必要がありますが、毎回一意のユーザー名を選択します。

また、対象システムに現実のような動作を刺激するのにも役立ちます。 以下の例を見てください。

問題の例:

ビジネス プロセスはサーバーから取得された現在の日付に対してのみ機能するため、ハードコードされたリクエストとして渡すことはできません。

場合によっては、クライアント アプリケーションがプロセスを続行するために一意の ID (session_id など) をサーバーに渡すことがあります (たとえ単一ユーザーであっても)。そのような場合、パラメーター化が役に立ちます。

多くの場合、クライアント アプリケーションは、サーバーとの間で送受信されるデータのキャッシュを維持します。 その結果、サーバーは実際のユーザーの行動を受信しません (サーバーが検索基準に応じて異なるアルゴリズムを実行する場合)。 VUser スクリプトは正常に実行されますが、取得されるパフォーマンス統計は意味がありません。 パラメータ化を通じてさまざまなデータを使用すると、サーバー側のアクティビティ (手順など) をエミュレートし、システムを実行するのに役立ちます。

記録中に VUser にハードコーディングされた日付は、その日付が経過すると無効になる場合があります。 日付をパラメータ化すると、ハードコードされた日付を置き換えることで VUser を正常に実行できるようになります。 このようなフィールドまたはリクエストは、パラメーター化の適切な候補です。

クリック こちら ビデオにアクセスできない場合

実行時設定とその VU シミュレーションへの影響

実行時設定は、VUGen スクリプトと同じくらい重要です。 さまざまな構成を使用して、さまざまなテスト設計を取得できます。 このため、実行時設定に一貫性がない場合、再現性のない結果が得られる可能性があります。 それぞれの属性について XNUMX つずつ説明していきます。

実行ロジック

実行ロジックは、vuser_init と vuser_end を除くすべてのアクションが実行される回数を定義します。

おそらくこれにより、LoadRunner がすべてのログイン コードを vuser_init 内に保持し、ログアウト部分を vuser_end 内に両方とも排他的に保持することを提案する理由が明確になります。

複数のアクション (サインイン、画面を開く、レンタルの計算、資金の送信、残高の確認、ログアウトなど) を作成した場合、仮想ユーザーごとに以下のシナリオが実行されます。

すべての VUser はログインし、「画面を開く」、「レンタルの計算」、「資金の送信」、「残高の確認」を実行し、その後、「画面を開く」、「レンタルの計算」などを 10 回繰り返し、その後 (XNUMX 回) ログアウトします。

これは、実際のユーザーのように動作できるようにする強力な設定です。 実際のユーザーは毎回ログインとログアウトを行うわけではなく、通常は同じ手順を繰り返すことに注意してください。

ログアウトする前にメールを確認するときに、「受信トレイ」を何回クリックしますか?

ペーシング

これは重要。 ほとんどの人は、ペーシングと思考時間の違いを理解できません。 唯一の違いは、 「ペーシングは反復間の遅延を指します」が、思考時間は任意の 2 つのステップ間の遅延を指します。

推奨される設定はテスト設計によって異なります。 ただし、積極的な負荷を検討している場合は、「前の反復が終了したらすぐ」を選択することを検討してください。

歳入録

ログは (一般に理解されているように) LoadRunner の実行中のすべてのイベントを記録したものです。 ログを有効にして、アプリケーションとサーバーの間で何が起こっているかを知ることができます。

LoadRunner は、それ自体で堅牢かつスケーラブルな強力なロギング メカニズムを提供します。 「標準ログ」または詳細な構成可能な拡張ログのみを保持したり、完全に無効にしたりすることができます。

標準ログは有益で理解しやすいものです。 これには、VUser スクリプトのトラブルシューティングに通常必要となる適切な量の知識が含まれています。

拡張ログの場合、すべての標準ログ情報がサブセットになります。 さらに、パラメータを置換することもできます。 これにより、LoadRunner コンポーネントに、要求および応答データを含むすべてのパラメータ (パラメータ化からの) の完全な情報を含めるように指示されます。

「サーバーから返されたデータ」を含めると、ログが長くなります。 これには、ログ内に含まれるすべての HTML、タグ、リソース、非リソース情報が含まれます。 このオプションは、深刻なトラブルシューティングが必要な場合にのみ適しています。 通常、これによりログ ファイルのサイズが非常に大きくなり、理解しにくくなります。

ここまででご想像のとおり、「Advance Trace」を選択した場合、ログ ファイルは膨大になります。ぜひお試しください。VUGen にかかる時間も大幅に増加していることに気付くでしょうが、これは VUGen によって報告されるトランザクション応答時間には影響しません。ただし、これは非常に高度な情報であり、対象のアプリケーション、アプリケーションとハードウェア間のクライアントとサーバーの通信、およびプロトコル レベルの詳細を理解している場合は役立つ可能性があります。通常、この情報は理解してトラブルシューティングするために多大な労力を必要とするため、本質的に役に立ちません。

ヒント：

• ログが有効になっているときに VUGen にどれだけ時間がかかっても、トランザクションの応答時間には影響しません。 HP はこの現象を「最先端のテクノロジー」と呼んでいます。
• ログが必要ない場合は無効にします。
• スクリプトの作成が完了したら、ログを無効にします。 ログを有効にしてスクリプトを含めると、コントローラーの実行が遅くなり、しつこいメッセージが報告されます。
• ログを無効にすると、LoadRunner からシミュレートできる最大ユーザー数の容量が増加します。
• 「エラーが発生した場合のみメッセージを送信」の使用を検討してください。これにより、不要な情報メッセージがミュートされ、エラー関連メッセージのみが報告されます。

考える時間

思考時間は、単純に XNUMX つのステップ間の遅延です。

実際のユーザーはマシン (VUGen) のようにアプリケーションを使用できないため、Think Time はユーザーの行動を再現するのに役立ちます。 VUGen は思考時間を自動的に生成します。 思考時間を削除、増加、または変動させることも完全に制御できます。

さらに詳しく理解するために、たとえば、ユーザーは画面 (つまり、応答とそれに続く要求) を開き、Enter キーを押す前にユーザー名とパスワードを入力することができます。 アプリケーションとサーバーの次のやり取りは、「サインイン」をクリックしたときに行われます。 ユーザーがユーザー名とパスワードを入力するのにかかった時間は、LoadRunner の思考時間です。

アプリケーションに対する積極的な負荷をシミュレートしたい場合は、思考時間を完全に無効にすることを検討してください。

ただし、実際のような動作をシミュレートするには、「ユーザーランダム思考時間」を使用して、必要に応じてパーセンテージを設定できます。

思考時間を正当な期間に制限することを検討してください。 通常、30 秒あれば十分です。

速度シミュレーション

速度シミュレーションは、単に各クライアント マシンの帯域幅容量を指します。

私たちは LoadRunner を通じて数千の VUser をシミュレートしているため、LoadRunner が帯域幅/ネットワーク速度のシミュレーションを制御するのがどれほど簡単であるかは驚くべきことです。

128 Kbps を介してアプリケーションにアクセスする顧客の場合、ここからアプリケーションを制御できます。 「実際のような動作」をシミュレートできるようになり、適切なパフォーマンス統計を取得するのに役立ちます。

最も推奨されるのは、最大帯域幅を使用するように設定することです。 これにより、ネットワーク関連のパフォーマンスのボトルネックを無視し、アプリケーション内の潜在的な問題に最初に焦点を当てることができます。 いつでもテストを複数回実行して、さまざまな状況下でのさまざまな動作を確認できます。

ブラウザエミュレーション

ユーザー エクスペリエンスは、エンド ユーザーが使用しているブラウザーには依存しません。 明らかに、これはパフォーマンス測定の範囲を超えています。 ただし、エミュレートするブラウザを選択できます。

この構成で適切なブラウザを選択することが本当に重要になるのはいつなのか、自分自身に答えられますか?

対象アプリケーションが Web アプリケーションであり、ブラウザーごとに異なる応答を返す場合は、この構成を使用します。 たとえば、IE と IE では異なる画像とコンテンツが表示されます。 Firefox 等々

もう 1 つの重要な設定は、ブラウザ キャッシュをシミュレートすることです。キャッシュが有効になっている場合の応答時間を測定する場合は、このボックスをオンにします。最悪の状況を探している場合は、これは当然考慮する必要はありません。

非 HTML リソースをダウンロードすると、LoadRunner は CSS、JS、およびその他のリッチ メディアをダウンロードできるようになります。 これはチェックしたままにしておく必要があります。 ただし、パフォーマンス テスト設計からこれを削除する必要がある場合は、このチェックを外すことができます。

プロキシ

プロキシを完全に削除するのが最善です。 テスト環境 – これにより、テスト結果の信頼性が低くなります。 ただし、それが避けられない状況に直面する可能性があります。 このような状況では、LoadRunner を使用するとプロキシ設定が容易になります。

プロキシ設定なしで作業することになります (または作業する必要があります)。 デフォルトのブラウザから取得できます。 ただし、どのブラウザがデフォルトに設定されているか、およびデフォルトのブラウザのプロキシ構成が何であるかを確認することを忘れないでください。

プロキシを使用していて、認証 (またはスクリプト) が必要な場合は、「認証」ボタンをクリックすると、新しいウィンドウが表示されます。 以下のスクリーンショットを参照してください。

この画面を使用して、プロキシ サーバーで認証を受けるためのユーザー名とパスワードを入力します。 「OK」をクリックして画面を閉じます。

おめでとう。 VUGen スクリプトの構成が完了しました。 すべての VUser スクリプトに対して忘れずに設定してください。