負荷テスト成功のポイント｜ツールを使ったテスト成功の勘所

皆様、こんにちは。この度「負荷テストの成功ポイント」と題して技術情報を連載させていただくことになりました。

簡単に自己紹介をします。アシストに入社して以来、テストツールの技術支援、およびサポートを担当してきました。対象システムは、Web、C/S、ERPパッケージ、BIツールなど多岐に渡ります。10年前はまだC/Sがまた多くWebが浸透し始めた頃でしたが、最近ではAjaxを使ったWebアプリケーションや、クラウド上のシステムの負荷テストなどの要件も増えており、Citrix XenApp/XenDesktopのような仮想化環境などの負荷テストニーズも増えています。

本連載では、これまでの経験を踏まえて、負荷テストを成功させるために事前に考えるべきこと、気をつけることなどを4回に渡って説明していく予定です。読者の対象は負荷テスト未経験者を想定しておりますが、経験された方にとっても新しい気づきにつながれば幸いです。

また本連載では、負荷テストツールを使った負荷テストを前提にしています。
それでは、第1回「負荷テストの成功ポイント Vol.1　～失敗から学んだ計画の重要性～」をご覧ください。

負荷テストの作業フェーズを以下の4つに分けて、話を進めていきます。

1. 計画

2. 準備

3. 実施

4. 分析

各フェーズの作業概要は以下です。

1. 計画

負荷テストの目標を明確にし、テスト計画を立案、関係者と合意するフェーズです。負荷テストの対象業務や実行ユーザ数、評価方法などを決定します。計画段階での詳細化によって防げる問題は多く、アシストではこのフェーズでの詳細化を重要視しています。

2. 準備

テストスクリプト、シナリオ、テストデータ、テスト環境を準備するフェーズです。スクリプトに記録する対象業務やテストデータ、テスト環境は基本的には計画フェーズで決められているものを準備します。

3. 実施

負荷テスト本番の実施フェーズです。想定通りの負荷量がかかっているか、データ収集は漏れがないかなどを確認します。分析により再テストが必要と判断された場合は、実施が複数回に渡ることがあります。

4. 分析

テスト結果を分析し、速報や最終報告書を作成するフェーズです。想定外の結果の場合、再度実施をすることがあります。

では、我々が重要視している負荷テスト計画についてお話ししていきます。負荷テスト計画を重要視している理由は、我々の失敗経験に基づきます。「計画段階で確認しておけば・・・」と思うことが今まで数多くあり、同じ過ちは繰り返さないという思いで、計画書を必ず作り（または作ってもらい）、抜け漏れがないかをチェックしています。

いくつか確認するポイントを挙げます。

負荷テストの背景や目的を明記するのは当たり前だと思われるかもしれませんが、意外と関係者全体に周知されていないことがあります。動機付けにもなりますので、計画書に明記し共有するようにしましょう。

目的には、「システム視点」と「ビジネス視点」が挙げられます。

システム視点

負荷テストの目的というと、こちらをイメージされる方が多いかと思います。システムの視点での負荷テストは、各SQLの実行時間や負荷分散装置の検証、秒あたりのヒット数等、多岐にわたります。

ビジネス視点

「システム＝ビジネス」と考えると、負荷テストの目的にもビジネスの視点が必要です。新製品発表やキャンペーンなど、アクセスの集中が予想されるシステムの負荷テストを計画する際、「システムがユーザに対してどのような状態でサービスを提供すべきか。」という目標を決めておくことでビジネス視点での計画を立てることができると思います。

負荷テストは本番稼動を想定した状態を再現することが重要です。その為には、システム分析が必要になります。以下のグラフはアシストのホームページ（https://www.ashisuto.co.jp/）のある日のアクセスログを分析した結果です。これを見るとトップページ、コラム、製品ページへのアクセスが多いことが分かります。また一日のアクセスのうち、トップページとコラムで全体の半分を占めていることが分かります。

どの画面や業務にアクセスが多いかという分析に加えて、アクセスが集中する時間帯とアクセス量の視点も必要です。

ここで「新システムの分析は？」という疑問を持つ方がいると思います。稼動実績のないシステムの分析はできませんので、要件定義に基づき想定アクセスパターンを幾つか考え、テストパターンを増やす必要があると考えます。したがって、新システムの場合は未知の部分が多い分、テストパターンが増えるため、それを見込んだテストスケジュールを組む必要が出てきます。

業務分析後、負荷テストの対象とする業務を決定します。業務を決定する際、オペレーションレベルまで確認して計画書に記載することをお勧めします。下図を参照ください。

オペレーションレベルは計画立案者ではなく、業務担当やユーザ部門に確認しないと分からないかもしれませんが、スクリプト作成時には必要になりますので、可能であれば計画フェーズで手順書まで作成することをお勧めします。

次回は計画フェーズでの「スケジュール」「システム構成要素」「体制・役割分担」「データ収集項目と判断基準」についてお話ししたいと思います。ご期待下さい。

【各回タイトル】
・第2回：計画段階で考えておくポイント

・第3回：ツールでの作業上の注意点

・第4回：本番実施から報告書作成