パフォーマンス・テストの種類
ひとくちにパフォーマンス・テストと言っても、何を目的とするかによって、いろいろな種類のテストがあります。パフォーマンスにまつわる会話を関係者間でしていると、そこに期待するものが違うために、時折話が食い違うこともあります。
パフォーマンス・テストを行うにあたって、どのように設計し、計画を立てるべきかを考えるのに先立って、求められている要件が何なのか整理し、目的をはっきりさせておくべきだと思います。
Performance Testing Guidance for Web Applications にアップされているドキュメントの Chapter 2 には、目的の違いによってそれぞれ種類の異なるパフォーマンステストの定義が説明されています。
自分のアタマの整理も兼ねて、主な4種類のテストが説明されている箇所を大雑把に翻訳・要約してみました。これらを念頭に置いて、ともすれば要件が混乱してしまいそうなパフォーマンステストについて、自分が行おうとしている内容の目的を見失わず、適切な手法を用いるように気をつけたいところです。
Performance Test : パフォーマンステスト
目的、メリット
- 速度、スケーラビリティ、安定性を決定・検証するための技術的調査
- ユーザが満足するパフォーマンスがでるかどうか検証する
- チューニングや最適化を支援する
難しいところ、目的としないところ
- 機能的な不具合を検出できるとは限らない
- 注意深く設計しないと、運用シナリオのほんの一部しかカバーできない
- 実運用で用いるハードウェアと全く同様の環境でない限り、結果にはある程度の不確かさが付きまとう
象徴的な質問
- 「十分な速度(レスポンス)が出るか？」
Load Test : 負荷テスト
目的
難しいところ、目的としないところ
- レスポンスの速さを見ることを優先して設計されるものではない
- テスト結果は、他の関連する負荷テストと相対的な比較でのみ有効
- 負荷がノーマルの状態→ピークの状態と推移させて、想定負荷に耐えられるか検証する
象徴的な質問
- 「全ユーザをサポートできるか？」
Stress Test : ストレステスト
- 実運用での想定利用モデル下で、負荷量と負荷サイズの増大させ、過負荷な状態で発生するバグ(同期の問題、競合条件、メモリーリークなど)を検出するため
- どの程度の状況で、(遅くなるだけではなく)エラーが起こるか
- 過負荷時にデータの破損やセキュリティ的な脆弱性が発生しないか
- エラーの事前検知のために何をモニタリングしておくべきか
- Spike test*1 はこれのサブセット。短時間に繰り返し急な負荷を与えた場合の検証に特化したもの
難しいところ、目的としないところ
- 仮定するストレスの状態が非現実的なため、テスト結果が関係者に無視されるかも
- どれくらいのストレスを与えるのが適切なのか知るのは難しい
- テスト環境が独立していないと、アプリケーションやネットワークなどに深刻な被害をもたらす可能性がある
象徴的な質問
- 「何かおかしくなったとき何が起こるか？」
Capacity Test : キャパシティ(処理能力)テスト
目的
- パフォーマンス要件を満たしつつ、どの程度のユーザやトランザクションをさばけるか検証するため
- 将来的なユーザ数やデータ量の増加に対して、どういったリソース(CPU性能、メモリ使用量、HDD容量、ネットワーク帯域など)を拡充すべきかのプランニングのための調査となる
- プランニングのために、現在のリソースの使われ方や処理能力の傾向をつかめる
難しいところ、目的としないところ
- 処理能力の検証モデルの構築は難しい
- 一回のテストで、処理能力のすべての面を検証することはできない
象徴的な質問
- 「ユーザが増えたとき何を増やせばいいか？」
