​​性能テストで「サクサク体験」を実現！目的・種類・指標・手順を解説​ 

​​ひとつ​​め​​の目的は「運用時に想定されるユーザー数やアクセス数に耐えられるか」の確認です。Webサービスや​​アプリケーション​​は、キャンペーンやメディアでの紹介などをきっかけに、アクセスが集中することが予想されます。​

​​その際「サーバーがダウンしてサービスが停止した」といった事態に陥らないよう、事前に負荷をかけてシステムの処理能力を​​確認​​しておく必要があります。実際の利用状況を想定したテストを行うことで、機会損失を防ぎ、安定稼働を保証することが可能になります。​

2​つめ​​の目的は「システムの性能限界を把握し、その対策を準備しておくこと」です。どれほど高性能なシステムであっても、必ず処理能力には限界が存在します。​

​​性能テストによって、システムがどの程度の負荷まで耐えられるのか、そして限界を超えた場合にどのような挙動を示すのかの正確な把握は欠かせません。​

​​限界点を知ることで、アクセスが急増した際にもサーバーを増強する、あるいは一部機能の制限によりサービス全体の停止回避など、具体的な対策を事前に計画できます。​

ユーザーが何らかの操作を行ってから、システムが反応を返すまでにかかる時間（応答時間）を測定する、もっとも基本的な性能テストです。

Webページの表示速度や、ボタンをクリックしてから次の画面に切り替わるまでの時間などを計測します。ユーザーの体感品質に直結するため、性能要件を満たしているかを確認するうえで欠かせないテストです。

システムに通常時やピーク時に想定される負荷（トラフィックやトランザクション）をかけ、その状態での性能（応答時間やスループットなど）を測定するテストです。たとえば、ECサイトのセール時や、人気ゲームのイベント開催時など、アクセスが集中する状況をシミュレートします。

これにより、システムが実運用に耐えうる性能を持っているか、また、性能要件を満たしているかの確認が可能です。

＜性能テストと負荷テストの違い＞
性能テストと負荷テストは混同されやすいですが、厳密にはそのスコープが異なります。性能テストは応答時間やリソース使用量など、システムの「性能そのもの」を多角的に評価する広範なテストの総称です。

システムの限界を超えるような極端な負荷を意図的にかけ、システムがどのように反応し、最終的にどこで破綻するのか、その限界点を特定するためのテストです。想定をはるかに超える数のユーザーが同時にアクセスしたり、膨大な量のデータを一度に処理させたりします。

正常にエラーメッセージ を表示できるか、データは保護されるかなどシステム障害が発生した際の挙動を確認し、万が一の際の被害を最小限に抑えるための対策を講じるのが目的です。

システムの拡張性を評価するためのテストです。将来的なユーザー数の増加やデータ量の増大に対応するため、サーバーの台数を増やす（スケールアウト）あるいはCPUやメモリを増強する（スケールアップ）といったリソースの追加が、どの程度性能向上に寄与するかを測定します。

このテストにより、ビジネスの成長に合わせてシステムを柔軟かつ経済的に拡張していけるかどうかの判断が可能です。

負荷テストの一種で、テレビで紹介された直後など、短時間にアクセスが急増する状況をシミュレートするテストです。突発的なアクセス集中に対するシステムの耐久性を確認します。

負荷が急激に変動した際にシステムが安定して稼働し続けることができるか、また、負荷減少後に速やかに正常復帰できるかを確認することが目的です。

システムに一定の負荷を長時間かけ続けることで、安定性や信頼性を評価するテストです。たとえば、数時間から数日間にわたってシステムを稼働させ続け、その間に時間経過とともに顕在化する問題が発生しないかを確認します。

24時間365日稼働が求められるシステムの長期的な安定稼働を保証するために重要なテストです。

複数のユーザーが同時に同じ機能やデータにアクセスした際のシステムの挙動を確認するテストです。たとえば、複数のユーザーが同時に商品の在庫を確認したり、同じファイルを編集したりするシナリオを想定します。

データの整合性が保たれるか、デッドロック（処理の停止）などの同時アクセス特有の問題が発生しないかの確認が目的です。

システムの処理能力の限界、つまり「どのくらいのユーザー数やデータ量までなら性能要件を満たせるか」というキャパシティプランニングの 基礎となる情報を得るためのテストです。

将来の需要予測にもとづき、どのタイミングでシステム増強が必要になるかを判断するための客観的なデータを提供します。

ユーザーがアクションを起こしてからシステムが反応を返すまでにかかる時間を示す指標です。ユーザーの体感にもっとも直接的な影響を与えるもので、一般的に応答時間が短いほどユーザー満足度は高くなります。

テストでは平均応答時間だけでなく、90パーセンタイル値（90%のユーザーが体験する応答時間）や最大応答時間、そして応答時間のばらつき（標準偏差）なども測定し、設定した目標値を満たしているか多角的に確認します。

システムが単位時間あたりに処理できるリクエストの数やデータ量を示す指標です。たとえば、ネットワークにおけるスループットは、1秒間に転送できるデータ量（bps:bits per second）で表されます。

近年では、従来と比較するとデータ量が増えたことから「Mbps（メガビット/秒）」や「Gbps（ギガビット/秒）」で表記されることが一般的です。

スループットが高いほど、システムの処理能力が高いことを意味します。負荷テストやストレステストにおいて、システムの処理能力の限界を把握するために重要な指標です。

特定の時間内にシステムを同時に利用しているユーザーの数です。この指標は、システムがどの程度の同時アクセスに耐えられるかを評価するために用いられます。

並行ユーザー数を段階的に増やしていくことで、応答時間やスループットがどう変化するかを観測し、性能が劣化し始めるポイント（性能飽和点）を特定することが目的です。

サーバーのCPUがどの程度稼働しているかを示します。この値が高い状態が続く場合、CPUが処理のボトルネック（性能低下の原因）になっている可能性があります。一般的に、CPU使用率が常に80%を超えているような状態は危険信号とされ、対策が必要です。

CPU使用量のほかにも、メモリ使用量やディスク、ネットワーク帯域など、サーバーのさまざまなリソース使用量を監視することが重要です。

たとえば、メモリ使用量が高止まりしている場合はメモリリークの可能性が疑われます。これらのリソース使用量を総合的に分析することで、性能問題の根本原因の正確な把握が可能です。

最初に行うのが、性能に関する要件の明確化です。「ピーク時の応答時間は3秒以内」のように、具体的な性能目標を数値で設定します。この目標が曖昧では後の評価ができないため、関係者間で十分に協議し、合意形成を図ることが重要です。

性能目標を達成しているかを確認するためのテスト計画立案です。実施するテストの種類やシナリオ、対象範囲、合否判定基準などを詳細に設計します。成果物として「性能テスト計画書」を作成し、テストの全体像を関係者間で共有します。

テスト設計にもとづき、ユーザーの典型的な操作を模した具体的なシナリオ作成です。「商品を検索し、カートに入れて決済する」など、実際の利用状況に近い現実的なシナリオ作成が、精度の高いテスト結果を得るための鍵となります。

テストを実施するための環境を構築します。本番環境と可能な限り同じ構成の環境を用意し、JMeterなどの負荷生成ツールを導入して、テストシナリオを実行できる状態に準備します。本番環境との差分がテスト結果にどう影響するかも考慮しておく必要があります。

計画したシナリオに沿ってシステムに負荷をかけ、応答時間やスループット、リソース使用率などのデータを収集します。テストは一度だけでなく、条件を変えながら複数回実施することが一般的です。実行中はリアルタイムでシステムの状況を監視します。

収集したデータを分析し、性能目標を満たしているかの評価です。目標未達の場合は、データからボトルネックを特定し、原因を究明します。開発チームへ改善策をフィードバックし、再度テストを行って効果を確認するというサイクルを回すことで、品質を高めます。