detail description jmeter components
Jmeterコンポーネントのレビュー（パートII）：
=>これはJMeterトレーニングシリーズの一部です。 このシリーズのすべてのチュートリアルのリストはこちらからご覧ください 。
皆さんが通過したに違いないことを願っています JMeterの紹介とインストール 今では。シリーズの次のシリーズを続けるので、JMeterをインストールして、並べて練習することを強くお勧めします。
このチュートリアルでは、読者は自分自身に精通するでしょう JMeterのすべてのコンポーネントとテスト計画でのそれらの使用方法 AUT（Application Under Test）をテストするために考えられるすべてのパフォーマンステストシナリオをカバーします。
Jmeterの要素は、前の記事にリストされていました。
学習内容：
JMeterのコンポーネント
参考までにもう一度ペンダウンします。
- テスト計画
- ThreadGroup
- サンプラー
- リスナー
- WorkBench
- アサーション
- 構成要素
- ロジックコントローラー
- タイマー
スレッドグループ、サンプラー、リスナー、構成要素など、Jmeterのすべての主要コンポーネントについては、この記事の後半で詳しく説明します。
各コンポーネントとJMeterの特定のモジュールとの関係を理解するには、以下のフロー図を参照してください。
ここで、Jmeterの各コンポーネントとユースケースに触れて、Jmeterがどのように機能し、テスターがテストでこれらをどのように実装できるかを理解します。この記事では、すべてのサンプラー、リスナーを網羅しているわけではないことに注意してください。最もよく使用されるものに取り組み、リアルタイムのテスト計画を作成するときに次の記事で休憩します。
テスト計画
ソフトウェアテストの単純なテスト計画がスクリプトを実行するすべてのステップで構成されているように、JMeterのテスト計画にも同じ目的があります。テスト計画に含まれるすべてのものは、上から下への順序で、またはテスト計画で定義された順序に従って実行されます。
テスト計画は、ThreadGroup、Sampler、およびListenerを使用するだけで、可能な限り単純にすることができ、構成要素、プリプロセッサ、コントローラーなどの要素を追加し始めるとすぐに複雑になり始めます。
JMeterは、実際のユーザーがサーバーにリクエストを送信しているかのように、テスト対象のサーバーにヒットする仮想ユーザーまたはスレッドを生成することでパフォーマンスを測定することは誰もが知っています。したがって、すべてのテスト計画には、JMeterの用語で仮想ユーザーまたはスレッドグループと呼ばれるものが必要です。
テスト計画に関する重要なポイント：
- 実行する前にテスト計画を保存する必要があります
- Jmeterファイルまたはテスト計画はの形式で保存されます。 JMX拡張ファイル
- テスト計画の一部を別の選択肢として保存することもできます。 例えば、 HTTPリクエストサンプラーをリスナーと一緒に保存する場合は、テストフラグメントとして保存して、他のテストシナリオでも使用できるようにすることができます。
- WorkBenchの要素はテスト計画で保存されません
スレッドグループ
スレッドグループは、テスト対象のサーバーに同時に、または事前定義された順序でアクセスするユーザーのグループです。テスト計画を右クリックすると、スレッドグループをテスト計画に追加できます。 JMeterはすべて「右クリックのもの」であり、右クリックですべてのオプションを取得できます。
スレッドグループ名を独自の名前に変更できます。名前を変更し、(テスト計画)ウィンドウの外側をクリックするだけで、名前が変更されます。
スレッドグループの追加については、以下のスクリーンショットを参照してください
（（注意：画像をクリックすると拡大表示されます）
テスト条件に従ってスレッドグループを構成することは非常に重要です。
例えば、 100人のユーザーが同時にWebサーバーにアクセスしたときのWebサーバーの動作をテストする場合は、スレッドグループを次のように設定できます。
基本的に、実際の負荷または仮想ユーザーを生成するために構成する必要がある3つの主要なパラメーターがあります。
- スレッド数（ユーザー） –仮想ユーザーの数を定義します。テストの目的では、一度に大量のスレッドを生成すると、多くのスレッドを消費することになり、最終的にCPU使用率が高くなる可能性があるため、限られた量の負荷のみを生成する必要があります。
- ランプアップ期間 –このフィールドは、負荷の生成を制御する上で非常に重要です。ランプアップ期間は、総負荷が生成される時間を定義しました。
例1：
- これは、テストが実行されるとすぐに、10人のユーザー全員が同時にサーバーにアクセスすることを意味します
例2：
- 上のスクリーンショットの「スケジューラー」チェックボックスに気付いたはずです。後で特定の時間にテストを実行する場合は、以下のスクリーンショットにも示されているように、タイミングを設定できます。これは、1秒ごとに、新しいユーザーがサーバーにアクセスすることを意味します。ロードは同時ではなく、増分で行われます。 10時までにth次に、すべてのユーザーがリクエストをヒットします。
- ループカウント –スレッドグループが実行される回数を定義します。 (永久)チェックボックスをオンにすると、手動で停止しない限り、テストは永久に実行されます。これは、「サーバーが数分間継続的なロードでクラッシュしない場合」などのテストに使用できます。
サンプラー
では、Jmeterはどのタイプのリクエストがサーバーに送信されたかをどのように知るのでしょうか？
- それはサンプラーを通してです。サンプラーは、テスト計画に追加する必要があります。サンプラーは、Jmeterに、どのタイプの要求をどのサーバーに送信する必要があるか、および事前定義されたパラメーターを使用して通知できるためです。リクエストには、HTTP、HTTP（s）、FTP、TCP、SMTP、SOAPなどがあります。
スレッドグループはサンプラーを使用してテスト対象のサーバーURLにリクエストを送信する必要があるため、サンプラーはテスト計画の直下ではなくスレッドグループにのみ追加できます。サンプラーはパスで追加できます スレッドグループ->サンプラー-> HTTPリクエスト。
HTTPリクエスト
これらは、サーバーに送信される最も一般的な要求です。いう、 例えば、 100人のユーザーにヒットしてもらいたい https://www.google.com 同時に、これは以下のスクリーンショットで説明されているように実行できます。
- パスは、メインWebサイト内のナビゲーションです。たとえば、http：//www.google.com/gmailにアクセスしたい場合は、パスに「/ Gmail」を設定しても、残りは同じままです。
- サーバー名に「www」と入力する必要はありません
- プロキシサーバーを使用している場合は、ポート番号が使用されます
- サーバー接続時間と応答時間のベンチマークが必要な場合は、タイムアウト接続と応答を設定できます。サーバーが構成されたものよりも応答の送信に時間がかかる場合、要求は失敗します
- リクエストとともに送信するパラメータを設定することもできます。 例えば： 場合によっては、リクエストとともに認証トークンを送信する必要があることがあるため、以下のようにHTTPリクエストに追加しました。
FTPリクエスト
パス->テスト計画->スレッドグループ->サンプラー-> FTPリクエスト
FTPはFileTransfer Protocolの略で、サーバーからファイルをアップロードまたはダウンロードするために使用されます。 JMeterのスレッドは、FTPサーバーにリクエストを送信して、そこからファイルをアップロードまたはダウンロードし、パフォーマンスを測定します。
- ローカルファイルは、ダウンロードしたファイルを保存する必要がある場所です
- FTPサーバーからダウンロードする場合は、GETオプションを使用します
- FTPサーバーにファイルをアップロードする場合のユーザーPOSTオプション
サンプラー、リスナー、構成要素などで構成される実際のテスト計画を実行するときにカバーされるリスナーがたくさんあります。
リスナー
そのため、これまで、サーバーにリクエストを送信するサンプラーはほとんど見られませんでしたが、応答はまだ分析されていません。パフォーマンステストとは、サーバーの応答をさまざまな形式で分析し、それをクライアントに提示することです。
テスターが統計を知ることができるように、リスナーはテスト実行の結果を表示するために使用されます。 Jmeterには約15のリスナーがありますが、主に使用されるリスナーはテーブル、ツリー、およびグラフです。
結果を表に表示：
これは、最も一般的に使用され、簡単に理解できる形式のリスナーです。結果は、いくつかの重要なパフォーマンスパラメータを含む表の形式で表示されます。
リスナーは、テスト計画の直下またはサンプラーの下に追加できます。違いは、サンプラーの下にリスナーを追加すると、そのサンプラーの結果のみが表示されることです。テスト計画のすぐ下にサンプラーを追加すると、階層の上位にあるすべてのサンプラーの結果が表示されます。
参考までに、以下のスクリーンショット：
以下のような結果が表示されます。
- レイテンシー ：最初の情報が受信されたとき、つまりデータの最初のバイトが受信されたときです。
- 接続時間 ：サーバーとの接続を確立するのにかかる時間です
- サンプル時間 ：完全なデータを受信するのにかかる時間です
- サンプル –サンプル番号のシーケンス
- バイト- 受信したデータのサイズ。
ツリーで結果を表示：
これは、もう1つの最も一般的に使用されるリスナーであり、要求と応答とともに詳細情報を提供します。 Json、XML、Text、RegExの表示とは別に、応答としてレンダリングされたHTMLページを表示することもできます。
テスターは、受信した応答にアサーションを設定して、テストに合格したことを確認できるため、非常に便利です。 Jmeterの結果には、応答が望ましくない場合でも「合格」と表示されます。
例えば： たとえば、任意のWebサイトでHTTPリクエストをヒットします www.xyz.com それに応じて、XYZを期待します。つまり、このページにアクセスすると、会社のホームページがその名前で開きます。アサーションを設定していない場合でも、ヒットがサーバーに送信されたため、Jmeterは結果を表示します。
結果の形式については、以下を参照してください。
応答のHTMLページを表示するには、左側のペインのドロップダウンをクリックしてから(HTML)を選択し、(応答)タブに移動して、サーバーの応答として返されるページを確認します。
作業台
ワークベンチは、現在のテスト計画では使用されていないが、後でコピーして貼り付けることができる要素を保存できる場所です。 JMeterファイルを保存するときに、ワークベンチに存在するコンポーネントは自動的に保存されません。右クリックして「名前を付けて保存」オプションを選択して、個別に保存する必要があります。
皆さんは、ワークベンチの使用法について考えているかもしれませんが、とにかく、Jmeterのテスト計画にコンポーネントを直接追加するのは簡単です。
ワークベンチを使用する理由は、ユーザーがいくつかの実験を行って新しいシナリオを試すことができるためです。すでに知っているように、ワークベンチの要素は保存されないため、ユーザーは文字通り何でも使用して破棄できます。ただし、WorkBenchでのみ使用できる「非テストコンポーネント」がいくつかあります。
それらはここにリストされています：
- HTTPミラーサーバー
- HTTPテストスクリプトレコーダー
- プロパティの表示
HTTP（s）Test Script Recorderは、JMeterで使用される最も重要な非テスト要素です。これは、テスターがスクリプトを記録し、各トランザクションの負荷を構成するのに役立ちます。
Javaで配列に追加できますか
Jmeterは、サーバーに送信された要求のみを記録します。 QTP / Seleniumの「記録と再生」機能と混同しないでください。すべてのリクエストが記録され、テスターはそれらに必要な負荷をかけて動作を確認できます。
この要素は、テスターがアプリケーションからのすべてのリクエストが何であるかを知らないシナリオにとって非常に重要です。彼らは、Http（s）スクリプトレコーダーを使用して、テスト中のアプリケーションを記録できます。
モバイルアプリケーションのパフォーマンステストも、この方法でJMeterプロキシを設定し、モバイルアプリがサーバーに送信するリクエストを記録することで実行できます。モバイルパフォーマンステストのステップバイステップの手順については、次の記事で説明します。
アサーション
これまで、JMeterがサーバーにアクセスする方法と、リスナーを介して応答が表示される方法について説明してきました。受信した応答が正しく、期待どおりであることを確認するには、アサーションを追加する必要があります。アサーションは、結果を比較するために応答に適用する必要がある単なる検証です。
以下は、一般的に使用されるアサーションのタイプです。
- 応答アサーション
- 期間アサーション
- サイズアサーション
- XMLアサーション
- HTMLアサーション
応答アサーション
応答アサーションでは、独自のパターン文字列を追加して、サーバーから受信した応答と比較できます。 例えば、 リクエストが何らかの応答を正常に返すと、応答コードは200になります。したがって、パターン文字列「Response Code = 202」を追加すると、テストケースは失敗するはずです。
以下のスクリーンショットを参照して、応答コードアサーションを追加してください。
これで、テストを実行すると、アサーションの結果が失敗したことを示す赤い色で結果が表示されます。
期間アサーション
期間アサーションは非常に重要であり、サーバーが指定された時間内に応答したことを検証します。これは、100個のリクエストをサンプリングし、ベンチマークされた制限内で応答を受信するたびに確認する必要があるシナリオで使用できます。
場合 ：10人のユーザーが同時に「google.com」サーバーにアクセスしており、DurationAssertionは1000msに設定されています。以下のスクリーンショットを参照してください。
XMLアサーションは、応答データに正しいXMLドキュメントが含まれているかどうかを検証し、HTMLアサーションはサーバーから受信した応答のHTML構文を検証します。
構成要素
サーバーに送信されるリクエストは、実際のリクエストの前に実行されるいくつかの構成要素を使用して、さらにパラメーター化できます。その簡単な例は、CSVデータセット構成が使用されているCSVファイルから変数の値を読み取ることです。
以下は、Webおよびモバイルアプリケーションのパフォーマンステストで使用される重要な構成要素の一部です。
- CSVデータセット構成。
- ユーザー定義変数
- HTTPSリクエストのデフォルト
- HTTPSキャッシュマネージャー
- HTTPS Cookie Manager
CSVデータセット構成
CSVデータセット構成は、Jmeterが個別のリクエストごとに異なるパラメーターを渡すのではなく、CSVファイルからいくつかのパラメーターの値を選択するのに役立ちます。 例えば、 異なるユーザーとパスワードのセットでログイン機能をテストする必要がある場合は、CSVファイルに2つの列を作成し、そこに値を入力して、JMeterがサーバーに送信されるリクエストごとに1つを選択できるようにします。
以下は、CSVデータセットを使用して、インドのさまざまな都市の天気APIをテストするための構成のフローです。
- CSVデータセット構成要素をテスト計画に追加する
- CSVファイルの作成
- リクエストパラメータで変数を渡します。 APPIDパラメータはから動的に生成できます http://openweathermap.org/appid
- テストの実行と結果の表示。
ユーザー定義変数
Jmeterが事前定義された変数から値を選択するのに役立ちます。 例えば、 同じURLに多くのHTTPリクエストを追加する必要があるテスト計画を作成する必要があり、クライアントが後でそれを別のURLに移行することを計画しているシナリオがある可能性があることをサポートします。したがって、各リクエストでURLを更新しないようにします。 JMeterにUDV（ユーザー定義変数）からURLを選択するように指示できます。これは、後で更新して、更新されたURLへのすべての要求を処理できます。
したがって、各リクエストでURLが更新されないようにするために、更新されたURLへのすべてのリクエストを処理するために後で更新できるUDV（ユーザー定義変数）からURLを選択するようにJMeterに指示できます。
HTTPリクエストのデフォルト
この構成要素は、https要求のデフォルト値を指定するのに非常に役立ちます。詳細については、Googleサーバーで50の異なるリクエストをヒットする必要がある例を見てください。このシナリオでは、HTTPリクエストのデフォルトを追加する場合、サーバー名、パス、またはポート番号、接続などの他のプロパティを指定する必要はありません。タイムアウトプロパティ。 HTTPリクエストのデフォルト設定要素で指定されているものはすべて、すべてのHTTPリクエストに継承されます。
このシナリオでは、HTTPリクエストのデフォルトを追加する場合、サーバー名、パス、またはポート番号、接続タイムアウトプロパティなどの他のプロパティを指定する必要はありません。 HTTPリクエストのデフォルト設定要素で指定されているものはすべて、すべてのHTTPリクエストに継承されます。
以下のHTTPリクエストのデフォルトを追加し、サーバーとパスを指定する方法をご覧ください。
HTTPキャッシュマネージャー そして HTTPクッキーマネージャー JMeterをリアルタイムブラウザとして動作させるために使用されます。 HTTPキャッシュマネージャーは各リクエストの後にキャッシュをクリアできますが、もう一方はCookie設定を管理できます。
ロジックコントローラーとタイマー
ロジックコントローラーとタイマーは、Jmeterがトランザクションのフローを制御するのに役立ちます。サーバーをテストする必要がある場合、タイマーは各スレッドの遅延を保証します。 例えば、 HTTPリクエストが完了してから5秒間待機するFTPリクエストが必要な場合は、そこにタイマーを追加できます。
ロジックコントローラーは、サーバーに送信される要求のフローを定義するために使用されます。また、ログインやログアウトなど、モジュールごとに個別にリクエストを保存することもできます。
結論
これまでに、皆さんはJMeterのコンポーネントに精通し、それを使用してみて、いくつかの問題に直面している必要があります。次の記事では、モビリティドメインをカバーするリアルタイムのパフォーマンステストシナリオをいくつか取り上げ、JMeterに関する実践的な知識をさらに身に付けられるようにします。
乞うご期待！次の記事は、リクエストの管理、結果の分析、パフォーマンステストのベンチマークとの比較に役立ちます。
=>パートIIIを読み続ける： JMeterプロセッサとコントローラ
=> JMeterチュートリアルについては、ここをクリックしてください。 JMeterの完全無料トレーニング（20以上のビデオ）