ロードテストとストレステストの違い

ロードテストとストレステストは、パフォーマンステストの一種であるため、しばしば類似しているとみなされます。どちらも主な目的は、特定のユーザーグループが大量に利用する状態でのソフトウェアの動作の可能性と基準を認識させ、ハッカーが行うDDOS攻撃のような予期しない不正な行為を防ぐことです。

しかし、ロードテストとストレステストの間には、その意味、プロセス、目標、およびその他の類似した要素にある微妙な違いが存在します。パフォーマンステストを検討しているのであれば、なぜロードテストやストレステストが行われるのか、その主な目的は何なのか、これらの違いを理解する必要があります。テストにはどのような基本ツールが使われるのか、ロードテストやストレステストにはどのようなメリットがあるのか。ここでは、パフォーマンステストの主な分類を紹介し、パフォーマンステストが実施されているその他の興味深いケースを紹介します。

ロードテストの意味

ロードテストとは、アクティブ・ユーザー数やトランザクション数などの負荷が増加したときのモジュールやシステムの挙動を測定し、そのモジュールやシステムが処理できる負荷の上限を決定する非機能テストです。また、アプリケーションのボトルネックの発見にも役立ちます。

なぜロードテストを行うのか？

ロードテストの主な目的は、システムがパフォーマンスを大幅に低下させることなく管理できる最適な負荷を説明することです。ロードテストではユーザをシミュレートする必要があり、これにより予想される負荷におけるソフトウェアの能力をテストすることができます。

したがって、このテストは、主要な機能をすべて備えた完全なアプリケーションに適しています。このようにして、ロードテストはより複雑で効果的なものになります。ロードテストは、ソフトウェアのコンポーネントを分割して行う場合にも有効です（例えば、システムをマイクロサービスに分割して、その相互作用の速度をテストする場合など）。

ロードテストの例

例えば、X社が推定1万人のユーザー向けにアプリを作ったとします。目的は、非常に需要のある新商品の広告キャンペーンを行うことでした。そこで、X社は資金の大部分を商品の広告キャンペーンに投資します。この商品は、アプリを通じてのみ、大幅な割引価格で予約することができます。

試写会当日は、かなりの人数が一斉に購入フォームの送信を繰り返し、順調に進んでいました。しかし、その後、サーバーに送られてくるリクエスト（ユーザーからの情報）は、サーバーに割り当てられたリソースでは、限られた数の問い合わせと回答しか実行・処理できないため、蓄積されていきます。

時間の経過とともに、X製品を購入したいと思うユーザーが増えてくると、状況は手に負えなくなり、アプリケーションは完全に失敗してしまいます。X社は莫大な費用をかけて広告キャンペーンを行い、多くの潜在顧客を獲得したにもかかわらず、過失により目的を達成できなかった。イメージも悪くなります。

ここでロードテストを行うことで、2つのことが実現できます。1つ目は、このアプリが推定1万人のアクティブユーザーを実際に運ぶことができるかどうかを確認することです。2つ目は、上記のような状況を回避できることです。

ロードテストのメリット

ロードテストは何の役に立つのでしょうか？ここでは、その利点をいくつか紹介します。

• 組織における障害コストを最小限に抑える。
• ソフトウェアの拡張性が向上する。
• お客様の満足度を高めることができる。
• システムダウンのリスクを低減することができる。
• 非効率的なコードの発見やシステムの隠れたバグの特定に役立つ。
• 複数のユーザーによるWebアプリの同時使用を容易にする 

ストレステストの意味 

サーバーの能力を超えた多数のユーザーを同時に操作し、ソフトウェアが適切かつ予測可能な反応をするかどうかをテストすることが最も重要です。また、データ損失やメモリリークを引き起こすアプリケーションの不具合も調査し、発見します。

なぜストレステストを行うのか？

ストレステストの主な目的は、高負荷の状況下でのソフトウェアの強度とエラー処理能力を推定し、過負荷の状況下でアプリケーションがクラッシュしないことを保証することです。

ストレステストの例

すでに述べたように、生活の中では、例えばインターネットを介してサーバーに接続し、オフィスや企業、あるいは一般のウェブサイトなど、一定数の受信者がログインして使用するようなアプリケーションに数多く出会うことができます。このようなアプリケーションやWebサイトは、少数の受信者のための限られた環境では非常によく機能します。しかし、活動が活発になると、様々な不都合が生じてきます。

例えば、あるゲーム会社がオンラインゲームのリリースを決定したとします。最終的にリリースされた後の最初の数時間、サーバーはプレイヤーの活動に耐えられませんでした。多くのデータが入力された結果、サーバーがオーバーロードして完全に停止し、プレイヤーは障害が解決するまでの数時間、サーバーに接続できなくなってしまったのです。さすがにプレイヤーは、プレミアパッケージを購入してもゲームができないことに落胆したようです。

ロードテストとは対照的に、上記の例では早期にストレステストを行うことで、サーバーが故障するまでにゲームアプリが搭載できるアクティブユーザーの最大数を把握することができました。そしてもちろん、この最大負荷を処理する際にソフトウェアがエラーを許容できるかどうかを検証します。

ストレステストの利点 

ストレステストの利点は以下のとおりです。

• バグやいくつかの同期の問題を発見
• インターロック（相互に依存する機能）の不具合の検出
• 優先度の問題を要求する
• リソースの損失の問題を発見する
• メモリリークの検出
• システムの破損や損失の発見

ロードテストとストレステストの相違点と類似点は何ですか？

ロードテストとストレステストの違いについては、以下の表で詳しく説明します。

これらのテストは、アプリが意図されたとおりに効果的に動作することを保証することを目的としたパフォーマンステストの種類です。

両方のテストは、ソフトウェア開発サイクルの不可欠な部分です（単にすべてがされ、アプリが本番稼動した後ではなく）。

これらの2つのテストは、適切なフレームワーク、ツール、およびテスト環境を持つ、熟練したQAエンジニアによって実行される必要があります。

ストレステストとロードテストのツール

よく使われるロードテスト・ストレステストツールには以下のようなものがあります。

Apache JMeter：パフォーマンステスト、ストレステスト、機能テストを行うための最も一般的で人気のあるツールの一つです。このプログラムはJavaで書かれており、無料で使用できます。ユーザーは追加のプラグインをダウンロードすることができます。GUIは簡単に操作できます（ただし、ロードテストを行う場合は、CMDコンソールからコマンドを実行することをお勧めします）。これにより、複数のマシンで同時にテストを行うことができます。また、統計情報を詳細に収集・分析し、レポートを作成することも可能です。しかし、このツールの欠点は、アプリが動作するために必要なハードウェアの条件が広範囲に及ぶことです（主にメモリリソース）。また、JavaによるGUIはアプリの速度に反映されるため、測定に支障をきたす可能性があります。JMeterは主にGETリクエストの送信に使用できます。

Gatling：Scala言語をベースに書かれた、Apacheベースの無償ベンチマークツールです。非同期型のアーキテクチャを採用しています。専用のスレッドを作成するのではなく、メッセージング指向のアクターモデルを導入しています（この場合、より大きなオーバーヘッドが発生します）。JMSとHTTPプロトコルを完全にサポートしています。

SoapUI：SOAPプロトコルに基づくWebサービステストの自動化を主目的としたツールです。(Simple Object Access Protocol - 呼び出しをコード化するためにXMLを使用するネットワークプロトコルです）。) 機能テスト、ストレステスト、セキュリティテストをサポートしています。REST、JMS、AMF、JDBCアプリケーションのテストが可能です。

まとめ

要約すると、ロードテストやストレステストなどの性能テストは、テスト文化の中で不可欠な要素です。これらのテストは、アプリケーションの開発と同時に比較的体系的に実施されるべきです。これらのテストのおかげで、アプリケーションが適切に動作するための適切で最適なリソースを見積もるために必要な データを得ることができます。また、これらのテストは、大量のデータに起因するエラーの発見や、外部からの攻撃に対する防御にも役立ちます。

とはいえ、パフォーマンステストから正しいデータを得ることは、簡単な仕事ではありません。パフォーマンステストの測定基準は、あらゆるソフトウェアの成功に不可欠です。アプリケーションの健全性を正確に評価するためには、QAチームがテスト中に主要なパフォーマンス指標をモニターし、これらの領域に焦点を当てることが極めて重要です。結局のところ、重要な成功要因は、それらが認識され、追跡された場合にのみ適用されます。

パフォーマンステストにおいてどのKPIが重要なのかを理解したい方、導入について検討したい方は、お問合せフォームからお気軽にお問い合わせください。