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

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

 

HP ソフトウェア

第二回(続 計画編)

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

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

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

前回のおさらい

第一回では「負荷テストの目的や目標」「システム分析、業務分析」「対象業務」についてお話しました。

この中で一番難しいのは「システム分析」特に負荷量の予測だと思います。社内システムであればある程度のアクセス予測は可能ですが、コンシューマ向けサイトは予測がつきません。過去に誰もが知っている商品の発表に向けてシステム拡張の負荷テストを計画したことがありましたが、アクセス予測ができないため、なかなか目標値というのが決まりませんでした。結局システム限界を計測するような大規模なテストを実施したことがあります。計画の段階で、目標値を立てることで、テストパターンの決定、それに基づいたスケジュール設定ができた例になります。

今回は「テスト環境の構成要素の確認」「体制・役割分担」「データ収集項目と判断基準」「スケジュール」についてです。

テスト環境の構成要素の確認

テスト環境の構成要素を確認することで、事前に準備すべき項目が整理できるため、必ず計画段階で確認いただきたい内容のひとつです。

いくつか例を挙げます。

  • テスト環境の構成台数とスペックは本番と同じか
    本番環境と同等の構成でテストがいいのは言うまでもありませんが、用意できない場合もあります。本番環境と違う構成の場合、テスト結果の評価方法についての協議が必要になります。

  • インターネット環境からの負荷を生成するか
    一般コンシューマ向けのサイトであれば、実際のユーザの動作、つまりインターネット環境からの負荷を生成することがテストが要件になる場合もあります。その場合、負荷を生成するクライアント端末の設置場所をどこに設置するかの確認が必要になります。オフィスエリア、もしくはデータセンターのインターネット環境に一番近いセグメントに設置する、などです。データセンターにクライアント端末を設置するとなると、一般的には事前申請等の手続きが必要になります。

  • 外部環境への接続はあるか
    テスト環境を準備する際、SaaSやホストなど外部環境への接続があるかの確認が必要です。SaaSの場合は課金されてしまったり、ホストの場合は本番環境と共存していることが多いためテスト実施時間の制約が生じる場合があります。結果、シナリオの変更や、スタブを作成する必要が出てくる可能もあります。

体制・役割分担

負荷テストの目的にもよりますが、検証範囲がネットワーク、アプリケーションサーバ、データベースサーバなど広い範囲に及ぶ場合、計画段階で各担当者の役割を明示しておくことをお勧めします。負荷テストに関連する役割としては、「負荷テスト統括」「インフラ、ネットワーク担当」「アプリケーション担当」「データベース担当」「負荷テスト実施担当」などが上げられます。負荷テスト実施担当は、アプリケーション担当やインフラ担当と兼任することもあります。

それぞれの役割内容は以下です。

  • 負荷テスト統括
    負荷テストの目的、ゴール、シナリオの決定を行います。またビジネスオーナーやプロジェクトマネージャへの負荷テスト結果を報告することもあります。

  • インフラ、ネットワーク担当
    負荷テストに必要なネットワーク機器やIPアドレスの準備、負荷テストツール端末設置のサポートなどを行います。またサーバリソースやネットワーク帯域を確認し、適切にインフラが用意されているか確認します。

  • アプリケーション担当
    エラーの原因調査、応答時間が遅いページの解析、チューニングなどを行います。

  • データベース担当
    応答時間の遅いSQLの解析やチューニングなどを行います。

  • 負荷テスト実施担当
    負荷テスト要件に基づいたテストの実施、結果の集計、分析を行います。

データ収集項目と判断基準

計画段階でデータ収集項目と判断基準を決めておくのがいいと思います。後で分析できるように、構成要素全てのデータを収集するのが理想ですが、データ収集可否やスケジュールの関係もあるので、ある程度の精査は必要です。

我々が支援する際は、以下の項目を標準項目としています。
‹Windows>
http://www.ashisuto.co.jp/product/category/quality/loadrunner/technical/list/1195227_3454.html 
‹Linux>
http://www.ashisuto.co.jp/product/category/quality/loadrunner/technical/list/1195222_3454.html 

またOS統計情報だけでなく、J2EE、.NET監視ツールと組み合わせて負荷テストを実施することもあります。
http://www.ashisuto.co.jp/product/category/quality/loadrunner/technical/list/1195238_3454.html 

データベースがOracleであれば、診断サービスと組み合わせることあります。

スケジュール

開発スケジュールによって負荷テストスケジュールは流動的になりがちですが、一般的なプロジェクト管理と同様クリティカルパスを設定し、スケジュールを作成されることをお勧めします。負荷テストを実施して想定外のエラーが発生することはよくあることです。テスト実施は2回以上、間にチューニング期間を設けて、スケジュール設定することをお勧めします。

大まかですが、おおよそ以下のスケジュールが一般的です。


過去に負荷テスト実施経験のある環境は別として、新システムの負荷テストであれば、計画から報告まで少なくとも1ヶ月、場合によっては3ヶ月になる場合もあります。

以上、テスト計画で確認しておくポイントを2回にわたってお話しました。次回からは「準備」フェーズです。テストスクリプト作成時の注意点や苦労話などをお話したいと思います。

コラム:負荷テストツールについて

計画フェーズで負荷テストツールの選定も行います。どのツールが最適かは色々な視点がありますが、いくつか選定のポイントをお伝えします。

  • 対応環境の広さ
    環境によって負荷テストツールを変えるのは、非効率です。特定の環境のみがテスト対象の場合もありますが、対応範囲の拡張性を考えると対応環境の広さは重要だと言えます。

  • レポーティング
    負荷テストはトライ&エラーで何度も実施します。そのためテスト結果が多くなりますので、テスト結果を判断するためのレポーティング機能の充実は重要です。グラフ加工の柔軟性、外部出力、分析パターンのテンプレート機能が備わっているツールをお勧めします。

  • ライセンス利用可能範囲
    SIer用ライセンスが用意されているか、クラウド環境でも利用できるかなど利用範囲はベンダーによって定義はばらばらです。自社の利用形態を考えて最適なツールを選びましょう。

  • 実績
    なんだかんだ言ってもこれが一番重要ですね。テストツールはテスト対象アプリケーションによって適用可否が全く異なります。同じWebアプリケーションでも利用不可の場合もあります。適用実績がないアプリケーションであれば、利用実績が一番多くナレッジが多いツールがリスクが少ないと言えます。

アシストは利用実績、適用範囲、レポーティングなどを考慮し、実プロジェクトで最も利活用できるツールとしてLoadRunnerを採用しています。


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