またまた、事件です。
今度は、JMeterでStress Testを行うべく、まずは小手調べとしてサンプル的にWebアプリケーションの簡単な更新処理を実行しようとしていました。ところが、更新処理前までの画面遷移を行うためのGETメソッドは上手く実行できているのに、肝心の更新処理でPOSTしたリクエストを受けたアプリケーションの処理結果がエラーとなっています。

そのテスト計画(JMeterの動作を規定するシナリオのようなものです)は、以下の手順で作成したので、HTTPリクエストサンプラー(HTTPリクエスト処理を自動的に実行してくれるものです)の中のリクエストパラメータの定義に誤りがある訳もないし、と首をひねっていました。
(1) JMeterのProxy機能を利用して画面操作のリクエスト内容を採取
(2) 採取されて記録されたHTTPリクエストサンプラーの中のダイナミック変数などを適宜、編集
うん、ここのところで間違いはないはず。

で、問題の更新処理用のHTML中でJavaScriptが使用されていて、JMeterはレスポンスの中のJavaScriptを実行する訳ではないので、それが犯人かと追求したのですが、冤罪であることが判明しました。
そもそも、(1)の手順の最中でも、作成したHTTPリクエストサンプラーの実行の際でも、サーバー側に渡ったリクエストのパラメータが空っぽであることが、ベテラン刑事の厳しい取調べによって明らかとなったからです。ところが、JMeterに記録された送信リクエストの内容には、パラメータがびっしりと記載されているから、さあ、いよいよ謎は深まるのでした。

なんと真犯人は、multipart/form-dataの扱いに潜んでいたのでした(多分。状況証拠のみ)。
JMeterのHTTPリクエストサンプラーでは、ファイル添付のためのオプション項目が用意されているのですが、そこのパラメータ名とMIMEタイプを指定しておきながら、ファイルそのものの指定はしないと、ヘッダはmutipartでボディにはmultipartの区切りのないリクエストを送るみたいなことが、Bugzilla Bug 27780 に書かれているようです。
問題の更新処理用のHTMLには、ファイル添付の項目(input type="file")が用意されていて、formにもenctype="multipart/form-data"が指定されていたのです。そのせいで、(1)の手順の中で特にファイル指定はしていないにもかからわず、意識しないうちに、HTTPリクエストサンプラーのファイル添付のためのオプション項目のパラメータ名とMIMEタイプに、そのinput項目から引用された内容が記録されていたのでした。
そのオプション項目の指定を消すと、それまでの苦しみが嘘のように、更新処理は問題なく実行できたのでした。

めでたしめでたし。
いえ、喜んでばかりはいられません。今回も解決までに時間を要し過ぎ、あやうく迷宮入りさせてしまいそうでした...
初期の思い込みで捜査方針をミスリーディングしてしまったことを反省すると同時に、初動捜査の重要性を改めて思い知らされました。