3. 検討が必要なトピックの解説

3.1. 性能テスト方針

このトピックでは、性能テストに関わる要件、制約を踏まえて、性能テスト全体に関わる方針を検討します。 検討においては、全体テスト計画で検討した内容に加え、性能テスト固有の制約を考慮します。 このテスト方針をベースに詳細な内容を検討します。

 

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

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

3.1.1. 性能テストに関わる初期条件

プロジェクト計画書や非機能要件定義書、全体テスト計画書などをインプットに、性能テスト計画の立案に必要な性能要件・制約事項を初期条件として収集・整理します。

全体テスト計画にて収集した初期条件(『全体テスト計画ガイド』の『4.1.テスト方針』をご参照下さい。)に加え、性能テストでは要件定義で定められた性能要件がインプットとして必要になってきます。具体的には、参考文献『非機能要求グレード』にて記載されているような項目が漏れなく定義されている必要があります。性能要件が要件定義にて決まっていない場合、性能テスト計画が立案できないので、早急に定義して下さい。

また、性能要件が決まっていたとしても、定義が曖昧な場合は性能テスト計画の立案時のインプットとして不十分となってしまいます。性能要件が以下のような観点で明確に決まっていなかった場合も早急に定義し直すようにして下さい。

観点 説明
業務量 性能要件として、想定される業務量が定義されている必要がある。Webアプリケーションにおいては単位時間あたりにシステムへ飛んでくるリクエスト量を業務量として定義することが多い。
ターンアラウンドタイム
(処理にかかる時間)
性能要件として、許容されるアプリケーションの処理時間が定義されている必要がある。

特に、システムにおけるどこからどこまでの範囲に対する処理時間なのかまで含めて決めておかないと、評価するための測定指標が決められなくなるので注意が必要。外部システムとの連携がある場合、外部システムの処理も含めての処理時間なのか、自システムと外部システムそれぞれでの処理時間なのかも要件定義時点で明確になっている必要がある。

また、ターンアラウンドタイムを「一律で○秒以内」のように決めてしまうと、たまたま処理が遅くなってしまったリクエストを許容できなくなるため、順守率やパーセンタイルを用いて定義することが多い。この場合、計測範囲が大きいほどネットワーク起因で順守率が下がる傾向にあるため、計測範囲に合わせた順守率となるように注意が必要。

以下にオンライン機能の性能要件に関する決め方の一例を示す。

    • ユーザ端末からリクエストを送信してから3秒以内にユーザ端末のブラウザ上でレンダリングが完了する。順守率は80%とする。※
    • ロードバランサにリクエストが到達してからアプリケーションの処理が完了し、ロードバランサからレスポンスを返すまでを1秒以内とする。順守率は90%とする。

※フロントエンドがリッチに作り込まれている場合、フロントエンドの性能も考慮する必要があるため、レンダリングまで含めた性能要件を例としている。

スループット
(単位時間あたりに処理できる量)

処理時間だけでなく、性能要件として、アプリケーションの単位時間あたりの処理量も合わせて定義されている必要がある。

多くの場合、バッチ処理に対する単位時間あたりの処理件数が指標となる。この場合は単位時間を明確にするとともに、バッチ処理ごとにスループットを定義する必要がある。

ターンアラウンドタイムと同様に、どこからどこまでの範囲に対するスループットなのかも含めて定義されている必要がある。

データ量

データ量によってもシステムの負荷は大きく変わるため、ユーザ数など、どのテーブルにどれだけのデータ量を格納する想定なのかについても性能要件で決まっている必要がある。

以下に性能要件の決め方の一例を示す。

    • 稼働時はユーザ100万人程度を想定し、5年後にはユーザが500万人に増加する想定とする。
インフラ もしアプリケーションが要件通りの性能を出せたとしても、そのときのサーバリソースが限界ギリギリでは、長期間の運用に耐えることができない。そのため、インフラ面でもサーバリソースの使用率について、性能要件として定める必要がある。

具体的には以下のようなサーバリソースが性能要件で決める対象となる。

    • CPU使用率
    • メモリ使用率
    • ディスク使用率

また、CPUやメモリについては、瞬間的なリソース使用率の高騰が正常に稼働している場合でも起こりうるため、インフラの性能要件ではリソース使用率の閾値を決めるとともに、瞬間的なリソース使用率の高騰を許容するように定めることが多い。

スケーラビリティ 将来的に見込まれる業務量やデータ量の増加、及びその増加に対するシステムの拡張性についても性能要件として定める必要がある。ターンアラウンドタイムやスループット、インフラについて将来の想定を決めて、それらに対し、例えば以下のような要件を決めていく。

    • 何年後かに想定される業務量やデータ量に耐えうるリソースをあらかじめ用意する。
    • 業務量やデータ量の増加に従ってリソースを増強する計画を立てる。
      (段階的に増強することもある。)
    • 業務量やデータ量に合わせて自動的にリソースを増強する。

また、業務量やデータ量の増加に伴ってリソースを増強していく場合は、増強後のシステム構成でも性能要件を満たしていなければならないため、増強後のシステム構成での性能テストも実施する必要がある。

    これらの要件については、以下のようなパターンそれぞれについても一律で定義するのか、それともパターンごとに定義するのか、合わせて要件定義で決定する必要があります。

      • テスト対象機能毎に定義するのかどうか
      • 負荷が平常時の場合とピーク時の場合それぞれで定義するのかどうか
      • 冗長構成をとる構成要素について、縮退状態の場合と冗長構成を維持している状態、それぞれで定義するのかどうか

    全ての機能について性能テスト対象とするのかについても非機能要件として定義する必要があります。ここが明確になっていない場合、テスト実施範囲に関する方針の定義ができなくなります。

    また、性能テストの制約事項として、どれだけのコストが割り当てられているのかについても確認する必要があります。「2.2. 性能テストで実施すること」にも記載したとおり、性能テスト固有で考慮すべき観点は多いうえに、方針によるコスト変動が大きく、他のテストよりも準備に時間がかかる傾向があります。そのため、性能テストのコストを正しく見積もるのは難易度が高く注意が必要です。割り当てられたコストが現実的なものであるかどうか確認し、そのコスト内で性能テストを実施することが困難だと判断される場合には、プロジェクト内でのエスカレーションが必要となります。

    他にも、後述の3.3. テスト環境』にて性能テストに必要な環境の要件を検討する際のインプットとなる、テスト環境に関する制約事項も併せて確認するようにして下さい。具体的には、例えば以下について確認する必要があります。

      • 各環境はどの時期から使えるようになるのか
      • 各環境はどのような構成となっているのか

    3.1.2. 品質・コスト・スケジュール・テスト実施範囲・網羅性に関する方針の定義

    品質・コスト・スケジュール・テスト実施範囲・網羅性に関する方針を検討します。基本的な考え方は『全体テスト計画ガイド』の『4.1.テスト方針』をご参照下さい。
    ここでは、性能テスト固有の考慮点について解説します。システムの性能品質や、どの機能についてテストするのかについては既に性能要件として決まっているので、ここでは性能要件に対して、どこまで性能を保証するのかを検討します。

    テスト品質としては100%の網羅率とするのが理想的ですが、コスト・スケジュールとの兼ね合いから、リスクの低いパターンについては目標とする網羅率を100%から下げることがあります。

    具体的には以下のような網羅性についてどこまでテストするのかを検討します。

    テスト対象機能に対する網羅性

    性能要件にて、全機能をテスト対象としている場合は特に問題はないですが、一部機能をテスト対象としている場合、計画時点で機能単位でテスト対象を決定する必要があります。対象とする機能を選ぶ観点としては、例えば以下があげられます。
          • 処理方式(登録、更新、検索、etc.)ごとに代表機能を選ぶ。
          • ユーザからのアクセスが多い機能を選ぶ。
          • 性能リスクが高い機能を選ぶ。
          • 性能を重要視する機能を選ぶ。

    また、連携する外部システムが存在する場合、外部システムの処理もテスト実施範囲に含めるかどうかについても合わせて検討する必要があります。検討する際に考慮すべき点として以下があげられます。

      • 連携する外部システムの性能が保証されているかどうか
        外部システムが既に稼働中のシステムで性能が保証されている場合は性能テストの実施範囲から外す選択肢も出てきます。
      • 連携する外部システムの性能テストが実施可能かどうか
        外部システムが既に稼働中のシステムで、テスト環境が存在しない、あるいはテスト環境が性能テストに必要な要件を満たさない場合、そもそも外部システムを含めた性能テストが実施できなくなってしまいます。このような場合はシミュレーターによって外部システムとの処理をダミー化することも選択肢の一つとなります。