LoadRunnerから.NETを使用する方法

LoadRunnerにはさまざまなテキスト処理に適したAPIがありますが、それでも十分ではない場合があり、汎用関数を使用して拡張する必要があります。 多くの場合、そのような実装は自転車の発明になります。ご存知のように、ほとんどすべてのタスクは既に誰かによって解決されています。 さらに、私はC＃のバックグラウンドが十分にあるため、問題を解決するときに、手元に.NET Frameworkクラスライブラリがあれば、このタスクは簡単に解決されると考えることがよくあります。 原則として、私がJavaプログラマであれば、Java（ほぼすべてを備えています）についても同様の考えがありますが、.NETは私に近いので、それについてのみ説明します。 副作用として、この記事はネイティブコードからCLRコードを呼び出す方法を学びたい人に役立ちます。 このオプションの小規模なパフォーマンス調査も提供されており、動作するVisual StudioプロジェクトテンプレートとLoadRunnerスクリプトが含まれています。

LoadRunnerの.NETおよびJava

まず、魅力的だが悪い選択肢を考えてください。 原則として、.NETとJavaの両方がLoadRunnerで直接動作します。 これらの各プラットフォームには、標準のLoadRunner APIのラッパーであるクラスがあります。 それぞれ.NETおよびJava Vuserモードを選択することにより、それらをすぐに使用できます 。 すぐに言ってみましょう。これらのスクリプト開発モードは、わずかに異なるモード用に作成されています。 .NETモードでは、.NETアプリケーションのアクティビティを記録し、アプリケーションのクラスメソッドを直接呼び出すスクリプトを作成できます。 Java VuserにはJava用の本格的で文書化されたAPIがありますが、記録モードはまったくありません（ .NETと同じ方法でJava Record Replayがあります ）。 このため、それらをWebに使用することは非常に問題が多く、一般的に、この場合の「使用」とは「何らかの形で機能するコードを書く」ことを意味し、それ以上は何もしません。 ツールからロードスクリプトを開発する場合、トラフィックを記録し、それをスクリプト（ドラフトも含む）に変換できることが重要です。これはさらに開発されます。 しかし、ここに問題があります：Webトラフィックの記録（ Webモード-HTTP / HTML ）は、Cコードへの変換でのみ可能です。 コミュニティはこれを長い間待っていましたが、少なくとも新しいバージョン12.00ではC＃またはJavaを選択できるようになることを正直に願っていましたが、これは起こりませんでした。 さらに、.NET用のAPIは実際には文書化されておらず、暗闇の中で熊手を踏んで行動する必要があります（ところで、.NETとJavaラッパーのメソッドシグネチャも異なります）。 .NETクラスで必要なラッパーメソッドを比較的迅速に見つけることができる場合、パラメーターを渡す方法がわかりません。



例：

namespace Script { public partial class VuserClass { public int Action() { web.url("ya.ru", "URL=http://ya.ru/", null, null); return 0; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードは機能し、C関数web_url（）と同等のリクエストを作成します。 この方法は、ランタイム設定で任意の.NETライブラリに接続してすぐに使用できるという点で魅力的ですが、すぐに疑問が生じます。

• web.url（）パラメータをweb_url（）と同じ方法で渡す方法は？
• プロキシを介してすべてを機能させる方法は？
• このモードでランタイム設定の大部分が消えるのはなぜですか？ （原則として、理由は理解できますが、これにより簡単になりません。）

一般に、このモードはそのために作成されていないため、このオプションの潜在的な利便性にもかかわらず、他の目的には使用せず、Cのままです。 それでも、スクリプトの一部をすばやく上書きする機能はより重要です。 同時に、いくつかの簡単な手順で、LoadRunner Cスクリプトから.NETコードを呼び出すことができます。



LoadRunnerは、ネイティブライブラリの呼び出しを定期的にサポートしています。これには、関数lr_load_dll（）があります。 .NETを呼び出すには、ネイティブレイヤーを記述する必要があります。実際、ネイティブコードからCLRコードを呼び出すことは、全体の問題です。 これを行う方法を知っている人は、次のセクションをスキップできます。残りの部分については、その方法を説明します。

.NETにアクセスできるネイティブDLL

フォームの行をデコードする必要があると：



Создать заявку







これは、XMLおよびHTML内で使用されるエンコードの一種です。各文字はUTF-8コードとして表されます。 LoadRunnerでこれを行うことに成功しませんでした（誰かが方法を知っているなら、私の鼻を突いてください）。 しかし、DottnetクラスHttpUtilityには、それを完全に行うHtmlDecode（）メソッドがあります。 それをzayuzatする方法を見てみましょう。

必要条件

当然、システムにインストールする必要があります。NETFramework。 具体的には、このメソッドは2.0以降のバージョン（またはそれ以前かもしれませんが、問題ではない）にありますが、ネイティブライブラリはアクセスしているバージョンを示し、異なるバージョンは互換性がないことに注意してください。 また、Win7 / 2008には.NET FW 3.5が既にインストールされているため、これらのOSでロードステーションを使用する場合、何もインストールする必要はありません。プラスプラスライブラリ内で.NET Framework 3.5を使用していることを示すだけです。

DLLを書く

しばらくの間、Visual StudioでC ++コードから.NETクラスにアクセスすることが非常に簡単になりました。 これを行うには、プロジェクト設定で共通言語ランタイムサポートモードを設定する必要があります。 次に、プロジェクトプロパティ、共通プロパティ、フレームワーク、参照に移動し、使用するアセンブリへのリンクを追加します。 この場合、Assemblies / FrameworkのSystem.Webに関心があります。 その後、C ++構文で.NETクラスに既にアクセスできます。

 #include "..\LR include 11.50\lrun.h" //... int xml_http_decode(const char* inputStr, const char* outputParam) { try { System::String^ temp = gcnew System::String(inputStr); System::String^ result = HttpUtility::HtmlDecode(temp); marshal_context^ context = gcnew marshal_context(); lr_save_string(context->marshal_as<const char*>(result), outputParam); } catch(char* message) { lr_save_string(message, outputParam); return LR_FAIL; } catch(...) { lr_save_string("!!! Unknown exception raised !!!", outputParam); return LR_FAIL; } return LR_PASS; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

LoadRunnerはネイティブdllのみを接続できるため、C互換のシグネチャと戻り値を持つ関数を宣言します。 次に、「^」記号を使用して.NET型を宣言し、C ++型と区別します。 C行からCLR文字列を作成して、.NETメソッドに渡す必要があります。 gcnewオペレーターは、CLRオブジェクトの作成に使用されます。



関数をdllの外部から呼び出すことができるように、エクスポートする必要があります。 このために次のように記述します

 extern "C" { __declspec( dllexport ) int xml_http_decode(const char* inputStr, const char* outputParam); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、ライブラリをLoadRunnerに接続し、静かに関数を呼び出します。

 lr_load_dll("hplr.dll"); // Native DLL  C++. xml_http_decode( "<span class=\"x11z\">&#1057;&#1086;&#1079;&#1076;&#1072;&#1090;&#1100; " "&#1079;&#1072;&#1103;&#1074;&#1082;&#1091;</span>", "p_decoded"); lr_output_message("%s", lr_eval_string("{p_decoded}")); //     .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

関数lr_load_dll（）が 、「ファイルが見つかりません」という紛らわしいエラーでLoadRunnerでクラッシュする場合、プラグインDLL自体ではなく、その依存関係である可能性があります。 デバッグモードでビルドされたライブラリを正常に接続するには、 msvcp110d.dllおよびmsvcr110d.dllファイルをそれぞれ32ビットおよび64ビットOSのSystem32またはSysWOW64に追加します 。 その他の依存関係は、Dependency Walkerなどを使用して調査できます。 ライブラリがリリースモードでコンパイルされる場合、追加の必要はありません（コンパイラ設定の追加の#includeおよび依存関係も削除します）。



C ++で記述された関数は、DLLですぐに使用できます（エクスポートすることを忘れないでください！）。 LoadRunnerで書くことができます

スクリプトフォルダから始まるDLLへの相対パス。 VuGenを再起動したり、スクリプトを再度開いたりする必要はありません。



これにより、既製の.NETクラスにアクセスできます。 しかし、私の意見では、.NETで作業するためにC ++でコードを書くのは多少不便で、これに適した言語が他にもあります。

注： C ++には、既製のライブラリもたくさんあります（そして、それらはより速く動作します）が、最初に、よく知られている経験と精度が必要です、そして第二に、これはこの記事の範囲外です。

C＃でカスタムライブラリを呼び出す

C＃でより複雑なロジックを記述し、別のアセンブリにパッケージ化したとします。 LRから彼女にアクセスする方法は？

原則として、すべては前の場合と同じで、リンクをアセンブリに追加するだけで（ソリューションまたは参照を使用）、クラスをアセンブリから呼び出す必要があります。

C＃DLL

何らかの理由で、LoadRunnerはサーバー応答でのみ正規表現を検索できますが、C行またはパラメーター値で正規表現を見つける方法は不明です（誰かが知っているなら、鼻を突く）。 この問題を解決するには、次の関数を記述できます。

 // C#-,    input   pattern   //   nGroup    nMatch. namespace HplrCs { public static class HplrHelper { public static string GetRegexMatch(string input, string pattern, int nMatch, int nGroup) { try { var re = new Regex(pattern); var matches = re.Matches(input); if (matches.Count < nMatch + 1) return String.Empty; var match = matches[nMatch]; if (match.Success) { if (match.Groups.Count < nGroup + 1) return String.Empty; return match.Groups[nGroup].Value; } else return String.Empty; } catch (Exception ex) { return ex.ToString(); } } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードを含むアセンブリをグローバルアセンブリキャッシュ（GAC）に配置する必要があります。 これを行うには、Windows SDKの一部であり、Visual Studioと共にインストールされるgacutil.exeユーティリティを使用します。 .NET Framework 4.0 / 4.5の場合、SDKの8番目のバージョンのgacutil.exeの対応するバージョンを使用する必要があります。以前のバージョンは4.0 / 4.5ビルドをインストールできません。



gacutil.exe -i HplrCs.dll







GACでのインストールは、管理者権限で実行する必要があります。 次のようにして、アセンブリがキャッシュに存在することを確認できます。



gacutil.exe -l HplrCs







GACのビルドバージョンを置き換えるには、以前のバージョンの上にインストールを再度実行する必要があります。 古いバージョンを削除する必要はありませんが、インストールが成功したことを確認することが重要です。

ネイティブラッパーの作成

繰り返しますが、最初のオプションと同様に、LoadRunnerと.NETアセンブリ間のリンクとなるネイティブライブラリを作成します。

 #include "..\LR include 11.50\lrun.h" //... extern "C" { __declspec( dllexport ) int get_regex_match( const char* inputStr, const char* pattern, const char* outputParam, int nMatch, int nGroup ); } int get_regex_match(const char* inputStr, const char* pattern, const char* outputParam, int nMatch, int nGroup) { try { System::String^ _inputStr = gcnew System::String(inputStr); System::String^ _pattern = gcnew System::String(pattern); System::String^ result = HplrHelper::GetRegexMatch(_inputStr, _pattern, nMatch, nGroup); marshal_context^ context = gcnew marshal_context(); lr_save_string(context->marshal_as<const char*>(result), outputParam); } catch(char* message) { lr_save_string(message, outputParam); return LR_FAIL; } catch(...) { lr_save_string("!!! Unknown exception raised !!!", outputParam); return LR_FAIL; } return LR_PASS; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

関数と定数LR

おそらく、上記のコードはLoadRunner関数と定数を使用していることに気づいたでしょう。 これは、私たちが行ったことのおかげで可能です。

 #include "..\LR include 11.50\lrun.h"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これを正しくアセンブルするには、リンカー入力にlrun50.libライブラリも追加する必要があります。 それらは、それぞれにあります

 C:\Program Files (x86)\HP\LoadRunner\include C:\Program Files (x86)\HP\LoadRunner\setup\dot_net\Vc9\VCWizards\LrCVuserDllLibrary\templates\1033
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

彼らの助けを借りて、スクリプトから呼び出した場合と同じ方法でLoadRunner API関数を呼び出すことができます。

例

MS Visual Studio 2012プロジェクトの形式の完全に既製のテンプレートがあります。 リンクから取得できます。



アーカイブコンテンツ：

• C ++は、.NET Frameworkと他の.NETアセンブリの両方で直接コードを呼び出すプロジェクトです。
• C Sharpは、.NETのライブラリ（アセンブリ）の例です。
• LR include *およびLR lib *はLoadRunnerパッケージのファイルで、LoadRunnerがインストールされていない場合にプロジェクトをビルドできるようにするためにコピーされます。
• 出力-収集されたバイナリ。
• LR Ext libの使用例-上記のアプローチを使用したLoadRunnerスクリプトの例。

Visual Studioでプロジェクトを初めて開くと、使用されている.NET Frameworkのバージョンを更新するように求められます。 何が起こっているのか理解できない場合は、これを行うべきではありません。 バージョンを更新すると、このバージョンとターゲットフレームワーク（プロジェクトプロパティ）を使用して.NETアセンブリをビルドする必要があります。 ところで、インターフェイスのどこでC ++プロジェクトの.NET Frameworkのバージョンを変更できるかはわかりませんでした。 C ++プロジェクトのプロパティに表示されますが、表示するためだけに変更することはできません。 ただし、これはテキストエディターで.vcxprojファイルを開き、XML要素TargetFrameworkVersionを見つけることで実行できます。 したがって、プロジェクトをまだ更新している場合は、TargetFrameworkVersionを必要なものに編集するか、.NET Frameworkの別のバージョンを使用するように切り替えます。

性能

提案されたアプローチのパフォーマンスは、組み込み関数を使用する意図が少なく、CのLRでコードを使用したいほど魅力的です。 何らかの目的で組み込みのLoadRunner関数がある場合は、その背後にネイティブコードがあるため、それを使用する必要があります。これは、より高速に機能することを意味します。



たとえば、約32KBの長さの文字列から部分文字列を見つけてみましょう（これより長くするのは困難です。これは、LoadRunnerがローカルパラメータのスタックに割り当てることができる最大値であるためです）。 私は特に部分文字列検索を古典的なタスクの1つとしています。なぜなら、おそらくそのアルゴリズムは可能な限り最適化されるべきだからです。

  #define BUFF_SIZE 32700 char buff[BUFF_SIZE]; int i; lr_load_dll("hplr.dll"); // Native DLL. memset(buff, '-', BUFF_SIZE); buff[BUFF_SIZE - 1] = 0; strcpy(buff + BUFF_SIZE - 4, "+++"); lr_start_transaction("Find substring, internal function"); for (i = 0; i < 100000; i++) strstr(buff, "+++"); lr_end_transaction("Find substring, internal function", LR_AUTO); lr_start_transaction("Find substrings, C# function"); for (i = 0; i < 100000; i++) find_substr_net(buff, "+++"); lr_end_transaction("Find substrings, C# function", LR_AUTO);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

.NETコードは引用しませんが、通常のString.IndexOf（）が続きます。 測定は、コントローラーのスタートアップモードでのみ実行する必要があり、VuGenでは、実行が2桁遅くなります。

 Find substring, internal function: 1,505 Find substring, C# function: 13,323
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さて、予想通り。 メインの実行時間は実際にはサブストリングの検索であり、ここではネイティブコードが大きな利点をもたらします。 const char *をSystem.Stringに変換すると、プロセスの速度も低下します。

しかし、答えがあります。 インタプリタを独立して動作させます。 これを行うには、整数演算で単純なアクションを実行する関数を作成します。

 int int_arithm_lr(int p) { int i; int s = p; for (i = 0; i < 10000; i++) { s += i * (i % 2 * 2 - 1); } return s; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

C＃コードはまったく同じですが、public staticという単語があります。

両方のランタイムで実行速度を比較します。

  lr_start_transaction("Integer arithmetics, LR function"); for (i = 0; i < 500; i++) int_arithm_lr(i); lr_end_transaction("Integer arithmetics, LR function", LR_AUTO); lr_start_transaction("Integer arithmetics, C# function"); for (i = 0; i < 500; i++) int_arithm_net(i); lr_end_transaction("Integer arithmetics, C# function", LR_AUTO);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 Integer arithmetics, LR function: 45,772 Integer arithmetics, C# function: 0,013
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

差は3.5千倍です。



このような計算の使用は負荷テストのシナリオでは一般的ではありませんが、LRインタープリターの弱点であるネイティブコードの低速化を明らかにします。 したがって、洗練されたものを書く必要がある場合、.NETでは、それを実装する方が便利であるだけでなく、LRのCコードよりもはるかに高速に動作します。



おそらく、あなたの注意に感謝します！