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

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

負荷テストの成功ポイント Vol.2 ~計画段階で考えておくポイント~

矢野 英也

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

はじめに


皆様、こんにちは。第一回の内容はいかがでしたでしょうか。第一回は各フェーズの定義と作業範囲、テスト計画のポイントについてお話ししました。第二回は前回に続き、テスト計画のポイントについてもう少しお話しさせていただきたいと思います。

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

前回のおさらい


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

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

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

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


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

いくつか例を挙げます。

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

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

外部環境への接続はあるか
テスト環境を準備する際、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を採用しています。


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

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


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

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

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


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

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



ページの先頭へ戻る