第105回：　負荷テストの設計

≡ はじめに

「ASTERセミナー標準テキスト」の138ページについてです。

前回は、「性能テストの設計」について書きました。今回は「負荷テストの設計」について書きます。

前回の復習となりますが、「性能テスト」は、簡単に言えば、「スループット、レスポンスタイム、リソース使用量を測定し、期待結果と比較して評価すること」です。

すべてのテストに共通なことですので書く必要はないのですが、「測定した結果を事前に用意した期待結果と比較すること」が重要です。
（書く必要が無いと言いながら書いたのは、特に「非機能テスト」の全般において、事前に期待結果を用意しない人が多いからです）
「ｘｘさんの感覚で『こいつは問題になる（ほど遅い）』と思ったらバグ票をあげてください」と言われて、期待結果を用意せずに性能テストを行う人がいるのですが、それ、アカンやつです。（笑）

※　探索的テストにおいても、ドキュメントにはしないけど、操作する前に期待結果を思い浮かべて、操作する方が良い結果になります。

今回のテーマである「負荷テスト」は、「1. 徐々に負荷を高くすることによって性能はどう変化するか？」、「2. スペックを超えた負荷がかかったときに、システムが重篤な問題（生命・財産・環境の問題）を起こさないこと」を評価するテストです。

上述の通り、やることは「性能テスト」と非常に似ています。同じといっても良いです。「負荷テスト」のポイントは、普通ではないこと（＝負荷）のかけ方です。

前回、

性能テストが性能要件を満たしていることの品質確認が主目的のテストであるのに対して、負荷テストの方はソフトウェアのロバストネスを確認することが主目的だからです。

と書いた通りです。

ここで「ロバストネス」というのは、「負荷がかかっても機能が正常に動作する性質」のことです。（“ロバストな車”と言えば、横風が吹いても操舵がみだれないとか、路面が濡れていたり砂利道や石畳でもブレーキが利くとか、そういう車のことです）

負荷以外にも、環境の変化や部品バラつきなど、いわゆる「外乱」に強い性質についてもロバストネスと呼びます。「デグレード（ハードウェアの劣化）」、「環境の差（開発環境と、顧客の使用環境との違い）」、「部品バラつき（粗悪な調達品）」の３つが代表的な「外乱」で、それぞれをさらに分解していくと多数の外乱が見つかりますが、結局どれも、「期待した動作前提条件と違う」というだけですので、どれかの変化に対してロバストならだいたいOKです。言い換えると、後で出てくる「負荷のかけ方」については悩まなくて良いです。（と、言われてもワケ分からんと思いますが、この連載では深追いしません、、、。）
なお、robustnessは、日本語で、頑健性、頑強性、強靭性、堅牢性と訳されることがありますが、ruggednessの訳に堅牢性が使われることもあるので、カタカナでロバストネスと表記することをお勧めします。その際に「ロバストネスって日本語で言うとなんだ？」と質問されてはじめて、「頑健性のことです」と答える感じでお願いします。

≡ 負荷テストの“負荷”について

負荷テストの種類として、「スパイクテスト」や「ソークテスト」という言葉を聞いたことがあるかもしれません。JSTQBの用語集やシラバス（FL-AuT）では、それぞれ、

スパイクテスト（spike testing）
システムが、ピークロードの急激な発生から定常状態に戻る能力を判定するためのテスト。

ソークテスト（soak testing）
大きなサンプルサイズに対して、通常のユーザーをテスト担当者として、事前に定義したテストシナリオに限定されず実施するテストである。また、ソークテストは実際の利用環境に基づいて実施される。

とあります。スパイクと聞くと、野球やゴルフで使用するスパイクシューズの裏についている釘のような突起物や、オシロスコープなどの波形が乱れるスパイクノイズが思い浮かびます。
ソークというと、「急な雨に降られて、ずぶ濡れだ」というときの「ずぶ濡れ」のイメージでしょうか。

負荷テストに限りませんが、テストタイプの名前には、暗喩（「～のような」をつけずに喩える）が使われることが多いように思います。その方が感覚的に分かりやすいからかな。
でも、通じないものも多いんですよね。初心者泣かせ……。　＞＜。

ところで、暗喩ですと「XXテスト」が多くなってしまいますので、そのチームではしっくりきても、他のチームに伝えたり、新しいメンバーに教えたりするのが大変です。大切なことはXX部分がどのような負荷なのかを知っていることです。

スパイクテストなら、針のように、一点に集中して短時間に強い負荷をかけるということですし、ソークテストなら、長時間連続して、実際の利用環境であり得る嫌な負荷をかけ続けるテストということを押さえておきましょう。

話は変わりますが、品質工学（タグチメソッド）では、負荷はノイズの一種として扱います。ノイズは「入出力を妨げるもの」という定義です。

大昔の電話はアナログでしたから、音声という入力が相手先に届くまでの電話線に、近くの電線の電圧の変化などが影響すればそれが雑音になって音声とともに相手に届きました。このとき、音声がシグナル（S）で雑音がノイズ（N）で「SN比」という言い方をしました。
今でも、説明に雑談が多く入ると「SN比悪いなー」と言われますよね。（このnoteでいえば、本文がシグナルで、コラムがノイズ）

ということで、“負荷”の見つけ方について書きます。負荷を見つけるときには、「負荷をかける場所と負荷そのもの」の2つを見つけてください。

■ 基本的な考え方

負荷テストでは、「負荷がかかるとやばそうな場所」と「負荷のかけ方」を見つけます。

自分の経験では、「負荷がかかるとやばそうな場所」探しのほうに大半の時間をかけます。

「負荷がかかるとやばそうな場所」は、性能テストの回でやった「リソース」が基本です。性能テストのまとめを再掲しますので思い出しましょう。

「性能テスト」は、簡単に言えば、「スループット、レスポンスタイム、リソース使用量を測定すること」

こちらは、Windowsのタスクマネージャーの画面です。

こちらの左ペインにある、CPU、メモリ、ディスク、イーサネット、GPUが「負荷がかかるとやばそうな場所」の第一候補です。

その他にも、「I/O」がありますし、システム全体を見たら、「ルータ」、「バランサー」、「データベース」なども、「負荷がかかるとやばそうな場所」の候補です。

テスト対象ごとに違いますし、ブラックボックスでは分からないこともありますので、「負荷がかかるとやばそうな場所」を見つけるときには、システムのアーキテクチャを熟知した開発者に協力してもらうことが必要です。特に、I/O等は、開発者に聞かないと分からないと思います。「負荷がかかるとやばそうな場所」のことをボトルネックと呼ぶことがあります。

2011年に、東日本大震災を受けて、テレビ局が義援金への協力を呼び掛けました。これにより、義援金口座に振り込みが殺到し、勘定系システムの取引明細の件数が1日に格納できる上限値を超えて「大規模なシステム障害」が発生したことを覚えているかもしれません。

ボトルネックを見つけるのは意外と難しいことです。

次は「負荷のかけ方」です。

■ 私の方法

私は、「大・小」、「長・短」、「多・少」の6つの負荷を考えます。「大きなシステム（オプション装置を全て装備するなど）」と「小さなシステム（オプションを一切つけないなど）」、「長時間動作」と「短時間に強い負荷」、「多くのデータ」と「少なく（壊れた）データ」という６つをボトルネックに与える方法を設計します。

■ HAZOPのガイドワードを使う方法

HAZPOとは、「Hazard and Operability Study」のことです。

簡単に言うと、「ハザードを想定し、ハザードが引き起こし得る危険事象をガイドワードを用いて挙げて安全についてのリスクの評価を行う方法」です。
私の方法で書いた、「大・小」、「長・短」、「多・少」をきちんとしたものがガイドワードです。ガイドワードを使うことによって、「設計意図・利用意図からの外れを想起」します。ガイドワードは11個あります。
　・　存在：　無(no)
　・　方向：　逆(reverse)、他(other than)
　・　量：　大(more)、小(less)
　・　質：　類(as well as、質的増大)、部(part of、質的減少)
　・　時間：早(early)、遅(late)
　・　順番：前(before)、後(after)
の11個です。これらのガイドワードを各ハザードにあてはめることで、安全についてのリスクの評価を行うのですが、「負荷のかけ方」と同じということです。

他にも鈴木三紀夫さんの「意地悪漢字」を使ってもいいですね。

≡ 終わりに

今回は負荷テストの設計について書きました。

「負荷がかかるとやばそうな場所」と「負荷のかけ方」を見つけたら、あとは、性能テストと同じように、負荷の増加に対して、スループット、レスポンスタイム、リソース使用量を測定すればOKです。

次回は、「リグレッションテストの設計」についてです。