JMeterが優れている点
同時負荷を生成すること。 スレッドグループ、ランプアップ、分散負荷生成。これこそがJMeterの作られた目的であり、今も無料の選択肢としては最良の部類に入ります。
プロトコルの対応範囲の広さ。 HTTPにとどまらない広さは、メッセージングやデータベースの層を持つエンタープライズシステムでは重要です。
すでに導入されていること。 技術的な利点ではありませんが、チームがJMeterを使う現実的な理由です。
JMeter APIテストが不向きになる場面
テストプランがXMLである
プルリクエスト上で変更内容をレビューすることは、ほぼ不可能です。
.jmxファイルのマージコンフリクトは、それ自体が別種の苦痛です。
デフォルトのアサーションが浅い
レスポンスコードと部分文字列のマッチングで一般的なケースは押さえられますが、それ以上のことはほとんどできません。
構造的な検証をしようとすれば、スクリプト要素を書くことになります。
状態管理が手作業になる
エクストラクター、変数、コントローラー、そのすべてを手で配線します。
依存関係のグラフは宣言されるのではなく、テストプランの構造の中に埋もれています。
うまくいく役割分担
キャパシティに関する問いはJMeterに任せます。持続的な同時アクセスの下でサービスがどう振る舞うか、どこでレイテンシが悪化するか、何が最初に壊れるか。それこそがJMeterの用途であり、ここでJMeterを置き換えることを勧めているわけではありません。
機能的な正しさの検証は、セッション、取得した値、実行順序、クリーンアップを、自分で組み立てる要素ではなく製品の一部として扱う場所へ移します。この4つについては APIテストのドキュメントで説明しています。
それでもJMeterでやっておく価値があること
負荷テストのプランには、一部のリクエストだけでもボディのアサーションを追加してください。ステータスコードしか確認しない負荷テストは、サービスが空の結果を返していても成功として報告します。速くて間違っているという結果は、誰も調査しないため最悪の事態です。
機能テストの層を用意する
ターミナル
npm install -g @testsprite/testsprite-cli
testsprite setup
ローカルにインストールしたくない場合は、ダッシュボードでも同じことができます。コマンドの全体像は CLIリポジトリにまとまっています。
.jmxの問題を率直に言えば
JMeterでの機能カバレッジが時間とともに劣化していく原因は、アサーションではなくファイル形式にあります。その理由を具体的に述べておく価値があります。
テストプランは、GUIが生成したXMLです。アサーションを1つ変更してプルリクエストを出すと、並び順の変わった要素と自動生成された識別子だらけの差分になり、レビューは信頼に頼る作業になります。同じプランを1週間のうちに2人が編集すれば、中身を読んで解決するよりも片方を捨てたほうが早いマージコンフリクトが発生します。そしてレビューが現実的でないため、プランには誰も目を通していない変更が積み上がっていきます。
これは実在するコストですが、1人がプランを所有しているうちは見えません。そして、ほとんどのJMeterスイートはまさにその条件のもとで作られています。
実行サイクルの違い
負荷テストはリリース前とアーキテクチャ変更後に。正しさの検証はプルリクエストごとに実行します。リグレッションの修正コストが最も安いのは、その時点だからです。
GitHub App は、TestSpriteのダッシュボードで設定するWebhookです。パイプラインがすでに発行しているデプロイイベントを受け取るため、リポジトリ側は何も変わりません。
GitHub Actions は、ターミナルから設定し、このステップを自分のワークフローの中に組み込みます。
TestSpriteが負荷テストのプランから引き受けるもの
JMeterがすでにそこにあったという理由でJMeterに置かれることになった、機能カバレッジです。テストプランは探索フェーズと仕様をもとに生成され、要素を組み立てるのではなく平易な言葉で記述され、生成されたXMLに埋もれることなくプルリクエスト上でレビューできます。
Auto-Authenticationは実行中ずっとセッションを維持し、Dynamic Variablesは呼び出し間で値を引き継ぎ、Dependency Chainsは各ケースが必要とするものと生成するものから実行順序を導き出し、Auto-Cleanupはその実行が作成したものだけを削除します。いずれも、現在はエクストラクター、変数、コントローラー、tearDownスレッドグループから自分で組み立てている部分です。
負荷テストのプランはそのままで、JMeterが本当に得意とすることを続けます。得られるのは、正しさの検証がリリース前ではなくプルリクエストごとに走ること、そしてアサーションの変更を別の人が読めるようになることです。
JMeterで機能的なAPIテストはできますか？
できますが、使い勝手は味方してくれません。XMLのプラン、浅いデフォルトのアサーション、手作業の状態管理がその代償です。
JMeterは置き換えるべきですか？
負荷テストについては、その必要はありません。成り行きでJMeterに入り込んだ機能カバレッジだけを移し、負荷テストのプランは残してください。
TaurusやJMeter DSLはどうですか？
どちらもテスト作成の体験を大きく改善します。ただし、このツールが何に最適化されているかは変わりません。
CIで両方を実行できますか？
できます。両者は異なるサイクルで異なる問いに答えるものであり、互いの存在を知る必要はありません。
TestSpriteは負荷を生成しますか？
いいえ。TestSpriteは境界値のケースも含めて正しさを検証します。持続的な同時アクセスはJMeterの領域です。