テックノート

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

  • システム運用管理/テスト効率化
2014.07.28

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

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

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

今回はテスト実施に向けての準備においてのポイントをいくつかお話しします。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秒)で取得すると良いと思います。

テスト環境構築について


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

テストデータ


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

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

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

スタブ/サービス仮想化


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

参考:品質とテスト効率化 「サービス仮想化」というアプローチ
https://www.ashisuto.co.jp/tech-note/article/20140320_system.html

環境構築自動化


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


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

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

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


連載記事

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


執筆者のご紹介

アシスト矢野 英也

矢野 英也
東日本技術本部

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

本記事をご覧いただいている方へのご案内

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。


関連している記事

  • システム運用管理/テスト効率化
2017.12.06

運用部隊にどのような影響が?「コンテナ」のメリットと3つの対策

2016年10月、コンテナ技術はWindows対応したことで、エンタープライズ環境での更なる利用の促進が見込まれます。本コラムでは、コンテナ導入時のメリットや運用業務の変更・注意点について考察します。

  • システム運用管理/テスト効率化
2017.08.15

新たなテクノロジーへの取り組み
『AI』を活用した運用部門のトランスフォーメーション

新たなテクノロジーを活用してビジネスモデルを創出する期待感が高まり、「守りのIT投資先」と言われ続けた運用部門でも、新たな取り組みが求められています。本稿では、ITSMを担う運用部門での「人工知能(AI)」の活用と、同部門が持つ「情報(運用データ)」に焦点を当てます。

  • システム運用管理/テスト効率化
2015.01.23

【徹底比較】商用ツールにも引けを取らない6つのOSS監視ツールを機能で比較

オープンソースソフトウェアベースのツールを利用したインフラ運用基盤の構築が広まり、特に運用管理の分野においては、監視ツールの機能、製品数がともに充実している。本記事では、主だったOSS監視ツール6製品について、4つの機能で比較します。

ページの先頭へ戻る