リニューアル! 新・負荷テストの極意

~現場の経験談を追加し、テクニカルエッセイが帰ってきました~

 

HP ソフトウェア

第一回(計画編)

株式会社アシスト
矢野英也

◊ 本記事についてのメールでのお問い合わせ(株式会社アシスト)
Email: hpmrctec_web@ashisuto.co.jp

はじめ

皆様、こんにちは。この度HP ALM ポータルサイトに「新・負荷テストの極意」と題して技術情報を連載させていただくことになりました。以前の記事を更新し、テスト現場での経験談も交えてお届けしたいと思います。

簡単に自己紹介をします。アシストに入社して13年、テストツールの技術支援、およびサポートを担当してきました。対象システムは、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の実行時間や負荷分散装置の検証、秒あたりのヒット数等、多岐にわたります。
  • ビジネス視点
    「システム=ビジネス」と考えると、負荷テストの目的にもビジネスの視点が必要です。新製品発表やキャンペーンなど、アクセスの集中が予想されるシステムの負荷テストを計画する際、「システムがユーザに対してどのような状態でサービスを提供すべきか。」という目標を決めておくことでビジネス視点での計画を立てることができると思います。

システム分析、業務分析

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


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

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

対象業務

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


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

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

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

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


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


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


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


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


◊ 本記事についてのメールでのお問い合わせ(株式会社アシスト)
Email: hpmrctec_web@ashisuto.co.jp