マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

  • 各種の設定方法と負荷テストの実施手順についてまとめる。

を行う。

設定

HTTPリクエスト

HTTPリクエストのサンプラーを追加して使用する。

プロパティ

以下のプロパティを設定。

  • 名前
    HTTPリクエストの名前(ID?)。
  • コメント
    HTTPリクエストのコメント。
  • Webサーバ
    • サーバ名またはIP
      テストするサーバ名またはIPアドレス(http:// は書くとエラーになるので注意)
    • ポート
      http なら 80、https なら 443など。
  • プロトコル
    HTTP(既定値)/HTTPS/FILEのいずれか。
  • メソッド
    GET(既定値), POST, HEAD, TRACE, OPTIONS, PUT, DELETE, PATCH
  • パス
    • / から始まる(サーバ名またはIPアドレスを除いた)パス
    • パスはURLエンコードされないので注意(URLエンコードされたものを指定)。
    • クエリ・ストリングを付加したい場合は 後述の「リクエストで送るパラメータ」に記載。
    • フルパスの場合、サーバ名またはIP、ポート、プロトコル、クエリ・ストリングは無視される。
  • Timeouts(millisecond)
    • Connect
      接続タイマー
    • Response
      応答タイマー。
  • HTTPリクエスト
    • Implementation
      • Java, HttpClient3.1, HttpClient4(既定値).
      • 既定値は Jmeter の jmeter.httpsampler プロパティの値にも依存。
  • Content encoding
    • (POST, PUT, PATCH, FILE に対して)使われるContent encoding。
    • HTTP の Content-Encoding ヘッダには影響しない。
  • KeepAlive?を有効にする
    • Jmeter に Connection: keep-alive ヘッダをセットさせる。
    • Apache HttpComponents?HttpClient? 実装であれば正しく動作する。
  • multipart/form-data
    • Use multipart/form-data for POST
      multipart/form-data もしくは application/x-www-form-urlencoded を使った POST リクエストを使用。
    • Browser-compatible headers
      multipart/form-data を使う際、Content-Type および Content-Transfer-Encoding ヘッダを使わず、Content-Disposition ヘッダだけを送る。
  • リクエストで送るパラメータ
    クエリ・ストリングとして送るパラメータを指定する。
  • リクエストと一緒に送信されるファイル
    アップロードするファイルを指定する。
  • Proxy Server
    • サーバ名またはIP
    • ポート番号
    • ユーザー名
    • パスワード
  • Embedded Resources from HTML Files(画像, JavaScript, CSS等)
    • 全てのイメージとアプレットを繰り返しダウンロードする(HTMLファイルのみ)
      HTML ファイルをパースし、埋め込みリソースをGET。
    • Use concurrent pool.
      同時並行コネクションプールを使う。
    • Size:
      同時並行コネクションプールのサイズ
    • URLs must match
      GETする埋め込みリソースのURLとしてマッチさせたいものを正規表現で指定。
  • Source address(HTTPClient 実装における HTTP リクエストのみ)
    • ソースアドレスの型
      ソースアドレスの値を区別するために型を選択する。
    • ソースアドレスの値
      ・・・
  • オプションタスク
    • モニタとして使用
      モニタ結果リスナーで使用する。
    • Save response as MD5 Hash?
      • 応答が結果に格納されなくなる。
      • 代わりに、32 文字の MD5 ハッシュが格納される。

HTTPリクエスト初期値設定

認証設定

  • 以下の認証がある場合、
    • Basic
    • Digest
    • NTLM
    • Kerberos

設定項目

  • 基底URL
  • ユーザー名
  • パスワード
  • Mechanism

Mechanism=KERBEROSの場合

追加で、以下の設定が必要。

  • system.properties
    • java.security.krb5.conf
    • java.security.auth.login.config
  • *.conf
    • krb5.conf(Kerberos 構成ファイル)
    • jaas.conf(JAASログイン構成ファイル)

HTTP関連の設定

Cookieの有効化

「設定エレメント」の「HTTP クッキーマネージャ」を追加する。

Cacheの有効化

「設定エレメント」の「HTTP Cache Manager」を追加する。

起動設定

プロキシ設定

自身がプロキシとして動作するが、
更に、プロキシを経由させる場合、起動オプションでプロキシ設定を行う。

jmeterWithProxy?.bat的なbatファイルを準備しておくと吉。
なお、この時、jmeter.batへのパスを、フルパスで記述しておくこと。

CUI(non-GUI)モード

  • 負荷テストの実行時は、CUI(non-GUI)モードで起動する。
  • 「テスト計画-nnnnnn.jmx」に定義されたテストを実施してlog.jtlに結果を出力。
    jmeter -n -t テスト計画-nnnnnn.jmx -l log.jtl
  • オプション
    項番オプション説明
    1-nCUI(non-GUI)モードモードで起動
    2-t [ファイル名]テスト計画を格納するJMXファイル名
    3-l [ファイル名]テスト結果を保存するJTLファイル名
    4-j [ファイル名]実行ログを保存するログファイル名
    5-g [CSVファイル名](テストは実行せずCSVファイルを読み込んで)レポートを出力
    6-e負荷テスト後にレポートを出力
    7-o [フォルダ名]レポートを出力するフォルダを指定。
    存在しないフォルダ名か空のフォルダを指定。

負荷設定

多重度(仮想ユーザ数)

多重度(仮想ユーザ数)は、スレッド数で設定する。

スループットの調整

  • スループットは、
  • Ramp-up期間(秒)
    1秒中の同時アクセス仮想ユーザー数 = (仮想ユーザ数 * ループ回数) / Ramp-up期間(秒)
  • タイマ
    • 定数タイマ
    • 定数スループット・タイマ

の何れかで調整する。

  • Ramp-up期間(秒)を使用した方法
    本来、「Ramp-up期間(秒)」は、
    多重度(仮想ユーザ数)を徐々に増加させるための用途で使用すため、
    スループットの調整には、「タイマ」を使用した方法が推奨される。
  • タイマを使用した方法
    入力時間、思考時間を考慮してタイマを設定する。
  • 定数タイマ
    • スレッドグループやコントローラーなどのシナリオ以下に定数タイマを追加する。
    • 以下の計算式を参考にして、スレッド遅延時間を設定する。
                      3,600秒
      ──────────────────── (秒/ページ) - 目標レスポンスタイム(秒/ページ) = スレッド遅延時間(秒/ページ)
        x(シナリオ実行回数/時) * yページ/シナリオ
    • 例えば、10ページのシナリオを10回実行する場合の目標レスポンスが3秒の場合
             3,600秒
      ──────────── (秒/ページ) - 3(秒/ページ)
        10 * 10 (ページ/時)
      
      = 3,600/100(秒/ページ) - 3(秒/ページ)
      
      = 36(秒/ページ) - 3(秒/ページ)= 33(秒/ページ)
  • 定数スループット・タイマ
    • スレッドグループやコントローラーなどのシナリオ以下に定数スループット・タイマを追加する。
    • 以下の計算式を参考にして、1仮想ユーザ中のターゲットスループット(サンプル数/分)を設定する。
        サンプル数/シナリオ       (シナリオ実行回数/時)
      ──────────── * ──────────── = 1仮想ユーザ中のターゲットスループット(サンプル数/分)
            1仮想ユーザ                   60分
    • 例えば、10サンプルのシナリオを10回実行する場合の目標レスポンスが3秒の場合
        10サンプル/シナリオ       10シナリオ/時
      ──────────── * ────────
            1仮想ユーザ              60分
      
          100(サンプル/時)
      =  ───────── = 100/60(サンプル/分) = 1.666(サンプル/分)
            1仮想 * 60分

手順

Jmeterのインストール

Jmeterの起動

以下に注意して、jmeter.batを起動する。

Java関係のパラメタ設定

必要に応じて、jmeter.batに、Java関係のパラメタ設定を行う。

管理者実行

jmeter.batを右クリックして、「管理者として実行」を選択する。

プロキシ設定

必要に応じて、jmeter.batに、プロキシ設定のコマンドライン引数を指定する。

言語の選択

必要に応じて「オプション → 言語の選択 → 日本」を設定。

初期設定

スレッドグループの追加

テスト計画に、スレッドグループを追加

HTTPリクエスト初期値設定

  • ここでは、スレッドグループ以下に当該「設定エレメント」を追加する。
  • 最低限、Webサーバ(サーバ名またはIP、ポート)項目の設定を行っておく。

HTTP認証の有効化

  • HTTP認証がある場合があるので、有効化しておく。
  • なお、ここでは、スレッドグループ以下に当該「設定エレメント」を追加する。

Cookieの有効化

  • 大概のWebアプリには、以下が使用されているので有効化しておく。
    • Session Cookie
    • Cookie認証Ticket
  • なお、ここでは、スレッドグループ以下に当該「設定エレメント」を追加する。

Cacheの有効化

  • 大概のWebサイトは静的コンテンツをキャシュ可能にしているので有効化しておく。
  • なお、ここでは、スレッドグループ以下に当該「設定エレメント」を追加する。

ワークベンチ設定

v4から表示されないので「テスト計画」側に追加する。

保存の設定

ワークベンチのSave Workbench チェック・ボックスをチェックにする。

HTTPプロキシサーバ(Test Script Recorder)

負荷テストのワークロード(電文)のキャプチャを行う。

  • 設定
    • ポート番号は既定で「8888」になっているので、必要に応じて変更する。
  • Test Plan Creationタブ > Test plan contents
    • 記録先を指定するため、
      [対象となるコントローラー]ドロップダウンリストから「テスト計画 > スレッドグループ名」を選択する。
    • また、ページ単位でリクエストをまとめて記録するようにするため、
      (Simple Controller以下に、HTTPリクエストのサンプラーが並ぶようになる)
      [グループにする]ドロップダウンリストから「新規コントローラーへ各グループを置く」を選択する。
  • リスナーの追加
    • プロキシサーバー機能が記録したワークロードを確認するためにリスナーを追加する。
    • HTTPプロキシサーバ(Test Script Recorder)に、「結果をツリーで表示」リスナーを追加する。
  • 開始
    • 設定画面中にある開始ボタン ( [▶] ) を押下する。
    • HTTPプロキシサーバ(Test Script Recorder)が開始したかどうかは「netstat -a」で確認できる。

Webアプリの電文を記録

  • ココまで来たら、一度、テスト計画(テスト計画-nnnnnn.jmx)を保存しておく。
  • なお、この*.jmxファイルは、backupフォルダに10世代分、自動的に保持される。

ブラウザの設定

  • 閲覧履歴(キャッシュ)を削除しておく。
  • その他、必要に応じて、各種ブラウザ設定を
    サイトユーザのメジャー設定に合わせて変更しておく。

HTTPプロキシサーバ(Test Script Recorder)の開始

HTTPプロキシサーバ(Test Script Recorder)を開始しておく。

ブラウザを操作してワークロードを記録

  • 以下は、当該PukiWiki?のページの新規作成と編集(削除)の操作をスクリプト化した例である。
    • PukiWiki?の仕組みを知らなかったため、ソレを理解しつつ、スクリプトの整理を行った。
    • このページは基本認証で守られているため、部外者は、新規作成と編集(削除)できません。
    • また、実際に、このページに負荷テスト・ツールを使用して負荷をかけないで下さい。
採取したワークロードを再現するスクリプト

HTTPプロキシサーバ(Test Script Recorder)の停止

ブラウザの設定を元に戻す

先程のブラウザ設定を元に戻しておく。

スクリプトのデバッグ・検証と修正

スクリプトのデバッグ・検証

スクリプトのデバッグ・検証と修正には、
HTTPとアプリケーションの知識が必要になる。

デバッグ実行

再生ボタンを押して、デバッグ実行してみる。

スクリプトのデバッグ実行1

デバッグ

正常に動作しない場合、以下の方法でデバッグする。

「結果を表で表示」リスナーの追加

「結果を表で表示」リスナーを使用してデバッグする。

「結果をツリーで表示」リスナーの追加

「結果をツリーで表示」リスナーを使用してデバッグする。

「アサーション(Response Assertion)」アサーションの追加

「アサーション(Response Assertion)」アサーションを使用してデバッグする。

  • スレッドグループ以下に「アサーション(Response Assertion)」アサーションを追加する。
    • 400 Bad Requestを検出する。
      応答コード、一致する、400
    • 500 Internal Server Errorを検出する。
      応答コード、一致する、500
    • カスタムのエラー画面を検出する。
      テキストのレスポンス、含む、「開発用エラー画面」(等、任意の文字列)

問題を発見した場合

上記のデバッグで問題を発見した場合、下記のスクリプト修正を行う。

スクリプトの修正

スクリプトのデバッグ・検証と修正には、
HTTPとアプリケーションの知識が必要になる。

可変値の追跡

リクエスト → レスポンス → リクエストと持ち回る値を追跡し変数化する。

抽出系の後処理を使用して可変値を追跡

はじめに、

追跡した可変値をリクエストに組込

次に、リクエストに「抽出系の後処理」に準拠した「参照名」を使用する。

「可変値の追跡」後のスクリプト動作確認

CSVの前に、入力値を編集してみて、スクリプトが正常に動作するか確認する。

  • ここでは、入力値の page と msg のパラメタを以下のように変更した。
    • page="aaa" ---> page="bbb"
    • msg="bbb" ---> msg="ccc"
  • 下記のように、
    • digest値の追跡前は編集(削除)に失敗するが、
    • digest値の追跡後は編集(削除)が成功することを確認できた。
スクリプトのデバッグ実行2

入力値にテストデータを組込む

  • 入力値に、CSVファイルなどを使用してテストデータを組み込む。
  • これにより、現実に近いシミュレーションやデータ競合の回避が可能になる。

追加の可変値の追跡

同様にして

  • 入力値(page と msg)に関連するパラメタを、
    • 可変値として追跡し(正規表現でリクエストから抽出)、
    • 追跡した可変値をリクエストに組込に組み込む。
  • 「可変値の追跡」後のスクリプトの動作確認を行う。
スクリプトのデバッグ実行3

入力値にCSVファイルからの入力を適用

  • 「CSV Data Set Config」には以下の設定を行い利用する。
    • Filename
      CSVファイルのファイルパス
    • File Encoding
      CSVファイルのエンコーディング(既定値はJavaVMの既定値)
    • Variable Names
      カンマ区切りの変数名(CSVのヘッダ行と同じ)
    • Ignore first line
      CSVファイルにヘッダ行がある場合、trueに設定しておく。
    • Delimiter
      CSVファイルの区切り文字
    • Allow quoted data?
      改行を含むデータ等は、""で囲んだりする。
    • Recycle on EOF?
      CSVファイルの終わりに到達した場合、先頭から再利用する。
    • Stop thread on EOF?
      CSVファイルの終わりに到達した場合、仮想ユーザーを停止する。
    • Sharing mode
      CSVファイルの共有モード
      • All threads
        全てのスレッドで共有
      • Current thread group
        スレッドグループで共有
      • Current thread
        個々のスレッドで利用(共有しない)
      • Identifier
        同じ識別子を共有するスレッドで共有
  • 「CSV Data Set Config」の設定例
  • 設定例
    CSV Data Set Config
  • CSVファイル(csv.csv)
    csv_page,csv_msg
    aaa,bbb
    bbb,ccc
    ccc,ddd
    ddd,eee
    eee,fff
    fff,ggg

CSVの変数をリクエストに組込

  • Variable Namesに指定した変数は、
    ${変数名}としてリクエストに組み込み、使用できる。
  • 上記の例では、
    • pageのユーザ入力:${csv_page}
    • msgのユーザ入力:${csv_msg}

と設定して、ユーザ入力をCSV入力に切り替える。

処理をループさせる

  • 全体をループさせる場合、
    スレッドグループの設定でループさせることができる。
  • 部分的にループさせる場合、
    • ループコントローラーにループ回数を指定して部分的にループさせることができる。
    • ログイン/ログアウト処理を一度だけ行い、内部をループさせる場合などに使用する。

CSV変数の組込後のスクリプト動作確認

CSVの変数をリクエストに組み込んだ後のスクリプトの動作確認を行う。

結果

クライアントのCookie操作の再現

前処理を行うBeanShell PreProcessorにCookie操作の処理を記述する。

機能テスト、負荷テスト

機能テスト

1多重で、機能テストを行う。

負荷テスト

n多重で、負荷テストを行う。

各種設定

各種設定を行う。

GUIの利用

  • GUIは電文の記録時やスクリプト修正時に使用し、負荷テスト実行時には使用しない。
  • 負荷テストの際はGUIで起動をしない。CUI(non-GUI)モードで起動する。

大規模なテストを行う場合

必要に応じて、複数のクライアントを準備して、
コントローラーから複数のエージェントを制御できる。

結果のレポーティング

負荷テストの結果のレポーティング用のリスナーを設定する

注意事項

HTTPS対応

キャプチャの際、ブラウザにJmeterプロキシ証明書をインストールする。

  • HTTSを使用する場合、Jmeterプロキシ証明書を、
    クライアント端末の「信頼されたルート証明機関」にインストールする。
  • Jmeterプロキシ証明書は、
    「HTTPプロキシサーバ(Test Script Recorder)」の開始後に、
    「Jmeterを解凍したフォルダ\bin\」以下に生成される。

リダイレクト

自動リダイレクト

  • 利用中の http プロトコルハンドラがリダイレクトに自動追従するようにする。
  • 自動リダイレクトの応答は、Jmeterのサンプルとして追加されない。

※ 自動追従したリクエストにはクッキーが送信されないので注意。

リダイレクトに対応

  • 自動リダイレクト」が無効の場合、
    応答がリダイレクトかどうかを チェックし、そうであればそれに従う。
  • この場合のリダイレクトの応答は、Jmeterのサンプルとして追加される。

参考

株式会社ケイズ・ソフトウェア

JMeter の利用方法


Tags: :テスト, :ツール類


添付ファイル: fileCsvFile.png 150件 [詳細] fileresult.png 201件 [詳細] filedebug3.png 168件 [詳細] filedebug2.png 164件 [詳細] filedebug1.png 194件 [詳細] filescript.png 172件 [詳細]

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-04-03 (火) 13:05:21 (565d)