こんにちは。
QAのinomataです。
パフォーマンスの問題は、顕在化するとシステム停止や機能の停止を余儀なくされたりと、インパクトが大きい可能性が高いです。個人的な位置づけだと、
セキュリティテスト ≒ パフォーマンステスト >> 機能テスト
くらいだと思ってます。しかもパフォーマンスの問題は修正が大変（すぐ修正できない）な場合が多いので、しっかりテストをやっておく必要があります。
ただ、ひとつの問題として、何をすればいいのか分からないんですよね。私自信も、最初は何をすればいいのかわかりませんでした。パフォーマンステストはセキュリティテストに次ぐ重要度にもかかわらず（恣意的）情報が少ないのです！！本屋に行ってもそんな本はほとんどありませんし、Google先生に聞いてもJmeterの使い方くらいしか出てきません。とは言ってもどうにかやらなくてはいけません。
今回は私がどうにかやってきた、パフォーマンステストの進め方ポイントをまとめてみたいと思います。
- まずパフォーマンステストの目的を決めよう
パフォーマンステスト（性能評価）といってもいろいろあります。同時にどれくらい使えるのか、連続稼働時間がどれくらいなのか、レスポンスはどれくらいか、システムがどこまで耐えられるか。パフォーマンスを測りたいからには目的があるはずなので、それを決めましょう。
- 目的が決まったら要件を決めよう
具体的な数値を持って要件を決めましょう。上記の例であればこんな感じ。
・同時にどれくらい使えるのか→同時1000ユーザーの使用を保障する
・連続稼働時間がどれくらいなのか→300時間の連続起動ができる
・レスポンスはどれくらいか→1秒以内でレスポンスがある
・システムがどこまで耐えられるか→平常時の倍の負荷まではシステムがダウンしない
要件がない場合、200%の確率で後で問題になります。webシステムであれば以下のようなテンプレートがあればよいでしょうか。
・単位時間当たりの処理数
・同時使用数
・応答時間
・エラー率
これらはお互いに関連性があるので、どれも抜けてはいけないのです。これ以外の重要な項目がないかも検討してください。
- テストケースを考えよう
要件も決まったのでテストケース組んでいきましょう。その際のポイントをいくつか紹介します。
・テストケースはユーザーの操作を意識する
テストはユーザーの操作に忠実でなければ、本番の挙動とかけ離れてしまいます。ここはユーザーの操作をシミュレーションしましょう。たとえば買い物サイトの場合以下のような操作がありますが、具体的にはこれらを網羅していきます。
・どこのカテゴリを見るのか。
・どれくらい検索するのか
・いくつ買うのか
・レビューを書くのか
・etc
ただこのような操作パターンはほぼ無限なので、全部を再現するのは現実的ではありません。どうにかこうにか間引いて、現実的なテストにしましょう。ABC分析とかが使えそうですね。またファイルダウンロードなど、パフォーマンス的に高負荷となる操作が別にあるのであれば、それは別枠で考える必要があります。
ひたすらログイン/ログアウトを繰り返すユーザーはそうそういません。申込フォームの開始から登録まで5秒で完了するユーザーもそうそういません。本番を想定するテストであれば画面遷移、参照する機能、入力フォームでのユーザーの思考時間等を考慮する必要があります。
・使うデータの検討
毎回同じデータを参照した場合、キャッシュによってパフォーマンスが良くなる場合があり、テスト結果の信頼性にかける場合があります。参照、または登録するデータは本番と同じようなデータにしましょう。
・テスト環境とタイミング
本番でのパフォーマンスを図りたいのであれば、本番と同じシステムを用意するか、本場でテストするしかありません。テストの目的に合わせてシステムの構成（ネットワーク機器、ロードバランサ等も含める）、リクエストを送る場所（ファイアーウォール越しかどうか等）、定期バッチ処理のタイミング、本番で稼働させる各サービス等も考慮しなければなりません。
・エラーの定義を決める
テストのエラーになる条件を決めます。HTTPのエラーコードが返ってくればエラーなのか、専用のエラーページを表示すればエラーなのか決めておきましょう。専用のエラーページはHTTP的にはエラーではないので、Jmeterではアサーションを仕込むなど、ひと手間必要になることを忘れずに。
・ログは何を見るか
何を見るのかは重要です。リクエストをかける外側と、処理を行う内側のログをとります。内側のログは、ログを出すこと自体がシステムに負荷をかける場合があります。ログの出力は、目的に合わせて必要最小限に抑えるのがよいでしょう。
・どれくらい負荷をかけるのか
基本的に要件を満たす分、ピーク時を想定した負荷の2種類があれば望ましいでしょう。信頼あるデータが必要なので、現実的な範囲で負荷をかける必要があります。過大、過少になってはいけません。
上記でもありますが、各要件を矛盾しないような量にしないとダメです。
・どうやってテストするのか
同時1000人のログインとかは手動じゃできませんよね。パフォーマンステストは、基本的にツールを使わなければ実現できません。どんなツールを使って、どうやって結果を判断できるのかを事前に検討しておきましょう。なんだったら外部に委託してしまうのも手でしょう。専門家に任せるのと、リスク移転の意味を込めて。
テストは繰り返しできるように準備しておくことも重要です。本番を使う場合は時間的な制限があったりするので、なるべく短い時間でかつ繰り返し実行できるようになっているとよいです。また、ボトルネックは一回のテストで一ヶ所しか発見できません。システムのパフォーマンスは一番のボトルネックに引きずられます。なのでパフォーマンステストは、テスト→修正→テスト→修正→テスト...と繰り返すことは必然です。となるとやはり繰り返し実行できることは重要です。ボタン一つで実行できるほど簡素化されているとよいですね。
- テストを実行しよう。
いよいよ作成したテストを実行します。ここまで事前に準備してきましたが、実行中でしかわからない情報もある場合もあるので、実行中は人が立ち会った方がよいです。
- 結果を検討しよう
得られた結果が決定した要件に沿った結果かどうかを検討します。結果の検討は一番重要かつ難しいフェーズです。応答時間などの外側からの結果とサーバのCPU等の内側の結果を突き合わせて、何が原因かを探ります。このためにも適切にログをとりましょう。有識者からのヒアリングもしましょう。
- その他
・いつテストしたらいいのか
なるべく早い方がいいには越したことはないですが、早すぎてシステムが動かなければ意味がありません。これはなかなか難しいのですが、開発の段階で小さい機能から段階的にテストをしていくのが一番です。パフォーマンステストはいきなりシステム全体をテストするという性質から、原因の究明が困難になりがちです。まして後工程では修正が困難な部分に手を入れなくてはならないと最悪なので、やはり小さい機能のうちからこまめに計測しておくのがよいでしょう。
・誰がやったらいいのか
これはいろんな分野の人が数人集まった方がよいでしょう。数人で意見を出し合った方が解析や検討が早いでしょう。重要なテストなので、それなりにコストをかけて取り組みましょう。
さて、一通り書いた感じですが、考えることがいっぱいありますね。これでもまだ十分ではないでしょう。大変すぎます。しかし手を抜くと何十倍ものコストで跳ね返ってくるので、プロジェクトがアツくなる前にしっかりテストしておきましょう。
