性能テストのススメ #4 テストパターン（ロードプロファイル）第一章_構成要素

こんにちは。性能テストグループのけんです。この記事では私が主に担当している性能テストについて、引き続き共有していきます。前回の投稿では対象シナリオについて説明しました。
今回は、対象シナリオを使用してどのように負荷をかけるのかを説明していきたいと思います。

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

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

テストパターン
さいごに

テストパターン

ISTQBのシラバスには性能テストの主要な活動として以下の項目が定義されています。今回のスコープはテスト計画、テスト分析、テスト設計になります。

参考文献：

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

テストパターンとは

「ロードプロファイル」というものがISTQBのシラバスで以下の通り定義されています。

ロードプロファイルは、本番でテスト対象のコンポーネントやシステムにて行うと思われる動作を仕様化するものである。

ロードプロファイルは、指定した数のインスタンスで構成される。

インスタンスは、特定の期間にわたり、定義済みの運用プロファイルのアクションを行う。

インスタンスがユーザーである場合、「仮想ユーザー」という用語を一般的に適用する。

難解ですが、ざっくりと要約すると「負荷のかけ方」を具体的に仕様化したものがロードプロファイルということになります。当社ではロードプロファイルのことを「テストパターン」と定義しており、基本的には「テストパターンの数＝テストの実行回数」として提示しています（再実施や繰り返し実施分は除く）。

テストの目的を明確に

テストパターンを定義するためには、まずテストの目的が明確になっていることが前提となります。そして、その目的に応じたテストの種類を紹介します。

以上が、テストパターンの定義において考慮すべきテストの目的と種類の一覧です。詳しい情報については、過去記事「#1 性能テストの目的と種」でより詳細に説明していますので、ぜひご確認ください。

目的が明確になることで、適切なテストの種類を選定できます。そして、テストの種類が決まることで、負荷をどのようにかけるべきかが大まかに決まります。その後、具体的なテストパターンを定義していくことになります。要約すると以下の様になります。

目的を明確化

↓

テスト種類を決定

↓

テストパターンを定義

テストパターンの構成要素

テストパターンを構成する要素には以下の4つがあります。

これらの要素をそれぞれ決定してテストパターンを作成します。それぞれの構成要素について説明していきます。

1. 対象シナリオ

対象シナリオ（運用プロファイル）についての説明は前回の記事をご確認ください。ここでは決定済みの対象シナリオをどの様に使用して負荷をかけるかを検討します。大きく２つに分類すると「シナリオ単体」と「シナリオ複合」があります。

シナリオ単体

対象シナリオを単体で負荷をかけて実行します。対象シナリオが複数ある場合、シナリオ単位での性能を一つずつ確認することでボトルネックを特定しやすくなります。対象シナリオが複数ある場合はその数の分だけテストパターン数が増えます。それによってテスト実施回数と作業工数が増加するため、必要に応じてシナリオ単体でのテスト対象を選別してください。

シナリオ複合

複数の対象シナリオを同時に負荷をかけて実行します。より運用想定に近い負荷を設定することで、テスト結果の信頼性が高くなります。シナリオ単体と比較するとテストパターン数が少なくなるため、テスト実施回数と作業工数は少なくなりますが、ボトルネックの特定が難しくなります。

シナリオ単体とシナリオ複合の特性

シナリオ単体とシナリオ複合の特性を以下の表にまとめました。

※ 対象シナリオの数に比例して増減

基本的にはシナリオ単体を実施し、問題なければシナリオ複合を実施することが望ましいです。ただし、限られた作業時間で実施する場合、最終的にシナリオ複合で合格しないといけないことから、始めから最後までシナリオ複合のみを実施するケースが多いのが実情です。

シナリオ複合の検討事項

シナリオ複合の場合、さらに検討すべきことがあります。それは「対象シナリオの選定」と「シナリオ毎の負荷量」です。

対象シナリオの選定

通常は全てのシナリオを複合して実行しますが、運用上におけるユースケースを考慮すると同時に発生しないシナリオがあるため、これらは別々に実施する必要があります。例えば、朝の出勤ラッシュ想定における出勤処理や退勤ラッシュ想定における退勤処理などです。

シナリオ毎の負荷量

対象シナリオ毎にそれぞれ負荷量を設定する必要があります。負荷量は「個別」に設定する場合と「実行比率」で設定する場合があります。各リクエストの負荷量が明確となるデータまたは資料が存在する場合は、データ通りの負荷量を「個別」に設定します。ユーザーアクセス数のデータは存在するけどリクエスト単位では不明確な場合等は、シナリオ毎の「実行比率」を検討した上で負荷量を設定します。

2. Ramp-Up期間・Ramp-Dowm期間

当社ではJMeterの設定に倣って「Ramp-Up期間・Ramp-Dowm期間」で記載していますが、
ISTQBのシラバスでは「ランプアップ・ランプダウン」と記載されており、以下の通り説明しています。

ランプアップ：段階的に負荷を高めていくこと

ランプダウン：段階的に負荷を下げること

Ramp-Up期間

では何のために設定するのかの説明ですが、ISTQBのシラバスではRamp-Up期間について以下の説明があります。

ランプアップにおいては、負荷状態を段階的に変化させて、着実に増加する負荷がシステムの応答に与える影響をモニタリングすることが望ましい。

これにより、ランプアップに十分な時間が割り当てられていること、システムが負荷を処理できることを確認できる。

いきなり大量の負荷をかけて「うまくいきませんでした」と言われても、それはそうでしょうとしか言いようがありません。負荷を徐々に上昇させることで、どのタイミングで性能が落ちるかを確認しましょう、ということですね。また、Ramp-Up期間を設定しない場合、全てのスレッドの最初のリクエストが時間のずれなしで同時に実行されるため、非常に負荷が高くなります。この瞬間的な負荷を分散させるためにRamp-Up期間を設定する必要があり、基本的に当社では必ず設定しています。
稀に、瞬間的かつ同時の実行を確認したい！シナリオのループは不要！というご要望があります。こちら当社で対応はしていますが、運用想定の負荷か？という観点ではあまり現実的ではないことと、初回アクセス時のリクエストのみのデータを元に出した統計が応答性能の評価としては適切とはならないことから、なるべく負荷テストを別途で実施することを推奨しています。

Ramp-Down期間

Ramp-Down期間を何のために設定するのかは、残念ながらISTQBのシラバスには記載されていません。当社で主にRamp-Down期間を設定するケースは、突然のピーク負荷から定常状態に戻るまでの一連の性能を確認するテスト、つまりスパイクテストの実施時になります。特に、システムがオートスケール構成の場合、スケールアウトしたコンポーネントが負荷の減少によって適切にスケールインするか確認するためにRamp-Down期間を設定することがあります。

3. 負荷継続時間

「負荷継続時間」という用語はISTQBのシラバスにはありません。当社では「一定のスレッド数で負荷を継続させる時間」を負荷継続時間と定義しています。

負荷継続時間の長さはテストの目的によって設定します。もちろん設定しない場合もあります。

4. 負荷量

負荷量とは、システムに負荷を生成するために設定するための量のことで、スレッド数かスループット、またはその両方で定義する場合があります。

スレッド数

当社ではスレッド数について以下の通り定義しています。
「対象シナリオを同時に並列で実行する数です。同時に接続するユーザー数に相当します。」

因みにISTQBのシラバスには「コンカレンシー」というものが以下の通り定義されていますが、「コンカレンシー＝同時/並列に実行されるスレッド数」と解釈してよさそうです。

コンカレンシーとは、同時/並列に実行されるスレッドの数を示す尺度である。

システムとのやりとりでは、同時/並列ユーザーの数を表すこともある。

ここで注意したいのはスレッド数は同時かつ並列で実行されるユーザー数を表すものであり、実行される総ユーザー数とは異なる点です。例えば、以下の図のパターン1では生成するスレッド数は1つですが、1ループ目をユーザーAで実行し、2ループ目をユーザーBで実行しているため、1スレッドで2ユーザー実行したことになり、1スレッド＝1ユーザーとはなりません。

パターン2は「スレッド数＝ユーザー数」となりますが、パターン1と比較すると負荷量は2倍になります。
同じユーザー数でもスレッド数の定義方法によって負荷量が変動するので、より運用想定に近い負荷量でテストしたい場合はスループットを確認すべきです。

スループット

スループットについて、ISTQBのシラバスでは「システムスループット」と定義されており、以下の説明があります。

システムスループットとは、単位時間内にシステムが処理する特定のタイプのトランザクション数を示す尺度である。

例えば、1時間あたりの注文数や、1秒あたりのHTTPリクエスト数などである。

システムスループットは、ネットワーク上を移動するデータ量であるネットワークスループットとは区別する必要がある

一般的に使用される「ネットワークスループット」とは別であるということがわかります。性能テストにおいては「システムスループット」の使用頻度が高いため、当社では「システムスループット＝スループット」として定義しています。スループットは「計測対象の実行回数 / 時間範囲」で表され、実行回数と時間範囲の単位は要件によって異なります。

スループットの単位

スループットの単位には以下があります。

※ スループットの単位とは違うかもしれませんが、参考値としてよく検討されるデータなので紹介しています

表に記載の単位について、一度定義した上で説明しておけば後からの説明が楽なのですが、馴染みがない方だと認識齟齬が発生する可能性があるため、当社では表の定義例の通り「100リクエスト/秒」の様に表記しています。また、要件によっては「1,000ログイン/3分」や「50,000回シナリオ実行/10分」などの場合もあるので、全てにおいて対応可能な表記はやはり「計測対象の実行回数 / 時間範囲」となります。

スループットの時間範囲

スループットの時間範囲はできる限り短い範囲で定義することが望ましいです。例として10万DAU（100,000ユーザー/日）というアクセスログがあった場合、1分間あたりで計算すると「100,000ユーザー / 24時間 / 60分＝ 69.44ユーザー/分」となるのでこれで負荷をかければいいよね…とはなりません。
なぜならシステムにアクセスが集中する時間帯とそうではない時間帯があるからです。例えば以下の表では一日の総ユーザー数は10万ですが、20時に2万ユーザーのピークアクセスあるので「20,000ユーザー/1時間」の負荷量でテストをすべきと考えます。これを分間スループットにすると「333.33ユーザー/分」となり、先ほど算出した「69.44ユーザー/分」から見ると5倍近い負荷量となりました。

さらに言うと、1時間の中でも波があるので、より詳細なデータがあればそれに合わせたスループットを定義してください。
単位の粒度は、以下の様に細かい方がより良いです。

データがない場合

新規サービスの新規稼働など、アクセス量のデータが存在しないこともあると思います。その場合は現状で取得可能な粒度の粗いデータから予測値を概算することになりますが、最終手段として負荷倍率をかける方法があります。先ほどの例で負荷量を5倍にすると「100,000ユーザー / 24時間 / 60分 * 負荷倍率5倍＝ 347.22ユーザー/分」となり、おおよそ近いものになります。ですがそもそも負荷倍率を何倍かけるかというのはテスト対象のシステムがどの様な使われ方をするのかで大きく変わってくるため、一概に何倍すればよいという規定はありません。そのため、予測値から検討する場合はどうしても最終的にはこの負荷倍率でいこう！という「決め」が必要となります。
ここで気を付けたいのは、決めた負荷倍率で性能テストを実施しても、運用開始してからのアクセス数の実績データとはどうしても乖離が出るため、後になって実施した性能テストの妥当性について問題となる可能性があることです。これを回避するため、できる限り高い負荷倍率をかけるという力技で解決できればいいですが、負荷をかける側と受け側（対象システム）共に費用面の兼ね合いが発生します。
個人的に最も大切と考えるのは、決定権あるいは責任を持つ方にテストを検討・決定した内容をしっかりと伝えてリスクを認識してもらうことです。これによって、テスト実施時よりも遥かに高い負荷が発生した場合の対策を検討するというタスクが発生するはずです。
対策が決定していれば、万が一に備えた上での運用を開始できるはずです。アクセス量のデータが存在しないときに負荷量を決定するためのポイントを以下にまとめました。

・想定の負荷量を可能な限り予測して検討

・検討結果に負荷倍率をかける（コストが許せば負荷倍率を上げる）

・実運用時との負荷量の乖離によるリスクの報告

・想定以上の負荷が発生した場合の対策を決定