performance-testing-strategy

パフォーマンステスト戦略の設計

対象を絞った質問でコンテキストを収集し、業界のベストプラクティスを適用して、完全で構造化されたパフォーマンステスト戦略を設計できるよう、QA エンジニアをガイドします。

重要： 出力を作成する前に、必ず最初にコンテキストを収集してください（ステップ 1）。システムとその制約を理解せずに、推奨事項を提示してはいけません。

出力形式

ステップ 1 の完了後、次のセクションを含む戦略ドキュメントを提示します。

1. テスト対象システム（SUT）の概要 — アプリケーションについて把握した内容
2. 推奨するテストの順序 — 実施するテストの種類とその順序、および根拠
3. テストごとの定義 — 各種類について、目標、ユーザー負荷、実行時間、ランプアップ、成功基準
4. 収集するメトリクス — 応答時間、スループット、エラー率、インフラストラクチャのメトリクス
5. リスクと前提条件 — テスト開始前に整えておく必要があるもの

---

ステップ 1 — コンテキストを収集する

まだ把握していないことだけを尋ねてください。次のカテゴリに沿って進め、戦略の設計に必要な情報が集まった時点で終了します。すべての質問を一度に尋ねないでください。自然なまとまりごとに質問し、回答を待ってから続けてください。

A. アプリケーションの概要

• どのような種類のアプリケーションですか？（Web アプリ、モバイルバックエンド、マイクロサービス、バッチジョブ、ストリーミングパイプライン）
• どのプロトコルを使用していますか？（HTTP/REST、GraphQL、WebSocket、gRPC、メッセージキュー）
• ステートフル（セッション、認証トークン）ですか、それともステートレスですか？
• 外部依存関係はありますか？（サードパーティ API、データベース、キャッシュ、メッセージブローカー）
• インフラストラクチャは自動スケールしますか、それとも容量は固定されていますか？

B. トラフィックと使用パターン

• 現在または想定されるピーク負荷はどの程度ですか？（リクエスト数／秒、同時ユーザー数、1 日あたりのトランザクション数）
• トラフィックは安定していますか（例：社内ツール）、それとも急増しますか（例：フラッシュセール、マーケティングキャンペーン、スケジュールされたバッチ処理）？
• 既知のピーク時間帯はありますか？（時刻、曜日、季節イベント）
• 一般的なユーザーフローはどのようなものですか？（単一のエンドポイントではなく、一連の操作）

C. SLA と受け入れ基準

• 応答時間の目標はありますか？（例：p95 < 1s、p99 < 2s）
• スループットの目標はありますか？（例：500 RPS を処理できること）
• 許容できるエラー率はどの程度ですか？（例：負荷時のエラーが < 0.1%）
• SLA はエンドポイントごと、全体、またはその両方で定義されていますか？

D. 環境と制約

• テストはどの環境で実施しますか？（本番クローン、ステージング、専用のパフォーマンステスト環境）
• 環境は本番トラフィックから分離されていますか？
• データに関する制約はありますか？（テストユーザー、サニタイズ済みデータ、データ量）
• 把握しておくべきインフラストラクチャの制限はありますか？（共有 DB、レートリミッター、WAF、CDN）
• 利用可能なテスト時間はどれくらいですか？（テスト実施に使える時間または日数）

E. 範囲と目標

• 今回はパフォーマンステストの初回実施ですか、それともリリース前の回帰テストですか？
• 背景にある特定の懸念やリスクはありますか？（新機能、ピークイベントへの備え、インシデントの事後分析、キャパシティプランニング）
• 使用する負荷テストツールは何ですか？（提案はせずに尋ねてください。戦略はツールに依存しません）

---

ステップ 2 — テストの種類を選択する

提示された目標とリスクに合致するテストの種類だけを推奨してください。デフォルトで 5 種類すべてを推奨してはいけません。収集したコンテキストに基づき、それぞれの理由を説明してください。

ユーザーが各テストの種類について詳細な定義、パラメーター、判断基準を必要としている場合は、references/TEST-TYPES.md を読み込んでください。

すばやい選択ガイド

状況	推奨テスト
初めてのテストで、ベースラインがない	スモーク → 負荷
リリース前のリグレッションチェック	スモーク → 負荷
リスクの低い社内ツール（ユーザー数 ≤ 50、外部 SLA なし）	スモーク → 負荷のみ — ここで止め、ストレステストやスパイクテストは追加しないでください
ピークイベント（Black Friday、ローンチ）に備える	スモーク → 負荷 → スパイク
継続的なトラフィック下での遅延を調査する	スモーク → 負荷 → 耐久
システムの限界点を見つける	スモーク → 負荷 → ストレス
本番品質のシステム向けの完全な戦略	スモーク → 負荷 → ストレス → スパイク → 耐久
時間に制約がある（4 時間未満）	スモーク → 負荷のみ

順序のルール

必ず最初にスモークテストを実行してください。 いきなりストレステストやスパイクテストを実行してはいけません。ベースラインに問題があると時間を無駄にし、誤解を招く結果につながります。

---

ステップ 3 — 各テストを定義する

推奨されるテストタイプごとに、具体的な定義を作成します。以下のテンプレートを使用してください。負荷は ユーザー数または RPS で表現し、ツール固有の構文は使用しないでください。

スモークテスト

Goal:          Verify the test setup works and the system handles minimal load
Users:         2–5 virtual users
Duration:      2–5 minutes
Ramp-up:       None (inject all users at once) or 30 seconds
Success:       0 errors, all responses within 2× the SLA threshold
When to skip:  Never — always run smoke first

負荷テスト

Goal:          Measure behavior under expected production load
Users:         Peak load × 1.0 (baseline) and peak load × 1.2 (safety buffer)
Duration:      30–60 minutes of steady state (after ramp-up)
Ramp-up:       10–20% of total duration (e.g., 10 min ramp for a 60 min test)
Success:       Error rate < 0.1%, p95 within SLA, p99 within 2× SLA
When to skip:  Only if a load test was run recently with no system changes

ストレステスト

Goal:          Find the maximum load before degradation or failure
Users:         Start at peak load; increase by 20–25% each step until breaking point
Duration:      Until failure or throughput plateaus — typically 30–90 minutes
Ramp-up:       Staircase: add load increments every 5–10 minutes
Success:       Identify the breaking point; confirm graceful degradation and recovery
When to skip:  When the only goal is SLA validation (not capacity exploration)

スパイクテスト

Goal:          Verify behavior during sudden, large traffic bursts
Users:         Baseline load → sudden jump to 2–5× peak → return to baseline
Duration:      10–20 minutes total (the spike itself: 2–5 minutes)
Ramp-up:       Instantaneous spike; gradual recovery back to baseline
Success:       System survives without crashing; recovers to baseline SLA within a defined window
When to skip:  When traffic is inherently steady with no burst patterns

耐久／ソークテスト

Goal:          Detect issues that only appear over time: memory leaks, connection exhaustion, resource drift
Users:         70–80% of peak load (sustainable, not maximum)
Duration:      2 hours minimum; 8–24 hours for critical or long-running systems
Ramp-up:       Standard ramp (10–15 min)
Success:       Response times and error rates at the end are within 10% of values at the start of steady state
When to skip:  Short-term regression only — note the risk and schedule a soak test later

---

ステップ 4 — メトリクスを定義する

ユーザーが収集するメトリクス、SLA しきい値の設定方法、またはインフラ側での監視対象について尋ねた場合は、Load を参照してください。

すべてのテストで最低限必要なメトリクス

アプリケーションレベル（負荷テストツールで収集）：

• 応答時間：p50、p90、p95、p99 — 平均値だけに頼ってはいけません
• スループット：1 秒あたりのリクエスト数またはトランザクション数
• エラー率：失敗したリクエストの割合（タイムアウト + エラーレスポンス）
• 時間経過に伴う同時ユーザー数／アクティブセッション数

インフラレベル（監視を通じて収集 — APM、メトリクスプラットフォーム、クラウドダッシュボード）：

• CPU 使用率（70% を継続的に超える場合は調査してください）
• メモリ使用率（耐久テスト中の上昇傾向に注意してください）
• ネットワーク I/O（飽和している場合は、アプリケーションではなくインフラがボトルネックであることを示します）
• データベース：コネクションプールの使用状況、低速クエリの割合、ロック待ち
• ランタイム固有（該当する場合）：ヒープ使用量、ガベージコレクションの頻度と停止時間

指示： すべてのメトリクスは汎用的な表現にしてください。ランタイム固有のフラグ、API 呼び出し、プラットフォーム固有の名称は含めないでください。-XX:+HeapDumpOnOutOfMemoryError、process.on()、HeapInuse、またはいずれかの言語／ランタイム構文ではなく、「ヒープ使用量」と「GC 停止時間」を使用してください。ステップ 4 と 5 を通じて、戦略はツールに依存しないものにしてください。

---

ステップ 5 — 前提条件チェックリスト

テストを実行する前に、以下を確認してください。

• テスト環境が分離されている — テストトラフィックが実ユーザーや本番データに影響しない
• テストデータが準備されている — ユーザー、商品、注文、またはドメインエンティティが現実的な量で用意されている
• データ戦略が定義されている — テストデータを循環、ランダム化、または実行ごとに一意にする方法が決まっている
• 監視が有効になっている — テスト開始前にメトリクス収集が実行されている
• ベースラインメトリクスがある — 最低限、比較対象となるスモークテストの結果がある
• チームが対応可能である — 必要に応じてテストを監視し、停止できる人がいる
• ロールバック計画がある — データ破損やサービス中断を引き起こす可能性のあるテストに備えている
• サードパーティサービスがスタブ化またはレート制限されている — 実際の料金が発生したり、パートナーの利用枠を超過したりしないようにする
• レート制限機能／WAF がテスト用に設定されている — またはテスト環境ではバイパスされている
• アラートが抑制されている — 意図的なストレステストやスパイクテスト中のオンコール通知を避ける

---

よくある戦略上の誤り

1. 負荷テストの前にストレステストを始める

負荷テストのベースラインなしでストレステストを実行すると、「500 ユーザーでシステムが停止する」のか、「100 ユーザーの時点ですでにシステムが停止していた」のかを区別できません。

2. 分離せずに本番環境でテストする

読み取り専用の負荷テストでも、本番環境のインシデントを引き起こす可能性があります（DB の CPU 使用率急上昇、キャッシュの追い出し、レート制限の発動）。必ず分離された環境を使用してください。

3. 現実的でないユーザーフローを使用する

単一のエンドポイント（例：ヘルスチェック）のみをテストしても、実際のユーザー行動は何もわかりません。分析データやビジネス要件に基づいて、主要なユーザージャーニーを2～3個モデル化してください。

4. リクエスト間の思考時間を無視する

リクエスト間の思考時間をゼロにすると、実際のユーザーが発生させる負荷の10～100倍になります。すべてのシナリオに、実際のユーザー行動を反映した現実的な一時停止を含めてください。

5. インフラストラクチャの監視をしない

応答時間がわかっていても、CPU／メモリ／DBの状態がわからなければ、システムの性能が低下した理由を診断できません。負荷テストと並行して、必ずインフラストラクチャを監視してください。

6. 耐久テストが短すぎる

5分間のソークテストでは、何も見つかりません。メモリリークや接続の枯渇は通常、30～120分間負荷を継続した後に現れます。実用上の最低限のソークテスト時間は2時間です。

7. テスト結果を絶対的な真実として扱う

結果が有効なのは、テストした環境、データ量、構成に限られます。結果と併せてこれらの条件を必ず記録してください。たとえば、本番データの10％を使用したステージング環境でのテストは、本番環境の処理能力を測るテストではありません。

8. 不適切なワークロードモデルをテストする

同時ユーザー数と到着率（RPS）は同じものではありません。システムのテストに、固定数の同時ユーザー（クローズドモデル）を使うべきか、新規リクエストの固定到着率（オープンモデル）を使うべきかを理解してください。誤ったモデルを使用すると、スループットの数値が誤解を招くものになります。

---

参考資料

• テストの種類 — 詳細なパラメーターと判断基準
• メトリクス、SLA、監視ガイド