動くソフトウェアと、負荷がかかった状態で動くソフトウェアは同じではありません。機能はすべての機能テストに合格し、クリーンな状態で出荷されても、実際のトラフィックが初めて到達したときに破綻することがあります。パフォーマンス テストは、このギャップを埋めるための規律です。システムがアイドル状態のときに正しいかどうかだけでなく、ビジー状態のときにどのように動作するかを測定します。
このガイドでは、パフォーマンス テストとは何か、その主な種類、結果を定義するメトリクス、そしてそれが現代のテスト プロセスにどのように適合するかを説明します。
パフォーマンス テストとは何か
パフォーマンス テストは、定義されたワークロードの下でのシステムの速度、安定性、スケーラビリティを評価します。それは「この機能は動作するか？」とは問いません。それは「どれくらい速いか、どれくらいの負荷に耐えられるか、そして十分な負荷がかかったときにどうなるか？」と問います。
この区別は重要です。機能テストとパフォーマンス テストは異なる質問に答え、異なるバグを検出します。ログイン エンドポイントは、毎回正しいトークンを返すことができても、負荷がかかると実行に4秒かかることがあります。機能テストは合格しますが、ユーザーは離れていきます。パフォーマンス テストは、その2番目の問題を浮上させるものです。
パフォーマンス テストの出力は、単純な合否ではありません。それはプロファイルです。この負荷では、システムはこの速さで応答し、このスループットを維持し、このポイントを超えてプッシュされるとこのように失敗します。このプロファイルによって、チームはキャパシティを計画し、現実的なサービス レベルを設定し、リリース前にリグレッションを検出することができます。
パフォーマンス テストの主な種類
パフォーマンス テストは、それぞれ異なる質問に答えるために異なる形状で負荷を適用するテストタイプの集合です。
ベースライン テストは、通常かつ想定される負荷の下でシステムを実行し、その結果を記録します。このベースラインは、後のすべてのテストが比較する参照点となります。それがなければ、数値が良いのか、悪いのか、あるいは単に異なるのかを判断することはできません。
ロード テストは、想定されるピーク トラフィックを適用し、システムが持ちこたえることを確認します。応答時間は予算内に収まり、エラーはほぼゼロに保たれます。それは、システムが通常の忙しい一日を乗り切れることを検証します。
ストレステストは、意図的にキャパシティを超過させ、システムが劣化または停止するまで負荷を上げていきます。目標は、限界点を見つけ、障害モードを観察することです。緩やかな劣化（遅くなるがサービスは継続）は許容されますが、データ損失や連鎖的なエラーは許容されません。
スパイク テストは、負荷が突然急増し、再び減少する状況を適用します。これは、フラッシュセール、ニュースイベント、その他のバースト的な負荷をモデル化します。安定したトラフィック向けに調整されたシステムでも、十分な速さでスケールできないために、スパイクに対応できないことがあります。
キャパシティ テストは、システムが目標を達成しながら処理できる最大負荷を見つけます。その答えは具体的な数値であり、キャパシティ プランニングやオートスケーリングの閾値に直接使用されます。
ソーク テスト（安定性テストまたは耐久性テストとも呼ばれる）は、中程度の負荷を長期間にわたって保持し、メモリ リーク、リソース枯渇、徐々の速度低下といったゆっくりとした障害を顕在化させます。これらは短時間の実行では見えませんが、数時間かけて初めて現れます。
ほとんどのチームは、ベースライン、ロード、ソーク テストを標準として実行し、トラフィックが多い、または予測できないシステムに対しては、ストレステストとスパイク テストを追加します。
結果を定義するメトリクス
パフォーマンス テストは、そこから読み取るメトリクスと同じくらいしか有用ではありません。
応答時間は、リクエストから応答までの期間です。常に分布として読み取ってください。平均は誤解を招きます。健全な平均値が、10倍も悪い99パーセンタイル値を隠していることがあります。実際のユーザーが気づき、不満を訴えるのは、遅いテール（応答の遅い部分）です。
スループットは、単位時間あたりに完了する作業量であり、多くの場合1秒あたりのリクエスト数です。これは、合計リクエスト数をテスト期間で割って計算され、システムの真のキャパシティを表します。
同時実行性（コンカレンシー）は、同時ユーザーまたは接続の数です。システム容量は、応答時間が許容可能な閾値を超える同時実行レベルとして頻繁に示されます。
エラー率は、負荷の下で失敗するリクエストの割合です。高速を維持しながらも高同時実行性でリクエストが失敗し始めるシステムは合格とは言えません。信頼性のない速度はパフォーマンスではありません。
CPUとメモリ使用率は、他の数値が変動する理由を説明します。CPUが100%に張り付いている間にレイテンシーが上昇する場合、システムは計算能力がボトルネックになっています（compute-bound）。CPUがアイドル状態のままレイテンシーが上昇する場合、ボトルネックはダウンストリーム、通常はデータベース、ロック、または外部依存関係にあります。
完全な結果は一つの文のように読めます。この同時実行性において、スループットはここでピークに達し、95パーセンタイル応答時間はこうで、エラー率はこれで、サーバーはこのリソースに依存していました。
プロセスにおけるパフォーマンス テストの位置付け
パフォーマンス テストは、かつてプロジェクトの終盤近くにある単一のゲートであり、専門チームによってローンチ前に一度だけ実行されていました。このモデルは、継続的にリリースされるシステムには当てはまりません。なぜなら、ほとんどすべての変更でパフォーマンスが劣化するからです。新しいクエリ、追加された統合、インデックスのないカラムなど、それぞれが静かにレイテンシーを追加し、機能テストでは検出できません。
より良いモデルは、パフォーマンスを正しさと同じように扱います。つまり、予算を持って継続的にチェックされます。クリティカル パスに対して、応答時間とエラー率の予算を定義します。CI/CDで軽量なロード テストを実行し、プル リクエストの段階でリグレッションによってビルドが失敗するようにします。重いストレステストとソーク テストは、長い実行時間が許容されるスケジュールされたリリース前テストのために予約します。
ほとんどのシステムにおいて、パフォーマンス テストの最も価値の高い場所はAPIレイヤーです。APIはコアロジックを運び、呼び出しが高速で決定論的であり、不安定なUIと戦う必要がありません。負荷の下でAPIをテストすることで、信頼性の高い数値を安価に得られます。APIパフォーマンス テストでは、その集中的なアプローチを詳細に説明しています。機能的なAPIテストの隣にパフォーマンス テストを置くことで、すべての変更が正しさと速度の両方について同時にチェックされることになります。
よくあるパフォーマンス テストの誤り
パフォーマンス テストは、自信満々で間違った答えを出す方法で実行されがちです。いくつかの誤りは何度も繰り返されます。
非現実的なインフラでのテスト。 開発者のラップトップ上でのロード テストや、本番環境のリソースのごく一部しかないステージング環境でのテストは、意味のない数値を生成します。本番環境にできるだけ近いインフラでテストしてください。
ウォームアップ効果の無視。 多くのシステムは、キャッシュが満たされ、コネクション プールが開くまでの最初の数秒間は動作が遅くなります。コールドスタートと定常状態を一緒に測定すると、誤解を招く平均値が生成されます。ウォームアップ期間を破棄するか、個別に報告してください。
パーセンタイルではなく平均値を読むこと。 この間違いは非常に一般的であるため、繰り返す価値があります。平均応答時間が200ミリ秒であっても、99パーセンタイル値が3秒である可能性を隠していることがあります。平均値は誰も実際には行わないリクエストを表し、パーセンタイル値は実際のユーザーを表します。
非現実的なデータの使用。 すべてのリクエストを同じユーザーIDまたは同じ製品でテストすると、データベースがすべてをキャッシュから提供することを意味します。実際のトラフィックはデータセット全体に広がり、コールド行やキャッシュミスを発生させます。それに合わせてテスト データを変更してください。
単一のエンドポイントを単独でテストすること。 実際のユーザーはワークフロー（ログイン、閲覧、検索、チェックアウト）を通じて移動します。単一のエンドポイントを集中してテストしても、複数のエンドポイントが同じデータベースやコネクション プールを競合するときに発生する競合を見逃してしまいます。個々の呼び出しだけでなく、現実的な複数ステップのシナリオをテストしてください。
テストを一度きりのものとして扱うこと。 リリース前の単一のパフォーマンス テストは、次の機能が出荷された瞬間に陳腐化します。パフォーマンスは継続的に劣化するため、テストも継続的に実行する必要があります。
これら6つの間違いを避けることが、意思決定に役立つパフォーマンス テストと、安心感を与えるが意味のないグリーンチェックを生成するテストを分けるほとんどの要素です。
Apidogでパフォーマンス テストを実行する
Apidogは、API設計と機能テストに使用する同じワークスペースにロード テストを組み込むため、パフォーマンス チェックに別のツールやAPI定義の別のコピーは必要ありません。
エンドポイントまたは複数ステップのテスト シナリオを選択し、機能的に合格することを確認した後、設定された数の仮想ユーザーで一定期間実行します。Apidogは負荷を徐々に上げ、応答時間のパーセンタイル、スループット、エラー率をリアルタイムで報告するため、パフォーマンスが変化する正確な同時実行レベルを確認できます。単一マシンを超える負荷の場合、シナリオはJMeterにエクスポートされ、同じ定義が維持されます。
同じテスト シナリオが機能テストとパフォーマンス テストの両方に使用されるため、2つのアーティファクトではなく1つのアーティファクトを維持します。既存のエンドポイントをプロファイリングするには、Apidogをダウンロードしてください。
よくある質問
パフォーマンス テストと機能テストの違いは何ですか？ 機能テストは、ソフトウェアが正しい結果を生成するかどうかをチェックします。パフォーマンス テストは、負荷がかかった状態でどれだけ速く、どれだけ確実にそれを行うかをチェックします。両方とも必要であり、どちらか一方がもう一方を置き換えるものではありません。
どのパフォーマンス テストの種類を最初に実行すべきですか？ ベースライン、次にロードです。ベースラインは通常の状態での参照点を提供し、ロード テストはシステムが予期されるピーク トラフィックに耐えられることを確認します。そこからストレステスト、スパイク テスト、ソーク テストを追加します。
平均応答時間の代わりにパーセンタイルを使用する理由は何ですか？ 平均は中央に引きずられ、遅いテールを隠します。95パーセンタイルと99パーセンタイルは、最も運の悪いリクエストが経験する状況を明らかにし、そのテールこそがユーザーが感じるものです。
パフォーマンス テストは自動化できますか？ はい、できます。軽量なロード テストは、変更ごとにCIでうまく実行でき、リグレッション時にビルドを失敗させる定義された予算を設定します。より重いストレステストとソーク テストは、通常、すべてのコミットで実行されるのではなく、スケジュールされて実行されます。
開発サイクルの中でいつパフォーマンス テストを開始すべきですか？ ほとんどのチームが考えているよりも早いです。実際のインフラなしでは最終的なレイテンシー数値を得ることはできませんが、設計段階で予算を設定し、テスト シナリオを作成することはできます。エンドポイントが機能的になり次第、基本的なロード テストを実行することで、修正が安価なうちに問題を発見できます。
パフォーマンス テストの責任者は誰ですか？ 現代のチームでは共有されています。開発者は自身の変更に対して軽量な負荷チェックを実行し、QAはより広範なテスト シナリオと予算を担当し、運用またはSREは本番環境に似たインフラとサーバー側のメトリクスを提供します。それを一人の専門家の仕事として扱うと、パフォーマンスの問題が本番環境に到達することになります。
パフォーマンス テストはどのくらいの期間実行すべきですか？ ウォームアップ期間を過ぎて安定状態に達するのに十分な長さで、通常ロード テストでは数分です。ソーク テストは、短時間の実行では見逃されるゆっくりとした劣化を明らかにするという目的があるため、設計上、数時間から数日間実行されます。