性能テストのススメ #1 性能テストの目的と種類

こんにちは。けんです。
私が主に担当している「性能テスト」についてあれこれ投稿していきます。
今回は第一回として「そもそも性能テストって何？」というところから開始したいと思います。

＜性能テストのススメ記事一覧＞ ※クリックで開きます

#1 性能テストの目的と種類
 #2 テスト計画
 #3 対象シナリオ（運用プロファイル）
#4 テストパターン（ロードプロファイル）第一章_構成要素
 #5 テストパターン（ロードプロファイル）第二章_負荷量（入門編）

そもそも性能テストって何？
性能テストって何のためにするの？
- 性能の故障モードの体験
- 性能の故障モードによる損失
性能テストの観点
性能テストの種類
負荷のかけ方
さいごに

そもそも性能テストって何？

性能テストについて、ISTQBのシラバスで以下の通り定義されています。

性能テストとは、システムやコンポーネントがさまざまな負荷にさらされたときの
性能（応答性）に焦点を当てたあらゆるタイプのテストを含む包括的な用語である。

要約すると、負荷がかかった時に応答時間が遅くなってないか確認をするテストということになります。
テストを実施して、もし応答時間（レスポンスタイム）が速ければ「よかったね！終了！解散！」となりますが、実際に一回のテストでうまくいくことは少ないです。
問題が発生した場合、許容できる問題なのか協議・検討します。
そしてその結果「対策が必要だ！」となった場合、応答遅延の原因やボトルネックの特定、発生したエラーの調査を行った後、適切な対策を講じた上で再度テストをする必要があります。

性能テスト（負荷テスト）｜お役立ち資料｜株式会社AGEST（アジェスト）

本資料は、以下の４点がまとめてわかる内容になっています。企業を取り巻く性能問題 AGEST性能テストの特長テスト実施の流れ導入事例 / お客様の声「画面の応答が遅い」「エラー画面が表示される」「システムダウン」といったお悩みをお持ち

　詳細はこちら　

株式会社AGEST（アジェスト）

性能テストって何のためにするの？

性能テストの原則についてISTQBのシラバスから切り貼りすると、

「性能（効率性）」は「ユーザに良い体験を提供するために不可欠な要素」

となります。
逆に、性能が悪いとユーザに悪い体験を提供してしまうということになりますね。
性能が悪い状態を「性能の故障モード」と、ISTQBのシラバスで定義されています。

性能の故障モードの体験

性能が悪い状態（性能の故障モード）の体験として、一般的に以下の様な例があります。

タイムセールでユーザからのアクセスが一時的に増えたことによってWebページを表示するのに
とても時間がかかる
大規模なイベントのチケットの販売開始直後にユーザから一斉にアクセスがあり、
チケットの購入画面までたどり着けない、または購入に失敗する
TV等のメディア露出で大量のユーザから一斉にアクセスがあり、システムがダウンした
いつアクセスしても（負荷がかかっていない状態でも）画面の応答に時間がかかる

性能の故障モードによる損失

性能が悪い状態（性能の故障モード）をユーザが体験したことにより、
程度にもよりますが以下の様な損失が生じる可能性があります。

時間浪費
機会損失
営業活用への支障
利用者の離脱
売上減少・経済的損失
クレーム・訴訟・損害賠償
企業ブランドの低下

こうした損失を未然に防ぐため、性能テストの実施が必要です。

性能テストの観点

性能テストの主な観点として性能効率性があります。
性能効率性は品質特性の一つとして「ISO 25010」に定義されており、
性能効率性には以下の３つの副特性が挙げられています。

1. 時間効率性

最も一般的な特性で、システムの応答性能の確認が目的となります。
レスポンスタイムやスループット※1 等を確認します。

2. 資源効率性

システムのリソース使用状況が適切かを確認することが目的となります。
主にサーバのスペックが適切か、またスケールアウトやスケールインの設定が適切か等を確認します。

3. キャパシティ

システムに要求されるユーザー数やデータ量等の容量（キャパシティ）の限界の確認と、限界時におけるシステムのふるまいを確認することが目的となります。

これらの副特性のどれか、あるいは全てを確認することを前提または目的とし、それに応じた様々なテスト方法があります。

※1 スループットとは、単位時間あたりに処理が何回実行されたかを表す数値です
　　処理の単位にはリクエスト、ページビュー(PV)、トランザクション等があります
　　例えば「100 PV /分」は、ページビューが1分間に100回実行されたことを表します

性能テストの種類

性能テストには以下の種類があり、テストの目的やシステムの特性に応じて適切なテストを行う必要があります。
確認する副特性については経験上からの個人的見解となります。

テスト種類	説明	主に確認する副特性	確認を推奨する副特性
負荷テスト	通常時想定やピーク時想定など、運用時に予想される現実的な負荷を発生させる、最も一般的なテスト	時間効率性	資源効率性
ストレステスト	運用時の想定以上となる、システムの限界または限界を超える負荷を発生させるテスト	資源効率性・時間効率性	キャパシティ
スパイクテスト	突然のピーク負荷から定常状態に戻るまでの一連の性能を確認するテスト	資源効率性	時間効率性・キャパシティ
拡張性テスト	将来的に想定される、ユーザ数や保存データ量の増加が発生した場合の性能を確認するテスト	キャパシティ・時間効率性	資源効率性
耐久テスト	長時間の連続稼働によって、メモリリークの発生やデータベース接続、スレッドプール等による性能の低下が生じないかを確認するテスト	資源効率性	時間効率性・キャパシティ
キャパシティテスト	システムがどの程度のユーザーと（または）トランザクションをサポートしても規定の性能の目的を満たすことができるかを確認するテスト。拡張性テストは想定の範囲内でのテストだが、キャパシティテストは想定の範囲の限界を見つけるテストとなる	キャパシティ	時間効率性・資源効率性
コンカレンシーテスト	特定のアクションが同時に発生する状況の影響を確認するテスト	※2	時間効率性・資源効率性・キャパシティ

※2 コンカレンシーテストは、同時発生による処理が正しく行われるかという機能面の観点を含むテストになります

負荷のかけ方

目的やテストの種類に応じた負荷のかけ方を紹介します。
これはあくまで一例であり、システムの特性やテスト要件に応じて適宜変更する必要があります。
また、コンカレンシーテストを問題の再現確認を目的として行う場合、どれを適用するかは障害の発生状況によって異なります。

レスポンスタイムの統計の確認

レスポンスタイムの統計を確認したい場合、かつ負荷量が確定している場合に採用します。
徐々に負荷を上げて想定の負荷量に達した後、一定の負荷量で継続させます。
図の負荷継続時間内の応答結果を集計して「レスポンスタイムの統計」を確認します。
負荷継続時間を増やすことでサンプル数も増えるため、より正確な統計結果が得られます。　
急激な負荷上昇となるスパイクアクセスを避けるため、Ramp-Up期間※3 を設けます。

※3 Ramp-Up期間は、想定のスレッド数に上昇させるまでの時間のことです
　　また、Ramp-Down期間は想定のスレッド数に下降させるまでの時間のことです

項目	対象
対象となりうるテスト	負荷テスト、拡張性テスト
確認できる項目	レスポンスタイム、スループット、リソース状況、発生したエラー

キャパシティの確認

目標負荷量まで徐々に負荷を高めていき、キャパシティ（サーバのリソース状況等）を確認します。
発生したエラーの内容からシステムが高負荷時の問題を確認します。
スループットが最大でどこまで上昇できるかを確認します。
※負荷量が常に変動するため、レスポンスタイムの計測には向いていません

項目	対象
対象となりうるテスト	ストレステスト、キャパシティテスト
確認できる項目	スループット、リソース状況、発生したエラー

スパイクアクセス

通常の負荷量から急激に負荷を上昇させ、一定の負荷量で継続させた後、元の負荷量に戻します。
主にサーバのリソース状況の確認となりますが、図の負荷継続時間内の応答結果を集計してレスポンスタイムの統計も確認します。

項目	対象
対象となりうるテスト	スパイクテスト
確認できる項目	レスポンスタイム、スループット、リソース状況、発生したエラー

長時間連続稼働

長時間の連続稼働によって、メモリリークの発生等による性能の低下が生じないかを確認します。
負荷のかけ方は「レスポンスタイムの統計の確認」と同様ですが、図の負荷継続時間が長いのが特徴です。
通常時想定の負荷量での実施が一般的です。

項目	対象
対象となりうるテスト	耐久テスト
確認できる項目	スループット、リソース状況、発生したエラー

さいごに

負荷量や実施時間の決定方法等については次回以降の記事で説明していければと考えています。
今後も連載を続けて徐々に技術的な話へシフトしていきたいと考えていますのでご期待ください。

参考文献：「ISTQB テスト技術者資格制度 Foundation Level Specialist シラバス性能テスト担当者 Version 2018.J01」