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

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

 

HP ソフトウェア

第四回(実施・分析編)

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

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

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

前回のおさらい

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

テスト実施のポイント

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

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

タイムスケジュールの例

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

テスト当日の体制

プロジェクトの体制については、第二回(続 計画編)の「体制・役割分担」でお話ししました。今回はテスト当日のオンサイト、オフサイトを含めた体制図についてです。必ずしもプロジェクトメンバー全員がオンサイトで対応する必要はありません。後日データ解析できるのであれば、オンサイトの対応は不要です。
ただし実際のテストの現場では、その場で解析、分析し、実施するテストケースの判断をしなければならない場合がほとんどです。テストの重要度、スケジュール、当日発生しうる問題を想定し、オンサイト、オフサイトメンバーを検討することをお勧めします。

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

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

  • 負荷テストツール側
    • スクリプト
      スクリプト作成時のデバックで実行確認しますが、アプリケーション改修によってスクリプトが動作しなくなる場合があります。問題切り分けのファーストステップとして、スクリプト単体でエラーの有無を最初に確認します。
    • パラメータデータ
      パラメータデータの不備や設定漏れでエラーになることがあります。例えば、ユーザIDを変えると、ユーザIDに関連している値がスクリプト内にある場合、相関(第三回「スクリプト作成のポイント」参照)が必要になる、等です
    スクリプトエラー、パラメータデータのエラーについては、テスト実施前にリハーサルをすることで事前にある程度対処することができます。
  • アプリケーション側
    アプリケーション側のエラーについては、OS・ミドルウェア設定不備、コネクション枯渇、ヒープサイズ設定不足、などが考えられます。問題切り分け・特定の時間が短くできるよう、分析に必要なデータを負荷テスト時に収集しておきます。データ収集項目については、第二回(続 計画編)「データ収集項目と判断基準」を参照下さい。

分析のポイント

速報

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

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

最終報告

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

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

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


最後に

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


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