3.2. 性能テストの実施方針

このトピックでは性能テストの実施方針について検討していきます。
3.1. 性能テスト方針』で検討した方針を踏まえ、どのように性能テストを実施していくのか検討していきます。
具体的には以下のトピックについて検討してきます。
    • 性能テスト観点
    • 性能テストシナリオの方針
    • 性能テストデータ方針
    • 負荷ツールの選定

 

性能テスト計画で検討する他のトピックとの関係

このトピックと関係がある主要なトピックは、以下の通りです。

3.2.1. 性能テスト観点

性能テストでは、システムが性能要件通りの性能を出しているかどうかという観点で検証を行います。

このトピックでは、何を持って性能通りの性能が出ていると評価するのか検討します。性能要件にて測定指標やその目標値は定義されていますが、性能テストの実施時にどうやって測定指標を測定するのか、どうやって目標値に収まっていることを評価するのかについては性能テスト計画にて検討する必要があります。

以下に性能要件ごとの測定方法の例を示します。実際のプロジェクトでは以下の例を参考に、システムの構成や使用する製品に合わせて確認方法を検討して下さい。また、生データのまま目視で確認することは難しく、確認漏れの原因となるため、評価方法として、測定したデータを可視化して評価することも併せて検討して下さい。

性能要件 測定方法の例
業務量
  • システムに対して単位時間あたりに送信したリクエスト数で評価する。
ターンアラウンドタイム
  • クライアントから見てリクエストを送信してからレスポンスを受け取るまでをターンアラウンドタイムとして定義している場合

使用する負荷ツール※から見たターンアラウンドタイムに当たるメトリクスを収集して評価する。

  • サーバ上での処理時間としてターンアラウンドタイムを定義している場合

ロードバランサにて、処理開始(リクエストを受け取った瞬間)や処理終了(レスポンスを返した瞬間)が分かるようなログを出力するように設定し、実行後のログから処理時間を算出する。算出には自動計算ツールを作成して使用する。

スループット
  • バッチの実行ログから処理件数と処理時間を取得し、単位時間あたりの処理数を算出する。
データ量
  • 性能テストの実施に当たって投入したデータをエビデンスとして残し、評価する。
  • 性能テスト実施時にDBのテーブルに対してレコード数を確認した結果も合わせてエビデンスに残すことで評価する。
インフラ
  • サーバリソースを取得するOSコマンドを1分ごとに実行し、その結果からCPU、メモリ、ディスク使用率が性能要件を満たしているかどうか評価する。

    ※負荷ツールについては『3.2.4. 負荷ツールの選定』をご参照下さい

    また、性能テストでは評価のための情報だけでなく、性能問題が発生した際の解析に使う情報も収集し、確認する必要があります。確認項目と確認観点、測定方法の例を以下に示します。これらが性能テスト実施時に確認出来る状態でないと、性能問題を解決する際に必要な情報が足りなくなってしまうので注意が必要です。

    確認項目 確認観点 測定方法の例
    CPU処理待ち行列 CPUの処理性能やコア数不足がボトルネックになっていないか サーバリソースを取得するOSコマンドを1分ごとに実行し、ロードアベレージを取得する。
    ページング発生有無 大量のページングが発生していないか サーバリソースを取得するOSコマンドを1分ごとに実行し、ページインとページアウトの情報を取得する。
    ネットワーク帯域使用量 ネットワーク帯域使用量・使用率がボトルネックになっていないか
    • サーバリソースを取得するOSコマンドを1分ごとに実行し、サーバ側でのネットワーク帯域使用量・使用率を取得する。
    • ネットワーク機器側で、製品に合わせた方法によりネットワーク帯域使用量・使用率を取得する。
    ディスクI/O ディスクI/Oがボトルネックになっていないか サーバリソースを取得するOSコマンドを1分ごとに実行し、その結果からディスクI/Oの情報を取得する。
    OS エラーが発生していないか OSのログにより、エラーの発生有無を確認する。
    共有ストレージ 共有ストレージのディスクI/Oがボトルネックになっていないか 製品に合わせた方法でディスクI/Oの情報を取得する。
    ディスク容量が枯渇していないか 製品に合わせた方法でディスク容量を確認する。
    ハードウェア共通 エラーが発生していないか 製品の機能によりエラーが検知されていないか確認する。

      3.2.2. 性能テストシナリオの方針

      このトピックでは性能テストで使用するテストシナリオの方針を検討します。性能テストでは負荷のかけ方も含めてテストシナリオを検討する必要があります。

      性能テストで重要となってくるのは、本番の運用時に性能要件通りに性能が出ることです。そのため、本番でかかる負荷を再現するために、実際のユーザの動きを再現するようなシナリオにすることが基本方針となります。

       

      オンライン機能

      オンライン機能に対するテストシナリオでは、ユーザの動きを再現するために、例えば以下のような点に注意が必要です。
            • ログインしてから該当機能へアクセスする。
      ログインが必要なシステムであれば、ユーザはログイン後に各種機能へアクセスします。そのため、テストシナリオでもログインから実行することで実際のユーザの動きが再現できます。
            • 運用時と各機能へのアクセス数割合が同じになるようにする。
      実際の運用時には、テスト対象機能だけにアクセスがくるのではなく、トップ画面やメインメニュー、システムの主要機能へアクセスが集中します。テスト実施時にかかる負荷もこれらの機能へ集中的にアクセスするようにテストシナリオを検討して下さい。
            • 単一ユーザによるシナリオではなく、複数ユーザによるシナリオにする。

      本番運用時は一人のユーザから大量にアクセスがくるわけではなく、多数のユーザから同時にアクセスが来ます。この状況を再現するために、テストシナリオでは複数のユーザを用いるように注意が必要です。

      バッチ機能

      バッチ機能でも実際の運用と同じ負荷となるようにバッチ実行のテストシナリオを検討する必要があります。テスト対象となるバッチ機能の実行について、例えば以下のような点に注意が必要です。
            • ジョブ管理ツールの定義に従って実行するシナリオとする。

      ジョブ定義上で先行後続の関係や、並列実行を定義している場合、その通りに実行するシナリオとする。

      3.2.3. 性能テストデータ方針

      このトピックでは性能テスト実施で使用するテストデータの方針について検討します。
      投入するデータ量は性能要件を満たす必要があります。『3.1. 性能テスト方針』で初期条件として収集したデータ量に関する性能要件通りとなるよう、各テーブルに投入するデータ量を検討して下さい。
      性能テスト実施時に本番通りの負荷をかけるためには、投入するデータの内容も本番運用時のものと同等となるようにすることが重要となってきます。例えば以下のような観点でデータの内容を検討します。
        • データの内容
      本番運用時のデータでも性能が出ることを検証するために、ダミーの値を使用する際には、運用時に想定される値を入れるようにします。
      また、大量投入時にエラーとならないよう、テーブル間のリレーションシップについても注意が必要です。
        • データの分布
      データの分布は検索実行時の性能に大きく影響します。実際の運用時に想定されるようなデータ分布となるようにデータの内容を検討します。例えば、以下のような点に注意が必要です。
            • ツールによって大量データを作成した結果、本番と異なるような分布になってしまう。
              例えば、ユーザ名は本番運用時には様々な値が入りますが、テストデータで全て同じダミーの値を入れてしまうと、検索時の性能が本番とは変わってしまいます。
            • 自動採番される値について、テストデータの採番方法自に考慮が漏れて、業務仕様と異なる分布となってしまう。
            • 日付データが特定の期間に偏ってしまう。
            • 業務観点で特殊な分布となっている項目を再現できていない。
              例えばサービス開始時に登録が集中し、ユーザの登録日時がサービス開始時期に集中するといったことが起こり得ます。
      また、連携する外部システムを性能テスト実施範囲に含める場合は、外部システムのテスト環境にもテストデータの投入が必要となる場合があります。自システムのテスト環境に投入するテストデータと整合性を保つ必要があるので、外部システムに投入するテストデータの方針も計画時点で検討する必要があります。
      このように性能テストにおけるデータ作成は考慮すべき観点が多くあり、他のテストに比べてデータ作成に時間がかかります。そのため、性能テストが割り当てられたコスト内に収まるかどうか確認する際にはデータ作成にかかる工数の見積もりが過小とならないよう注意が必要です。

      3.2.4. 負荷ツールの選定

      性能テストでは本番相当の負荷をかけるために、システムに対して相当数のアクセスをする必要があります。人力で実施するのは現実的ではないため、システムヘの大量アクセスを自動的に行ってくれる負荷ツールを用いて性能テストをすることがほとんどです。
      このトピックでは性能テストの実施時にどの負荷ツールを使用するのか検討します。検討時には以下のような点を考慮します。
      観点 説明
      導入のしやすさ コストやスケジュールの面から、導入のしやすさが重要になる。以下のような観点で、プロジェクト特性と照らし合わせながら検討する。

      • プロジェクト内に該当ツールの有識者がいるかどうか。
      • どのぐらい学習コストがかかるのか。
      • 環境構築がしやすいかどうか。
      シナリオの柔軟性
      負荷ツールによって、テストシナリオの方針で検討した方針通りのシナリオが作成できるかどうか確認する必要がある。具体的には以下のような点に注意が必要。
      • セッションを維持できるかどうか。

      ログインが必要なシステムでは必須の機能となる。

      • クッキーから値を抽出できるかどうか。

      セッション維持や何らかの機能でクッキーを使用する場合は必須の機能となる。

      • レスポンスデータからCSRFトークン等を抽出できるかどうか。

      トークンを使用する機能では必須の機能となる。

      • ログインしてから該当機能へアクセスするような複雑なシナリオが組めるかどうか。

      簡単なシナリオでの使用のみを想定したツールもあるため、注意が必要。

      かけられる負荷 負荷ツールも無制限に負荷をかけられるわけではない。ツール自体の限界や、ツールを使用する端末のスペックによってもかけられる負荷の上限が決まってしまうため、注意が必要。
      場合によっては、並列実行可能なツールの使用や、複数端末から負荷ツールを同時実行することを検討する。
      結果の評価しやすさ
      テスト観点で検討した評価方針の通りに実施結果が取得できない場合、テストが実施できても評価することできなくなってしまうので、検討時には注意が必要。評価に支障が出ないようにするため、以下のような観点で検討する。
      • 評価に必要な情報が負荷ツールから取得できるかどうか。
      • 評価ツール単独で可視化までできるのか、それとも可視化ツールとの組み合わせが必要かどうか。

      可視化ツールとの組み合わせが必要な場合、可視化ツールも合わせて選定する必要がある。

         

        注釈

        準備作業時に考慮できていないと、後々性能テストの実施ができなくなるような問題について、以下に例を示します。
        ※性能テスト計画の範疇を超えていますが、計画時点で考慮することによって対処できるものもあるため、参考として記載します。
        • 多要素認証が必要で、負荷ツールによる自動化ができない
          テスト対象機能の性能測定を手動で行うか、画面操作を自動化するようなツールの導入を検討する必要があります。
          あるいは、性能テストの実施時に多要素認証を無効とするような仕掛けをあらかじめ作り込んでおくという手もありますが、本番運用時に多要素認証を有効化し忘れるリスクがあるため注意が必要です。
        • 登録機能や削除機能等で、単純な連続実行ができない
          登録機能や削除機能では、すべてのリクエストで同じ入力値を使用してしまうと、重複登録や削除対象がないことで入力チェックによりはじかれてしまい、連続実行ができなくなってしまいます。そのため、例えば以下のようにして連続実行可能なテストシナリオとなるように検討する必要があります。
            • 登録機能で、重複不可項目について連番等を使って重複不可項目が重複しないようにする。
            • 削除機能で、事前に十分な量の削除対象データを用意するか、登録してから削除を行うシナリオにする。