性能試験と負荷試験の違いとは?IT初心者向けに目的・確認項目・テスト方法をわかりやすく解説
結論から言うと、性能試験は「システムが求められる処理速度や処理能力を満たしているか」を確認する試験で、負荷試験は「システムに一定量または大きな負荷をかけたときに、問題なく動作できるか」を確認する試験です。
この2つはIT現場でも混同されやすく、プロジェクトによっては負荷試験を性能試験の一部として扱うこともあります。
新人エンジニアは、「性能試験=性能を確認する大きな枠組み」「負荷試験=負荷をかけて性能や安定性を確認する試験」と理解しておくと整理しやすいでしょう。
- 性能試験と負荷試験の違い
- 性能試験とは
- 負荷試験とは
- 具体例で性能試験と負荷試験の違いを理解する
- 負荷試験と高負荷をかける試験は必ずしも同じではない
- 性能試験・負荷試験はなぜ重要なのか
- 性能試験・負荷試験で重要な「性能要件」
- 負荷試験で確認する場所
- WindowsでCPU・メモリを確認する方法
- PowerShell・CUIで確認できること
- ログとイベントビューアーの確認方法
- 性能が悪い場合の原因切り分け
- 現場でよくあるトラブル例
- 筆者が性能確認で失敗した経験
- 初心者がやりがちなミス
- 性能試験で上司へ報告するポイント
- エスカレーションするタイミング
- 現場で評価される性能試験の進め方
- 性能試験・負荷試験に関連するIT用語
- 性能試験と負荷試験のよくある質問(FAQ)
- まとめ
性能試験と負荷試験の違い
| 項目 | 性能試験 | 負荷試験 |
|---|---|---|
| 主な目的 | 性能要件を満たしているか確認する | 負荷がかかった状態で正常に動作するか確認する |
| 英語 | Performance Test | Load Test |
| 確認例 | 応答時間、処理時間、処理件数 | 同時アクセス時の応答時間、エラー、リソース使用率 |
| 負荷 | 目的に応じて設定する | 想定ユーザー数やアクセス数などを再現する |
| 代表的な指標 | レスポンスタイム、スループット | CPU、メモリ、DB接続数、エラー率など |
ただし、現場によって用語の定義は異なります。「性能試験」と「負荷試験」をほぼ同じ意味で使っているプロジェクトもあるため、用語だけで判断せず、試験計画書に書かれている目的・負荷条件・合格基準を確認することが重要です。
性能試験とは
性能試験とは、システムやアプリケーションがあらかじめ決められた性能要件を満たしているか確認する試験です。
たとえば業務システムの要件に「検索ボタンを押してから3秒以内に結果を表示する」と定められている場合、その条件を満たしているか測定します。
性能試験で確認する代表的な項目
- 画面が表示されるまでの時間
- 検索処理にかかる時間
- ファイルのアップロード・ダウンロード時間
- 一定時間内に処理できる件数
- バッチ処理の完了時間
- CPU使用率
- メモリ使用率
- ディスクI/O
- ネットワーク通信量
- データベースの処理時間
特に重要なのがレスポンスタイムとスループットです。
レスポンスタイムは、操作してから結果が返ってくるまでの時間です。スループットは、一定時間内に処理できる件数を意味します。
負荷試験とは
負荷試験とは、システムに一定量のアクセスや処理を発生させ、実際の利用状況に近い負荷がかかった状態でも正常に動作するか確認する試験です。
Webシステムなら、複数ユーザーからの同時アクセスをテストツールで再現する方法が代表的です。
たとえば通常時に500人、ピーク時に1,000人が利用すると想定されるシステムなら、その条件に近いアクセスを発生させます。
その状態でレスポンスが極端に遅くならないか、エラーが増えないか、サーバーのCPUやメモリに余裕があるかなどを確認します。
具体例で性能試験と負荷試験の違いを理解する
社員が利用する勤怠管理システムを例に考えてみましょう。
性能試験の場合
要件として「ログイン画面から2秒以内にトップページを表示する」と決められていたとします。
実際に処理時間を測定し、2秒以内に表示されるか確認します。
「要求された性能を満たしているか」が主な確認ポイントです。
負荷試験の場合
午前9時に社員1,000人が一斉に勤怠システムへアクセスする可能性があるとします。
テストツールを使って多数のユーザーからのアクセスを再現し、その状態でもログインや打刻が正常に行えるか確認します。
「多数の利用者が同時に使っても耐えられるか」を見るのが負荷試験の代表的な考え方です。
負荷試験と高負荷をかける試験は必ずしも同じではない
初心者が特に間違えやすいのが、「負荷試験=限界まで負荷をかける試験」と思ってしまうことです。
負荷試験では、想定される通常時やピーク時の負荷を再現することがあります。一方、意図的に想定以上の負荷をかけ、どこで限界になるか確認する試験はストレステスト(Stress Test)と呼ばれることがあります。
| 試験 | 主な目的 |
|---|---|
| 性能試験 | 要求された性能を満たしているか確認 |
| 負荷試験 | 想定した負荷のもとで正常に動作するか確認 |
| ストレステスト | 想定以上の負荷をかけて限界や障害時の挙動を確認 |
| 耐久試験 | 長時間負荷をかけ続けても安定しているか確認 |
これらをまとめて性能試験と呼ぶ場合もあります。
性能試験・負荷試験はなぜ重要なのか
機能テストで正常に動作していても、本番環境で多数のユーザーが利用すると問題が発生することがあります。
たとえば次のようなトラブルです。
- ログイン画面が表示されない
- 検索に30秒以上かかる
- タイムアウトが発生する
- WebサーバーのCPU使用率が100%になる
- メモリ不足が発生する
- データベースへの接続数が上限に達する
- 特定のSQL処理がボトルネックになる
- バッチ処理が業務開始時間までに終了しない
開発者が1人で操作したときには快適でも、500人が同時に利用したら急激に遅くなることがあります。
そのため、本番稼働前に実際の利用状況を想定した性能・負荷の確認が必要です。
性能試験・負荷試験で重要な「性能要件」
試験を行う前に必要なのが性能要件です。
単に「速ければ合格」では、試験結果を客観的に判断できません。
たとえば次のように数値で定義します。
- 通常時の画面応答時間は3秒以内
- 同時接続500ユーザーに対応する
- 1分間に1,000件の処理が可能
- 夜間バッチを午前5時までに完了する
- ピーク時でもエラー率を規定値以内にする
試験前に「何をもって合格とするのか」を決めることが重要です。
負荷試験で確認する場所
レスポンスタイムだけを見て「問題なし」と判断するのは危険です。
システム全体を確認し、どこがボトルネックになっているか調べます。
| 確認対象 | 主な確認内容 |
|---|---|
| クライアント | レスポンスタイム、エラー |
| Webサーバー | CPU、メモリ、接続数 |
| APサーバー | 処理時間、スレッド、エラー |
| DBサーバー | SQL、CPU、メモリ、接続数、ロック |
| ネットワーク | 帯域、遅延、パケットロス |
| OS | CPU、メモリ、ディスクI/O |
Webサーバーに問題がなくても、データベースのSQL処理が遅ければシステム全体のレスポンスは悪化します。
WindowsでCPU・メモリを確認する方法
Windows 11では、タスクマネージャーから基本的なリソース状況を確認できます。
- 「Ctrl」+「Shift」+「Esc」を押す
- タスクマネージャーを開く
- 「パフォーマンス」を選択する
- CPU、メモリ、ディスク、ネットワークを確認する
- 必要に応じて「プロセス」から負荷の高いプログラムを確認する
Ctrl+Shift+Escは運用保守やヘルプデスクでもよく使うショートカットキーです。
PowerShell・CUIで確認できること
Windows環境ではPowerShellからプロセスを確認できます。
Get-Process
実行中のプロセスやCPU使用状況などを確認するときに利用できます。
ネットワークの疎通や遅延を簡易的に確認する場合は、コマンドプロンプトやPowerShellからpingを使用することもあります。
ただし、pingの応答が速いからといってWebアプリケーションの性能に問題がないとは判断できません。ネットワーク、Webサーバー、アプリケーション、データベースなどを分けて考える必要があります。
ログとイベントビューアーの確認方法
負荷試験中にエラーが発生した場合は、アプリケーションログだけでなくOS側のログも確認します。
Windows ServerやWindows 11ではイベントビューアーを利用できます。
- 「Windows」+「R」を押す
- 「eventvwr.msc」と入力する
- 「Windowsログ」を開く
- 「システム」「アプリケーション」を確認する
- 試験実施時刻付近の警告やエラーを調べる
確認するときは発生日時、イベントID、ソース、メッセージを記録します。
重要なのは、試験ツールの結果とサーバー側のログを同じ時間軸で比較することです。
性能が悪い場合の原因切り分け
性能試験で目標値を満たさなかった場合、すぐに「サーバーのスペック不足」と判断してはいけません。
原因はさまざまです。
- どの処理が遅いのか確認する
- 問題が発生し始める負荷量を確認する
- CPU・メモリ・ディスクを確認する
- ネットワークの状態を確認する
- Web・APサーバーのログを確認する
- データベースの処理状況を確認する
- SQLやアプリケーション処理を確認する
- 正常時の測定結果と比較する
「どこが遅いか」ではなく「どこから遅くなっているか」を追うことが、性能問題の切り分けでは重要です。
現場でよくあるトラブル例
CPU使用率が高い
アプリケーション処理やSQL、バックグラウンド処理などが原因として考えられます。どのプロセスがCPUを使用しているか確認します。
メモリ使用量が増え続ける
負荷を下げてもメモリ使用量が増え続ける場合は、アプリケーションのメモリ管理に問題がないか確認が必要です。
DBだけ負荷が高い
SQLの実行計画、インデックス、ロック、接続数などを調査します。アプリケーションサーバーのCPUに余裕があっても、DBがボトルネックならレスポンスは遅くなります。
一定人数を超えると急激に遅くなる
接続数やスレッド数などの上限に達している可能性があります。「100人までは正常だが200人になると急激に遅くなる」といった境界を確認することが重要です。
筆者が性能確認で失敗した経験
性能確認を始めたばかりのころ、画面のレスポンスタイムだけを見て「性能に問題なし」と判断したことがあります。
ところがサーバー側を確認すると、CPU使用率がかなり高く、ピーク時には余裕がほとんどありませんでした。
その状態では、少しアクセスが増えただけで性能要件を満たせなくなる可能性があります。
この経験から、性能試験では結果の秒数だけではなく、その結果を出したときのサーバー状態も確認することが重要だと学びました。
初心者がやりがちなミス
- 性能試験と負荷試験を完全に同じものだと思う
- 負荷試験では限界までアクセスさせると思い込む
- 合格基準を決めずに試験を始める
- レスポンスタイムしか記録しない
- CPU使用率が一瞬100%になっただけで異常と判断する
- テスト環境と本番環境のスペック差を考慮しない
- 試験中に別のバッチ処理を実行してしまう
- ログの時刻と試験結果の時刻を合わせていない
- 試験条件を記録せず、結果だけ報告する
性能試験で上司へ報告するポイント
「性能試験で遅かったです」だけでは、原因調査につながりません。
少なくとも試験日時、環境、負荷条件、対象処理、期待値、実測値、CPU・メモリなどの状況、エラーの有無を整理して報告します。
たとえば「同時100ユーザーでは平均2秒以内ですが、500ユーザーでは平均8秒となり、目標値3秒を超過しました。同時間帯にDBサーバーのCPU使用率が高くなっています」のように、条件と事実をセットで伝えます。
エスカレーションするタイミング
性能試験中に次のような状況が確認された場合は、担当者や上司へのエスカレーションを検討します。
- 性能要件を満たしていない
- 大量のエラーやタイムアウトが発生する
- CPUやメモリなどのリソースが継続的に逼迫する
- データベースがボトルネックになっている
- 原因を特定できない
- サーバー設定の変更が必要になる
- 本番環境への影響が考えられる
特に本番環境で許可なく負荷試験を実施してはいけません。大量のリクエストによって通常利用者へ影響を与える可能性があります。試験環境、実施時間、負荷量、監視方法、停止条件などを事前に関係者と確認してください。
現場で評価される性能試験の進め方
新人のうちはツールの操作方法よりも、試験条件と結果を正確に記録することが重要です。
- 性能要件と合格基準を確認する
- 本番の利用状況を確認する
- 試験環境と本番環境の違いを整理する
- 同時ユーザー数などの負荷条件を決める
- 監視するCPU・メモリ・DBなどの項目を決める
- 負荷をかけながら性能を測定する
- アプリケーションとサーバーのログを保存する
- 期待値と実測値を比較する
- 問題があればボトルネックを切り分ける
- 条件・結果・原因候補を整理して報告する
性能試験・負荷試験に関連するIT用語
レスポンスタイム
要求を送信してから応答が返るまでの時間です。Webシステムの性能評価で頻繁に使われます。
スループット
1秒間や1分間など、一定時間内に処理できる量を表します。
ボトルネック
システム全体の性能を制限している部分です。CPUだけでなく、メモリ、ディスク、ネットワーク、データベースなども原因になります。
ストレステスト
通常の想定を超える負荷を与え、システムの限界や障害発生時の挙動を確認する試験です。
耐久試験
長時間にわたって処理を継続し、時間経過による性能低下やリソース不足などが発生しないか確認する試験です。
性能試験と負荷試験のよくある質問(FAQ)
Q. 性能試験と負荷試験は同じですか?
厳密には目的が異なります。性能試験は性能要件を満たしているか確認する広い概念で、負荷試験は一定の負荷を発生させた状態で性能や安定性を確認する試験として扱われるのが一般的です。ただし、プロジェクトによって定義は異なります。
Q. 負荷試験は限界まで負荷をかけますか?
必ずしも限界まで負荷をかけるわけではありません。通常時やピーク時の利用状況を再現することもあります。想定を超える負荷を与えて限界を確認する試験は、ストレステストと呼ばれることがあります。
Q. 性能試験ではCPU使用率だけ確認すればよいですか?
CPUだけでは不十分です。メモリ、ディスク、ネットワーク、データベース、レスポンスタイム、スループット、エラー率などを目的に応じて確認します。
Q. 負荷試験は本番環境で実施してもよいですか?
自己判断で実施してはいけません。通常ユーザーへの影響や障害につながる可能性があります。本番環境で実施する必要がある場合は、関係者の承認を得たうえで、実施時間や負荷量、監視体制、停止条件などを決めます。
Q. 新人が最初に覚えるべきことは?
「何人で試験したか」だけではなく、「どの処理を、どの負荷条件で実行し、何を合格基準として、実際にどうなったか」を記録することです。再現できる試験条件を残すことが現場では重要になります。
まとめ
性能試験は「要求された処理速度や処理能力を満たしているか」を確認する試験、負荷試験は「一定の負荷をかけた状態で問題なく動作できるか」を確認する試験です。
負荷試験は性能試験の一部として扱われることもあり、プロジェクトによって言葉の定義が異なる点には注意が必要です。
実務では名称を覚えるだけではなく、目的・負荷条件・合格基準・測定項目を確認しましょう。
また、性能問題が発生したときは「サーバーのスペック不足」と決めつけず、CPU、メモリ、ディスク、ネットワーク、Web・APサーバー、データベース、ログなどを順番に確認します。
新人エンジニアは、試験条件を正確に残す、正常時と比較する、サーバー側の状態も確認する、結果を数値で報告するという基本を身につけると、性能試験や負荷試験の現場で役立ちます。
