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

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

負荷テストの成功ポイント Vol.4 ~本番実施から報告書作成~

矢野 英也

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

はじめに


皆様、こんにちは。第三回の内容はいかがでしたでしょうか。第三回は「スクリプト作成」「シナリオ作成」「モニタリング設定」「環境構築」など準備の際の注意点、またツールを利用する側の視点でのポイントをお話ししました。

今回はテスト実施・分析においてのポイントをいくつかお話しします。

テスト実施のポイント

テスト当日のタイムスケジュール


全体スケジュールについては、第二回の「スケジュール」でお話ししました。今回はテスト当日のタイムスケジュールについてです。ここで重要なポイントはテスト前後の作業一覧と所要時間の整理です。前後の作業時間を算出し、1日何回のテストが実施できるか見込みを立てます。この前後の作業が意外と見落としがちで重要です。

負荷テストの成功ポイント Vol.4:タイムスケジュールの例

タイムスケジュールの例

図の例ですと、1日に4つのテストケースを実施しています。システムによっては、毎回データリストアが必要な場合もありますし、逆に不要な場合もあります。その点を考慮しタイムスケジュールを立てます。またテスト結果が想定通りにならず、同じテストケースを再実行する場合もあります。想定外の結果を見込んで、テストケースに優先度をつけると良いと思います。1日に実行できるテストケースは限られていますので。

テスト当日の体制


プロジェクトの体制については、第二回の「体制・役割分担」でお話ししました。今回はテスト当日のオンサイト、オフサイトを含めた体制図についてです。必ずしもプロジェクトメンバー全員がオンサイトで対応する必要はありません。後日データ解析できるのであれば、オンサイトの対応は不要です。

ただし実際のテストの現場では、その場で解析、分析し、実施するテストケースの判断をしなければならない場合がほとんどです。テストの重要度、スケジュール、当日発生しうる問題を想定し、オンサイト、オフサイトメンバーを検討することをお勧めします。

負荷テストの成功ポイント Vol.4:当日の体制図の例

当日の体制図の例

テスト実行時のエラー解析


多重で同時に実行すると、私の経験上、エラーなく全てのユーザが成功することはまずありません。エラーの原因は多岐に渡りますが、まずは原因の所在を負荷ツール側、アプリケーション側のどちらか切り分けます。

負荷テストツール側

・スクリプト
スクリプト作成時のデバックで実行確認しますが、アプリケーション改修によってスクリプトが動作しなくなる場合があります。問題切り分けのファーストステップとして、スクリプト単体でエラーの有無を最初に確認します。

・パラメータデータ
パラメータデータの不備や設定漏れでエラーになることがあります。例えば、ユーザIDを変えると、ユーザIDに関連している値がスクリプト内にある場合、相関(第三回「スクリプト作成のポイント」参照)が必要になる、等です。

スクリプトエラー、パラメータデータのエラーについては、テスト実施前にリハーサルをすることで事前にある程度対処することができます。

アプリケーション側

アプリケーション側のエラーについては、OS・ミドルウェア設定不備、コネクション枯渇、ヒープサイズ設定不足、などが考えられます。問題切り分け・特定の時間が短くできるよう、分析に必要なデータを負荷テスト時に収集しておきます。データ収集項目については、第二回「データ収集項目と判断基準」を参照下さい。

分析のポイント

速報


速報で必要なのは、テスト合否判定、問題切り分けのための情報です。事前に判断基準を確認の上、テスト実施直後に提示できるようにしておくと良いと思います。テスト回数が多い場合、負荷テストツール側にあるテンプレート機能を使って、必要なグラフを事前に準備しておいて、すぐに出力するなどの工夫をしましょう。

負荷テストツールの情報だけで不十分な場合は、必要データの収集を各担当者に依頼しておきます。

最終報告


最終報告書は、テストの目的、テスト環境、期間、総評などの項目を盛り込みます。再度同じようなテストを実施する際に見直せるよう、負荷量の考え方やテスト条件などを入れるのも良いでしょう。

コラム:テスト実施から判定会議まで2時間!

あるコンシューマ向けサイトの新商品発表に向けた負荷テストのことです。テスト実行できるのが、AM2:00~AM5:00、判定会議がAM7:00という非常にタイトなスケジュールを組んだことがありました。テスト終了から判定会議まで2時間、事前に必要レポートの認識をあわせ、データベース担当、ネットワーク担当、負荷テストツール担当、各自レポートを作成。ギリギリ判定会議に間に合いました。チームになった瞬間です。


最後に


四回にわたり「負荷テストの成功ポイント」と題しましていくつかポイントを述べさせていただきました。「成功ポイント」と大げさに言っていますが、特別なものはなく実際には十分な計画と経験が必要だと考えています。予定通り進まないことが多く、負荷テストを敬遠される方もいますが、品質保証という面では必要なテストです。アシストはツールの使い方だけでなく、負荷テストの進め方やポイントについて今後とも情報提供して参りたいと思います。

ご意見、ご質問等ございましたら、 hpmrctec_web@ashisuto.co.jp までお問い合わせ下さい。

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

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


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

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

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


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

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



ページの先頭へ戻る