負荷テストのやり方。シナリオの作成方法や自動化ツールを紹介

参考文献[1]の記載および筆者の経験則などに基づき、負荷テストのポイントを4つのプロセスごとに説明します。

1）要求分析・計画時

要求分析や計画時におけるポイントを5つ紹介します（図表1）。 

ポイント1：性能要件や性能要件に基づく概要設計情報を収集する  

性能要件や性能要件に基づく概要設計などの情報を収集します。テスト結果の妥当性判断やテストの実施条件を明確にすることが目的です。 

ポイント2：性能目標設定時に時間効率性、資源効率性、容量満足性を考慮する

性能目標を立てる際、ISO/IEC 25010のプロダクト品質モデルにおける性能効率性の3つの副特性（時間効率性、資源効率性、容量満足性）を考慮し定めます。テスト結果の妥当性判断やテストの実施条件を明確にすることが目的です。

 ポイント3：性能目標設定は理解を得やすい計測項目・目標値で表現する  

性能目標を立てる際は、関係者と会話・合意しやすいように関係者の理解を得やすい計測項目・目標値に置き換えて表現します。これにより、妥当性確認やテスト終了条件の擦り合わせが容易になります。

ポイント4：負荷モデルは業務分析の上、オンライン・バッチを中心に検討する  

負荷モデルを考える際、業務分析を行います。オンライン・バッチ（定期処理）を中心に検討します。これは、テスト結果の妥当性判断やテストの実施条件を明確にするためであり、テストの網羅性を高めるためでもあります。

ポイント5：適切なコミュニケーションプランを計画する

ステークホルダを特定し、適切なコミュニケーションプランを計画します。最終的な妥当性判断とクライテリアの合意を行いやすくすることが目的です。また、性能テストに関連する課題が後続フェーズで発生した場合に、関係者が迅速に対応するための備えにもなります。

図表1：要求分析・計画時における5つのポイント 

2）ツール・環境準備 

ツールや環境準備におけるポイントを3つ紹介します（図表2）。

ポイント1：負荷テストツールのPoCを実施する

負荷テストツールのPoC（Proof of Concept：概念実証）を実施します。負荷テストツールでの制約により、負荷テスト対象のプロトコルや特殊な認証などが含まれ、そのままでのツールの適用が難しい場合があります。テストの準備工程での手戻りや追加開発が発生することを防ぐために行います。

ポイント2：負荷テスト用スタブを準備する

必要に応じて、負荷テスト用スタブを準備します。対象システム内に外部システムや外部サービスとの連携がある場合は、負荷テスト中にそれらが性能ボトルネックとなりテストが継続できなくならないよう、スタブ開発の要否、負荷生成時の規約や申請の有無、環境の妥当性を事前に検討します。

外部システム、外部サービサーが持つ環境がテストに適した環境ではない場合（外部システム側のサイジングが適切でない、外部システム側が本番環境であるなど）があるためです。また、スタブの開発タスクがアサインされていないことによりテスト工程を始められないといった事態や手戻りを防ぐためです。

ポイント3：負荷テストのための事前申請を行う

必要に応じて、負荷テストのための事前申請を行います。負荷テストを実施する際に、テスト対象環境におけるテスト実施時の規約の有無を確認します。

また、許諾が必要な場合は許諾を得るようにします。DoS（Denial of Service：サービス拒否攻撃）やDDoS（Distributed Denial of Service：分散型サービス拒否攻撃）と誤認されないようにするためなどの理由があります。

図表2：ツール・環境準備における3つのポイント 

3）設計 

設計時におけるポイントを2つ紹介します（図表3）。

ポイント1：経年データを考慮する

経年のデータ等、データ量が多い場合、そのデータへアクセスする機能において性能ボトルネックが発生することがあるため、経年データを考慮する必要があります。

ポイント2：データのバリエーションを考慮する

データのバリエーションが少ない場合、性能ボトルネックの発生条件を見逃す場合があるため、データのバリエーションを考慮する必要があります。

図表3：設計時における2つのポイント

4）準備・実行/監視 

準備・実行/監視におけるポイントを3つ紹介します（図表4）。

ポイント1：計測・監視の方法を事前に考慮する

性能目標に対する達成度合いを確認するための計測方法・監視項目は、実行前に提供されていなければなりません。また、計測・監視の項目はシステムアーキテクチャーに依存し、ケース・バイ・ケースで計測方法や監視項目が異なります。

また、既存にない監視項目が発生した場合は、個別に検討が必要となる場合があります。そのため、計測・監視の方法を事前に考慮することが必要です。

ポイント2：実行履歴を記録する

実施中に負荷生成側の条件変更、テスト対象側の設定変更など、何をどのように変更し実施したかを記録しない場合は、どういう条件で性能が改善されたのか、達成されたのかが不明瞭となるため、実行履歴の記録が必要です。

ポイント3：一度に変更するパラメータは極力一つにする

負荷生成条件パラメータと、テスト対象側の設定パラメータの両方を変更する場合は、どの変更が性能改善として有効であったかが分かりにくくなるため、一度に変更するパラメータは極力一つを推奨します。

図表4：準備・実行/監視における3つのポイント

本セクションではテスト対象別の負荷テストの実施方法について説明します。

テスト対象：サーバー・サービスの負荷テスト

「サーバー・サービスの負荷テスト」は「何らかのプロトコルを用いたクライアントをエミュレートし、同プロトコルを用いたサーバーやサービスに対して負荷をかけた際のシステムの振る舞いや性能目標の達成度合いを確認するためのテスト」を意味します。

以下に、サーバー・サービスの負荷テストの概要や実施方法と製品例をまとめます。

テスト対象：ネットワークの負荷テスト

本セクションにおける、ネットワークの負荷テストは「ネットワークレイヤの要求や帯域をエミュレートし、テスト対象であるネットワークアプライアンスの製品に対して負荷をかけた際のシステムの振る舞いや性能目標の達成度合いを確認するためのテスト」を意味します。

以下に、ネットワークの負荷テストの概要や実施方法と製品例をまとめます。 

負荷テストツール上で負荷テストのシナリオを作成、実行することで負荷の生成が可能になります。以下、負荷テストのシナリオの作成方法について説明します。

用語の定義

本セクションでの「負荷テストのシナリオ作成」は「負荷モデルの実装」を意味します。

負荷モデルは、計画や設計に基づいた、業務の種類、並列数（※1）、ランプアップ・ランプダウン（※2）、実行時間を定義したものです。

（※1） 一般的な用語では、同時接続ユーザーとも呼ばれる
（※2） 並列性の増加減時間間隔定義のこと（例：1分ごとに1ユーザーを10分かけて生成または削減する）

概要

負荷モデルの例を図表5に示します。 この負荷モデルを、負荷テストツールを用いて実装します。

• 定常的な業務を行う100ユーザーの負荷が存在する（以下、定常負荷と呼ぶ）
• 定常負荷とは別に、ピーク時間帯に発生する200ユーザーの業務負荷が存在する （以下、ピーク業務負荷と呼ぶ）
• 負荷テストに利用する負荷モデルは300ユーザー並列とし、負荷シナリオを実装する

負荷テストのシナリオの作成方法

基本的には、あらかじめ定めた計画やテスト設計、もしくは、負荷モデルに基づいて作成します。以降、一般的な負荷テストのシナリオ作成方法を示します。なお、特に断りのない場合は、クライアントがWebブラウザ、サービス側はAPIやWebシステムが稼働しているアプリケーション環境を想定するものとします。

またここでの「シナリオ」とは、図表5に記載の「ピーク業務負荷」や「定常業務業務に含まれる業務単位の操作を意味するものとします。（例：検索、更新、削除など）

負荷テストツールによる業務の記録

負荷テストツールの記録機能（ロギング機能）を用いて、テスト対象システムのアプリケーションを通じた業務操作の記録を行います。一般的に、この記録した生成物を「スクリプト」と呼びます。スクリプトはユーザーの操作やアプリケーションの通信をプログラムで模擬したものです。

負荷テストツールによるスクリプトの再生と拡張

記録した直後のスクリプトは、ある操作断面での静的な記録となっており、そのままでは再生・実行ができないことが少なくありません。アプリケーション動作に必要なリクエスト・レスポンス値を動的に適切に扱い、加えて並列な動作・再生が可能なように、修正・拡張を行います。拡張すべき内容は以下の通りです。

• 状態遷移の対応
  CSRF値やCookie値の扱い、その他アプリケーションの状態に関する値を扱えるようにします。
• 計測区間の定義
  操作のどこからどこの区間を計測すべきか定義します。
• 返却値の検査
  スクリプトはプログラム化されているため、テスト対象から返却される値を機械的に確認・検査します。
• 外部パラメータ化
  スクリプト内で利用したい業務固有の値を固定値ではなく外部定義として与えます。 例えば、ログインするユーザーのIDや検索したい商品のIDなどです。

負荷テストほどツールで自動化されたテストに向いているテストはないと言えます。むしろ、負荷テストはツールで自動化された状態であることが望ましいです。

理由としては2点あります。１つ目はユーザー操作、並列性やタイミングを正確に制御する必要があるためです。

2つ目は 大量の計測データを自動収集して、結果を即時統合し、速やかに分析・改善の工程を素早く回していく必要があるためです。

AWS（Amazon Web Services）での負荷テスト

本セクションにて想定している環境は、テスト対象のシステムがAWS上にあり、負荷生成用の環境もAWS上にあるものとします。AWS上で負荷生成が可能なように、負荷制御用のマシンおよび負荷生成用のマシンを準備した上で、対象のシステムに対して負荷生成を行います。負荷制御用のマシンや負荷生成用のマシン（EC2）へ、負荷テストツールをセットアップし実施するのが一般的です。

なお、EC2上にたてた負荷生成マシンから、AWSプラットフォームへ負荷生成を行う場合は、プラットフォーム側から攻撃的な負荷とみなされることがあるため、サポート等を通じて負荷生成の事前申請を行う必要があります。また、条件を満たす場合は申請が不要な場合もあるため、テストポリシーページ（※3）を参照ください。 

（※3） Amazon EC2 Testing Policy

その他のツールでの負荷テスト 

上記のように、負荷生成マシンを特定の環境に保有せず、必要な分量のみアドホックに負荷生成が可能なマネージドサービスとなっているサブスクリプション型の負荷テストサービスも利用が可能です。そのようなクラウドサービスを利用したい要件がある場合は、利用を検討します。

ただし、マネージドサービスごとの各種制約等がある場合があるため、計画した負荷テスト内容の実現が可能か事前に確認することが望ましいです。例えば、マネージドサービスが特定のパブリッククラウド上で動作している、負荷量の上限が利用料金で決まっている、サービスの稼働リージョンが海外であるなどです。

負荷テストを自動化するメリット

前述の通り、負荷テストは基本的にテストの自動化がほぼ必須となります。なお、自動化のメリットは、いわゆるソフトウェアテスト自動化のメリットに等しいです。
（デメリットも同様です。なお、よりテスト自動化について詳細をお知りになりたい方は、「テスト自動化とは」の記事をご参照ください。） 

なお、負荷テストをさらに高度に自動化した、継続的デリバリー内での負荷テストを達成するためには、さまざまな工夫が必要となるため注意が必要です。

例えば、アプリケーションの仕様変更に合わせた継続的なシナリオやスクリプトなどのテスト資産の保守や管理、一般的なテストの自動化で必要となる考慮点のみならず、負荷生成環境の保守や拡張などの考慮も必要となるため、そこまでの負荷テストの自動化が必要かどうかは、プロダクトまたはプロジェクトの成熟度合いを見定めて行います。

負荷テストの基本的な考え方や負荷テストのプロジェクトの考え方、進め方の原理原則は今も昔も大きく変化していないものと考えます。

しかしながら、テスト対象を構成する環境はめまぐるしく変化しており、特に技術的には、仮想化・コンテナ技術の活用、クラスタ・HAシステム、アプリケーションアーキテクチャーの複雑化（SaaS、FaaS）、セキュリティの仕組みの複雑化（多要素認証、生体認証、IDaaS）、マルチクラウドへの対処が必要となる場合があります。

また、利用者・クライアントも多種多様なデバイスを通じてアクセスしている場合があり、負荷モデルの予想が難しい場合もあります。それらの課題の一部を取り上げつつ、一般的な対応策について記載します。

課題1　ユーザー利用やアクセスの予測が外れやすい

以下に、ユーザー利用やアクセスの予測が外れやすいことに対する課題の種類と概要、対処をまとめます。 

（※4）　オブザーバビリティ（Observability）は、オブザーブ（Observe：観測する）、アビリティ（Ability：能力）を組み合わせた複合語で、日本語では「可観測性」あるいは「観測する能力」などと訳される。システム上で何らかの異常が起こった際に、それを通知するだけでなく、どこで何が起こったのか、なぜ起こったのかを把握する能力を表す指標、あるいは仕組みです

参考：New Relic

課題2　テスト環境の準備が不十分

以下に、テスト環境の準備が不十分であることに対する課題の種類と概要、対処をまとめます。 

課題3　テストのためにクラウド利用時の追加コストが発生する

以下に、テストのためのクラウド利用時の追加コストが発生することに対する課題の種類と概要、対処をまとめます。 

課題4　短納期・短期間で大規模な負荷テストの実施が難しい

以下に、短納期・短期間で大規模な負荷テストの実施が難しいことに対する課題の種類と概要、対処をまとめます。 

課題5　セキュアな仕組みにより負荷テストの実施が難しい

以下に、セキュアな仕組みにより負荷テストの実施が難しいことに対する課題の種類と概要、対処をまとめます。

ここまでお読みいただきありがとうございました。

「負荷テストとは。種類や目的、観点について解説」の記事に加え、本記事も併せてご覧いただくことで、皆さまの負荷テスト実施の一助となれば幸いです。しかし、実際の各プロジェクトの個別要件は複雑かつ多種多様ですので、最後に、当社のサービスを紹介いたします。 

ベリサーブでは、お客様の負荷テストに関するお悩みを、システム負荷検証サービスで解決いたします。サービスの詳細は、以下URLをご参照ください。 

システム負荷検証サービス

■参考文献■
[1] ISTQBテスト技術者資格制度 Foundation Level Specialist シラバス 性能テスト担当者 日本語版 Version 2018.J01.