| Oracle® Load Testing Load Testingユーザーズ・ガイド バージョン9.20 B62626-01 |
|
 戻る |
 次へ |
この章では、ライフ・サイクル全体を通したWebアプリケーションのスケーラビリティとパフォーマンスに関する基本的なテストの方法論について説明します。スケーラビリティ・テストを効果的に実行するために、適切なツールと推奨手順を選択するプロセスについて説明します。この章は、次の項で構成されています。
スケーラビリティ・テストの目標と要件: Webアプリケーション開発の各段階におけるスケーラビリティ・テストの結果として、目標とする項目
方法論: アプリケーションのライフ・サイクルを通したパフォーマンスとスケーラビリティを確認するために必要なプロセスと手順
テストの計画と実行: 開発の各段階での、スケーラビリティ・テストの計画と実行方法
負荷テストの主な目標は、次のとおりです。
Webアプリケーションの最大ユーザー数の決定
最大ユーザー数とは、ユーザーが複数の一般的な業務トランザクションを実行している状況で、安定性と適度な応答時間を保持しながら、システムで同時にサポートできる最大ユーザー数のことです。
最大ユーザー数は、運用時にアプリケーションがサポートできる同時ユーザーの要求数より、大きくします。
負荷がかかっている状態での、クライアント側の効率低下とエンド・ユーザー活動の決定
ユーザーはタイムリにWebアプリケーションに移動できたか。
ユーザーは、業務の処理やトランザクションの実行を、適切な時間内で行えたか。
時刻、同時ユーザー数、トランザクション、使用率が、Webアプリケーションのパフォーマンスにどのような影響を与えるか。
効率低下は徐々に発生しているか。負荷が大きい状態では、アプリケーションはゆっくりと正しい処理を行っているか。コンポーネントがクラッシュしたり、クライアントに誤ったページや不完全なページを送っていないか。
ユーザーが気付くエラーの発生率はどれくらいか。それは許容範囲内か。負荷が大きい状態では、ユーザーの大部分が業務トランザクションを続行し、完了しているか。それとも、多数のユーザーがエラー・メッセージを受信しているか。
サーバー側の頑強性と効率低下の決定
Webサーバーは負荷が大きいときにクラッシュするか。
アプリケーション・サーバーは負荷が大きいときにクラッシュするか。
その他の中間層のサーバーは、大きな負荷がかかったときにクラッシュするか、または、処理速度が低下するか。
データベース・サーバーは負荷が大きいときにクラッシュするか。
システム負荷の分散を必要としているか、または、負荷分散システムがある場合、それは正しく機能しているか。
現在のアーキテクチャは、よりよいパフォーマンスを得られるように適切に調整されているか。
パフォーマンスを向上させるために、ハードウェアを変更する必要はあるか。
システムにリソース・デッドロックはないか。
Webアプリケーションの負荷テストとスケーラビリティ・テストの各段階は、次のとおりです。
アーキテクチャ検証: Webアプリケーション開発の初期段階に、アーキテクチャのスケーラビリティをテストします。たとえば、アプリケーションのプロトタイプが作成され、そのアプリケーションのすべての層にアクセスするトランザクションを生成できるようになった後などです。このテストにより、エンジニア・チームはWebアプリケーションの構築に選択したアーキテクチャ・フレームワークの実行可能性を判断できます。
パフォーマンス・ベンチマーク: 全業務トランザクション用のアプリケーションの初期バージョンに対して、ベンチマーク・テストの設定と作成を行います。また、アプリケーションのスケーラビリティを測るための測定基準を、エンジニア・グループと品質管理グループに提供します。指定された要件に基づいて、開発グループはこのスケーラビリティを維持するか、または、さらなる改善を続けます。
パフォーマンス回帰: 確定したベンチマークでWebアプリケーションをテストし、アプリケーションの変更がスケーラビリティの効率低下を招かないことを確認する段階です。これらのテストは、主要な到達点に達したときや、アプリケーションの開発中にアーキテクチャに関わる修正が行われたときに、実行します。また、最初にアプリケーションに設定されたベンチマーク・テストや測定基準は、アプリケーションの改良を反映するため、さらにテストしたり、新しい測定基準に置き換えたりするのが一般的です。
受け入れおよびスケーラビリティの適切な調整: ハードウェア、負荷分散コンポーネント、すべてのソフトウェア・コンポーネントを含む、Webアプリケーションの全部品の統合とスケーラビリティの検証が終了した、Webアプリケーションの公式運用前の、最後の負荷テストの段階です。実際の使用方法の様々なシナリオをエミュレートし、最終構成のスケーラビリティを検証します。これらのシナリオは、ハードウェア・コンポーネントとソフトウェア・コンポーネントを構成して、最適なパフォーマンスを得るためにも使用します。
毎日24時間のパフォーマンスの監視: アプリケーションの運用後は、実際のユーザーによる現実の負荷の下で、システムのパフォーマンスを監視し、クラッシュや効率低下が問題になる前に、その箇所を見つけることが、最も重要になります。この段階では、収集された現実の使用によるデータを使用して、負荷を正確にエミュレートするためのスケーラビリティ・テストを、将来に向けて改善します。
実際のアプリケーション使用と相関する現実的な負荷をエミュレートするため、負荷テスト・ツールには次の機能が必要です。
多層アプリケーションのすべての層にかかる負荷の作成
ピーク時のサイトで、異なるタイプの業務処理を実行する異なるグループを現実的に組み合せたシミュレーション
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の他に、特別な監視やレポーティング用のソフトウェア・ツールが必要になることがあります。
その他のシステム・モニタリング・ツール: 負荷テストの監視には、他にどんなソフトウェア・ツールが必要かを検討します。
ログ・ツール: トランザクションやパフォーマンス・データのログ記録や、エラーのログ記録のために使用する、ソフトウェア・ツールを検討します。
さらに、アプリケーション・アーキテクチャで、異なるコンポーネントの状態を監視する他のツールから、データを収集する必要もあります。これによって、スケーラビリティ・テスト中に確認したクライアント側の効率低下と、アプリケーションの特定のコンポーネントで発生している1つあるいは複数のスケーラビリティの問題を、関連付けることができます。
スケーラビリティ・テストを効率よく実行するため、テスト・ツールの実行に必要となる適切なハードウェアを入手して、設定します。
何千という同時ユーザーを使用してWebアプリケーションに負荷を生成する際には、次の項目を考慮します。
負荷分散機能: 複数マシンで生成され、中央で制御される負荷に対して、負荷テスト・ツールは対処できるか。
オペレーティング・システム: どのオペレーティング・システムで負荷テスト・マスターと負荷生成エージェントを実行するか。
プロセッサ: どのCPUのタイプがマスターと仮想ユーザー・エージェントに必要か。
メモリー: マスターと仮想ユーザー・エージェントに必要なメモリー容量はどれくらいか。
スケーラビリティ・テストのための適切なハードウェアを確実に用意するため、負荷テスト・マスターとエージェント・マシンに必要なハードウェア要件を、負荷テスト・ツールのベンダーに提供してもらいます。
Windows NT 4.0/2000/2003のほうがスケーラブルで、オペレーティング・システムも安定しているので、Windows 98/XPよりも負荷テスト仮想ユーザーの実行に適しています。
負荷テスト（同時ユーザーを実行する負荷マスターや負荷エージェント）を実行中のワークステーションのCPU使用率が70〜80%より高い場合、または、メモリー消費量が85%を超えている場合、そのワークステーションで実行しているプロセスは、オペレーティング・システムのリソース競合が生じ、そのテストのパフォーマンス結果が歪められることになります。
可能であれば、別のマシンで負荷マスターを起動してください。一般的に、マスターとして動作するマシンには、ハイ・パフォーマンスCPUが必要です。仮想ユーザーは1つ以上のマシンで実行できます。これらのマシンには、多数の仮想ユーザーを実行するのに十分なメモリーが必要です。
マシンで実行可能な仮想ユーザーの数を決定するには、各仮想ユーザーが消費するメモリー量に基づいて推定できます。仮想ユーザーがプロセス内のスレッドとして実行されている場合、平均で300〜500KBのメモリーを消費します。仮想ユーザーが別々のプロセスとして実行されている場合は、平均で1,024〜2,048KBのメモリーを消費します。
ハードウェアの構成のマニュアルは、通常、各テスト・ベンダーから入手できます。このマニュアルでは、特定の負荷テスト設定用のハードウェア要件について説明しています。
負荷テストに積極的に参加するグループは、次のとおりです。
開発エンジニアとアーキテクチャのグループ: アーキテクチャの検証テストとWebアプリケーションのベンチマーク基準を設計、実行します。品質管理（QA）グループと協力して、負荷がかかった状態でも最適に実行できるようアプリケーションと運用アーキテクチャを適切に調整します。
大規模なソフトウェア部門では、スケーラブルなフレームワークを構築し、保守する責任を課された専門のパフォーマンス・アーキテクチャ・グループが存在することもあります。
品質管理（QA）部門: 開発テストを設計、実行し、アプリケーションの適切な動作と許容可能なパフォーマンスを検証します。
統合と受け入れ部門: アプリケーションの受け入れと運用の前に、統合テストを設計、実行して、すべての層とハードウェアがともに正しく動作していることを確認します。ほとんどの組織では、品質管理グループにもこの責任が課されます。
監視と操作のグループ: 監視テストを設計し、実行して、運用アプリケーションが毎日24時間運用可能であること、通常の使用で負荷がかかったり長期間稼働したりしてもパフォーマンスが低下しないことを確認します。
スケーラビリティ・テストを実行する部署は、些細なミスで誤った結果や潜在的なエラーが発生しないように注意します。次のようなことを行わないように留意することが必要です。
テスト実行中に変更されたアプリケーションでの負荷テストの実行。
機能テストが行われていないために、基本的な機能が処理できないアプリケーションでの負荷テストの実行。
アプリケーションの一部分のみに対して負荷テストの実行とその結果からのアプリケーション全体の結果の推測。
少数の同時ユーザーでの負荷テストの実行とその結果からの多数の同時ユーザーの結果の推測。
Webアプリケーションのスケーラビリティ・テストの一般的なプロセスは、次のとおりです。
アプリケーションのライフ・サイクル全体を通してスケーラビリティ・テストを実行するため、繰り返しの可能なプロセスを定義します。
スケーラビリティの条件を決定します。
負荷テストに使用するソフトウェア・ツールを決定します。
スケーラビリティ・テストの実行に必要なハードウェアと環境を決定し、構成します。
スケーラビリティ・テストを計画します。
テスト・シナリオを計画します。
スクリプトを作成し、検証します。
負荷テストのシナリオを作成し、検証します。
テストを実行します。
定義した条件に対する結果を評価します。
必要なレポートを生成します。
前述の手順については、後述の項で詳細に説明します。
負荷テストの要件が決定した後、テストの計画者はプロセスを定義します。プロセスの定義において、テストの計画者は次の点を考慮します。
必要なアプリケーション: どのアプリケーションに対して負荷テストを実行するか。
スケジュール: テストを実行するタイミングはいつにするか。実行に必要な日数、時間、設定可能な構造、テストの目標はどうするか。
担当者: 分析、計画、テストの開発、テストの実行、評価の担当者を誰にするか。誰に（ビジネス・アナリスト、ネットワーク・スペシャリスト、品質管理エンジニア、開発者など）テストに協力してもらうか。サード・パーティの担当者（ツール・ベンダー、インターネット・サービス・プロバイダ、テスト機関）は必要か。
場所: テストを実行する場所はどうするか。テストを内部で行うか、または、インターネット・サービス・プロバイダやテスト機関などの外部機関に委託するか。
テスト環境: 負荷テストを実行するソフトウェア/ハードウェア環境をどうするか。テスト環境を指定する場合には、次の点に注意します。
アプリケーションの安定性: 負荷テストの実行中に、アプリケーションが変更されないようにします。アプリケーションの負荷テストを実行している最中に、アプリケーション全体またはその一部を変更してしまうことが頻繁にあります。
運用環境: 負荷テストの実行時にアプリケーションが稼働する環境は、できるだけ実際の運用環境と似たものになるようにします。たとえば、大きい負荷に耐えられるだけの能力を備えたHTTPSサーバーで負荷テストを実行する必要がある場合、開発グループで使用しているサーバーより小さいサーバーで実行しないようにしてください。
受け入れ環境: 製品出荷前の受け入れテストでは、負荷テストを実行する環境が、実際の（仕様書で定義されている）運用環境とまったく同じになるようにします。
ハードウェア割当て: 必要なハードウェア（ネットワーク、マスター負荷テスト用コンピュータ、エージェント・コンピュータなど）が割り当てられ、使用可能になっているか。テスト担当者は次のような情報に基づいて必要なハードウェアを決定します。
仮想ユーザーの数またはアプリケーション全体で必要なスループット（トランザクション数/秒）
各業務トランザクションの最大処理時間または許容可能処理時間
業務トランザクション間の最大遅延時間または許容可能遅延時間
負荷テストの計画をする前に、アプリケーションが受け入れ可能で、実際の運用の準備ができているかどうかを判断する条件を定義する必要があります。条件を定義する際には、次の項目を指定します。
シミュレートする負荷: エミュレートの必要な仮想ユーザーの数。これは、Webサーバー上の同時ユーザーの数を示します。
シミュレートする業務トランザクションの数: どのくらいの数の業務トランザクションを負荷テストでシミュレートするか。これは、要件計画時のアプリケーション分析で決まり、トランザクション数/秒（TPS）、トランザクション数/時間、または同時ユーザー・セッション数で指定します。
シミュレートする業務トランザクションのタイプ: シミュレートの必要な業務トランザクションは何か。たとえば、口座残高の読込み、会計トランザクションの作成、会計詳細のチェック、寄付金のチェックなどがあります。
各業務トランザクションの条件: 各業務トランザクションに対して次の項目を決定します。
様々な負荷状態での許容可能応答時間: 様々な負荷条件下で許容できる応答時間（たとえば、100仮想ユーザーで実行しているときの許容可能な応答時間、200仮想ユーザーの場合または最大限度数の仮想ユーザーで実行しているときの許容可能応答時間など）。
許容可能なエラー発生率: 負荷がかかったときのトランザクション全体の許容可能なエラー発生率および各業務トランザクションの許容可能なエラー発生率（たとえば、100仮想ユーザーまでは0%のエラー発生率で、200仮想ユーザーまでは5%とするなど）。
ユーザーのカテゴリ: 様々なトランザクションでシミュレートするユーザーのカテゴリ（初回ユーザーか、リピーターかなど）。初回ユーザーの場合、すべてのイメージをダウンロードするため、Webサーバーに対するオーバーヘッドが高くなります。いずれのユーザー・タイプに対しても、テストの設計および開発を行い、異なる条件における負荷テストの組合せが実行できます。
SSLとHTTP: SSLと簡単なHTTPの組合せ、SSLのみまたはHTTPのみのいずれがテストに必要であるかを決定します。
シミュレートするブラウザ: 負荷テストでシミュレートするブラウザを決定します（Internet ExplorerかNetscapeのいずれか、またはその両方など）。
ペーシング・モード: 負荷テストに使用する仮想ユーザーのペーシング。テストに、記録された思考遅延時間（スクリプト記録中に自然発生した休止時間に相当する時間をページ間の遅延とする）を使用するか、ページ間の遅延なしで最も負荷の大きい状態をテストするか、また、T3接続の熟練ユーザーからモデム使用の初心者ユーザーまでの、ある範囲のユーザー速度を表す遅延のランダム分布を使うかなどを決定します。
業務トランザクション実行間の遅延: 業務トランザクションのテスト間にどれだけの遅延時間を入れるかを決定します（該当する場合）。
イメージの有無: 仮想ユーザーの実行にイメージは含まれるかどうかを決定します。イメージはWebサーバーの負荷を増大させます。通常は、比較するためにイメージありとイメージなしの両方で負荷テストを実行します。
必要なトランザクション数/秒の全体的なスループット: 負荷テストに必要なトランザクション数/秒（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のグループA、仮想ユーザー数20のグループB、仮想ユーザー数60のグループCでテストする前に、グループAの仮想ユーザー数1、グループBの仮想ユーザー数1、グループCの仮想ユーザー数1で最初にテストを実行して、結果が予測どおりであることを確認します。
現実的なシナリオの作成: このプロセスは、各シナリオのテスト計画で定義されます。個々のシナリオの作成時に、テスト計画で定義される項目として、次の情報を指定します。
ユーザーのタイプ
ペーシング・モード
実行するナビゲーションやトランザクション
トランザクション実行間の遅延
タイプごとのユーザー数
イメージの有無
負荷の生成に使用するシステム
エラー・ログの設定
ブラウザ・エミュレーション
前述のような基本的な負荷テスト・シナリオの作成、検証が終わったら、多数の仮想ユーザーで負荷テスト・シナリオを実行することができ、有効なテスト結果を期待できます。
基本テスト実行によるスケーリングの確認: 最小数の仮想ユーザーでテストを実行して、システムが正しくスケールしていることを確認します。
個々の業務トランザクションの実行: 仮想ユーザー数を10で開始し、25〜50まで増やしながら、異なる業務トランザクションをそれぞれ実行します。
業務トランザクションの組合せの実行: 仮想ユーザー数を5で開始し、25まで増やしながら、異なる業務トランザクション・スクリプトを組み合せて実行します。
前述の2つのシナリオが問題なく実行できたら、次のステップとして、各ユーザー・グループ・タイプのすべての仮想ユーザーで完全な負荷テストを実行します。
現実的なシナリオの実行: 前述の手順で説明したように、現実的なシナリオをそれぞれ実行します。
シナリオの数を、必要な同時仮想ユーザー数に増やします。
システムのエラーを監視します。
現実のユーザーでのシナリオの再実行: 負荷テストの実行中に、実際のユーザーに標準的なブラウザからアクセスしてもらい、パフォーマンスについての次の監視結果を報告してもらいます。
実際のユーザーが経験した効率低下の回数
ブラウザに返されたすべてのエラー
各負荷テスト・シナリオに対してパフォーマンス・データを調査し、予期した条件に対する結果を検証します。調査するパフォーマンス・データは、次のとおりです。
異なる仮想ユーザー数での、ユーザー・グループに対する応答時間
様々な仮想ユーザー数での、システムのスループット
発生したすべてのエラー
グラフ実行の参照オプションを使用すると、パフォーマンスをリアルタイムで評価することができます。
問題発生時にエラーのあったHTMLを保存しておくと、開発グループがエラーをデバッグするときに役立ちます。
様々なレポートを生成して、パフォーマンスを文書化します。これらのレポートは、アプリケーションの受け入れと運用に必要となります。負荷テストで生成できるレポートのタイプには次のようなものがあります。
パフォーマンス vs. 時間
統計情報 vs. 時間
ユーザー VS. 時間
エラーvs.ユーザー
統計情報vs.ユーザー数
エラーvs.時間
発生した可能性のある問題を開発グループがデバッグ、修正するために、他のエラー・レポートが必要になることもあります。
「レポートの作成」タブ内のOracle Load Testingグラフでは、負荷テストで得られたパフォーマンス・データとエラー・データを、複数のフォーマットで参照できます。
開発サイクル全体を通した負荷テストは、スケーラブルで信頼性のあるWebアプリケーションを設計するプロセスにおいて、最も重要な部分です。現在、開発者と品質管理の専門家は、システム・アーキテクチャの検証、最高のパフォーマンスのためのアプリケーションの調整、ハードウェアのアップグレードによる影響の評価を行う手段として、負荷テスト・ツールに依存しています。したがって、アプリケーションの迅速な対応や、システムのハードウェアとソフトウェアの潜在的な変更について、基本的な決定のための基盤として信頼できる、負荷テスト結果を使用できるということは、重要なことです。このマニュアルで説明している方法論を、Oracle Load Testingのような正確な負荷テスト・ツールで使用すれば、Webアプリケーションのパフォーマンスを確認する体系的なアプローチを獲得したことになります。アプリケーションのライフサイクルのルーチン作業として負荷テストの利用を確立することで、アプリケーションの初めての運用時、またその後のバージョン・アップ時に、損害の大きい予期しないスケーラビリティの問題の発生を確実に回避できます。
