Rational Performance Tester V7.0 による Web システムの負荷テスト概要 本記事では、これまで負荷テストを実施する機会の少なかった開発者の方に向けて

Rational Performance Tester V7.0 による Web システムの負荷テスト概要
本記事では、これまで負荷テストを実施する機会の少なかった開発者の方に向けて
「Rational Performance Tester V7.0（以下 RPT）を使ってどうやって負荷テストを実施し
ていくのか」概要をご紹介していきます。実際に RPT を評価・導入される際には、Rational
Developer Domain（http://ibm.com/jp/developerworks/rational/）にある「Rational
Performance Tester V7.0 導入ガイド」にて詳細な操作方法を紹介していますので、合わせ
てご参照ください。
本記事の目次
・高まる負荷テストの重要性と課題
・RPT の特徴
・RPT による負荷テスト「ステップ１：スクリプト作成」
・RPT による負荷テスト「ステップ２：ワークロードのスケジュール」
・RPT による負荷テスト「ステップ３：実行と分析」
・まとめ
高まる負荷テストの重要性と課題
インターネットの普及等により、多くのシステムにおけるトランザクション量が格段に
増大している中、Web システムに対する性能・信頼性への要求も高まっています。このよ
うな中、本番稼働前に実際に Web システムに対し本番同様の負荷をかける負荷テスト、お
よび開発途中でのパフォーマンス検証の重要性は高まる一方です。
とはいうものの、「パフォーマンステストってなんだか難しそう」とか「やらなきゃいけ
ないのは分かっているんだけど実際には時間がなくてやれない」といった声を多く耳にす
るのも事実です。
Rational Performance Tester は、こういった声に答えるべく「テスト専門家だけでなく、
開発者にも使いやすいパフォーマンステストツール」をコンセプトとしています。
RPT の特徴
RPT は Web(HTTP/HTTPS)ベースのアプリケーションに向けたパフォーマンステスト
ツールです。
【テスト専門家だけでなく、開発者にも馴染みやすい Eclipse ベースのテストツール】
多くの開発者に支持されている「Eclipse」をベースとしており、ユーザーインターフェ
ース・操作感とも Eclipse に準拠しています（図１）。テストスクリプトはコーディングな
しで作成できますが、もし独自のカスタマイズを施したい場合は Java でコードを追加しま
す（独自言語ではなく、Java であるところがポイントです）。
図１
Rational Performance Tester の画面
【効果的なパフォーマンステストをサポートする、シンプルなインターフェースと充実し
た機能】
スクリプト作成、編集、ワークロードスケジューリング、実行、結果分析といった一連
の作業を、RPT のシンプルかつ一貫したインターフェースから実施します。例えば負荷テ
ストを実施する際には、データとして何を入力するか、サーバー応答値が何だったら正し
いのか、といった「データの扱い」がポイントとなります。RPT では、テストパラメータ
の変数化やサーバー応答値の検証設定などといった負荷テストに欠かせない作業を、図２
のようなシンプルなインターフェースでサポートします。
ページエレメントのツリービュー表示
データ相関関係の自動設定
データプール作成 など
図２
Rational Performance Tester におけるテストシナリオとデータ
【Extension（別売）によるターゲット拡大】
Siebel、SAP、Citrix に向けた Extension により、必要に応じてテスト対象ターゲットを
拡大することも可能です。
RPT の特徴が分かったところで、RPT による負荷テスト実施の手順をみていきましょう。
RPT によるパフォーマンステスト「１：スクリプト作成」
ま ずは テスト 対象 のアプ リケ ーショ ンを 操作し てス クリプ トを 記録し まし ょ う 。
Performance Tester で記録を開始すると、Internet Explorer などの Web ブラウザに対し
て行った操作に対応する HTTP/HTTPS 通信が記録されます。そして記録を停止したタイ
ミングでテストスクリプト（＝テストコンテンツ）が生成さます（図３）。
次に、記録したスクリプトに手を加えましょう（注：シンプルな負荷テストではこのス
テップを省略できることもあります）。たとえばログインを行うシナリオのテストを「A さ
ん」ユーザーを使って記録したとします。100 人が同時にログインする場面を再現する場合、
100 人がいっせいに「A さん」でログインしても困ります、普通は「Ｂさん」や「Ｃさん」
やその他たくさんのユーザーがいるはずだからです。そのようなときは、「A さん」のよう
な入力値を変数化し「B さん」
「C さん」
・・・でログインするように変更しますが、このと
き RPT は「A さん」のような変数候補を自動で抽出しピックアップしてくれます（図２参
照）。テストのシナリオと変数候補が 1 つの画面で確認できるのも嬉しいところです。これ
ら変数候補から変数にしたい項目を選び、データを作成していきます。
Performance Tester
HTTP
Proxy
レコーダー
ブラウザー
テストを生成
テスト対象
サーバー
図３
スクリプトの作成
RPT によるパフォーマンステスト「２：ワークロードのスケジュール」
「１：スクリプトの作成」が終ったら、できあがったスクリプトを組み合わせて現実の
負荷に近いスケジュールを組み立てましょう。たとえば 50 人の振る舞いをシミュレートす
る場合（50 仮想ユーザーあるいは 50 バーチャルユーザーと呼びます）、30%の人たちが注
文のシナリオを行っていて残り 70%の人たちが検索のシナリオを行っている、といった形
にシナリオを組み合わせていきます。RPT では、スクリプト作成と同様に図４のようなグ
ラフィカルな画面上でこのスケジュール操作を実施します。
図４
ワークロードのスケジュール
RPT によるパフォーマンステスト「３：実行と分析」
さあ、ワークロードのスケジュールが終ったらいよいよ負荷テストを実行しましょう。先
ほど作成したスケジュールを「実行」すると負荷テストがスタートします（図５）。
図５
スケジュールの実行
実行を開始すると、負荷テスト状況が逐次表示されます（図６）。ページ毎のパフォーマン
スやメモリーなどリソースの消費状況を確認しながらステータスが「完了」になるのを待
ちましょう。負荷テストが終了したら結果を検証します（図７）。
図６
負荷テスト実行中
サーバー環境のCPU使用率
図７
サーバー環境のCPU使用率
結果レポートの一例
負荷テストを実施した後に大事な作業は、パフォーマンスの悪かった箇所を分析すること
です。RPT では、WebSphere Application Server などの対応する J2EE アプリケーション
サーバーについてパフォーマンスの悪いページに対してより深く分析を行う「応答時間明
細」を行う機能が、デフォルトで付属しています（図８）
。
特定のページで応答時間の遅い
コンポーネントまで特定可能
マシン別応答時間
サーバー別応答時間
コンポーネント別応答時間
図８
応答時間明細
まとめ
本記事では RPT を使ってどうやって負荷テストを実施していくのか、その概要をご紹介
しました。「テスト専門家だけでなく、普通の開発者の方にとっても使いやすい負荷テスト
ツール」が RPT のコンセプトです。実際に操作して試されたい方には評価版 DVD も用意
されていますので是非お試しください。
IBM Rational Software Delivery Platform V7 評価版DVDのお申し込みはこちら
RPT評価版ダウンロードはこちら