data parameterization jmeter using configuration elements
このチュートリアルでは、手動構成の代わりに構成要素を使用してファイルからデータを選択するJMeterのデータパラメーター化について説明します。
Jmeter構成要素 後でサンプラーによって使用される変数です。サンプラーによって行われた要求は、構成要素を使用して追加または変更できます。
JMeterは、Webの実際の動作を再現できるように構成要素を提供します。
=>ここをクリックしてください JMeterでの完全な無料トレーニング（20以上のビデオ）
学習内容：
データのパラメータ化に関するビデオチュートリアル
JMeter構成要素
さまざまなタイプのJMeter構成要素を以下に示します。
- CSVデータセット構成
- FTPリクエストのデフォルト
- DNSキャッシュマネージャー
- HTTP認証マネージャー
- HTTPキャッシュマネージャー
- HTTPクッキーマネージャー
- HTTPリクエストのデフォルト
- HTTPヘッダーマネージャー
- Javaリクエストのデフォルト
- JDBC接続構成
- キーストア構成
- ログイン構成要素
- LDAP要求のデフォルト
- LDAP拡張要求のデフォルト
- TCPサンプラー構成
- ユーザー定義変数
- 確率変数
- カウンター
- 単純な構成要素
- MongoDBソース構成（非推奨）
- ボルト接続構成
一般的に使用されるJMeter構成要素をいくつか見ていきましょう。
＃1）CSVデータセット構成
CSV ファイルから行を読み取り、それらを変数に変換するために使用されます。 CSV Data Set Configは、テストしているシナリオに従って大量のデータを提供できるデータソースの目的を果たします。
ユーザーが異なる資格情報を持つ50人のユーザーのWebアプリケーションをテストしたい場合、50個のスクリプトを作成する必要はありません。ここで行う必要があるのは、（ユーザー名、パスワード）のようなユーザーレコードを持つファイルを作成し、このファイルをCSVにアップロードすることです。 CSVは、すべてのデータ行を変数に変換します。
以下の例を見て、CSVファイルからデータを読み取り、結果の表示ツリーに印刷する方法を理解しましょう。
＃1） テスト計画を作成する
＃二） ユーザー数が1、ランプアップ期間が1秒、ループ数が5のスレッドグループを追加します。
＃3） 構成要素をCSVデータセット構成として追加します。
- 以下のデータを含むCSVファイルをアップロードします。
- 変数名をユーザー名とパスワードとしてコンマ区切りの区切り文字で指定します。
- EOFに到達するとファイルが再読み込みされるように、(EOFでリサイクル)をtrueとして選択します。
＃4）サンプラーを追加する： サンプラーをデバッグします。
＃5）リスナーの追加： 結果ツリーを表示します。
＃6） トップメニューの(スタート)ボタンを選択して、テスト計画を実行します。
CSVファイルの変数値が出力されます
スレッド数は5に選択されており、CSVファイルには3行までのデータしかないため、ファイルを再度読み取り、4の1から始まる値を出力します。thサンプラー。
以下は、各フィールドの説明です。
CSVデータソースを構成する
ファイル名 ：読み取られて変数に変換されるファイルの名前。このフィールドには、ファイルをアップロードするための参照オプションが用意されています。
ファイルのパスを指定するには、CSVがJMETERディレクトリのBINフォルダにある場合はファイル名を直接入力できます。それ以外の場合は、システムのフルパスを指定します。
ファイルエンコーディング： ファイルを読み取るには、使用するエンコーディングをドロップダウンから選択する必要があります。
ファイルエンコーディングには、以下のオプションがあります。
オプションが選択されていない場合は、プラットフォームのデフォルトが使用されます。これは必須フィールドではありません。
変数名 ：変数リストはここにあり、区切り文字で区切る必要があります。このフィールドに何も入力されていない場合、ファイルの最初の行が読み取られ、列名と見なされます。
最初の行を変数名として使用する ：変数名が空の場合、最初の行にはヘッダーが必要です。変数名が空でない場合は、CSVファイルの最初の行が使用されます。
デリミタ： ファイル内のデータは、区切り文字を使用して分離できます。
引用データを許可する： CSVファイルデータを引用する必要があるかどうかをチェックします。ユーザーは、ドロップダウンからオプションをTrue / Falseとして選択できます。
EOFでのリサイクル： これは、ファイルが最後に達したときにファイルを再読み取りする必要があるかどうかを表します。 EOFはファイルの終わりを表します。デフォルトでは、選択された値はTrueです。
EOFでスレッドを停止しますか？ EOFに達したら再読み取りを停止するか、続行するかを尋ねます。デフォルトでは、選択された値はfalseです。
共有モード：
- すべてのスレッド： ファイルはすべてのスレッドで共有されます。
- 現在のスレッドグループ： すべてのファイルは、すべてのスレッドグループに対して開かれます。
- 現在のスレッド： ファイルはスレッドごとに開かれます。
- 識別： 共通IDは、複数のグループ間でファイルを共有するために使用されます。
＃2）FTPリクエストのデフォルト
JMeterはFTPプロトコルもサポートしています。スクリプトは、JMeterのFTP、FTPS、およびSFTPを使用して実行できます。
FTPリクエストのデフォルトを使用します。
- テスト計画を作成します。
- スレッドグループを追加します。
- 構成要素「FTP要求のデフォルト」を追加します。
- サンプラーの追加：FTPリクエスト。
- リスナーの追加：テーブルに結果を表示します。
表の結果の表示に表示される出力：
以下の詳細は、FTPデフォルトのフィールドについて詳しく知るのに役立ちます。
- サーバー名またはIP ：FTPサーバー名またはIPをここに入力する必要があります。提供される詳細は、ファイルが配置されるサーバー、またはそこから取得できるサーバーの詳細です。
- ポート番号： それは FTPサーバー 。使用されるデフォルトのポート番号は21です。
- リモートファイル： ファイルをグローバルに宣言する必要がある場合は、FTPサーバー上のファイルの唯一のパスをこのフィールドに指定する必要があります。それ以外の場合は、空白のままにすることもできます。
- ローカルファイル： リモートファイルと同じ–フィールドは空白のままにすることができます。ファイルをグローバルに宣言する必要がある場合は、ローカルサーバーへのパスを指定する必要があります。
- ローカルファイルの内容： サーバーへのアップロード時に使用できるソースファイルのコンテンツをここで提供できます。
- Get（RETR）： FTPサーバーからダウンロードするファイル。
- 置く（STOR）： FTPサーバーにファイルをアップロードするには
- バイナリモードを使用する： テキストファイルではこのモードの選択を解除し、他のすべてのファイルではバイナリオプションを選択する必要があります。
- 応答でファイルを保存： このオプションを選択すると、出力がFTP応答データとして保存されます。
＃3） DNSキャッシュマネージャー
DNSキャッシュマネージャーは、テスト計画またはスレッドグループの直下で使用できます 。
DNSキャッシュ要素マネージャー インスタンスの障害やその他の理由でサービスが中断されないなどのシナリオでアプリケーションをテストするのに役立ちます。 JMeterは、デフォルトのキャッシュをJVMDNSキャッシュとして使用します。
JMeterはリクエストをロードバランサーに送信します。ロードバランサーは、3つのアプリケーションがテスト中であると言って、複数のアプリケーションへのリクエストをさらに分割します。リクエストが1つのAUTのみに送信される場合があります。この理由は、JVMレベルのDNSキャッシュとして識別されます。
= >>もお読みください DNSキャッシュをクリアする方法
DNSキャッシュマネージャーは、次の方法でこの問題を解決するのに役立ちます。
- テスト計画にDNSキャッシュマネージャーを追加し、オプション「 カスタムDNSリゾルバーを使用する」 ホスト名またはIPアドレスを指定して、テストを実行します。 1つではなく両方のIPアドレスにヒットします。
- HTTPリクエストを使用している間は、常に Httpclient4 。
- DNSキャッシュマネージャーは、テスト計画またはスレッドグループ要素で使用する必要があります。
フィールドの説明：
- 各反復のキャッシュをクリアします。 このオプションを選択すると、新しいサイクルが開始されると、すべてのスレッドのDNSキャッシュがクリアされます。
- ユーザーシステムDNSリゾルバー： ユーザーがシステムDNSリゾルバーを使用したい場合。
- ホスト名またはIPアドレス： 使用するDNSサーバーの詳細。
- ホストとホスト名またはIPアドレス： 静的ホストとホスト名またはIPアドレスがマップされます。
＃4）HTTP認証マネージャー
HTTP認証マネージャー サーバー認証を使用して制限されているWebアプリケーションのページにユーザーログインを提供できます。ユーザーが制限されたページに接続しようとすると、(ログイン)ダイアログボックスが表示されます。
最高の無料のウイルス除去は何ですか
各反復で認証をクリアします。 このオプションを選択すると、前のスレッドグループで行われた認証の有無に関係なく、各反復での認証が行われます。
ベースURL： 1つ以上のHTTPURLに一致するURL。
ユーザー名 ：認証用のユーザー名。
パスワード ：上記のユーザー名のパスワード。
ドメイン ：NTLMのドメイン。
レルム ：NTLMのレルム。
機構 ：実行する認証メカニズムを提供する必要があります。
同じことを理解するために例を見てみましょう。
次のURLでサイトにログインしてみてください。 https://httpbin.org/basic-auth/user/passwd 。認証ウィンドウが表示されます。
ユーザー名またはパスワードが正しくない場合、またはconfig要素が有効になっていない場合は、 応答コード-401
また、詳細が正しく、config要素が有効になっている場合は、 応答コード-200
＃5） HTTPキャッシュマネージャー
HTTPキャッシュマネージャー 実行の進行中に、ダウンロードしたすべての静的ファイルを保存するために使用されます。これは、「すべての埋め込みリソースを取得する」オプションが選択されている場合にのみ行われます。また、変更が行われるまで、すでに保存されているものは保存されません。
各反復でキャッシュをクリアします。
スレッドグループ構成を使用して、キャッシュのクリアを制御します。
GETを処理するときにcache-Control / Expiresヘッダーを使用する リクエスト。 このオプションを選択すると、キャッシュ制御/有効期限が現在の時刻に従って検証されます。
キャッシュ内の要素の最大数： デフォルトでは、値はユーザーあたり5000です。すべてのキャッシュはRAMに保存されます。ユーザーが5000を超える値を入力した場合、サーバーは例外をスローできます 「メモリ不足」 同じように。
cache-control / expireヘッダーオプションを使用した場合と使用しない場合の動作を見てみましょう。
次に、3番目のオプションを選択して、テスト計画を再実行します。
オプションを選択すると、サンプル時間と待ち時間が短縮されました。
セキュリティキーの不一致とはどういう意味ですか
＃6）HTTP Cookie Manager
HTTPクッキーマネージャー ユーザーにHTTP要求があり、応答にCookieがある場合、CookieマネージャーはそのCookieを保存し、その特定のサイトの将来の参照に使用するという機能があります。
ブラウザのEdge、Firefox、およびChromeがWebサイトの閲覧に使用されているとします。ユーザーがユーザー名とパスワードを使用してログインすると、Cookieとしてシステムに保存されます。次回ユーザーが同じWebサイトにアクセスするとき、ユーザー名やパスワードなどの詳細を入力する必要はありません。これは、既にCookieとしてシステムに保存されているためです。
反復ごとにCookieをクリアする ：各反復で、つまりスレッドループが1回実行されると、サーバーベースのCookieがクリアされます。
理解するために例を見てみましょう：
- ループカウント3でスレッドグループをテスト計画に追加します
- スレッドグループの構成要素としてHTTPCookieManagerを追加します
- サーバー名とパスを提供するHTTPリクエストを追加します
- リスナーの追加“ 結果ツリーを表示 」と出力を観察します。
上記の結果によると、最初の反復ではリクエストにCookieがないのに対し、他のすべてのリクエストにはCookieデータがあることがわかります。
次に、下の画像に示すようにCookie Managerの構成要素に詳細を追加し、同じ結果を観察します。
＃7）HTTPリクエストのデフォルト
この構成により、ユーザーはHTTP要求コントローラーのデフォルト値を設定できます。
例： サーバーxyz.comに50個のHTTPリクエストを送信する場合-ユーザーは50個のHTTPリクエストに対して「servername = xyz.com」を50回入力する必要がありますが、HTTP Request Defaultを使用すると、ユーザーは50個のHTTPを作成できます。サーバー名= xyz.comを1回入力してリクエストします。それはユーザーの時間を節約します。
すべてのリクエストは、提供されたWebサーバーに送信されます。
HTTPリクエストのデフォルト要素は、HTTPリクエスト要素によって使用されるデフォルト値を指します。
HTTPリクエストのデフォルト要素の使用方法の例：
- テスト計画： 追加 HTTPリクエストのデフォルト サーバー名をtribuneindia.comとして追加します
- スレッドグループの追加
- パスのみを提供する2つのHTTPリクエストを追加します。
- リスナーを追加 「結果ツリーを表示」 スクリプトを実行します。パスが指定されていない場合、要求はHTTP要求のデフォルト構成要素で指定されたサーバーに送信されます。
＃8）HTTPヘッダーマネージャー
HTTPヘッダーマネージャー HTTPリクエストヘッダーの追加または重複に役立ちます。 JMeterは複数のヘッダーマネージャーをサポートしています。サンプラーのリストは、ヘッダーエントリで構成されています。マージされるヘッダーエントリから、それらのいずれかが既存のヘッダー名と一致する場合、古いものが新しいものに置き換えられます。
Accept-Language、Accept-Encoding、User-Agent、Referrer 使用できる標準ヘッダーです。
ヘッダー名と値は、(追加)ボタンを選択して追加できます。
言語を受け入れる どの言語サーバーが応答をブラウザーに送り返すかを定義するために使用されます。
エンコーディングを受け入れる： Acceptコーディングは、サーバーが応答するために使用する必要があるコーディング方法を定義します。サーバーが受け入れられたエンコーディングで応答を送信できない場合、サーバーは エラーメッセージとステータスコードを406として送信します。
エンコードフィールドの受け入れが指定されていない場合、サーバーはクライアントが任意のエンコード方法を受け入れると想定します。
ユーザーエージェント： ユーザーエージェントを使用すると、Webサーバーのブラウザー、バージョン、オペレーティングシステムなどの特性を見つけることができます。ブラウザがいずれかのWebサイトに接続すると、ブラウザはユーザーエージェントを同じWebサイトに送信します。 User-agentはHTTPヘッダーに含まれています。
HTTPヘッダーマネージャーでサポートされているブラウザーは次のとおりです。
- IE
- Firefox
- サファリ
- オペラ
- クロム
リファラー： あるWebサイトが別のWebサイトを参照する場合、そのアドレスはHTTPリファラーにキャプチャされます。
このHTTPヘッダーマネージャーがどのように機能するかを見てみましょう。
- テスト計画を作成し、それにスレッドグループを追加します。
- Config要素のHTTPヘッダーマネージャーを追加し、Accept-LanguageやAcceptなどのフィールドとその値を追加します。
- サーバー名とパスをwebsite.comとしてHTTPリクエストを追加し、ログインします。
- リスナーを追加 「結果ツリーを表示」 スクリプトを実行して出力を観察します
次に、別のHTTPヘッダーを追加し、Accept-languageasなどの変更を加えます。 SP-sp とで 受け入れる 同様に、スクリプトを再実行します。
ヘッダーは最新のヘッダーマネージャーからのみキャプチャされますが、既存のヘッダーは変更されません。
＃9）キーストアの構成
キーストア構成 KeyStore-ロード方法と使用するキーを構成することです。
サーバーに接続しているユーザーを知るために、一部のシステムではクライアント側の証明書を構成する必要があります。この構成要素は同じ構成に役立ちますが、KeyStore構成要素を追加する前に–Javaキーストアをクライアント証明書で設定する必要があります。
同じことを行うには、次の手順に従う必要があります。
証明書の作成：
- JavaKeytoolユーティリティの使用
- PKIを介して：PKIを介して実行する場合は、JKSで受け入れ可能な形式に変換する必要があります
システムに以下を追加します。プロパティファイル：
javax.net.ssl.keyStore = path_to_keystore
javax.net.ssl.keyStorePassword = password_of_keystore
プリロード ：プリロードするかどうかのキーストアは、trueまたはfalseを選択して選択できます。
証明書エイリアスを保持する変数名： クライアント証明書による認証に使用されるエイリアスで構成される変数名。
エイリアス開始インデックス（0ベース）： KeyStoreで使用される最初のキーのインデックス。
エイリアス終了インデックス（0ベース）： KeyStoreで使用される最後のキーのインデックス。
＃10）LDAPリクエストのデフォルト
LDAP要求のデフォルト LDAPテストのデフォルト値を追加できます。
同じLDAPサーバーに対して要求の数を作成する場合は、LDAP要求のデフォルトの構成要素を使用できます。これは、ユーザーがLDAP要求に対して同じ詳細を何度も入力する必要がないためです。
4つのLDAP要求を構成できます。
- テストを追加
- テストを削除
- 検索テスト
- テストの変更
これらの要求は、LDAP要求をサンプラーに追加してから、名前をAdd / Delete / Modified / Searchに変更し、プロパティをAdd Test / Delete / Modified / Searchテストとしてそれぞれ選択することで構成できます。
＃11）LDAP拡張リクエストのデフォルト
この構成要素を使用すると、拡張LDAPテストのデフォルト値を追加できます。
LDAP Config要素には、以下に定義する9つのテスト操作があります。
品質保証面接の質問と回答
＃1）スレッドバインド
スレッドバインドは、LDAPサーバーとのセッションを開始するために使用されます。ユーザーは、セッションを開始するためのユーザー名とパスワードを提供します。間違ったパスワードを入力すると匿名セッションが開始されますが、同じように失敗します。
＃2）スレッドのバインド解除
スレッドのバインド解除 セッションを終了するために使用される操作です。
＃3）シングルバインド/アンバインド
シングルバインド/アンバインド 両方の操作の組み合わせとして機能します。セッションを開いてユーザー名とパスワードの有効性を確認してから、セッションを終了します。
＃4）エントリの名前を変更する
名前が示すように、エントリの名前を変更するために使用されます。また、エントリをLDAPツリーの別の場所に移動するためにも使用できます。
＃5）テストを追加
これは、LDAPサーバーにオブジェクトを追加するために使用されます。使用されているのはLDAPの「追加」操作です。
＃6）削除テスト
削除テストは、LDAPツリーからオブジェクトを削除するために使用されます。
使用される操作は、LDAP「削除」操作と呼ばれます。
＃7）検索テスト
LDAP '探す' このテストでは操作が実行されます。
オブジェクトが返されるかどうかに関係なく、サーバーが検索を実行するのにかかる最大時間などの仕様を指定できます（デフォルトではfalseのみと見なされます）。検索結果の解析がtrueに選択されている場合、検索結果は応答データに追加されます。
＃8）比較テスト
比較テストは、属性を既知の値と比較するために使用されます。一般に、グループ内の個人の名前を確認するために使用されます。つまり、提供された名前がそのグループにすでに存在するかどうかを比較できます。
LDAP「 比較する 」操作も同様に使用されます。
＃9）修正テスト
変更テストは、LDAPを使用して値を追加/削除/削除/置換するために使用できます。 変更する 」操作。
JMeter構成要素に関するFAQ
Q＃1）JMeterのConfig要素とは何ですか？
回答 ：サーバーに送信されるリクエストは、JMeterのconfig要素を使用して変更または構成されます。
Q＃2）JMeterのスレッドプロパティとは何ですか？
回答 ：スレッドプロパティには、同じシナリオを実行するために使用されるスレッドの数と、構成から設定できる反復の数が含まれます。
Q＃3）JMeterのどの要素が、シミュレートするユーザーの数に対応しますか？
回答 ：スレッドグループは、シミュレートするユーザーの数に対応します。これは、スレッドの数を使用して、パフォーマンスとユーザーとアプリケーションの相互作用をチェックするようにシミュレートするユーザーを構成できるためです。
結論
JMeter構成要素を使用すると、ユーザーはJMeterの値にさらに関連付けられている任意の変数にアクセスできます。サンプラーから発信されたリクエストの値を変更できます。
追加したサンプラーを右クリックし、リストから構成要素を選択することで、構成要素を追加できます。それらは、それが配置されている場所、つまり木の枝の内側からのみアクセスできます。
この記事で説明されているように、JMeterにはいくつかの構成要素があり、ユーザーの要件に従って使用できます。
=>ここをクリック JMeterでの完全な無料トレーニング（20以上のビデオ）