4.5 性能テスト (Performance Testing)
性能テストの目的
Section titled “性能テストの目的”性能テスト(Performance Testing)の主な目的は、指定された条件下でのシステムの応答時間、スループット(単位時間あたりの処理量)、およびリソース利用率を評価することです。
テクニカルテストアナリスト(TTA)は、システムがビジネス要件を満たす速度で動作し、インフラコストに対して最適化されているかを検証します。JSTQBの最新シラバスでは、性能の評価軸として「キャパシティ」という新しい副特性が明示され、より包括的な検証が求められるようになりました。
性能を構成する3つの側面(副特性)
Section titled “性能を構成する3つの側面(副特性)”性能テストでは、以下の3つの側面(副特性)に着目し、それぞれの評価指標を用いて検証を行います。
1. 時間効率性 (Time Behavior)
Section titled “1. 時間効率性 (Time Behavior)”システムが処理を実行する際の「応答時間」「処理時間」「スループット」を検証します。
- 主な指標: 画面が表示されるまでの時間(レスポンスタイム)、APIの応答速度、1秒間に処理できるトランザクション数(TPS)など。
2. 資源利用性 (Resource Utilization)
Section titled “2. 資源利用性 (Resource Utilization)”システムが動作しているときに、どれだけの「リソース(CPU、メモリ、ディスク、ネットワーク帯域、電力など)」を消費しているかを検証します。
- 主な指標: CPU使用率のピーク値、メモリの消費トレンド、ディスクI/Oのボトルネックなど。
3. キャパシティ (Capacity)
Section titled “3. キャパシティ (Capacity)”システムが満たすことができる「最大限界(上限)」を検証します。
- 主な指標: データベースが保持できる最大レコード数、同時に接続できる最大アクティブユーザー数、システムが破綻せずに受け入れられる最大通信量など。
性能テストの主な種類
Section titled “性能テストの主な種類”TTAは、テストの目的に応じて以下のような様々な種類の性能テストを計画・設計します。
- 一般的な性能テスト (Performance Testing): 定常状態(想定される通常の利用負荷)において、システムが要求された応答時間やリソース利用率を達成できるかを測定するベースラインテストです。
- 負荷テスト (Load Testing): システムの設計上の限界、またはシステムが処理できると想定されている「最大負荷(ピーク時の負荷)」を継続的にかけ、システムの振る舞いやリソースの安定性を評価します。
- ストレステスト (Stress Testing): 仕様や想定を超えた「過大な負荷」を意図的にかけ、システムがどのように限界を迎え(壊れ方)、負荷が下がったときに安全に自動回復できるか(堅牢性)を検証します。
- スケーラビリティテスト (Scalability Testing): ハードウェア(CPUやメモリ)やネットワーク資源を拡張(スケールアップ/スケールアウト)した際に、システムの処理能力が比例して向上するかどうかを検証します。将来のユーザー増に備えるために不可欠です。
- スパイクテスト (Spike Testing): 突発的なアクセスの急増(例:テレビ放映、セール開始、プッシュ通知の直後など)が発生した際に、システムがクラッシュせずに負荷をさばけるか、あるいは適切にリクエストを制限(キューイング)できるかを検証します。
- 耐久テスト / ソークテスト (Endurance / Soak Testing): 標準的な負荷を「長時間(数日間〜数週間)」連続してかけ続けるテストです。短時間のテストでは表面化しないメモリリーク、データベースの接続プールの枯渇、ディスク容量の緩やかな圧迫などを発見するのに有効です。
テクニカルテストアナリストとしての注意点
Section titled “テクニカルテストアナリストとしての注意点”性能テストを成功させるため、TTAは以下の技術的要素をコントロールする必要があります。
- ボトルネックの特定: 単に「遅い」という結果を報告するだけでなく、動的解析ツール(プロファイラやAPMツール)を用いて、データベースのインデックス不足、コード内のスレッド競合、ネットワークの遅延など、ボトルネックの根本原因を特定します。
- シミュレーションの正確性: 負荷生成ツール(JMeterやLocustなど)を使用する際、実際のユーザーの操作のばらつき(思考時間:Think Time)や、データの多様性を正確にシミュレートしないと、現実とは異なる誤ったテスト結果(フォールスポジティブ/ネガティブ)を招くリスクがあります。