パフォーマンス テストの初心者ガイド: 負荷テストからストレス テストまでの完全なチュートリアル
パフォーマンス テストを開始するための完全ガイド - 負荷テスト、ストレス テスト、ソーク テストをカバーし、3 つの主要なツールである JMeter、k6、および Locust の実際の使用法を紹介し、オンラインの安定性を確保するためにシステムのボトルネックを最初から特定する方法を学びます。
最後更新：2026-03-16
この記事では、パフォーマンス テストの入門ガイドを提供します。実際のツールの選択とテスト戦略は、プロジェクトのニーズに基づいて調整する必要があります。
目錄
1. パフォーマンステストが必要な理由
機能が正しくても、システムが実際のトラフィックを処理できることを意味するものではありません。電子商取引のプロモーション中に、Web サイトがハングアップし、イベント ページが開くのが非常に遅くなり、API 応答がタイムアウトになります。これらはすべてパフォーマンスの問題です。パフォーマンス テストの目的は、オンラインにする前にシステムの限界とボトルネックを見つけて、実際のユーザーの前で転倒することを避けることです。一般的なパフォーマンスの問題には、データベース クエリの遅さ、メモリ リーク、接続プールの枯渇、キャッシュ ヒット率の低さ、全体的なパフォーマンスを低下させるサードパーティ API 応答の遅さなどがあります。
2. 4種類の性能試験
予想される通常トラフィックとピークトラフィックをシミュレートして、システムがターゲット負荷の下で適切に動作できることを検証します。例: システムには同時に 1,000 人のユーザーが存在すると予想されており、テスト シナリオは 1,000 人の仮想ユーザーです。システム容量を超えて負荷を徐々に増加させ、過負荷になったときにシステムがどのように動作するかを観察します。焦点は「それに耐えられるかどうか」ではなく、「過負荷がかかったときに直接クラッシュするのではなく、穏やかに劣化するかどうか」にあります。通常の負荷で数時間、場合によっては数日間実行して、メモリ リークや接続プールの枯渇などの長期的な問題を検出します。マーケティング キャンペーンにより多数のユーザーが瞬時に流入し始める場合など、トラフィックの突然の急増をシミュレートします。システムが迅速に拡張でき、トラフィックが減少した後に通常に戻ることができるかどうかをテストします。
3. パフォーマンステストの重要な指標
パフォーマンス テストを実行するときは、次の主要な指標に焦点を当てる必要があります。
-
応答時間
P50 (中央値)、P95、P99 分位数。 P99 は平均よりも優れた実際のユーザー エクスペリエンスを反映しています
-
スループット
1 秒あたりのリクエスト数 (RPS)。システムの処理能力を表します
-
エラー率
失敗したリクエストの割合。負荷が増加してもエラー率が急激に増加しないようにする必要があります
-
同時ユーザー数
同時にオンラインになるユーザーの数
-
リソースの使用量
CPU、メモリ、ディスク I/O、ネットワーク帯域幅の使用状況
4. 3 つの主要なパフォーマンス テスト ツールの比較
最も古い歴史と最大のコミュニティを持つ Apache Foundation のオープンソース ツール: Grafana Labs によって保守され、JavaScript を使用してテスト スクリプトを作成する最新のパフォーマンス テスト ツール: Python で作成され、Python を使用してユーザーの動作を定義するパフォーマンス テスト フレームワーク:
-
アドバンテージ
GUI 操作は直感的でプラグインが豊富で、複数のプロトコル (HTTP、FTP、JDBC、SOAP) をサポートしています。
-
欠点がある
Java での記述はリソースを消費し、スクリプトの保守コストが高くつくため、バージョン管理には適していません。
-
適切な
入門学習、GUI 操作が必要、非エンジニアリングのバックグラウンドによる QA
-
アドバンテージ
スクリプトは JS で書かれており、読みやすく保守しやすく、CLI の実行は CI/CD に適しており、リソースの消費量も低くなります。
-
欠点がある
HTTP/WebSocket/gRPC のみをサポートし、GUI 記録はサポートしません
-
適切な
最新の Web API テスト、CI/CD 統合、プログラミングの経験を持つ QA
-
アドバンテージ
豊富な Python エコシステム、簡単な分散実行、Web UI を介したリアルタイム監視
-
欠点がある
Python GIL はスタンドアロンのパフォーマンスを制限し、Python の知識が必要です
-
適切な
Python テクノロジー スタック チームは複雑なユーザー行動シミュレーションを必要としています
5. 性能試験の実践的な流れ
テストを開始する前に、チームとパフォーマンス目標を確認します。パフォーマンス テストは、実稼働環境とできる限り似た環境で実行する必要があります。主な考慮事項: 実際のユーザーの行動に基づいてテスト シナリオを設計します: テストの実行時にシステム リソースを同期的に監視します: テストが完了したら、結果を分析してレポートを生成します:
-
ホームページの読み込み時間は2秒以内にしてください（P95）
ホームページの読み込み時間は2秒以内にしてください（P95）
-
APIの応答時間は200ms以内であること（P99）
APIの応答時間は200ms以内であること（P99）
-
システムは 5000 人の同時ユーザーをサポートする必要があります
システムは 5000 人の同時ユーザーをサポートする必要があります
-
エラー率は0.1%未満でなければなりません
エラー率は0.1%未満でなければなりません
-
ハードウェア仕様は実稼働環境と一致している必要があります (または縮小して変換したもの)。
ハードウェア仕様は実稼働環境と一致している必要があります (または縮小して変換したもの)。
-
データベースには実際のレベルに近いテストデータが必要です
データベースには実際のレベルに近いテストデータが必要です
-
結果への影響を避けるために、不要なモニタリングとログをオフにします。
結果への影響を避けるために、不要なモニタリングとログをオフにします。
-
実稼働環境でのトラフィック パターン (どの API が最も頻繁に呼び出されるか) を分析する
実稼働環境でのトラフィック パターン (どの API が最も頻繁に呼び出されるか) を分析する
-
ユーザーの行動パスを定義します (ホームページの閲覧 → 検索 → 製品の表示 → ショッピング カートに追加)
ユーザーの行動パスを定義します (ホームページの閲覧 → 検索 → 製品の表示 → ショッピング カートに追加)
-
適切な思考時間 (ユーザーがページに滞在する時間) を設定します。
適切な思考時間 (ユーザーがページに滞在する時間) を設定します。
-
テストデータの準備（異なるアカウント、異なる製品）
テストデータの準備（異なるアカウント、異なる製品）
-
Grafana + Prometheus を使用してサーバー メトリクスを監視する
Grafana + Prometheus を使用してサーバー メトリクスを監視する
-
データベースの遅いクエリのログを観察する
データベースの遅いクエリのログを観察する
-
アプリケーションログにエラーを記録する
アプリケーションログにエラーを記録する
-
ガベージ コレクション (GC) の頻度と一時停止時間に注意する
ガベージ コレクション (GC) の頻度と一時停止時間に注意する
-
実際のデータをパフォーマンス目標と比較する
実際のデータをパフォーマンス目標と比較する
-
ボトルネックを見つける (CPU、メモリ、データベース、ネットワークのいずれか)
ボトルネックを見つける (CPU、メモリ、データベース、ネットワークのいずれか)
-
具体的な最適化の提案と優先順位を提供する
具体的な最適化の提案と優先順位を提供する
-
後続の回帰比較の基礎としてベースライン データを記録します。
後続の回帰比較の基礎としてベースライン データを記録します。
6. 一般的なパフォーマンスのボトルネックと解決策
以下は、パフォーマンス テストで最も一般的に発生するボトルネックとそれに対応する解決策です。
-
データベースクエリが遅い
インデックスの追加、クエリの最適化、キャッシュの使用
-
メモリリーク
プロファイラーを使用してリークを見つけ、未リリースのリソースをチェックする
-
接続プールが枯渇した
接続プールのサイズを調整し、接続が正しく返されるかどうかを確認します
-
CPU がフルロードされている
CPU 負荷の高い操作を特定し、非同期処理または水平スケーリングを検討する
7. よくある質問
機能が安定してからオンラインにする前に、完全なパフォーマンス テストを実行することをお勧めします。ただし、より良いアプローチは、軽量のパフォーマンス テスト (API 応答時間のしきい値など) を CI/CD に追加し、デプロイメントごとにパフォーマンスの低下を自動的にチェックすることです。できる。 k6 と Locust はどちらも 1 台のマシンで基本的な負荷テストを実行できます。重要なのは、小さなことから始めて結果の分析を学び、徐々にテストの複雑さを増していくことです。パフォーマンス テストの結果にばらつきがあるのは正常です。最初のウォームアップの影響を排除するために、各シーンを少なくとも 3 回実行し、平均値を取ることをお勧めします。また、テスト中に他のプログラムがリソースを競合していないことを確認してください。
相關懶人包
2026年のQAトレンド： AIテスト、左シフト、新しいキャリアの方向性
AIアシストテスト、左シフト戦略、QAエンジニアのキャリア移行など、QAの最新トレンドをご覧ください。
API 測試入門：用 Postman 和 pytest 打造你的第一個 API 測試
API 測試是現代 QA 必備技能。從 HTTP 基礎概念到實際用 Postman 和 pytest 寫測試，帶你踏出 API 測試的第一步。
CI/CD でのテスト戦略: すべてのデプロイメントの品質を確保
CI/CD パイプラインでのテスト戦略を計画する方法、コミットからデプロイまでの各段階でどのようなテストを実行する必要があるか、品質レベルを設定する方法を共有します。
一般聲明
本站提供之資訊僅供參考，不保證其完整性與正確性。使用者應自行判斷資訊之適用性。