JMeterのシナリオ作成がうまくいかない！そんなときのトラブルシューティングガイド

はじめに

こんにちは、開発エンジニアのnorth_mkyです。先日業務にて負荷検証をJMeterで行うことになり、弊社エンジニアが書いた下記の記事を読みつつ複数のシナリオ作成を行いました。

tech-blog.rakus.co.jp

ですが最初の1シナリオの作成で全然想定している動作にならず、予想よりも3倍ほど時間がかかってしまいました。。。

シナリオ作成にあたって必要な知識として、もちろんシナリオを作成する対象の画面の仕様理解も必要ですが、思った以上に小さな設定ミスが多いです。この記事では原因箇所に気づくまでのプチ・ベストプラクティスをご紹介したいと思います。

はじめに
対象読者
シナリオ作成トラブルシューティングガイド
おわりに

対象読者

シナリオを作成している方には有益な記事になっていると思います。特に少し複雑なシナリオを作成しようとしている方にはぜひ一度みていただけたらと思います。

JMeterのシナリオ実行はしたことがあるけどシナリオ作成は初めて/始めたばっかりの方
シナリオ開始から終了までの間の画面遷移が多い(サンプラーが多い)
特定のリクエストパラメータの値を外部ファイル(CSV)から読み込んでセットするようにしている
リクエストパラメータが動的に変わる画面遷移がある
- CSRF トークン

シナリオ作成トラブルシューティングガイド

ミスの原因調査が簡単なものから除々に特定が難しい原因調査へとステップを踏むと効率的ですのでそのような構成にしました。シナリオデバッグをしていると最初は直しても直しても違うエラーがでてくる...と思わせてくるところがあるのですが、多くは簡単な設定ミスなので、気にせず淡々と確認していきましょう！

Step0. 準備

まず最初にデバッグができるようにする設定が必要です。テスト計画の直下に以下2点のコンポーネントを追加します。設定を適切に行うと実際に実行したときのリクエスト・レスポンスの情報がすべて見れるようになります。注意なのですが、デバッグ用に追加するので実際に負荷検証を流すときには必ず無効にしてください。 正しく計測ができない可能性があります。

リスナー > シンプルデータライタ
実行結果をファイル出力するコンポーネント。以下のようなxmlファイル形式に設定する
リスナー > 結果をツリーで表示
1.で出力したファイルを読み込んでリクエスト・レスポンスをわかりやすい形で表示するコンポーネント
- 失敗したリクエストは赤字にしてくれる ¹
- まちがっていそうなパラメータを赤字にしてくれる
- URLエンコードされたパラメータをデコードして表示してくれる

Step1. jmeter.logを確認する

ポイント
- 外部ファイルが正しく読み込まれているか
  - パスの指定が誤っていないか
  - 外部ファイルの書き方とシナリオで設定したカラムの順番、情報に誤りがないか

いざテスト実行してみたものの、本来ならもっと実行に時間がかかるところが一瞬で実行が終わってしまった...という場合はそもそもシナリオを実行するための準備に不足がある可能性が高いです。そのときはまずjmeter.logを確認します。jmeter.logは実行ログとなっており、外部ファイルの読み込みがうまく行っていない場合はエラーとして記録を残してくれます。

jmeter.logをみて原因箇所が推測できたら、設定エレメント > CSV Data Set Configの設定内容であったり指定したファイルの形式があっているか確認し適宜修正してください。

Step2. リクエストパラメータの値が正しいか確認する

Step0 で設定したリスナー > 結果をツリーで表示を見て実際にアクセスしたときのリクエストパラメータを見ていきます。このパラメータの設定のミスが割と多いので下記ポイント4つを順番に見ていくと良いと思います。

ポイント
1. 変数名がそのまま出ていないか
2. 適切にURLエンコードをしているか
3. 前画面の値を取得する後処理 > 正規表現抽出で設定した変数名をパラメータにセットし忘れていないか
4. 受け渡している変数パラメータの値が前画面から正しく取得されているか

1. 変数名がそのまま出ていないか
リクエストパラメータの値を見ればすぐに見つけられます。(${hoge})
大抵原因は
「サンプラーに設定した変数名が定義した変数名と違う」
「後処理 > 正規表現抽出の正規表現が誤っていて抽出結果が空」
のいづれかになります。

2. 適切にURLエンコードをしているか
マルチバイト文字であったりURLでメタ文字や利用できない文字が含まれるパラメータをURLエンコードしないでリクエストを投げているか、逆にすでにURLエンコードしているところに誤って二重でURLエンコードを行ってしまっている場合があります。「URL Encode?」チェックボックスを確認してみてください。 HTTPプロキシをたててリクエストを記録した場合、よしなにJMeterがつけてくれている場合が多いですが、正規表現を組んだりしていくうちにチェックが外れてしまった/ついてしまったことがでてくるかもしれません。緻密な作業でミスが起きやすいので自分を責めず、そしてめげずに進めていきましょう...(経験談)

3. 前画面の値を取得する後処理 > 正規表現抽出で設定した変数名をパラメータにセットし忘れていないか
リクエストを記録した場合、その記録していた値のままになっているかもしれません。もう一度変数の設定漏れがないか確認してみてください。

4. 受け渡している変数パラメータの値が前画面から正しく取得されているか
1.で書いた原因に似ていますが、正規表現抽出で前画面から抽出自体はできていても余計な文字も拾ってきていてエラーになっている可能性があります。リスナー > 結果をツリーで表示ではレスポンスのbodyに対して文字列検索ができるため、リクエストパラメータにセットした値が前画面のレスポンス内で引っかかるか確認してみてください。

Step3. シナリオ実行がどこのリクエストで落ちたか実行順に見て特定する

ポイント
- リクエスト/レスポンスごとに想定の挙動になっているか確認する
  - webサーバ/アプリログなど
  - 画面

Step1,2を確認しても解消しない場合はいよいよシナリオをしらみつぶしに確認する作業になります。複数箇所でエラーが出ている場合は、だいたい上のエラーが引き継がれてエラーがでることが多いので焦る気持ちを抑えて上から順番に見ていきます。レスポンスでエラー画面やエラー文言があれば、そこからコケた原因を考えられるかと思います。

アサーションを適切に設定していないとエラーなのに見た目は成功を表すグリーンのアイコンになるのでより原因特定が難しくなりますよね。後世のために原因がわかったらアサーションを追加して次もし引っかかったときは失敗を表すレッドのアイコンになるようにすると良いと思います。

おわりに

いかがでしたでしょうか。長いシナリオだったりパラメータの多い画面の遷移となるとシナリオに小さいミスが起きやすくなる割に原因特定に時間がかかり気味になります。そんなときにこの記事をみていただいて皆さんのもやもやや苦痛が少しでも和らげば幸いです。

エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。

https://career-recruit.rakus.co.jp/career_engineer/
カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
rakus.hubspotpagebuilder.com
ラクスDevelopers登録フォーム

https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/
イベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！