性能テスト計画ガイド

概要

本書は、アプリケーション開発プロジェクトの性能テスト計画で検討すべきトピック、及び性能テストを推進・実施する上で考慮すべきポイントを解説するものです。 性能テストを計画・実施する意義への理解を促進するとともに、性能テスト計画の属人化を回避することを目的としています。 本書はウォーターフォールによるWebアプリケーション開発を行うプロジェクトで活用できます。 なお、本書の一部内容は参考文献『全体テスト計画ガイド』と『テスト種別＆観点カタログ』、『非機能要求グレード』を利用することを前提としています。

また、『性能テスト計画書サンプル』にて、本書をもとに作成した性能テスト計画書のサンプルを用意しています。こちらも合わせてご参照下さい。

• • プロジェクトにおける性能テストの方針を決定する。
  • 性能テストを行うための環境の要件を決定する。

1.1. 目的

• • 性能テストを計画・実施する意義が理解されること。
  • 性能テスト計画で検討するべき事項、及び性能テストで実施する作業内容を定義するとともに、それらについて考慮すべきポイントを解説することで、性能テスト計画の属人化を回避すること。

1.2. コンセプト

• • プロジェクト固有の事情に依存せず、横断的に利用できること。  
  • テストの中でも性能テスト計画固有のトピックを中心に解説すること。

1.3. 対象

1.3.1. 想定読者

• • • • 性能テスト計画の策定、またはレビューを担当する人。
      • 性能テストで実施する作業を担当する人。

1.3.2. 対象とするプロジェクト

1.3.3. 取り扱わない内容

• • • • 「プロジェクト計画書」に詳細が記載される傾向にあるトピックの詳細。 例えば、進捗管理、品質管理などの管理方針は「プロジェクト計画書」に記載されることが多いため、本書では詳細な説明は行わない。
      • 見積りや品質の指標についてはプロジェクト毎に過去実績値などを参考に検討するものとし、本書には記載しない。
      • 『全体テスト計画ガイド』に記載のある内容については冗長となるため、本書には記載しない。

1.4. 活用シーン

• • 全体テスト計画で検討した性能テスト方針が問題ないか、実施可能かどうか評価するとき。
  • 実施可能な性能テスト計画を考えるために必要な検討事項や、あらかじめ収集が必要な情報を確認するとき。
  • 性能テスト計画書の構成や内容を決定するとき。
  • 性能テスト計画書の作成後、セルフチェックやレビューにて、記載内容の過不足を確認するとき。
  • 性能テストに関わったことのない⼈が内容について学習するとき。

2. 性能テストについて

2.1. 性能テストとは

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

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

• • 性能テスト計画策定
  • テスト環境の準備
  • 外部連携システムとの調整
  • 性能テストシナリオ作成
  • 性能テストケース作成
  • 性能テストデータ作成・投入
  • 負荷ツールの準備
  • 性能テスト実施
  • 性能テスト結果の評価
  • 性能のボトルネック解消
  • テストの再実施と再評価

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

2.3. 性能テストの意義

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

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

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

2.5.検討時期

2.6.検討事項

3.1. 性能テスト方針

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

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

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

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

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

3.2.1. 性能テスト観点

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

オンライン機能

• • • • ログインしてから該当機能へアクセスする。

• • • • 運用時と各機能へのアクセス数割合が同じになるようにする。

• • • • 単一ユーザによるシナリオではなく、複数ユーザによるシナリオにする。

バッチ機能

• • • • ジョブ管理ツールの定義に従って実行するシナリオとする。

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

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

• • データの内容

• • データの分布

• • • • ツールによって大量データを作成した結果、本番と異なるような分布になってしまう。
        例えば、ユーザ名は本番運用時には様々な値が入りますが、テストデータで全て同じダミーの値を入れてしまうと、検索時の性能が本番とは変わってしまいます。
      • 自動採番される値について、テストデータの採番方法自に考慮が漏れて、業務仕様と異なる分布となってしまう。
      • 日付データが特定の期間に偏ってしまう。
      • 業務観点で特殊な分布となっている項目を再現できていない。
        例えばサービス開始時に登録が集中し、ユーザの登録日時がサービス開始時期に集中するといったことが起こり得ます。

3.2.4. 負荷ツールの選定

3.3. テスト環境

このトピックでは、『3.1. 性能テスト方針』や、『3.2. 性能テストの実施方針』にて検討した内容を踏まえ、性能テストに必要なテスト環境の要件を検討します。 基本的な考え方については『全体テスト計画ガイド』の『4.5.テスト環境』をご参照下さい。

ここでは性能テストに必要な環境に求められる要件について解説します。

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

検討方法

まず、大前提として、性能テストでは本番同等のテスト環境を用意する必要があります。本番と同等の環境で検証しなければ、本番運用時に性能要件を満たすことを確認出来ないためです。具体的には以下の要件を満たしている必要があります。

また、連携する外部システムを性能テスト実施範囲に含める場合は、外部システムのテスト環境にも同様の要件が求められます。自システムのテスト環境だけでなく、外部システムのテスト環境についても要件を検討するようにして下さい。

3.4. 体制

このトピックでは、テスト実施に関与するステークホルダーと、各ステークホルダーの責務、指示系統、トレーニングについて検討します。 基本的な考え方については『全体テスト計画ガイド』の『4.6.体制』をご参照下さい。

ここでは性能テストの体制を考える上で重要となる観点について解説します。

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

性能テストの実施では、以下のメンバーが体制に含まれている必要があります。

• • アプリケーションの開発チームメンバー
  • システムのインフラ開発メンバー

理由は以下の通りです。

アプリケーションの開発チームメンバー

性能テストでは多くの作業において、業務要件の知識が必要となります。そのため、アプリケーションの開発チームメンバーを性能テストの体制に含める必要があります。具体的には以下の作業で業務要件の知識が求められることになります。

• • テストシナリオ作成

実際のユーザの動きを意識したシナリオとするためには業務要件の知識は不可欠です。

• • テストデータ作成

業務要件の知識が無ければ、テーブル間のリレーションシップを意識しつつ、本番データと類似した内容のデータを大量に作成することは難しいです。

• • 負荷ツールの準備

検討した方針に従って負荷ツールでテストシナリオを作成する際も、入力項目の仕様等、業務要件の知識が要求されます。

システムのインフラ構築メンバー

性能テストの検証対象はアプリケーションプログラムだけではなく、システム全体となります。そのため、性能テストでは開発しているシステムのインフラに関する知識も必要となります。それに加え、『3.3. テスト環境』にて検討した要件を満たすテスト環境の設計・構築が必要となるので、インフラ開発チームメンバーを性能テストの体制に含める必要があります。具体的には以下の作業でインフラの知識が求められることになります。

3.5. タスクと役割分担

このトピックでは性能テストに必要なタスクを洗い出し、その役割分担を検討します。 基本的な考え方については『全体テスト計画ガイド』の『4.6.体制』をご参照下さい。

検討方法

以下に性能テストで発生するタスクの例を記載します。タスクを洗い出す際の参考にして下さい。

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

• • テスト環境の設計、テスト環境の構築
    設計と構築作業は他の環境構築作業と並行して進めるスケジュールとしています。
  • 外部連携システムとの調整
    外部システムとの連携部分も性能テスト範囲に含める場合、外部システム側でもテスト環境の準備が必要であるため、要件定義時点から調整を行っていくスケジュールとしています。
  • 性能テストシナリオ作成、性能テストケース作成
    外部設計が終わった機能のテストシナリオから着手するスケジュールとしています。
    また、機能によっては内部設計の内容を踏まえてバリエーションを検討する必要があるため、一部機能についてはテストシナリオとテストケースの作成を内部設計で実施するスケジュールとしています。
  • 性能テストデータ準備
    データモデルの設計が完了してからの着手となるほか、テストシナリオやテストケースの内容を踏まえての実施となるため、内部設計からの着手としています。
  • 負荷ツール準備
    負荷ツールのテストシナリオ作成はアプリケーションを動かしながら実施する必要があるため、PG・UTからの着手としています。また、事前疎通の実施はIT～STで実施するスケジュールとしています。
  • 性能テスト実施、性能テスト結果の評価、性能のボトルネック解消、性能テストの再実施と再評価
    どれも性能テストの工程で実施する作業となります。