性能テストのススメ #2 テスト計画

こんにちは。テストオートメーショングループのけんです。
私が主に担当している「性能テスト」についてあれこれ投稿していきます。

前回記事では「性能テストの目的と種類」について投稿しており、そのあとがきで負荷量や実施時間の決定方法等の説明を予告をしていたのですが、その前に一番大切なことの説明を忘れていました。

はい、それは本記事のタイトルの通り「テスト計画」です。
予定を変更し、今回はテスト計画に必要な項目ついて説明していきたいと思います。

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

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

テスト計画
さいごに

テスト計画

ISTQBのシラバスには性能テストの主要な活動として、以下の項目が定義されています。

性能テストの主要な活動
テスト計画
テストのモニタリングとコントロール
テスト分析
テスト設計
テスト実装
テスト完了

参考文献：

ISTQB テスト技術者資格制度 Foundation Level Specialist シラバス性能テスト担当者 Version 2018.J01

各項目の説明について今回は割愛しますが、その中でテスト計画は特に重要となります。

これは性能テストに限ったことではないと思うかもしれませんが、ISTQBのシラバスには以下の記載があり、性能テストにおけるテスト計画の重要性が強調されています。

テスト計画は性能テストでは特に重要である。
なぜなら、テスト環境、テストデータ、ツール、人材などを割り当てる必要があるためである。
また、テスト計画は性能テストのスコープを設定する活動でもある。

目的を決めた上でテスト範囲を設定し、テストを実現するために必要なリソースと作業とその工数を洗い出した上で人員と予算を決定するため、適切な計画を行うことが重要となります。

それでは、性能テストを計画するにあたってまず最初にすべきことは何でしょう？
それは…….情報収集です。

情報収集

情報収集には主に３つのパターンがあります。

1. ステークホルダーからの情報収集
2. 資料からの情報収集
3. ユーザーの振る舞いをモニタリングする

１つずつ説明していきます。

1. ステークホルダーからの情報収集

情報を持っている人から聞いて情報収集します。対象となる人は主に以下になります。

– プロダクトオーナー

– セールスマネージャー

– （潜在的な）エンドユーザー

情報保持者からヒアリング、あるいは情報保持者との会議を実施することにより、ユーザーの主な運用プロファイル(※1)が明らかになります。その結果、「このアプリケーションは誰のためのものか」という基本的な質問に対する答えが得られることがよくあります。

※1 運用プロファイルは、システムの特定の使用方法についてのフローを提供します。
　　運用プロファイルを集約することでロードプロファイル（一般的にはシナリオと呼ぶ）となります。

また、私の経験則では「性能テストを実施すべき」と最初に提案した人に話を聞くのは有益だと考えています。必ずしもではありませんが、いわゆる言い出しっぺが最も課題意識を持っており、解決すべき課題についての情報を持っていることが多いからです。

2. 資料からの情報収集

資料を確認して情報収集します。対象となる主な資料は以下の二つとなります。

– 機能仕様や要件

– 類似のアプリケーションから得られた使用データやメトリクス

A. 機能仕様や要件

機能仕様や要件が記載された資料は重要な情報源です。以下の特定に役立ちます。

– ユーザーのタイプとその運用プロファイルの特定

– UMLのユースケース図や説明文から、ユースケースの「アクター」の特定

B. 類似のアプリケーションから得られた使用データやメトリクス

類似のアプリケーションから得られた使用データやメトリクスを評価することで、ユーザーのタイプの特定を支援し、予想ユーザー数の初期値を得ることができます。運用中のシステムの更新が予定されている場合は、その使用状況から得られるモニタリングのログやデータを確認します。

3. ユーザーの振る舞いをモニタリングする

アプリケーションであらかじめ定義されたタスクを実行する際のユーザーの振る舞いをモニタリングすることで、性能テストでモデル化すべき運用プロファイルの種類についての洞察を得ることができます。

例えば、商品を購入するタスクを設定した場合、以下のフローになると洞察します。

トップ → ログイン → 商品検索 → 商品一覧 → 商品詳細 → カートに入れる → 購入手続きへ → 購入内容確認 → 決済 → 決済完了

性能テストの目的

さまざまな人から話を聞き、資料を確認し、実際にシステムを操作して一通り情報収集したところで、あらためて性能テストは誰のために何のために実施するのかを考えてみましょう。性能テストの主要な目的について、ISTQBのシラバスに以下の記載があります。

性能テストの主要な目的は、潜在的なリスクを識別し、改善の機会を見つけ、必要な変更を識別することである。

抽象的な文言ではありますが、、以下の様に解釈しました。

「必要な変更を識別」するために目的と目的の達成基準を明確にする
↓
性能テストを実施して、目的と目的の達成基準を満たしているかを確認（「潜在的なリスクを識別」）する
↓
達成基準を満たしていない（「改善の機会を見つけた」）場合、改善すべきか検討（「必要な変更を識別」）する

そのため、まずは目的と目的の達成基準を明確にしていきましょう。

目的の導出

性能テストの目的の導出について、ISTQBのシラバスに以下の記載があります。

性能テストの目的は、さまざまなタイプのステークホルダーに関連している。
ユーザーに基づいた目的と技術的な目的を区別するのはよい方法である。

性能テストの目的を明確にする場合、さまざまな立場の人によって目的が異なる場合があるため、「ユーザーに基づいた目的」と「技術的な目的」を区別すべきと解釈します。それぞれの目的における焦点は以下になります。

目的	立場	焦点
ユーザーに基づいた目的	ユーザ	主にエンドユーザーの満足度
ユーザーに基づいた目的	ビジネス	主にビジネスゴール
技術的な目的	技術	主に運用面（システム拡張性、性能低下条件等）

具体例

目的を具体化するにあたり、ISTQBのシラバスに以下の記載があります。

ビジネスに重心を置いたステークホルダーには、目的とプロダクトリスクとの関連性を明確に示す必要があります。

対象が「ビジネスに重心を置いたステークホルダー」と限定されていますが、性能テストの計画においては共通して重要と考えます。なぜなら、目的とプロダクトリスクとの関連性を明確に示すことで、性能テストの必要性を理解してもらえるようになるからです。

ご参考までに、以下の文法例で明示してみます。

「性能の故障モード(※2)が発生するとプロダクトリスクが生じるため、性能テストを実施してリスクがないか確認し、目的の達成基準に満たない場合は改善する」

※2 性能の故障モードについては前回記事をご参照ください

以下、文法例を具体化したものです。

– システムの応答性が著しく低下すると利用者が離脱する可能性があるため、応答性能を確認して3秒以上かかるものは改善する

– 大量アクセスでサーバがダウンすると日常業務が混乱または停止し、機会損失、経済的損失が発生する可能性があるため、運用上のピーク想定となる500リクエスト/秒の負荷をかけて応答性能低下やエラー発生等の問題があった場合はシステムや構成を改善する

– 運用中のシステムでユーザーアクセスがピークに達した時にWebサーバのCPU使用率が100％に達していたため、スケールアウトが可能な構成に変更して正常に負荷分散できることを確認する

– 現状では1時間以内で5万件の決済処理を捌いているが、利用者増加により10万件の決済が要求されているため、システムの処理性能（スループット）を向上させる

目的は定量的な数値を含めることによって具体化されますが、その妥当性については議論になることがよくあります。

そのため、情報収集で得た「根拠となる情報」を提示できるようにしておいてください。

目的を達成するためのフロー

性能テストの主要な目的についてもう一度、ISTQBのシラバスの文言を引用します。

性能テストの主要な目的は、潜在的なリスクを識別し、改善の機会を見つけ、必要な変更を識別することである。

目的を達成するためには、性能テストを1回実施しただけで問題なく終了となるケースは稀であり、実際には以下のフローで性能テストを複数回実施することが多いです。

シラバスのお言葉が正しければ、このフローを実施することで性能テストの目的が達成できることとなります。

性能テスト計画書の作成

情報収集をしてテストの目的が定まったら、計画書を作成しましょう。以下は計画書に記載すべき内容の一覧です。

項目	詳細
テストの目的	性能テストの目的の導出を参照
システム概要	テスト対象システムの概要
システム構成	具体的なシステムアーキテクチャの説明
性能テストのタイプ	実施する性能テストの種類については前回記事を参照
受け入れ基準	いわゆる合否判定基準を設定。システムの応答性、スループット、信頼性、拡張性等を判断基準とする
プロファイル	システムの特定の使用方法についてのフロー。これを集約すると一般的にシナリオと呼ばれる。
テスト環境	・本番と別の環境の場合、本番環境と同等の構成やスペックであることが望ましいが、本番環境より規模が小さい場合はどのようにテスト環境のデータから推定するかを記載すべき・本番環境の場合は、具体的なリスクを検討すべき
テストデータ	・ユーザーアカウントデータ・ユーザー入力データ・データベース
関連するメトリクス	・性能メトリクス・性能モニタリング
テストツール	・ユーザートランザクションをシミュレーションするツール・負荷を発生させるツール・システム性能をモニタリングするツール
リスク	・測定されていない領域・性能テストの制限（例：シミュレーションできない外部インターフェース、不十分な負荷、サーバをモニタリングできないことなど）・テスト環境の制限（例：不十分なデータ、スケールダウンされた環境）

上記の項目が決定することによって性能テストの内容が明確になります。以下、特筆事項となります。

システム構成

システム構成には、サーバ（Web、データベース、ロードバランサーなど）を含む、具体的なシステムアーキテクチャの説明を記載します。

– 複数の階層の定義

– コンピューティングハードウェア（例：CPU コア、RAM、SSD（ソリッドステートドライブ）、HDD（ハードディスクドライブ）のバージョンを含む具体的な詳細）

– ソフトウェア（アプリケーション、オペレーティングシステム、データベース、企業をサポートするために使用されるサービスなど）のバージョンを含む具体的な詳細

– テスト対象システムと一緒にに動作する外部システムおよびその構成とバージョン

– テスト対象システムのビルド／バージョン識別子

受け入れ基準

受け入れ基準は、関連するすべての測定値に対して設定されるべきです。

テストデータ

最低限必要なデータ数を用意すればテストの実行自体は可能ですが、それで本当に性能要件を満たしているかは確認が必要です。例えば、前提条件として満たすべきデータ数がある場合はデータ準備が必要です。なぜなら、100件ヒットする検索を実行する際、データベース内のデータが以下の2パターンで応答性能に差異が出てしまうからです。

– データが100件存在している状態

– データが1万件存在している状態

また、1度実行すると使用できなくなるようなデータについては実行回数分用意が必要なため注意が必要です。

タイプ	メトリクス
仮想ユーザーのステータス	成功、失敗
トランザクションの応答時間	最小、最大、平均、パーセンタイル値
秒単位のトランザクション	成功/秒、失敗/秒、合計/秒
ヒット数（例：データベースやWeb サーバ）	ヒット数/秒（最小、最大、平均、合計）
スループット	ビット/秒（最小、最大、平均、合計）
秒単位のHTTP レスポンス	レスポンス数/秒（最小、最大、平均、合計）、 HTTP レスポンスコードごとのレスポンス

タイプ	メトリクス
CPU使用率	使用可能なCPUの割合
メモリー使用量	使用可能なメモリーの割合

スケジュールについて

スケジュールについて、ISTQBのシラバスには以下の記載があります。

性能テスト計画書（PTP）は、関連するスケジュール情報を含むテスト計画書（[ISTQB_FL_SYL]参照）によって参照されるべきである。

要するに、スケジュールは性能テストの計画書にではなく、その上位となる全体のテスト計画書に含まれるべきであると解釈します。プロジェクト内で管理されている場合はそれで問題ありませんが、性能テストが独立または単体で稼働しているケースもよくあるので、その場合は性能テストの計画書に含めるようにしています。

さいごに

いかがでしたでしょうか。今回は性能テストの計画についてざざっと説明したのですが、説明しきれていない箇所も多くあるので、気になる点があった方は是非シラバスを解読してみてください。

今後も性能テストについて深堀りしていきたいと考えていますので、次回記事もよろしくお願いいたします。

連載一覧

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