TOP>企業情報>コラム>技術情報>負荷テストの成功ポイント Vol.1

負荷テストの成功ポイント Vol.1

負荷テストの成功ポイント Vol.1 ~失敗から学んだ計画の重要性~

矢野 英也

2001年、株式会社アシスト入社。
テストツールのご紹介、サポート、技術支援を担当。年間何十件もの負荷テストを支援し、その経験を他のお客様にも伝えるべく、セミナーや執筆活動を行っている。
月一回のゴルフと年一回の同期BBQを楽しみに日々奮闘中。昭和生まれのうま年。

はじめに


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

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

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

また本連載では、負荷テストツールを使った負荷テストを前提にしています。

負荷テスト全体の作業一覧


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

  1. 計画
  2. 準備
  3. 実施
  4. 分析

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

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

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

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

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

負荷テスト計画のポイント


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

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

負荷テストの目的や目標


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

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

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

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

システム分析、業務分析


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


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

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

対象業務


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


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


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


コラム:負荷テスト?性能テスト?限界テスト?

どの用語が正しいか迷うことはありませんか?実は「性能テスト」の一種に「負荷テスト」「限界テスト」が位置付けられるのが一般的です。『 ソフトウェアテスト標準用語集(日本語版) には以下のように定義されています。

■性能テスト(performance testing)
ソフトウェア製品の性能を判定するためのテストプロセス。

■ロードテスト(load testing)
コンポーネントやシステムの振る舞いを測定する性能テストの一種。負荷(たとえば、同時実行ユーザ数やトランザクションの数)を増加させ、コンポーネントやシステムがどの程度の負荷に耐えられるか判定する。

■ストレステスト(stress testing)
予測又は特定した負荷、若しくはメモリやサーバなどのリソースの可用性が低減したときの限界、又は、それを超えた条件でシステムやコンポーネントを評価するために行なわれる性能テストの一種。

人によってテストのイメージが異なるかもしれませんので、計画書等で用語の定義をされることをお勧めします。


アシストでご紹介している負荷テストツール

その他、矢野の執筆した記事はこちら


アシストの負荷テストツールへのお問い合わせはこちら

資料請求/お問い合わせはこちら(専門の担当者が確認し、ご対応します。)

お客様の状況に合わせて詳しい情報をお届けできます。お気軽にご相談ください。


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る