負荷テストって何をどうやるの？目的・種類・進め方・指標を解説

負荷テストを行う主な目的は、以下の2点です。

■製品の信頼性を担保するため

負荷テストの最大の目的は、システムの信頼性の担保です。たとえば、ECサイトのセール時期などでアクセスや注文が集中し、サーバーがダウンしたり、応答が極端に遅くなったりすれば、ユーザーはサイトから離れてしまいビジネス機会の損失につながります。

このような状況下でパフォーマンスが著しく低下するようでは、信頼できるシステムとはいえません。

しかし、テストをクリアすれば、たとえ高負荷な環境に置かれても、期待される動作や性能の維持が証明できます。つまり、結果がシステムの信頼性を確固たるものにします。

■潜在的なリスクを把握するため

システムには普段の運用では表面化せず、特定の負担で著しくパフォーマンスが低下する潜在的な問題を抱えていることがあります。これらは設計やプログラムの不備によって生じるケースも少なくありません。

負荷テストでは、通常の利用では発生しにくい潜在的なリスクを顕在化させます。事前にシステムのボトルネックを特定し、問題が大規模化する前に修正すれば、リリース後の致命的な障害を回避できます。

負荷テストと、性能テスト（パフォーマンステスト）は混合されやすいですが、厳密には異なる概念です。両者ともに性能に関するテストという点では共通していますが、その目的と確認範囲には違いがあります。

性能テストは、システムが特定の条件下でどれほどの性能を示すかを測定することが目的です。たとえば「応答時間が○秒以内であるか」や「データ処理が○件/秒できるか」など、あらかじめ定められた性能要件を満たしているかを確認します。主にシステムの効率性や応答性といった個々の機能や処理能力に焦点を当てます。

対する負荷テストは、性能テストのひとつであり、とくにシステムが耐えられる限界や、過負担になった際の挙動を確認することが目的です。システムの堅牢性や耐久性を評価し、キャパシティプランニングの参考にします。

※ こちらの記事では、性能テストについて解説しています。
　実施目的や指標も取り上げているため、ぜひ合わせてご覧ください。

ロードテストは、システムが通常の予想される負荷、またはピーク時の予想される負荷に耐えられるかどうかを確認するために実施します。システムが定義された性能要件を満たしているかを確認し、ボトルネックがどこにあるかを特定することが目的です。

具体的には、通常の同時接続ユーザー数やトランザクション量をシステムにかけ、その際の応答時間、スループット、CPU使用率といったパフォーマンス指標を測定します。システムの現状のキャパシティを把握するためのもっとも基本的な負荷テストです。

ストレステスト（限界負荷テスト）は、システムに通常の負荷をはるかに超える過度な負荷をかけ、システムがどこで限界を迎え、どのように振る舞うかを確認するために実施します。意図的に故障させることで、その回復力や安定性を評価することが目的です。

システムのブレイクポイント（限界点）を見つけること、そしてその限界を超えた際に、エラーメッセージが適切に表示されるか、データ破損が発生しないかといった耐障害性や復旧能力を確認します。想定外のアクセス集中やサイバー攻撃などの把握に役立ちます。

ロングランテスト（連続負荷テスト）は、長時間にわたって一定の負荷をかけ続けることで、システムの安定性や信頼性を確認するために実施します。別名「ソークテスト」とも呼ばれ、短時間のテストでは見つからない、時間経過とともに顕在化する問題を発見することが目的です。

具体的には、メモリリークによるパフォーマンスの低下やデータベース接続の枯渇、キャッシュの不整合といったシステムが長時間稼働した際に発生し得る問題を洗い出します。システムの持続的な安定稼働の保証に役立ちます。

スパイクテストは、短時間に急激なアクセス集中（スパイク）が発生した際のシステム挙動を確認するために実施します。システムが急激な負荷の増加にどれだけ対応できるか、そしてその負荷が収まった後に正常な状態に回復できるかを確認することが目的です。

たとえば、テレビCM放映直後やセール開始時など、瞬間的にアクセスが跳ね上がる状況をシミュレートします。

ボリュームテストは、システムが大量のデータを効率的に処理できるか、または大量データが格納された状態でも適切に機能するかを確認するために実施されます。想定されるユーザー数に応じた負荷量をもとにテストデータを作成し、特定の動作を実行させる手法でテストを行います。

主な目的は、データ量の増加にともなうパフォーマンス劣化の有無や大容量データを扱う際にボトルネックを特定することにあります。

とくに、データ分析システムやECサイトの商品データなど、将来的にデータ量が飛躍的に増加する可能性があるシステムにおいて、有効なテスト手法です。

自社で負荷テストを実施する場合、専用のテストツールを導入して行います。自社で行う方法は、オープンソフトであれば低コストで実施できる、必要なタイミングで迅速に実施できるといったメリットがあります。

その一方で、適した担当者がいなければ学習コストがかかる、テストの品質が低下するといったデメリットもあります。

とくに、大規模なシステムや複雑なシナリオの場合には、実施に相当な時間と人員のリソースが必要なため、担当者にとっては大きな負担となるでしょう。

的に実施できる点がメリットです。テストに関する専門知識や経験が不足している場合や、テスト環境の構築やテストシナリオの作成に手が回らない場合に有効な選択肢です。

一方で、外部委託費用が発生し、社内にノウハウが蓄積されにくい点がデメリットとして挙げられます。ただし、短期間で高品質な効果が得られ、社内の人間は本来の業務に集中できることを考えれば、費用対効果は高いでしょう。

株式会社NEXERとポールトゥウィンが共同で実施した、ソフトウェア開発経験者を対象としたアンケート調査によると、全体の84.1％が「ソフトウェアテストは非常に重要」と回答しました。

一方で、テスト体制やプロセスに満足していないと答えた開発者は38％にのぼり、現場には依然として多くの課題や不満が存在している実態が明らかとなりました。

その理由には「体制が不十分」「人員が不足している」「時間がない」といった、リソースに関する課題が多く挙げられています。

ソフトウェアテストの重要性は広く認識されている一方で、実施体制やリソース不足といった課題が、テストの品質や継続的な運用を妨げている現状が浮き彫りとなっています。限られたリソースのなかでも効果的にテストを実施できる体制の整備や、外部支援の活用が求められるでしょう。

負荷テストを成功させるための最初の重要なステップは「計画」です。テストの目的を明確にし、何を、どのように、誰が、いつまでに行うのか詳細を定めます。

■テストの目的

まずは、なぜ行うのかという目的を明確にしましょう。ECサイトのセール時のサーバーダウンを防ぎたい、新機能のリリース時にシステムが安定稼働するか確認したいといった、課題と目標を明確にすることで、行うべきテストの種類や範囲、目標値が定まります。

■テストの対象と監視項目

対象となるシステムやコンポーネントを特定します。サーバー、データベース、ネットワークなど、システムのどの部分に負担をかけ、どこを監視するのか明確にします。

監視項目は、応答時間、同時ユーザー数、スループット、エラー率などです。これらの項目について正常時の基準値や、許容できるしきい値を設定しておくと、結果分析がスムーズになります。

■テストの方法と環境

ロードテスト、ストレステスト、ロングランテストといった種類を決定します。そして、テスト環境の準備を検討します。本番環境とほぼ同等の構成、データ量を持つテスト環境を用意することが望ましいです。

■テストの人員とスケジュール

負荷テストでは、テストツールを扱うスキルだけでなく、システム全体の知識や結果分析スキルといった多様な能力が求められます。テストの計画から実施、分析まで、誰がどの役割を担うのかを明確にしましょう。

スケジュールの作成は、まず作業の洗い出しを行い、各工程の見積もりと優先度の設定を踏まえて、全体のスケジュールを策定します。これらの要素を含んだテスト計画書を作成し、関係者間で共有・合意形成を行うことで、スムーズに進行できます。

テスト計画にもとづき、実際にどのような負担をシステムにかけるのか具体的に定義するテストケースを作成します。

■シナリオと目標値

シナリオは、ユーザーがシステムで行う一連の操作を具体的に再現したものです。たとえば、ECサイトであれば「商品検索→商品詳細の閲覧→カートに追加→注文手続き」という流れです。

テストシナリオでは、この一連の流れを定義し現実のユーザーの行動を忠実に再現することで、テスト結果の信頼性が高まります。

また、各シナリオにおいて、期待される目標値（合格基準）を設定します。具体的な数値目標を設けることで、テストの合否を客観的に判断できます。

■負荷の設定

作成したシナリオにもとづき、どの程度の負荷をかけるのか設定します。これは主に、同時実行ユーザー数（仮想ユーザー数）や、単位時間あたりのリクエスト数（スループット）として表現されます。負荷設定は、計画段階で定めたテストの種類と目的によって決定しましょう。

テストを実施するための環境を準備します。本番環境にどれだけ近い環境を用意できるかが、テスト結果の信頼性を左右します。

■テスト用のインフラ

テスト用のインフラストラクチャを用意します。インフラストラクチャには、システムが稼働するサーバーやデータベースサーバー、ネットワーク機器などが含まれます。

ここで重要なのが、テスト環境が本番環境の構成やスペックに極力近づけることです。CPUやメモリ、ディスク容量、ネットワーク帯域のほか、OSやミドルウェアのバージョンまで、本番環境と同一にすることで、より現実的な結果が得られます。

■テストデータとスクリプト

負荷テストでは、大量のデータが必要となる場合があります。データ量が不十分だと、データベースの性能問題など、特定のボトルネックを見逃す可能性があるため、本番環境から匿名化したデータをコピーして使用したり、大量のダミーデータを生成したりしましょう。

また、ツールでシナリオを実行するためのスクリプトを作成します。スクリプトは、仮想ユーザーがどのような操作をどういった手順で行うかをツールに指示するプログラムです。正確なスクリプトを作成することで、信頼性の高い負荷を生成できます。

準備が整ったら、いよいよテストを実施します。

■【重要】テスト計画を厳守すること

実施中は、事前に作成したテスト計画を厳守することが重要です。計画と異なる負荷をかけたり、監視項目を途中で変更すると、テスト結果の比較可能性や信頼性が損なわれます。

テスト実施中は設定した負荷が意図どおりにかかっているか、システムの各コンポーネントがどのように振る舞っているかをリアルタイムで監視しましょう。

テストが完了したら、収集した膨大なデータを詳細に分析し、システムのパフォーマンスに関する洞察を得ます。

収集した応答時間、スループット、エラー率といったデータを事前に設定した目標値や基準値と比較しましょう。分析フェーズでは、ボトルネックの特定や問題の根本原因の特定、改善策の検討と提案、そして報告書の作成といった点を明確にしていきます。

応答時間は、レスポンスタイムとも呼ばれ、ユーザーがリクエストを送信してから、システムが応答を返すまでの時間を示すものです。ユーザーがシステムを操作する際に体感する速度に直結する最も重要な指標のひとつです。

一般的には、表示系で5〜8秒以内、更新処理系で8〜10秒以内が合格基準の目安とされており、これを超えるとユーザーの離脱や不満につながる可能性があります。

そのため、目標となる応答時間をあらかじめ設定し、負荷テストを通じてその基準を満たしているかを確認することが重要です。

同時ユーザー数は、ある瞬間にシステムにアクセスしている仮想ユーザー数、または同時に処理を行っているユーザー数を指すものです。システムがどれくらいのユーザー数まで快適にサービスを提供できるか、あるいは限界を迎えるかを示す基準です。

システムのキャパシティプランニングを行ううえで不可欠な情報であり、将来的なユーザー増加に耐えうる設計になっているか確認する際にも活用されます。

スループットは、単位時間あたりにシステムが処理できるリクエスト数やトランザクション数を示すものです。スループットが高いほど、システムはより多くの処理を効率的にこなせていることを意味します。

一方、低下している場合はどこかに処理のボトルネックが存在する可能性を示唆します。

エラー率は、システムが処理したリクエストのうち、エラーとして返されたリクエストの割合を示すものです。システムの安定性や信頼性を評価するうえで重要な指標です。

エラーが発生している箇所や内容を詳細に分析することで、システムの脆弱性や欠陥を特定し、修正につなげられます。

CPU使用率は、システムやサーバーのCPU（中央演算処理装置）が、どの程度の割合で処理に利用されているかを示すものです。CPUはシステムの「頭脳」であり、使用率が高すぎる場合には、処理能力が限界に近づいていることを示唆します。

一般的に、CPU使用率が80%以上を継続すると問題視されることが多く、システムの応答時間の遅延や、エラーの発生原因となります。

メモリ使用率は、システムやサーバーが、プログラムやデータを一時的に保存するために使用しているメモリの量を示すものです。メモリ使用量を継続的に監視することは、システムの安定性を評価するうえで欠かせません。

メモリが不足すると、システムはディスクへのデータの読み書き（スワップ）を頻繁に行うようになるため、全体の処理速度が著しく遅くなる原因となります。