こんにちは。性能テストグループのけんです。（前回執筆時まではテストオートメーショングループ配属でしたが、今年度から新たに性能テストグループが爆誕しました）
私が主に担当している性能テストについてあれこれ投稿していきます。
前回までは性能テストの概要やテスト計画について説明しましたが、今回は対象シナリオについて説明していきたいと思います。
＜性能テストのススメ 記事一覧＞ ※クリックで開きます
#1 性能テストの目的と種類
#2 テスト計画
#3 対象シナリオ（運用プロファイル）
#4 テストパターン（ロードプロファイル）第一章_構成要素
#5 テストパターン（ロードプロファイル）第二章_負荷量（入門編）
対象シナリオとは
ISTQBのシラバスには性能テストの主要な活動として以下の項目が定義されています。
今回はテスト計画からテスト設計へと足を踏み入れていきます。
| 性能テストの主要な活動 |
|---|
| テスト計画 |
| テストのモニタリングとコントロール |
| テスト分析 |
| テスト設計 |
| テスト実装 |
| テスト実行 |
| テスト完了 |
参考文献：
「ISTQB テスト技術者資格制度 Foundation Level Specialist シラバス 性能テスト担当者 Version 2018.J01」
性能テストの話をすると、まずどの機能または画面を対象とするのかという議論が自然に出るかと思います。
それを決定したものが対象シナリオになるのですが、もう少し詳しく説明していきます。
運用プロファイルとロードプロファイル
性能テストの対象として選定する画面や機能には、送信されるリクエストとその実行順序があります。
それらのリクエストを組み合わせた一連の流れをISTQBのシラバスでは「運用プロファイル」と定義しているように読み取れます。以下がISTQBのシラバスの説明文です。
システムの特定の使用方法について、アプリケーションを通じた再現可能なステップバイステップのフローを提供する。
運用プロファイルとは別に「ロードプロファイル」というものも定義されています。
ロードプロファイルは、運用プロファイルを使用してどのように負荷をかけるかを定義することになりますが、今回は詳細な説明については割愛します。
運用プロファイル＝対象シナリオ
ですが、そもそも「運用プロファイル」という字面だけを見た場合、何を指しているのかわからないですよね。
そのため当社では余計な補足説明が必要となることを避けるため「対象シナリオ」と定義しています。
対象シナリオについて、当社では以下の通り説明しています。
「特定のユーザー操作を模倣して送信されるリクエストの一連の流れです。」
手前味噌ながら簡潔かつ洗練された文言で定義されていますね。
また、「シナリオ」の前に「対象」という言葉を添えることで、それが性能テストの対象となるシナリオであることを表しており、シナリオは選定する必要があるという意味も込めています。
対象シナリオの定義
対象シナリオを定義する上で基本方針となるのは、本番の運用でかかる負荷を再現するために、主となるユーザーの操作を模倣することです。
ユーザーがたどる動線からシナリオを作成するために以下を定義していきます。
- シナリオ動線
- シナリオ詳細
シナリオ動線
シナリオにどのような動線（ページまたは機能など）を含めるべきかを説明していきます。
アクセス量の多いページまたは機能
稼働中のシステムのアクセスログを確認して、アクセス量が多いリクエストを対象とする方法が最も妥当です。
「アクセス量が多い ＝ 負荷が高い」となるため性能テストの対象とすべきという考え方です。
稼働前でアクセスログの確認ができない場合は、他の類似システムのデータを調査すると良いそうです。
アクセス量が多いものとしては以下があります。
直接アクセスされるURLリンク
フロントとなるトップページやWeb検索でヒットしやすいページなど、外部サイト等からの入口として直接アクセスされるURLリンクのリクエストはアクセス過多になる可能性が高いため、対象にすべきと考えます。
ログイン
システムを利用するために必要な動線として、最もよく使われる機能の一つです。
システムの主目的となるページまたは機能
システムの主目的となる機能や、アクセスできなくなることで損失が生じる可能性があるページまたは機能は対象とすべきです。
例としては以下があります。
- ECサイトにおける「決済処理」
- 勤怠管理システムにおける「勤怠入力」
- アンケートサイトにおける「アンケート回答送信」
また、基本的にはそこへ至るまでの動線についても同様、対象にすべきと考えます。（例外については後述します）
処理に時間がかかる機能
リクエストの処理に時間がかかる機能またはページは、その処理の完了を待つユーザーにとってはストレスと感じてしまうため、ユーザービリティを満たす性能を担保すべきと考えます。
また、処理しているサーバー側ではCPU使用率が上がって性能が低下するかもしれません。
さらに、サーバーの構成次第では他の主要な機能に影響が出る可能性もあるため、テスト対象にすべきと考えます。
以下は時間がかかる機能または処理とその例です。
| 機能または処理 | 例 |
|---|---|
| 大量のデータ処理 | 全件検索 |
| ファイルサイズの大きなデータの処理 | ファイルアップロード |
| 複雑な演算処理 | リアルタイム集計 |
| ユーザーアクセスが多い時に実行されるバッチ(※) | 定期実行バッチ（1時間毎） |
※ バッチの実行が他のユーザーのアクセスに影響を及ぼさないかを確認するために対象として挙げていますが、実行時間の調整等で運用回避する方法も模索すべきです。
また、夜間バッチ等はユーザーアクセスが少ない時に実行されることから、性能テストの対象となる場合はバッチ単体のスループット計測が目的となる傾向があります。（趣旨がずれるため詳細説明は割愛します）
シナリオ例
例として、ECサイトにおける主目的の機能となる決済処理のシナリオは以下の通りです。
「TOP画面（アクセス量の多いページ）」から「決済（システムの主目的となる機能）」まで一気に進むシナリオになります。
厳密に考えると全てのユーザーが決済完了までの動線を辿るわけではないので、ログインするまでのシナリオやTOP画面のみアクセスするシナリオ等を別途作成して、それぞれのシナリオで負荷量とその実行比率（あるいは割合）を調節する必要があります。
例外
前述のシナリオ例ではユーザー操作を模倣して作成していますが、テストの目的によっては必ずしもそれが正しいやり方とは限りません。
例えば、決済サーバーのスペック変更（プログラム変更なし）に伴う性能テストの場合は、決済処理のみをテストすればよいため、決済のAPIのみを単体のシナリオとして実行することもあります。余計なテストを含めないためには事前に要件を確認することが重要です。
対象外とすべきシナリオの考え方
もし対象シナリオを選定する際に「あれもこれも、あとそれもー」と大量のシナリオを実施することになった場合、負荷生成ツールの自動実行スクリプトの実装や、テスト実行にかかる作業工数が肥大化し、結局のところ期間内に終わりません（泣）ということになってしまう可能性があります。
そうならないためにプロダクトオーナーには最小限のリスクを許容していただいた上で「ムダの撤廃、作業コスト削減、生産性向上、働き方改革」などの大義名分を掲げ、強い使命感を持って対象シナリオを絞り込むための交渉をしてください。
交渉材料としてテスト対象外とすべきシナリオの考え方を説明すると、運用時に起こりうる悲観的な状況を想定し、目的を満たせないことで起こる損失の度合いで検討すると良いと考えます。
逆に、以下の様な機能については予算、工数の都合によって優先度を下げる、あるいは除外してもよいのではないかと考えます。
| 機能・処理・ページ | 例 |
|---|---|
| 使用ユーザー数が少ない機能 | 管理者機能 |
| 性能が低いことで直接的な損失にならない機能 | ユーザー退会 |
| 類似機能、且つサーバーの同じリソースを使用している | 別ページで同じ検索機能 |
| データベースへのアクセスが発生しない静的コンテンツのみのページ | 説明・ヘルプページ |
| 付加価値として実装されている、主目的の実行とは直接関係のない機能 | 履歴・ポイント参照 |
シナリオ詳細
対象シナリオの動線が決定したら、今度はシナリオの詳細となる以下を定義していきます。
- トランザクションの定義
- 滞留時間の設定
トランザクションの定義
トランザクションについて、ISTQBのシラバスでは以下の様に定義されています。
トランザクションとは、開始時点から1 つ以上のプロセス（リクエスト、操作、操作プロセス）が完了するまでにシステムが実行する一連のアクティビティのことである。 トランザクションの応答時間は、システムの性能を評価する目的で測定することができる。 性能テストでは、この測定値を修正や最適化が必要なコンポーネントを特定するために使う。
要するに、対象シナリオに含まれるリクエスト群の計測対象の範囲を定めたものになります。
例えば1ページビューを1トランザクションと定義した場合、メインとなるリクエストの他にサブのリクエストやリダイレクト、静的コンテンツの取得、機能実行に必要なAPI等が含まれる可能性があり、それら全ての応答結果の合計をレスポンスタイムとして計測します。
負荷生成ツールの制約
JMeterなどの負荷生成ツールを使用する場合、Webブラウザーの挙動を完全には模倣できません。（厳密には同じ様な振る舞いをするようにJMeterにプログラムを実装できる場合もありますが、それはブラウザーの挙動ではなくJMeterの挙動となります。）
そのため、WebブラウザーがJavaScriptをダウンロードした場合は必要に応じてJavaScriptのプログラムを自動的に処理して機能を実行しますが、JMeterではJavaScriptのプログラムを処理しないため、JavaScriptをダウンロードするまでの時間のみが計測対象となります。
実際に確認してみると…
Webブラウザー（例ではGoogle Chrome）の開発者ツールを開いた状態（F12押下）で本サイトのとあるページを開くと、以下の様に主となるリクエストの他にスタイルシート（CSS）やJavaScript（JS）等の大量の静的コンテンツを取得していることがわかります。
リクエストを一つずつ確認すると、ドメインがGoogleのサイトだったりするものが含まれるので、テストの対象外となるサイトにはアクセスしないように除外する必要があります。
また、クラウドサービスが提供しているストレージサービスに静的コンテンツを格納していてそこから直接取得しているような場合、それはクラウドサービスの性能テストになってしまうため対象外としてもよいという考え方もあります。
例
先ほどのECサイトにおける決済シナリオに対して、ページビュー毎にトランザクションを定義すると以下の通りになります。
ログイン処理とログイン後TOP画面が同じトランザクションになるのは、ログイン処理を実行すると、ログイン完了後にログイン後TOP画面へ自動的に遷移するためです。商品検索処理と決済処理も同様です。
滞留時間の設定
ユーザー操作をある程度模倣するため、ページビュー毎に滞留時間を設けます。
滞留時間の考え方は負荷生成方法によっても検討の余地がある部分ではありますが、1仮想ユーザーの動線の再現性を高めたい場合には、ユーザーが各ページをどのくらいの時間参照しているかを検討した上で設定します。
例えば、TOP画面へのアクセス後にログイン画面へ進む場合はそんなに時間を要しないですが、ログイン画面でログインIDとパスワードを入力する場合は時間がかかる想定です。（一定のユーザーはブラウザーに記憶させる場合があるので一概には言えませんが…）
ただ、現実に即した長い滞留時間を設定してしまうと、その分だけ目標負荷量を達成するために仮想ユーザー（スレッド）を大量に作成することになります。
その場合、スレッドの大量生成のために負荷生成用のサーバーを増設しなければいけなくなるケースもあります。
そもそも滞留時間には個人差が大きいことから実のところ正解などないため、現実に即した滞留時間を必ずしも追求していく必要はないと考えます。
また、滞留時間は生成するための負荷量（特に時間あたりの処理時間）に大きく影響するため、負荷量の調節に滞留時間の調整が必要になる場合もあります。
必ず設定すべき滞留時間
実際にシナリオを実行する場合、1仮想ユーザー（スレッド）がシナリオを1回完了した後、また同じシナリオを最初からループ実行します。
正常時は特に問題はないのですが、例えばログインに失敗した場合にそのまま後続の処理を継続させると決済処理に進めなくてエラーが発生するので、ログインに失敗した時点でエラーとしてまた最初からループ実行するように設定しています。
もしエラーになってから次のループを開始するまでの間に滞留時間が設定されていない場合、ゼロタイムでのアクセスとなるためここで負荷が上昇してしまいます。
特に、システムへの負荷が原因で大量の仮想ユーザーがエラーとなった場合、エラーとなった仮想ユーザー全てがシナリオの最初のページへゼロタイムでアクセスしてしまうため、サーバーダウンの原因になってしまう可能性があります。
そのため当社ではシナリオの先頭には必ず滞留時間を設けることをルール化しています。
例
先ほどのECサイトにおける決済シナリオに滞留時間を定義すると以下の様になります。
ループの概念も考慮しました。
以上で対象シナリオ（運用プロファイル）の1つが完成となりました。
この対象シナリオをテスト仕様として提示する場合、当社ではドキュメントに以下の通り記載します。
対象シナリオ詳細：【EC-1】決済シナリオ
| 識別子 | トランザクション | 滞留時間（秒） |
|---|---|---|
| EC-1-01 | 画面 | 3.0 |
| EC-1-02 | ログイン画面 | 6.0 |
| EC-1-03 | （ログイン処理）ログイン後TOP画面 | 5.0 |
| EC-1-04 | （商品検索処理）商品一覧画面 | 5.0 |
| EC-1-05 | 商品詳細画面 | 5.0 |
| EC-1-06 | 購入手続画面 | 3.0 |
| EC-1-07 | （決済処理）決済完了画面 | 5.0 |
| EC-1-08 | （ログイン処理）ログイン後TOP画面 | 5.0 ※ |
※ 最後の滞留時間は【EC-1-01】TOP画面を実行する前に設定されます
さいごに
いかがでしたでしょうか。
今回は対象シナリオ（運用プロファイル）の話ができたので、次は対象シナリオを使ってどのように負荷をかけるのか（ロードプロファイル）の話に入っていきたいと考えています。
今後も性能テストについて深堀りしていきたいと考えていますので、次回記事もよろしくお願いいたします。
連載一覧
性能テストのススメ #1 性能テストの目的と種類
性能テストのススメ #2 テスト計画
性能テストのススメ #3 対象シナリオ（運用プロファイル）
性能テストのススメ #4 テストパターン（ロードプロファイル）第一章_構成要素
性能テストのススメ #5 テストパターン（ロードプロファイル）第二章 負荷量（入門編）
