| Oracle® Load Testing Load Testingユーザーズ・ガイド バージョン9.31 B62626-03 |
|
 前 |
 次 |
この章では、ライフサイクルを通じてWebアプリケーションのスケーラビリティとパフォーマンスをテストする基本的な方法について説明します。効果的なスケーラビリティ・テストを実行するための適切なツールと推奨される手順を選定するプロセスの概略を紹介します。この章は、大きく以下の項に分かれています。
スケーラビリティ・テストの目的と要件: Webアプリケーション開発の各段階で、スケーラビリティ・テストの結果として達成すべき内容。
方法論: アプリケーションのライフサイクルを通じてパフォーマンスとスケーラビリティを保証するために必要なプロセスと手順。
テストの計画と実行: 開発の各段階でスケーラビリティ・テストを計画し実行する過程。
負荷テストには、主に次のような目的があります。
Webアプリケーションのユーザー制限を決定すること。
ユーザー制限とは、ユーザーが一般的な各種のビジネス・トランザクションを実行するとき、安定して妥当なレスポンス時間をユーザーに提供しつつシステムでサポートできる最大同時ユーザー数のことです。
ユーザー制限は、デプロイされたときアプリケーションがサポートできる同時ユーザー数より大きくなければなりません。
負荷時におけるクライアント側の性能低下とエンド・ユーザー体験を判断すること。
ユーザーが適切なタイミングでWebアプリケーションにアクセスできるかどうか。
ユーザーがビジネスを遂行あるいはトランザクションを実行する時間は許容範囲かどうか。
時間帯や同時ユーザー数、トランザクション数や使用状況がWebアプリケーションのパフォーマンスに影響するかどうか。
性能低下は適切か。負荷が大きい状況で、低速であってもアプリケーションが正しく動作するかどうか。コンポーネントがクラッシュしないか、エラーや不完全なメッセージがクライアントに表示されないか。
ユーザーが遭遇するエラー率はどのくらいか。許容範囲かどうか。負荷が大きい状況でも、ユーザーはビジネス・トランザクションを完了できるか。多くのユーザーにエラー・メッセージが表示されないか。
負荷が大きくなったときWebサーバーがクラッシュしないか。
負荷が大きくなったときWebサーバーがクラッシュしないか。
負荷が大きくなったときアプリケーション・サーバーがクラッシュしないか。
負荷が高くなったとき、その他の中間層サーバーがクラッシュしたり低速になったりしないか。
負荷が大きくなったときデータベース・サーバーがクラッシュしないか。
システム負荷のバランシングが必要かどうか。ロード・バランシング・システムを使用している場合には、正しく機能するかどうか。
現在のアーキテクチャを微調整してさらにパフォーマンスの向上を期待できるかどうか。
パフォーマンスの向上にハードウェアの変更は必要かどうか。
システムにリソース上のデッドロックはないか。
Webアプリケーションの負荷とスケーラビリティをテストする各段階は次のとおりです。
アーキテクチャの検証: Webアプリケーション開発の早い段階でアーキテクチャのスケーラビリティをテストします。アプリケーションのプロトタイプを作成し、トランザクションを生成してアプリケーションのすべての層にアクセスが可能になった段階などが考えられます。この過程で、Webアプリケーションの構築に選定されたアーキテクチャ・フレームワークか現実的かどうかを、エンジニアリング組織が判断できます。
パフォーマンスのベンチマーク: すべてのビジネス・トランザクションを想定した初期段階のアプリケーションに対してベンチマーク・テストを設定し作成します。これによって、エンジニアリング・グループと品質管理グループは、アプリケーションのスケーラビリティを定量化する一連のメトリックを得ることができます。開発グループは所定の要件に基づいて、このスケーラビリティを維持するか、次のマイルストーンを経てスケーラビリティを引き上げます。
パフォーマンスの回帰テスト: 確定したベンチマークを使用してWebアプリケーションをテストし、アプリケーションに対する変更点がスケーラビリティ低下の原因になっていないことを確認する段階です。回帰テストは、アプリケーションの開発中に主なマイルストーンに達した時点やアーキテクチャ変更があった時点で実行されます。回帰テストは、アプリケーションの開発中に主なマイルストーンに達した時点やアーキテクチャ変更があった時点で実行されます。
承認とスケーラビリティの微調整: Webアプリケーションを公式に公開する前の最終的な負荷テスト段階です。ハードウェア、ロード・バランシング・コンポーネント、すべてのソフトウェア・コンポーネントなど、Webアプリケーションのあらゆる部分を統合し、スケーラビリティを検証します。最終構成のスケーラビリティは、実世界での様々な使用シナリオをエミュレートした上で検証されます。このようなシナリオは、最適なパフォーマンスを発揮するハードウェアとソフトウェアのコンポーネントを設定する目的でも利用されます。
24x7態勢のパフォーマンス監視: アプリケーションのデプロイ後には、深刻な問題となる以前にクラッシュや速度低下を検出するために、実際のユーザーによって発生する現実的な負荷状況でシステムのパフォーマンスを監視することが不可欠です。この段階では、現実的な用途に伴うデータを収集すると、将来的なスケーラビリティ・テストを再調整して負荷を正確にエミュレートする役に立ちます。
実際のアプリケーションの使用が反映される現実的な負荷をエミュレートするには、負荷テストのツールに次のような条件が求められます。
多層アプリケーションのすべての層に負荷をかけられること。
ピーク期間のサイト上で種類の異なるビジネス活動を実行する各種のグループが混在する、現実的な状況をシミュレーションできること。
Internet ExplorerやNetscapeなどユーザーの多いブラウザで生成されるページ・リクエストやリソース・リクエストをエミュレートできること。
何千という同時ユーザーのそれぞれに対してWebブラウザから返されるレスポンスを評価し、負荷時でもWebアプリケーションから正しいページが返されることを確認できること。
システムが変更されるたびにスケーラビリティを再評価できるように、アプリケーション変更時にはスクリプトを簡単にメンテナンスできること。
さらに、次のような基準も重要です。
ユーザーの動的なダイアルアップ: 現在のテストを停止せず、負荷テストに新規ユーザーを追加できることです。たとえば、100ユーザーの負荷テストを実行しているとき、動的にさらに100ユーザーを追加する場合、負荷テストを停止することなく200ユーザーで新しいテストを再開できます。
リアルタイムの仮想ユーザー・デバッガ: 負荷テスト・ツールには、負荷テストの進行中いつでも、ユーザーの進捗状況を仮想的に監視できる機能が必要です。
リアルタイム・グラフ機能を使用すれば、負荷テストの進行中にアプリケーションのスケーラビリティ特性を判定できます。
LAN/WAN上の多くのマシンから一元的な管理下で負荷テストを分散できること。
記録された思考時間、ランダムな思考時間(なんらかの統計的分散による)、あるいは思考時間なしで負荷テストを実行できること。
サブフレームや画像などページ上の個々のオブジェクトに加え、ビジネス・トランザクション全体のレスポンス時間を測定できること。
異なるタイプのキャッシュ動作をシミュレーションできること。
システム上の一意の同時ユーザーに対して、データ駆動型テストを実行できること。
開始、終了、増加の各シナリオに応じた複雑なスケジュールに対応できること。
実行後の解析や以前のベンチマークとの比較を行うために、レポートおよびパフォーマンス・データベースの機能があること。
スケーラビリティ・テストには、様々なレベルでテストを実施し結果をレポート/解析するために、各種のソフトウェア・ツールが必要です。テストを実行する前に、テストで使用する次のソフトウェア・ツールに習熟しておく必要があります。
Oracle OpenScript: 仮想ユーザーが実行する各種のスクリプトを作成するツールです。スクリプトには、アプリケーションでビジネス・トランザクションを実行するときの実際の手順を指定します。アプリケーションを完全にテストするには、様々な領域(ビジネス・トランザクション)を実行する多様なスクリプトが必要になります。アプリケーションに変更がある場合、スクリプトのメンテナンスは容易です。
Oracle Load Testing: 仮想ユーザー・プロファイルとシナリオを定義し、負荷テストを実行します。Oracle Load Testingは、アプリケーションのスケーラビリティをテストする複数の仮想ユーザーとしてスクリプトを実行します。Oracle Load Testingでは、仮想ユーザーのタイプおよび数と、仮想ユーザーごとに実行するスクリプトを定義します。また、テストの進行状況を評価するためのリアルタイム・レポートとグラフ、テスト結果を実行後に解析する分析後のレポートとグラフの機能もあります。
Oracle Load Testing ServerStats: 各種のデータ・ソースに関してリアルタイムのシステム監視を行い、個々のサーバー(Webサーバー、データベース・サーバー、アプリケーション・サーバーは、システム・カウンタ)に対する負荷テストの影響を監視します。たとえば負荷テストでは、Netscape Webサーバー、ColdFusionアプリケーション・サーバー、Tuxedoサーバー、メインフレームのデータベース・サーバーなどのソフトウェアの監視が必要になる場合があります。
Oracle Application Testing Suiteのほかに、監視またはレポートに特化した他のソフトウェアが必要な場合があります。
他のシステム監視ツール: 負荷テストの監視に必要な他のソフトウェア・ツールを決定してください。
ログ・ツール: トランザクションやパフォーマンスのデータ、またはロギング・エラーなどのログに使用するソフトウェア・ツールを決定してください。
また、アプリケーション・アーキテクチャで各種コンポーネントの状態を監視する他のツールからデータを収集することも必要になります。こうすると、スケーラビリティ・テストの際にクライアント側で確認された性能低下を、アプリケーションの特定のコンポーネントに伴うスケーラビリティの問題に関連付けることができます。
スケーラビリティ・テストを効果的に実行するには、テスト・ツールの実行に適したハードウェアを用意して設定する必要があります。
何千という同時ユーザーが使用するWebアプリケーション上に負荷を発生させるには、次の点を考慮する必要があります。
負荷分散の機能: 負荷テスト・ツールで、複数のマシンから負荷を生成し、一元的に制御できるかどうか。
オペレーティング・システム: 負荷テスト・マスターと負荷生成エージェントを、どのオペレーティング・システムで実行するか。
プロセッサ: マスターと仮想ユーザー・エージェントに必要なCPUのタイプ
メモリー: マスターと仮想ユーザー・エージェントに必要なメモリーの容量。
スケーラビリティ・テストの実行に適したハードウェアを用意するには、負荷テスト・ツールのベンダーに問い合せて、負荷テスト・マスターおよびエージェント・マシンのハードウェア要件を確認してください。
仮想ユーザーの負荷テストを実行するには、オペレーティング・システムとしてのスケーラビリティと安定性に優れているので、Windows NT 4.0/2000/2003の方がWindows 98/XPより適しています。
負荷テストに使用するワークステーションのいずれか(負荷マスターでも、同時ユーザーを実行している負荷エージェントでも)でCPU使用率が70%から80%より高くなる場合、あるいはメモリー使用量が85%を超える場合には、そのワークステーションで実行されているプロセスにオペレーティング・システム・リソースの競合が発生しており、そのテスト・ステーションでのパフォーマンス結果は正常になりません。
可能であれば、負荷マスターを別のマシンで実行することを検討してください。マスターとして動作するマシンは一般的に高性能のCPUを必要とするからです。仮想ユーザーは1つ以上のマシンで実行できます。そのマシンには、大量の仮想ユーザーを実行できる十分なメモリーを搭載する必要があります。
1つのマシンで実行できる仮想ユーザーの数を決定するには、各仮想ユーザーが消費するメモリー量に基づいて概算する方法があります。仮想ユーザーを1プロセス内のスレッドとして実行する場合、メモリー消費量は平均で300から500KBです。仮想ユーザーをプロセス内の個々のプロセスとして実行する場合、メモリー消費量は平均で1024から2048KBです。
特定の負荷テスト用設定のハードウェア要件を説明しているハードウェア設定のドキュメントについては、各テスト・ベンダーにお問い合せください。
負荷テストには、次のグループが主に関与します。
開発エンジニアとアーキテクチャのグループ: Webアプリケーションについて、アーキテクチャ検証テストとベンチマーク基準を設計し実行します。負荷状態で最適に実行されるようにアプリケーションおよびデプロイメント・アーキテクチャを微調整する際には、品質保証グループと連携します。
大規模なソフトウェア組織になると、スケーラブルなフレームワークの構築と保守を担当する専門のパフォーマンス・アーキテクチャ・グループも存在します。
品質保証グループ: 適切なアプリケーションの運用と許容パフォーマンスを検証するために、開発テストを設計し実行します。
統合と承認のグループ: アプリケーションの承認とデプロイに先立ち、すべての層とハードウェアが正しく連携することを確認するために、統合テストを設計し実行します。ほとんどの組織では、これも品質保証グループの担当になっています。
監視と運用のグループ: デプロイされたアプリケーションが24x7態勢で利用でき、負荷状態や、通常の使用でも長期にわたる場合に性能低下が見られないことを確認するために、監視テストを設計し実行します。
結果が不正確になりエラーの原因にもなる一般的な落とし穴があり、スケーラビリティ・テストを実行する組織はこれを回避しなければなりません。次のようなことを避けてください。
テストの実行中にも変更されるようなアプリケーションに対して負荷テストを実行すること。
機能テストが済んでいないため基本的な機能さえ運用されていないアプリケーションに対して負荷テストを実行すること。
アプリケーションの一部に負荷テストを実行し、その結果をアプリケーション全体に当てはめて考えること。
アプリケーションの一部に負荷テストを実行し、その結果をアプリケーション全体に当てはめて考えること。
Webアプリケーションに対してスケーラビリティ・テストを実行する一般的なプロセスは、次のとおりです。
アプリケーションのライフサイクルを通じてスケーラビリティ・テストを実行するために反復可能なプロセスを定義します。
スケーラビリティの基準を定義します。
負荷テストの実行に必要なソフトウェア・ツールを決定します。
スケーラビリティ・テストの実行に必要なハードウェアと環境を定義し、設定します。
スケーラビリティ・テストを計画します。
テスト・シナリオを計画します。
スクリプトを作成して検証します。
負荷テストのシナリオを作成して検証します。
テストを実行します。
定義された基準に照らして結果を評価します。
必要なレポートを生成します。
以上の手順の詳細を、これ以降の項で説明します。
負荷テスト作業の要件を定義したら、テスト計画の担当者がプロセスを定義します。プロセスを定義する際、テスト計画担当者は次の質問と回答について考える必要があります。
必要なアプリケーション: 負荷テストを実行する対象のアプリケーションは何ですか。
スケジューリング: テストを実行するのはいつか。日付と時刻、ビルドの可用性、達成する必要のあるテストのマイルストーンはどうか。
担当者: 解析、計画、テストの開発、テストの実行、評価を実施するのは誰か。部署内部の担当者(ビジネス・アナリスト、ネットワーク専門家、品質保証エンジニア、開発者など)は関与するのか。第三者の担当者(ツール・ベンダー、インターネット・サービス・プロバイダ、テスト・ラボなど)は必要か。
場所: テストをどこで実施するか。テストを社内で実行するか、インターネット・サービス・プロバイダやテスト・ラボなど外部で実行するか。
テスト環境: 負荷テストを実行する対象のSW/HW環境は何か。テスト環境を指定する際には、一般的に陥りやすい次のような点に注意してください。
アプリケーションの安定性: 負荷テストの実行中にはアプリケーションが変更されないようにすること。アプリケーションの全体または一部が、アプリケーションの負荷テスト中にさえ変更されることは少なくありません。
デプロイメント環境: 負荷テストを実行するときアプリケーションが動作する環境が、完全に同じではないとしても実際のデプロイメント環境にきわめて近いこと。たとえば、高い負荷に対応できる十分な性能で設定したHTTPSサーバーに対して負荷テストを実行しなければならないという要件がある場合、開発グループが使用する小規模なサーバーに対して実行しないようにしてください。
承認環境: 製品を出荷する前に実行する承認テストの一環として、負荷テストの実行に使用する環境が、実際の本番環境(仕様ドキュメントで定義される)と正確に同じであること。
ハードウェアの割当て: 必要なハードウェア(ネットワーク、マスター負荷テスト用コンピュータ、エージェント・コンピュータなど)が割り当てられ、使用できるかどうか。テスト・ベンダーは、次の情報に基づいて必要なハードウェアを決定をサポートする必要があります。
仮想ユーザーの数、またはアプリケーション全体に必要なスループット(1秒当たりのトランザクション)
各ビジネス・トランザクションの最大時間または許容時間
ビジネス・トランザクション間の最大時間または許容時間
負荷テストの計画を始める前に、アプリケーションを承認し実際にデプロイする準備ができたかどうかを示す基準を定義する必要があります。基準を定義する際には、次の点を指定します。
シミュレートする負荷: シミュレートが必要な仮想ユーザーの数。Webサーバー上の同時ユーザー数を表します。
シミュレートするビジネス・トランザクションの数: 負荷テストでシミュレートが必要なビジネス・トランザクションの数。これは要件を計画するときのアプリケーションの解析によって決定され、1秒当たりのトランザクション数(TPS)、1時間当たりのトランザクション数、または同時ユーザー・セッション数として指定できます。
シミュレートするビジネス・トランザクションのタイプ: シミュレートが必要なビジネス・トランザクションのタイプ(勘定残高の読取り、勘定取引の実行、勘定詳細のチェック、寄与率のチェックなど)。
各ビジネス・トランザクションの基準: ビジネス・トランザクションごとに、次の点を決定します。
様々な負荷における許容レスポンス時間: 様々な負荷条件下で許容されるレスポンス時間。たとえば仮想ユーザー数が100の場合、200の場合に許容されるレスポンス時間、あるいは上限最大数の仮想ユーザーを実行するとき許容されるレスポンス時間などです。
許容される失敗率: 負荷状態で、すべてのトランザクションについて、また各ビジネス・トランザクションについて許容される失敗率。たとえば、仮想ユーザー数が100の場合の失敗率はゼロ、仮想ユーザー数が200の場合の失敗率は5%などです。
ユーザーのカテゴリ: 各種のトランザクションでシミュレートするユーザーのカテゴリ。初回ユーザーか、繰返しユーザーかなどです。初回ユーザーの場合は、すべての画像をダウンロードする必要があるので、Webサーバーに対するオーバーヘッドが高くなります。両方のタイプのユーザーに対するテストを設計および開発し、様々な条件下で負荷テストの組合せを実行することができます。
シミュレートするブラウザ: 負荷テストでシミュレートするブラウザの種類。Internet ExplorerとNetscapeのどちらをテストするか、両方か。
ペーシング・モード: 負荷テストで使用される仮想ユーザー・ペーシングの種類。テストは、記録された思考時間を使用して実行する(つまり、スクリプトの記録中に発生する自然な一時停止に対応する遅延をページ間に設定して実行する)のかどうか。ページ間の遅延を設定せずに最大負荷をシミュレートするのか。あるいは、T3接続を利用する熟練ユーザーから低速なモデムを利用する初心者ユーザーまで幅広いユーザー速度を表すランダムな遅延時間をシミュレートするのか、ということです。
ビジネス・トランザクション実行間の遅延: ビジネス・トランザクションのテスト間に遅延時間を含める場合、どのくらいの時間か。
画像の有無: 仮想ユーザーは画像あり、画像なしのどちらで実行するのか。画像はWebサーバーに対する負荷が増える要因となります。比較のために画像ありと画像なしの両方で負荷テストを実行するのも一般的です。
1秒当たりに必要な総合スループット: 負荷テストで、1秒当たりのトランザクション数(TPS)に必要な総合スループットはどのくらいか。これは、同時ビジネス・トランザクションの数と代表的なトランザクションの時間とに基づいて計算できます。
エラー処理のタイプ: 負荷テストを実行する際に必要なエラー処理のタイプ。特定のエラーが発生した場合に、負荷テストを停止するのか、単にエラーをログに記録して続行するのか。同時ユーザーごとに、またアプリケーション・アーキテクチャのコンポーネントごとに、どのような種類のエラー処理が必要か。
トランザクションおよびパフォーマンス・データのログのタイプ: 各種のスクリプトで、どのようなトランザクション・データとパフォーマンス・データの記録が必要か。
実際にテストを作成する前に詳細なテスト計画を策定するのは、アプリケーションのビジネス解析と定義された基準にテストが適合しているかどうかを確認するための重要なステップです。
ビジネス・トランザクションを実行するテストごとに、次の内容を計画し定義します。
スクリプトのステップ: 各スクリプトには、ユーザーが実行するアクションを厳密に定義した詳細なステップ順序が必要です。複数のスクリプトを使用できます。たとえば、ユーザー・ログインを処理する特定のスクリプト、一連のビジネス・トランザクションを実行する複数のスクリプト、ユーザーのログオフを処理するスクリプトなどを定義できます。スクリプトごとに、想定される結果も定義します。Oracle OpenScriptを使用すると、ユーザーのアクションをエミュレートするスクリプトを簡単に記録できます。
ランタイム・データ: テスト計画には、アプリケーションとのやり取りに必要なランタイム・データを指定する必要があります。たとえば、ログイン時のユーザーIDとパスワードなど、実行時のアプリケーションに固有のデータです。
データ駆動型テスト: スクリプトを実行するたびに異なるデータが必要な場合には、このデータを必要とするすべてのフィールドを把握しておく必要があります。仮想データを作成する、あるいは既存のデータベースから実データを抽出する際に必要なデータソースとツールも定義してください。
Oracle OpenScriptのデータ・バンク・ウィザードを使用すると、外部データソースを指定してスクリプトに結び付けることができます。
スクリプトごとのビジネス・トランザクションの詳細に加え、テスト計画では負荷テストに必要なユーザー・グループとテスト・シナリオも指定する必要があります。テスト・シナリオごとに、次の内容を計画し定義します。
ユーザーのタイプ: アプリケーションの初回ユーザーか、繰返しユーザーか。ユーザーによってアプリケーションの応答が異なり、初回ユーザーの方が繰返しユーザーのときよりサーバーに対する負荷が大きくなる場合には、この点が重要です。Oracle Load Testingのシナリオには、初回ユーザーと繰返しユーザーのいずれかを指定できます。
実行するトランザクション: このユーザーはどのようなビジネス・トランザクションを実行するか。実行する順序はどうか。初回ユーザーになんらかの登録の実行を求めるアプリケーションの場合、初回ユーザーのユーザー・プロファイルには登録スクリプトを含める必要があります。
ユーザーの数: 同じ期間にこのユーザー・プロファイルで実行される仮想ユーザーの数。Oracle Load Testingでは、テスト・シナリオごとに仮想ユーザーの数を指定できます。
使用するシステム: このユーザー・グループに対して実際に負荷を生成するコンピュータ。Oracle Load Testingは、単一システムでも、Oracle Load Testingエージェントを実行する複数の分散システムでも仮想ユーザーを実行できます。Oracle Load Testingには、どの仮想ユーザー・シナリオをどのワークステーションで実行するかを指定します。
使用するブラウザ: このユーザー・グループでエミュレートされるブラウザ。Oracle Load Testingでは、仮想ユーザー・シナリオでエミュレートするブラウザとしてInternet ExplorerかNetscapeを指定できます。
ペーシング・モード: ユーザー・グループに対して使用されるペーシング・モード。テストは、記録された思考時間と時間範囲のどちらで実行するのか、あるいは可能なかぎり高速に実行するのか。Oracle Load Testingの仮想ユーザー・シナリオには、記録済、ランダム、ペーシングのいずれかを指定できます。
ビジネス・トランザクション実行間の遅延: ビジネス・トランザクション間に遅延時間を含める場合、どのくらいの時間か。Oracle Load Testingでは、トランザクション実行間の遅延時間を指定できます。
画像の有無: ユーザー・グループが画像あり、画像なしのどちらで実行するのか。比較のために、画像ありと画像なしの両方で負荷テストを実行するグループを作成する場合もあります。Oracle Load Testingにはこの機能が用意されています。
スクリプトを計画したら、Oracle OpenScriptを使用して各スクリプトを作成して検証します。
スクリプトの作成: このプロセスはOracle OpenScript (ユーザー・アクションを記録する)と、スクリプトごとの個々のテスト計画によって定義されます。スクリプトを作成する際には、テスト計画での定義に従って次の情報を指定します。
実行するユーザー・アクション
タイマー
実行するテスト
データソース
スクリプトの検証: 作成したスクリプトが、予定どおりに実行され、所定の結果を生成するかどうかを検証します。スクリプトのデバッグが容易になるように、各スクリプトは相互に独立して、また管理下で検証する必要があります。
個々のスクリプトの作成と検証が終わると、負荷テスト・シナリオの作成と検証が可能になります。最終的な負荷テストの前に単純な検証ステップを数多く実行しておけば、時間の節約になり、事態の悪化も避けることができます。
複数の仮想ユーザーによるスクリプトの検証: 複数のスクリプトを1つの負荷テスト・シナリオに組み合せる前に、複数の仮想ユーザーで1つのスクリプトが正常に稼働することを検証します。各スクリプトは、アプリケーションの基準で定義したとおりに動作する必要があります。
Oracle Load Testingのオートパイロットを使用すると、仮想ユーザーの特性を変化させて複数のシナリオを実行できます。
複数マシンでの分散テスト実行の検証: 複数のCPUを使用して負荷を生成する予定の場合には、負荷テスト・ツールが分散環境で個々のスクリプトを適切に実行できるかどうかを検証する必要があります。これには通常、ネットワーク上の複数のワークステーションで仮想ユーザーの実行を制御するマスター・システムを使用します。この検証で、個々のインストール環境の問題とネットワーク関連の問題を切り分けやすくなります。
ユーザー・グループのいずれかを含む現実的なシナリオの検証: 完全な負荷テストを実行する前に、同時に実行したい各ユーザー・グループのうち1つの仮想ユーザーを含むシナリオを作成し、検証します。つまり、20の仮想ユーザー(VU)から成るグループA、20 VUのグループB、60 VUのグループCを実行する前に、まずグループA、グループB、グループCのそれぞれ1 VUを実行し、予測どおりの結果が得られることを確認するということです。
現実的なシナリオの作成: このプロセスはシナリオごとのテスト計画で定義する必要があります。個々のシナリオを作成する際には、テスト計画での定義に従って次の情報を指定します。
ユーザーのタイプ
ペーシング・モード
実行するナビゲーション/トランザクション
トランザクション実行間の遅延
各タイプのユーザー数
画像の有無
負荷の生成に使用するシステム
エラー・ログ設定
ブラウザ・エミュレーション
ここまでで基本的な負荷テスト・シナリオの作成と検証が済んだら、多数の仮想ユーザーで負荷テスト・シナリオの実行を開始し、テスト結果が有効であることを確認できます。
基本テキストを実行してスケーラビリティを確認: 最低限の仮想ユーザー数でテストを実行し、システムが適切にスケールすることを確認します。
個々のビジネス・トランザクションを実行: 仮想ユーザー数10から始めて25から50までに増やしていきながら、個々のビジネス・トランザクションを実行します。
ビジネス・トランザクションの組合せを実行: 仮想ユーザー数5から始めて25までに増やしていきながら、異なるビジネス・トランザクション・スクリプトの組合せを実行します。
上の2つのシナリオを問題なく実行できたら、次のステップではユーザー・グループ・タイプごとにすべての仮想ユーザーに対して全負荷のテストを実行します。
現実的なシナリオの実行: 前のステップで説明したように、実際のシナリオを実行します。
必要な同時仮想ユーザー数までシナリオを増やします。
システムでエラーを監視します。
実際のユーザーに対してこのシナリオを再実行: 負荷テストの実行中に、実際のユーザーが標準ブラウザを使用してシステムにアクセスし、そのときのパフォーマンス状況をレポートします。
実際のユーザーがアクセスしたときの性能低下を観察します。
ブラウザでレポートされるエラーがあれば確認します。
開発サイクルを通じて行われる負荷テストは、スケーラビリティと信頼性の高いWebアプリケーションを設計するプロセスに欠かせない要素になりました。開発者もQA専門家も、システム・アーキテクチャを評価する、最大限のパフォーマンスを得るためにアプリケーションをチューニングする、そしてハードウェア・アップグレードによる影響を査定するために負荷テスト・ツールを利用しています。その結果、アプリケーションの完成度やシステム・ハードウェアおよびソフトウェアの変更の可能性に関する大きな意思決定の基礎として負荷テストの結果を利用できることが、今や不可欠です。このマニュアルに記載されている方法論と、Oracle Load Testingなどの高精度な負荷テスト・ツールを使用すれば、Webアプリケーションのパフォーマンスを保証する体系的なアプローチが可能になります。負荷テストをアプリケーション・ライフサイクルのルーチンとして確立することで、アプリケーションの公開時やその後のリリース時に「想定外のスケーラビリティ」に伴うコストも回避できます。
