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

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

負荷テストの成功ポイント Vol.3 ~ツールでの作業上の注意点~

矢野 英也

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

はじめに


皆様、こんにちは。第二回の内容はいかがでしたでしょうか。第二回は「テスト環境の構成要素の確認」「体制・役割」「データ収集項目と判断基準」「スケジュール」など計画段階で確認しておくべきことについてお話ししました。今回は準備編、主に負荷テストツールを使って作業を進める上での注意点を中心にお話しさせていただきたいと思います。

今回はテスト実施に向けての準備においてのポイントをいくつかお話しします。LoadRunnerをベースにした内容ですが、確認するポイントはどの負荷テストツールでも共通しています。

スクリプト作成のポイント

相関


SessionIDや排他ロックIDなど、実行する度に動的に変化する値をハンドリングする設定のことを相関と呼んでおり、Webアプリケーションであれば、ほとんどのケースで必要になります。スクリプト作成にあたって、重要なポイントのひとつになります。

相関が必要な場合の例

負荷テストツールによって設定手順や容易さは異なりますが、どのツールにも備わっている機能です。ツールによって、修正箇所を自動検出できる機能を備えているものもありツール選定時に確認された方がいいでしょう。
またある程度ツールの方で相関箇所を検出できたとしても、アプリケーションの仕様を確認の上、動的に変わる箇所を確認しておくことは重要です。スクリプトでバック時に、アプリケーションの仕様通りの実行が行われているかを確認する時に役に立ちます。

遅延時間


スクリプトの各ステップ間で一時的に停止する機能です。画面入力にかかる時間や思考時間をシミュレートする際に利用します。

遅延時間の有無や倍率によって、単位時間あたりの処理数は大きく変わります。目標処理数から遅延時間を調整するようにしましょう。遅延時間については「シナリオ作成のポイント」でもう少し触れます。

パラメータ設定(変数化)


複数ユーザで同時実行する際に、ログインユーザや検索条件など同一データではなく、パラメータ設定(変数化)が必要になります。事前にパラメータ対象箇所を確認の上、Excelなどの外部ファイルを作成して用意します。

成功・失敗の判断


実行の成功・失敗はツールによって判断方法は異なりますが、多くの場合、HTTPステータスコードで判断しています。ステータスコードだけの判断ですとステータスコード200であれば、成功になります。そのため「ただ今込み合っています。しばらく経ってからアクセスして下さい」というページでも成功になります。ページタイトルや画面内の任意のテキストを成功条件になるようにツールで設定しましょう。

シナリオ作成のポイント

実行順序


起案→申請→承認 などのワークフローを負荷テストで再現する場合、スクリプトの実行順序の設定が必要になります。参照業務を中心とした負荷テストであれば、あまり考慮する必要はありません。

目標処理数


目標となる処理数を達成する為にあらかじめ机上で算出した上で、シナリオを設定するのが望ましいと思います。処理数は以下の要素を考慮しながら調整します。

・ユーザ数
・遅延時間
・応答時間

以下の例は、各業務が30分以内で実行する回数を目標設定し、遅延時間の倍率を設定した例です。ユーザ数ではなく、遅延時間の倍率を変えて、30分以内に実行する処理数を調整しています。

スクリプト ユーザ数 目標応答時間
(全体)
スクリプト内
遅延時間
遅延時間倍率 繰り返し回数
業務A 100 960 160 5.6 2
業務B 50 1280 170 6.8 2
業務C 30 560 100 5.2 4
業務D 1 480 80 5.6 4


応答時間は不確定要素(実際に負荷テストしてみないと分からない)の為、この表の通りにいかない場合があります。その場合は遅延時間を多くする、あるいはユーザ数を増やして、目標処理数に到達するようにします。

モニタリング設定


収集項目と判断材料については第二回でお話ししました。あとはツールで取得するだけです。ツールによって取得方法が異なりますので、対象サーバとの接続方法、プロトコル、ポートを確認しておきましょう。また監視間隔は細かい分析ができるようなるべく短い間隔(5~10秒)で取得すると良いと思います。

テスト環境構築について


負荷テストの準備を進める上で、テスト環境構築もあわせて考えなければなりません。テスト環境構築におけるソリューションをいくつかご紹介したいと思います。(負荷テストツールの機能ではありません)

テストデータ


テストデータの件数によって負荷テストの結果は変わりますので、なるべく本番環境と同等、何年後を想定する場合は本番データの数倍のデータ件数を用意しなければいけません。本番環境から抽出・加工しテスト環境で利用する方法が一般的ですが、専用ツールを使ってテストデータを作成する方法もあります。

またアプリケーションの画面からデータを作成しなければならない場合、キャプチャ&リプレイツールを使うこともあります。

参考:QuickTest Professionalで定例業務の自動化を!
http://www.ashisuto.co.jp/product/category/quality/functional-testing/technical/list/1195246_3455.html

スタブ/サービス仮想化


一部の機能開発が遅れてテスト環境が完成しない、またホスト環境やSaaS環境に接続する為、利用時間に制約があるなどの場合は、スタブを開発してテスト環境を構築する方法があります。また最近では「サービス仮想化」という方法も出てきました。

参考:品質とテスト効率化 「サービス仮想化」というアプローチ
http://www.ashisuto.co.jp/corporate/column/technical-column/detail/1196090_2274.html

環境構築自動化


開発中のアプリケーションであれば、1日に何十回という頻度でビルド、デプロイが発生します。手動で作業するとミスも発生しやすく、テスト環境の不備にもつながります。そのために、アプリケーション改修→ビルド→デプロイ→テスト を自動化する方法もあります。


コラム:テストスクリプト、どのタイミングで作成開始?

テストスクリプトはアプリケーションが完成してから作成するのが基本です。ただし、「アプリケーションが完成していない、でもテストスケジュールは決まっている、テスト準備を進めないと・・・」といった話はよくあることです。いつからスクリプト作成するのが正解か。

現時点で明確な回答はございません。アシストがご支援する場合は、スケジュールを優先して、アプリケーション改修がある前提でスクリプト作成を開始します。アプリケーション改修後、スクリプトを再作成する必要があるかもしれませんが、相関箇所、パラメータ設定など事前に確認しておけば、仮に再作成になったとしても、効率よくスクリプト作成ができるからです。


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

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


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

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

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


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

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



ページの先頭へ戻る