負荷テスト実施要/実施不要の判断基準を示すマトリックス

要件フェーズ、概要設計フェーズで負荷テストの要不要の判断をする材料として、実施要/実施不要 マトリックスを作ってみました。
結構前に書いたもので、うろ覚え知識の中で適当なことを書いているかもですが、自分の思考整理として置いておきます。

前提となる情報

マトリックスの前に前提となる情報を記載します。

ここでの負荷テスト

負荷テスト支援サービス | テスト支援サービス | インターネットサービス | テクマトリックス株式会社
に記載があるロードテストを指して「負荷テスト」と言っています。

理想は

どんな機能においても負荷テストは実施すべき

現実は

納期、工数の問題(短い、足りない)でできない場合がある。
重要な機能を対象に負荷テストを実施する。

対象アプリケーション

Web アプリ 、ストレージは RDB に対する負荷テストを想定しています。

以前書いた記事

初めて負荷テストを実施した時の感想を初負荷テストで、得られた知見 | Monotalk にまとめています。
よろしければこちらもご確認ください。

マトリックスのパラメータ

• バッチ/オンライン
  バッチ処理かオンライン処理かを表します。

• 大量データあり/大量データなし
  大量データの CRUD のありなしを示します。

• アクセス量 多い/少ない
  アクセス量[リクエスト数]の多い/少ないを示します。
  オンライン処理のみのパラメータと考えます。

• 外部サービス連携あり/連携なし
  外部 Web API の呼び出し(でなくても、自分達で内部処理をコントロールできない API)との連携あり/連携なしを示します。

• 高負荷クエリの発行あり/発行なし
  負荷の高いクエリの発行あり/発行なしを示します。

マトリックスの結果値

• 負荷テスト
  要不要でいくと、理想は要だと思ったので、やったほうがいいですよのレベルで記載。
  5を 必要、1を 不要 と位置づけます。

• 改善施策
  負荷テストで問題がでた、または出そうな場合の改善策を記載。

  • A
    Index の有無。
    適切な Index が貼られている場合は、Table の分割等を検討する。

  • B
    プログラム実装で、非効率な処理実装がないのか確認する。
    RDB であればデッドロックを疑うのもいい。

  • C
    参照系で外部サービスの Cache 化。
    更新系であれば非同期での更新を検討する。

  • D
    クエリのチューニング。
    RDB 以外のストレージを使うことを検討する。

  • E
    並列処理で発生する問題、Java であれば Syncronyzed の範囲が広すぎる等。
    ThreadLocal 等に対象実装を置き換えできないか検討する。

マトリックス

アクセス量が多いテスト以外は、負荷テストツール無しでも確認できるのでそのあたりを実施すべきテストフェーズできちっと拾いたいものです。

以上です。