今のテスト方法がベストですか？

Aさん：
今日は、負荷テストの件で相談したいことがあります。

コンシェルジュ：
はい。こちら IBM コンシェルジュ・サービスです。お問い合わせいただきありがとうございます。
どのようなことでしょうか？

Aさん：
実は、システム試験の最後に実施した負荷テストでパフォーマンス要件に満たないことがわかりまして…。
まあ、なんとか本番稼働には間に合わせたのですが、事前に防ぐことができないものかと…。

コンシェルジュ：
そうでしたか。それは、“負荷テストは最後にするもの”という思い込みが問題になっているのかもしれません。

Aさん：
え？負荷テストって最後にやるものじゃないですか？

コンシェルジュ：
確かに、負荷テストはシステム全体の開発が終わり、さまざまなテストの最終段階で行われることが多いですが、実際は、本番稼働直前の“末期”といえる段階でパフォーマンスの問題が見つかっても、もはや手遅れ。本来ならば、システムの構造やソース・コードに問題がないか、データベースのインデックスは大丈夫か根本から見直すべきなのに、その段階では、とてもそんな時間がありません。結局、ハードウェアの増強でその場をしのぐ…といった対応になりがちです。
後からシステム全体を見直そうとしても開発を担当したプログラマーは、すでに別プロジェクトに異動していて誰もわからない…ということにもなりかねません。

Aさん：
具体的にどうすれば…？

コンシェルジュ：
最後にやるのではなく、機能テストや単体テストが終わった段階から順番に、モジュールごとに負荷をかけて「パフォーマンスが低下することはないか」、「複数ユーザーでの利用に問題がないか」をチェックしておくことが大切です。こうして早い段階で問題を見つけ改善しておくことで、本番稼働直前に致命的な問題が発覚することを防ぎます。さらにソース・コードの修正が必要になっても、開発を担当しているプログラマー自身が修正対応できるから効率的です。その上で、最後にハードウェアやネットワークなど本番環境での負荷テストを実施してインフラを集中的にチェック。こうすれば“手戻り”も発生せず、“その場しのぎ”改善策は必要なくなります。

初期段階から小規模の「負荷テスト」を繰り返すイメージ

Aさん：
とはいっても負荷テスト・ツールって高額ですよね？

コンシェルジュ：
IBM Rational PerformanceTester (以下 RPT）ならベース・モジュールが20万円台。しかも5ユーザー分が含まれていますから、それだけで始めることもできます。

Aさん：
なるほど、これなら早い段階から小規模でも使えそうだ。

コンシェルジュ：
はい。ではこの RPT がどのような課題を改善できるのか、具体的にご説明いたします。FAX をお送りしますのでご覧ください。

課題1：ツールの使い方がわからない！難しくて使えない！
これで改善！ Eclipse ベースで使いやすいインターフェース
Java 開発で多く利用されている統合開発環境 Eclipse をベースにしており、使い慣れたインターフェースで利用できます。また、Java 開発ツールなど画面を切り替えながら利用することができるため、開発しながら負荷テストを行う場合もスムーズに行えます。

Eclipse ベースの使いやすいインターフェースに、洗練されたツールをラインアップ

課題2：負荷テストはデータも大量…。設定するのが面倒！
これで改善！テスト・データの設定をサポート
データベースのテーブルを指定することで、該当テーブルの構成に基づいたデータを入力フィールドに簡単に設定。ユーザーIDやパスワード、そのほか入力データなど実際の操作に近いものを簡単に作成できます。

課題3：複数ユーザーの同時操作試験は、現実的には難しい…。
これで改善！柔軟な“スケジューリング”が可能
各シナリオの“スケジューリング”も簡単。複数シナリオの同時実行など実際の負荷状況を想定したシミュレーションが可能だ。GUI ベース、コーディングなしで設定でき、同期などのタイミングも調整できます。

課題4：ボトルネック、性能劣化の原因がわからない…。
これで改善！サーバー側のパフォーマンスもまとめて分析
クライアント側におけるページ単位のスループットなどと同時に、サーバー側の CPU、メモリー、ディスク I/Oを取得可能。サーバー側のデータは API で呼び出すため、エージェントのインストールなどは不要。分析機能では、これらのデータを重ね合わせたグラフ表示が可能です。

課題5：パッケージ製品や SOA サービスのテストができない。
これで改善！パッケージ製品・SOAモジュールにも対応
GUI がない、SOA などのサービス・モジュールもテスト可能。また、SAP や Siebel、Citrix などのパッケージ性のテストにあらかじめ対応しているため、テスト準備がより容易になります。

※別途 Extension の導入が必要となります。

課題6：アプリケーションの問題点は、イチからのソース解析が必須。
これで改善！IBM WebSphere Application Server と連携し、より詳細に分析
Java によるアプリケーションの場合、IBM WebSphere® Application Server と連携することで、J2EE サーバー側のパフォーマンス・データ収集が可能。個別コンポーネントごとの実行時間を表示することができます。

※別途 Extension の導入が必要となります。

根本原因分析機能でボトルネックをポイント特定

Aさん：
RPT だと、いろいろできて、いままで悩んでいた問題のほとんどが解決できそうですね。ツールの威力はすごいね。
そういえば知り合いの会社では、プロジェクト・レベルのテストを、フリーのツールや自分たちで作った簡易ツールを使って行っていたようだけど、そういうツールは安心して使えるものでしょうか？

コンシェルジュ：
確かにコストがかからないメリットはありますが、企業としてのガバナンスや、テストの信頼性を考えると好ましい状況とは言えません。また、フリーツールを使いこなすにはそれなりの知識が必要です。スキルの高い人が情報を集めながらニーズに合った形で使わないと、なかなか思い通りには使えません。それに、もしもその人が異動になってしまったら、それ以降の試験や運用は立ち行かなくなってしまいます。自社で作られたツールにも同じことが言えます。ツールを開発した人が異動してしまったら、結局、誰もわからないということになることが多いようです。

Aさん：
なるほど。次のプロジェクトでは、RPT を利用できるよう検討してみます。

コンシェルジュ：
ありがとうございます。
最初は小さな範囲から始め徐々に、大規模なプロジェクトに展開していくことも可能なライセンスになっていますので、ぜひご利用ください。

コンシェルジュへお問い合わせ

中堅企業の皆様の課題解決をお手伝いします。まずはコンシェルジュにご相談ください。

お電話でのお問い合わせ:0120-03-9966
受付:9時30分から17時30分 平日のみ受け付けております