負荷テストツールの分類
スクリプト中心型。 シナリオをコードで記述し、ローカルまたは分散環境で実行します。柔軟でレビューしやすく、保守は自分たちの手に委ねられます。
テストプラン型。 UI 上でシナリオを組み立て、プロジェクトファイルとして保存します。対応プロトコルは幅広い一方、プルリクエスト上でのレビューには向きません。
ホスト型。 複数のリージョンからの負荷生成を他社に任せる方式です。維持すべきインフラはなく、実行ごとの課金となります。
多くのチームにとっては、どれを選ぶかよりも、そのテストが意味のあるものを測定しているかどうかのほうが重要です。
負荷テストを始める前の3つの確認
毎秒1リクエストでも正しく動作していますか。 壊れたエンドポイントに負荷をかけても、どれだけ速く誤った結果を返せるかを測るだけです。これは、パフォーマンス改善において最もよくある四半期の浪費です。
実行後に後始末が行われますか。 レコードを作成したまま放置する負荷テストは、次回の実行結果を変えてしまい、その環境上の他のすべてにも影響します。
環境は本番を代表するものになっていますか。 データ量が10分の1しかない環境で得られる結果は、単なる数値であって予測ではありません。
ほとんど誰も有効にしない設定
少なくとも一部のリクエストについては、レスポンスボディをアサーションの対象にしてください。多くの負荷テストツールがこれをサポートしていますが、負荷生成側のスループットを落とすため、大半のチームは無効のままにしています。その結果、すべてのレスポンスが空のリストを返していても、負荷テストのレポートはきれいなグリーンのままになります。
速くて誤っている状態は、遅くても正しい状態より悪いものです。誰もそれを調べようとしないからです。
価値を決めるのはシナリオです
多くのチームは負荷テストツールの選定に長い時間をかける一方、シナリオにはほとんど時間をかけません。これは順序が逆です。その数値に意味があるかどうかを決めるのは、シナリオだからです。
1,000人の仮想ユーザーが単一のエンドポイントを叩き続けるテストは、作るのは簡単ですが、現実の何かに似ていることはめったにありません。実際のトラフィックは混在しています。大半は読み取り、わずかな書き込み、ときおり走るコストの高いレポート処理があり、そのすべてが、すでに1年分の履歴を抱えたデータセットに対して行われます。人工的なシナリオは余裕でさばけるシステムが、現実に近いシナリオでは倒れることがあります。競合が起きるのは、単純なシナリオが一度も触れていない場所だからです。
実際のトラフィックに似た混在パターンを組み立てる作業は、ログを眺める半日ほどで済み、比較検討しているツール間のどんな機能差よりも価値があります。
機能検証が果たす役割
自動生成される API テストプランには境界値やストレスに近いケースが含まれ、構造的な理由でエンドポイントを遅くする入力の組み合わせを浮かび上がらせます。ページサイズを大きくすると劣化するクエリは、キャパシティテストが見つけるよりはるかに早く、しかもごくわずかなコストでここに現れます。
これは負荷テストではありませんし、負荷テストの代わりにもなりません。その下にある安価な層であり、多くのチームが負荷生成ツールを購入する途上で飛ばしてしまう層です。
ターミナル
npm install -g @testsprite/testsprite-cli
testsprite setup
何もインストールしたくない場合は、ダッシュボードでも同じことができます。コマンドラインでできるその他のすべては、 CLI リポジトリにあります。
詳しい仕組みは、 API テストのドキュメントに記載されています。
実施頻度
負荷テストはリリース前とアーキテクチャ変更後に実施します。正しさの検証はプルリクエストごとに行います。そのタイミングであれば、リグレッションの修正コストが最も低く済むからです。
GitHub App は、TestSprite のダッシュボードで設定する webhook です。パイプラインがすでに発行しているデプロイイベントを監視するため、リポジトリ側は何も変わりません。
GitHub Actions は、ターミナルから設定し、自分たちのワークフローの中にステップとして組み込みます。
負荷テストの前に TestSprite がカバーする範囲
このページで挙げた3つの確認を、製品として提供します。毎秒1リクエストでの正しさは、ステータスコードではなくレスポンスボディを検証する自動生成のカバレッジで確認します。後始末については、Auto-Cleanup が名前による照合ではなく、その実行が作成したものだけを正確に削除します。そして構造的な遅さを明らかにする境界値ケースは、キャパシティテストが到達するよりはるかに早い段階でここに現れます。
カバレッジは、API Discovery と手元の仕様書をもとに生成されます。Auto-Authentication がセッションを維持し、Dynamic Variables が呼び出し間で値を受け渡し、Dependency Chains が安全な実行順序を導き出します。
負荷生成ツールは今のままで構いません。得られるのは、そのツールが出す数値が、正しい結果を返すサービスについてのものになるということです。これこそが、意味のある計測と、何も表していない自信満々の数値との違いです。
TestSprite は負荷を生成しますか。
いいえ。境界値ケースを含めて、正しさを検証します。継続的な同時アクセスには、専用の負荷生成ツールが必要です。
どの負荷テストツールを選ぶべきですか。
チームが実際に保守し続けられるものを選んでください。主要な選択肢の間の違いよりも、シナリオに意味があるかどうかのほうが重要です。
負荷テストはどのくらいの頻度で実施すべきですか。
リリース前とアーキテクチャ変更後です。負荷テストを常時実行するのはコストが高く、その間に新しい発見が得られることはめったにありません。
CI で負荷テストを実行できますか。
スモークテスト程度の確認であれば可能です。CI で本格的なキャパシティテストを行おうとすると、負荷レベルが無意味になるか、パイプラインが極端に遅くなるかのどちらかになります。
最もよくある失敗は何ですか。
正しさを確認する前に負荷テストを行うことです。空の結果を返しているエンドポイントについて自信たっぷりのスループット値を出すのは、数値がまったくないよりも悪い状態です。