2. 性能テストについて

2.1. 性能テストとは

性能テストとは、広義の意味では言葉の通りシステムの性能を検証するテストです。しかし、性能と言っても様々な要素があり、性能テストが何を指すのかはあいまいになりがちです。それゆえに、人によって性能テストの定義が異なるということが起こり得ます。
本書における性能テストとは、『テスト種別&観点カタログ』にて定義している狭義の意味での性能テストを指しています。『テスト種別&観点カタログ』では性能・拡張性に関わるいくつかのテスト種別が定義されており、それぞれを簡単に表現すると以下のようになります。
テスト種別 概要
性能テスト 性能要件で決められた業務量を処理した時に性能要件通りの処理速度が出るかどうかを検証するテスト。
ストレステスト 外部からシステムの限界負荷となるアクセスをした時の動作を検証するテスト。主に以下の種類がある。

    • システムの限界負荷となるまで徐々にアクセスを増やした時の動作を検証する。
    • システムの限界負荷となるように短い時間で急激にアクセスをした時の動作を検証する。
    • システムの限界を超えた負荷となるようにアクセスをした時の動作を検証する。
ボリュームテスト システムに限界負荷となる量のデータを投入した時の動作を検証するテスト。
ロングランテスト システムに長時間の負荷をかけた時の動作を検証するテスト。

上記の通り、非機能要件として定められた性能要件(想定負荷、処理速度等)をシステムが満たしているかどうか検証するのが本書で取り扱う性能テストです。

2.2. 性能テストで実施すること

性能テストでは、大きく分けて以下の作業が発生します。
    • 性能テスト計画策定
    • テスト環境の準備
    • 外部連携システムとの調整
    • 性能テストシナリオ作成
    • 性能テストケース作成
    • 性能テストデータ作成・投入
    • 負荷ツールの準備
    • 性能テスト実施
    • 性能テスト結果の評価
    • 性能のボトルネック解消
    • テストの再実施と再評価
上記のうち、負荷ツールの準備、性能のボトルネック解消が性能テスト固有のものとなります。後述しますが、他のテストでも実施することになるテスト環境の準備、テストデータ作成・投入、テスト結果の集計・評価でも性能テスト固有で考慮すべき観点があります。そのため、性能テスト計画では多くのトピックで性能テスト固有の観点が要求され、属人化しやすい傾向にあります。

本書ではそういった観点を記載することで、属人化を回避することを目的としています。より具体的なタスクについては『3.5. タスクと役割分担』にて一覧化しています。

2.3. 性能テストの意義

性能テストを行う意義は、本番稼働時に近い状況下でシステムの動作確認をすることです。

機能テストにより、機能要件通りにアプリケーションが動くことは保証されます。しかし、機能テストは性能に関するテストではないため、システムに性能要件通りの負荷がかかった時の動作保証までは出来ません。本番稼働時のようにシステムに高い負荷がかかっている場合には、CPUやメモリ等のリソース枯渇や、同一のDBレコードアクセスによる競合が発生したり、処理が性能要件の処理時間内に完了しなかったりと、機能テストでは起こらなかったような不具合が発生することがあります。このような不具合は実際に本番相当の環境で本番相当の負荷をかけなければ検出できません。また、このような不具合が本番稼働後に発生してしまうと、画面がまともに動かなかったり、締め日までに処理が完了しなかったりと、業務に多大な影響が出てしまうことが多くあります。そのため、性能テストを実施し、本番稼働時にもシステムが正常に動くことを検証する必要があります。

2.4. 性能テスト計画の意義

性能テストを計画的に進めていかないと以下のような問題が発生する可能性があります。これらの問題により性能テストが十分に実施できなくなってしまうと、最悪の場合システムをリリースできなくなくなったり、リリース後に性能問題が発生したりする可能性があります。
発生する問題 説明
性能テスト実施に必要な作業が漏れてしまう 性能テスト固有の作業はどれも時間がかかるものが多く、検知が遅れるとリカバリが効かなくなってしまうリスクが高い。
性能テスト実施に必要な大量データが用意できない 性能テストでは本番相当の負荷をかけるために大量のデータを環境へ投入する必要がある。データは業務特性を踏まえたものでなくてはならないため、簡単には作成することが出来ない。手作業でできる規模ではないため、どうやって大量データを用意するのか、計画を立てて進めていく必要がある。
テスト実施時に本番相当の負荷をかけられる環境やツールが用意されていない 性能テストでは本番と同等の環境に本番相当の負荷をかける必要があるため、環境の設計や負荷をかけるためのツールの準備が必要となる。どちらも時間のかかる作業であり、計画的に進める必要がある。
性能テストの実施結果を評価する方針がぶれてしまう 性能テストの実施結果はサーバリソースの使用状況や、多数のリクエストに関する応答時間や応答結果等、膨大なデータとなる。これらを生データのままで評価することは難しく、統計をとったり、可視化したりすることが多い。ツールの導入や作成等の準備が必要となるため、計画的に進める必要がある。
性能テストの実施方針に関してステークホルダー間で認識齟齬が発生してしまう 性能テストで誰がどこまで検証するのか、どうやって検証するのか、実施や評価のタイミングで認識齟齬が発生してしまうと、テストの実施ができなくなったり、テストをやり直さなければならなくなったりといった問題が発生する。性能テストの実施にあたり、その意義と実施方針をステークホルダー間で合意する必要がある。

このような問題を未然に防ぐため、性能テストの計画を立案し、計画的に作業を進めるとともに、ステークホルダーと合意形成を行っていくことが重要となります。

2.5.検討時期

性能テスト計画は、各作業を実施するよりも早く立案する必要があります。性能テストで実施すべき作業は『3.5. タスクと役割分担』にて解説しますが、性能テストをするための環境構築が必要となるため、要件定義や設計工程から作業が発生します。そのため、それに伴って性能テスト計画も要件定義時点から始めていく必要があります。具体的には、性能要件が決まった段階から計画の立案を始めるのが理想的です。

2.6.検討事項

具体的な全体テスト計画の検討事項については、以下をご参照ください。
章番号 トピック 概要
3.1. 性能テスト方針 性能テスト計画を立案する上での、基本的な考え方・方針および前提事項を検討する。
3.2. 性能テストの実施方針 性能テストの実施や準備における方針を検討する。
3.3. テスト環境 性能テストを実施する環境の要件を検討する。
3.4. 体制 性能テストの推進体制・役割を検討する。
3.5. タスクと役割分担 性能テストのタスクと役割分担を検討する。
3.6. スケジュール 性能テストのスケジュールを検討する。