| Oracle® Fusion Middleware Oracle Access Manager管理者ガイド 11g リリース1（11.1.1） B62265-01 |
|
 戻る |
 次へ |
Oracle Access Managerのアクセス・テスターを使用することにより、ITの専門家や管理者は、登録されたOAMエージェントとOAM 11gサーバーの連携をシミュレートして、エージェント接続に関わる問題のトラブルシュートを容易にしたり、ポリシー定義をテストしたりすることができます。この章では、Oracle Access Managerのアクセス・テスターとその使用法の概要を示します。内容は次のとおりです。
この章に示すタスクを実行するには、以下の前提条件を満たす必要があります。
OAM管理コンソール、OAMランタイム・サーバー、および登録OAMエージェントが実行中であることを確認します。
第9章の説明に従い、1つまたは複数のリソースのアプリケーション・ドメインとポリシーを確認します。
アクセス・テスターは移植可能なスタンドアロンのJavaアプリケーションで、Oracle Access Manager 11gに同梱されています。アクセス・テスターは、個々のIT専門家や管理者とOAMサーバー間の機能的なインタフェースを提供します。
IT専門家はアクセス・テスターを使用して接続を検証し、物理的デプロイメントのトラブルシュートを行なうことができます。アプリケーション管理者は、アクセス・テスターを使用してポリシーを迅速に検証することができます。この章で言う「管理者」とは、アクセス・テスターを使用する人物を表します。
アクセス・テスターは、WebLogicドメイン内外の任意のコンピュータから使用できます。また、グラフィカル・ユーザー・インタフェース（この章ではコンソールと呼びます）とコマンドライン・インタフェースの両方を使用することができます。コマンドライン・モードを使用すれば、シングル・クライアントまたはマルチクライアント・モード環境のテスト・スクリプト実行を完全に自動化できます。
実際のエージェントのように見せることによって、アクセス・テスターはポリシー構成設計やトラブルシューティングを助け、場合によってはOAMサーバーの応答性に関するトラブルシューティングに使用することもできます。アクセス・テスターを使用する時は実際のエンド・ユーザーのように振る舞う必要がありますが、アクセス・テスターが実際にエンド・ユーザーと通信することはありません。
アクセス・テスターを使用するには、Oracle Access Manager 11gによって保護されるアプリケーションまたはリソースの認証ポリシーと認可ポリシーを理解し、管理する必要があります。
アクセス・テスターを使用すれば以下のことが可能です。
エミュレート用のOAMサーバーに送信するリクエストの構成。エミュレート用OAMサーバーは、実際のエージェントが本番環境のOAMサーバーに送る内容をエミュレートします。
リクエストをOAMサーバーに送信し、実際のエージェントが受信する応答と同じ応答を受信。アクセス・テスターはOAMアクセス・プロトコル（OAP）APIを使用し、OAMチャネルを介して、OAMサーバーの一部として実行中のOAMプロキシにリクエストを送信します。OAMサーバーはこのリクエストを処理してレスポンスを返します。
サーバー・レスポンスの処理と表示。
実際のエージェントによるレスポンスの取り扱いと同様に処理を続行。たとえば、WebGateがリソースは証明書認証スキームによって保護されていると判断した場合、WebGateはhttp SSL接続からエンド・ユーザーの証明書を取得しなければなりません。
証明書認証スキームの場合、アクセス・テスターにはエンド・ユーザーの資格証明として使われる証明書を参照させなければなりません。
先に挙げた機能を実行してエージェントをシミュレートすることに加えて、アクセス・テスターによって以下の操作を行なうことができます。
予定しているポリシー変更のパフォーマンス特性の確認
認証リクエストと認可リクエストの待機時間の追跡
OAMサーバーのストレス・テストを実施してユーザー負荷に関連するローパフォーマンス・ウォーターマークまたはハイパフォーマンス・ウォーターマークを確立し、バックエンド・ハードウェアのサイズを決定
継続的にパォーマンス・メトリックの確立と測定を行い、求められていた成果を検証
基本的な動作中、アクセス・テスターはサーバー・レスポンスに関して何の判定も行なわず、そのレスポンスの可否判定も行ないません（たとえばリソースXが保護されているかどうか、あるいはユーザーYがリソースXへのアクセスを認可されているかどうかなど）。アクセス・テスターを操作するときは、特定のレスポンスが適切なものかどうかを決定するポリシー構成に注意する必要があります。
アクセス・テスターは、複数の個別リクエストをグループ化してテスト・スクリプトにまとめ、それをOAMサーバーに送って処理することを可能にする拡張機能を備えています。このようなテスト実行の出力はアクセス・テスターで取得し、「確認済みの」応答を含む同様ドキュメントとの比較に使用することができます。このように、アクセス・テスターは、ポリシー構成の誤変更検出用の自動化テストに使用することができます。
詳細については、この章の以下の説明を参照してください。
OAMアーキテクチャにおける2つの主要なアクター・タイプは、ポリシー・サーバー（OAMサーバー）とOAMポリシー強制エージェント（WebGateまたはAccessGate）です。セキュリティ分野においてはエージェントがポリシー強制点（PEP）を表し、OAMサーバーがポリシー決定点（PDP）を表します。
エージェントはhttpベース・アプリケーションなどのリソースのセキュリティを確保するゲートキーパーの役割を果たし、そのリソースにアクセスしようとするユーザーとのすべての対話操作を管理します。これは、ポリシー・サーバー（OAMサーバー）に保持されているアクセス制御ポリシーに従って実現されます。
OAMサーバーの役割は、エージェントに対してポリシー・サービス、アイデンティティ・サービス、およびセッション・サービスを提供してアプリケーション・リソースに対する適切なセキュリティを確保し、ユーザーの認証と認可を行なって、ユーザーセッションを管理することです。
この中核的なOAM製品アーキテクチャは、エージェントとOAMサーバー間の相互動作を支配する以下のようなやり取りを中心に展開します。相互運用性と重要な決定点を明らかにするために、ユーザーがリソースに関するリクエストを行なう際のOAMエージェントとOAMサーバー間の標準的な相互動作を図10-1に示します。
以下の概要では、OAMエージェントとOAMサーバー間で行なわれる処理を説明します。テストの際は管理者がエンド・ユーザーの役割を果たしながら、アクセス・テスターがエージェントをエミュレートしてOAMサーバーと通信を行ないます。
プロセス概要: OAMエージェントとOAMサーバーの相互運用性
サーバ接続の確立: 登録OAMエージェントがOAMサーバーに接続します。
ユーザーがリソースへのアクセスをリクエストします。
リソース保護の検証: エージェントがOAMサーバーにリクエストを送って、リソースが保護されているかどうかを判断します。
保護されている場合: OAMサーバーは必要な資格証明のタイプで応答します。
ユーザー資格証明: ユーザー・アイデンティティが確立されると、監査およびSSOのための追跡とアプリケーションへの伝達が可能になります。このため、エージェントはユーザーに対して資格証明を求めます。
ユーザー資格証明の認証: エージェントは、提供されたユーザー資格証明を検証のためOAMサーバーに送ります。
認証の成功: エージェントはリソース・リクエストをOAMサーバーに送ります。
リソースへのユーザー・アクセスを認可: エージェントはまず、認可ポリシーの検証のためにOAMサーバーへアクセス・リクエストを送ることによって、リソースへのユーザーのアクセスを認めるかどうかを判定しなければなりません。
エージェントは、ポリシー応答に基づいてアクセスを認可または拒否します。
アクセス・テスターは、OAMサーバーとの通信について、オープン接続モードと簡易接続モードだけに対応しています。
|
注意: アクセス・テスターは現在のところ、証明書モードのトランスポート・セキュリティ用に構成されたOAMサーバーとエージェントには対応していません。 |
アクセス・テスターは、テスターが構成ファイルとテスト・ケースに保存するすべてのパスワード型の値を暗号化します。すべてのネットワーク接続は、シングル接続プールのNetPoint Accessプロトコル（NAP）制限を継承します。
永続性: アクセス・テスターは、アクセス・テスターを次回起動するまで永続的に保存しておく必要のある複数のデータ構造を管理します。以下の種類の情報については、XMLファイルベースで保存が行なわれます。
アプリケーション再起動時のデータ入力をできるだけ少なくするための構成データ（OamTestConfiguration）
取得されたテスト・ケースで構成されるテスト・スクリプト（OamTestScriptCase）
テスト実行の実行メトリックを表わす統計データ（OamTestStats）
入力、ロギング、および分析用のXMLファイル: テスト・スクリプトを処理するためにアクセス・テスターを実行すると、以下のXMLファイルが作成されます。
構成スクリプト: config.xmlは、アクセス・テスター内でSave Configurationコマンドを使用して作られる出力ファイルです。このドキュメントの名前は、コマンド・ライン・モードで実行中のアクセス・テスターに正しい接続情報を提供するために入力スクリプト内で使われます。詳細については「保存された接続構成ファイルについて」を参照してください。
入力スクリプト: script.xmlは、1つまたは複数のテスト・ケースを取得後にアクセス・テスターによって作られるスクリプトです。詳細については「作成された入力テスト・スクリプトについて」を参照してください。
ターゲット出力スクリプト: アクセス・テスターをコマンド・ライン・モードで実行して入力スクリプトを指定すると、oamtest_target.xmlが作成されます。詳細については「テスト実行結果が格納されたターゲット出力ファイルについて」を参照してください。例: -Dscript.scriptfile="script.xml" -jar oamtest.jar
統計: oamtest_stats.xmlは出力スクリプトとともに作成されます。詳細については「統計ドキュメントについて」を参照してください。
実行ログ: lamtest_log.logは出力スクリプトとともに作成されます。詳細については「実行ログについて」を参照してください。
その他の詳細については「アクセス・テスター・モードと管理者の対話操作について」を参照してください。
コンソール・モードでは、アクセス・テスターはユーザーとの対話操作のために1つのウィンドウを表示します。すべてのアクセス・テスター操作はメイン・ウィンドウから行なうことができ、このウィンドウは、ユーザーがテスト・ケースの特定の詳細を送信したりレスポンスを表示したりすることのできるセントラル・ダッシュボードとしての役割を果たします。
あるいは、アクセス・テスターをコマンド・ライン・モードで使用し、生産性を最大限まで向上させてコストとリソースを最小限に抑える自動実行を実現するために、対話的な実行やバッチ実行が可能なテスト・スクリプトを作成することができます。
ランタイム: アクセス・テスターでは、メインjarであるoamtest.jarと同じディレクトリ内にnap-api.jarを置く必要があります。
アクセス・テスター実行のために選択したモードに関わらず、ユーザーとアクセス・テスターの主な対話操作には以下の操作が含まれます。
リクエストの発行と結果の表示
リソース保護、ポリシー構成、ユーザー認証、およびユーザー認可を検証するために、アクセス・テスターを使用してOAMサーバーへのリクエストを発行します。必要に応じ、テスト・ケースの結果はただちに分析することもできますし、長期的な分析のためにデータを保存しておくこともできます。
テスト・スクリプトの管理
テスト・スクリプトはテスト実行によって作成されたデータを取得することによって作成でき、これはスタンドアロン・ドキュメントとして使用できます。テスト・スクリプトは手動分析と自動分析の両方で実行できます。アクセス・テスターを使用すれば、事後分析を可能にするあらゆる統計データを収集して、それぞれの自動実行後に何らかの自動分析を行なうことができます
OAMサーバー接続の管理
サーバー接続情報を含むアプリケーション設定を管理することができます。
コンソール・モード操作とコマンドライン・モード操作の両方おける情報の流れを図10-2に示します。詳細については図の後の説明を参照してください。より高度な操作としては、テスト・スクリプトの作成と実行があります。
|
注意: |
コンソール・モード操作とコマンドライン・モード操作の両方における情報の処理フローをを表10-1に示します。
表10-1 コンソール・モードとコマンド・ライン・モードを使用したユーザー操作
| コンソール・モード | コマンドライン・モード |
|---|---|
|
ユーザーはコマンド・ラインからアクセス・テスターを開始します。 |
コマンドライン・モードでは、ユーザーまたはシェル・スクリプトがアクセス・テスターを開始します。 |
|
ユーザーが前に保存された構成ファイルを開いてアプリケーション・フィールドへの入力を行い、接続フィールドを含めてデータ入力をできるだけ少なくします。あるいは、コンソールを使用して手動でデータを入力することもできます。 |
アクセス・テスターは、入力スクリプトに基づいてテスト・ケースの処理を開始します。 |
|
ユーザーが「接続」ボタンをクリックしてOAMサーバーとの接続を開きます。 |
入力スクリプトの詳細に基づいてアクセス・テスターがOAMサーバーとの接続を開きます。 |
|
リソース保護: ユーザーが、リソース保護の検証、ユーザー資格証明の認証、およびユーザー・アクセスの認可のためのステップを順番に実行します。 |
リソース保護: 入力スクリプトに基づいてアクセス・テスターがテスト・ケースの処理を開始します。 |
|
アクセス・テスターはテスト完了時に以下のものを作成します。
|
アクセス・テスターはスクリプト完了時に以下のものを作成します。
|
|
必要に応じてユーザーがステップを繰り返して検証を終了させます。 |
必要に応じてユーザーがステップを繰り返して検証を終了させます。 |
以下ではアクセステスターの使用に伴うタスクの概要と、詳細が記載されたこの章のトピックを示します。
タスクの概要: OAM 11gの接続とポリシーのテストには以下のタスクが含まれます。
以下のトピックを確認します。
「アクセス・テスター・コンソールによる接続性とポリシーのテスト」の説明に従ってアクセス・テスター・コンソールを使用し、テストを実行してデータを取り込みます。
「テスト・ケースおよびスクリプトの作成と管理」へ進みます。
アクセス・テスターは、WebLogicドメイン内外の任意のコンピュータから使用できる2つのjarファイルで構成されています。この項ではアクセス・テスターのインストール方法を説明します。インストールするには、テストを実行するコンピュータにアクセス・テスターのjarファイルをコピーする必要があります。テスト入力用に選択したモードがコンソール・モードかコマンドライン・モードかに関わらず、アクセス・テスターはコマンド・モードから開始しなければなりません。この項は以下のトピックに分割されています。
このトピックでは、どのコンピュータでも使えるようにアクセス・テスターをインストールする方法を説明します。インストール終後は、いつでもアクセス・テスターを使用することができます。特別なセットアップは必要ありません。
アクセス・テスターのインストール方法
テスターを実行するコンピュータにJDK/JRE 6が含まれていることを確認します。たとえば、以下のようにJavaをテストすることができます。
java -version
上記のコマンドは次に示す情報を返します。
java version "1.6.0_18" Java(TM) SE Runtime Environment (build 1.6.0_18-b07) Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode)
OAMサーバーをホストしているコンピュータ上で、アクセス・テスターのJarファイルを探してコピーします。例:
Oracle_HOME/oam/server/tester/oamtest.jar Oracle_HOME/oam/server/tester/nap-api.jar
アクセス・テスタを実行しようとするコンピュータ上の同じディレクトリ内に、jarファイルのコピーを保存します。
使用する環境と要件に応じて、以下の手順に従ってください。
コンソール・モードで使用するためのシステム・プロパティなしでアクセス・テスターを開始するの手順に従えば、手動でリクエストを行なうことができます。
テスト・スクリプトの実行の手順に従えば、「確認済み（Known Good）」のポリシー構成に従って作成され、「確認済み」としてマークされたテスト・スクリプトを使用することができます。
アクセス・テスターでは、プレゼンテーションに使用したりテストの特定側面に使用したりすることのできるいくつかの構成オプションを選択することができます。これらのオプションは、サポートされているすべてのシステム・プロパティを示した表10-2に示すように、起動時にJavaの-Dメカニズムを使用して指定します。
表10-2 アクセス・テスターでサポートされているシステム・プロパティ
| プロパティ | アクセス・テスター・モード | 説明とコマンド構文 |
|---|---|---|
|
log.traceconnfile |
コンソール・モードとコマンドライン・モード |
指定ファイル名への接続詳細を記録します。 -Dlog.traceconnfile="<file-name>" |
|
display.fontname |
コンソール・モード |
指定フォントでアクセス・テスターを開始します。これは、表示解像度の違の補正に有効です。 - Ddisplay.fontname ="<font-name>" |
|
display.fontsize |
コンソール・モード |
指定フォント・サイズでアクセス・テスターを開始します。これは、表示解像度の違いの補正に有効です。 - Ddisplay.fontsize ="<font-size>" |
|
display.usesystem |
コンソール・モード |
デフォルトのフォント名とフォント・サイズ（ダイアログ・フォント、サイズ10）でアクセス・テスターを開始します。 - Ddisplay.usesystem |
|
script.scriptfile |
コマンドライン・モード |
コマンドライン・モードでスクリプト<file-name>を実行します。 -Dscript.scriptfile="<file-name>" |
|
control.configfile |
コマンドライン・モード |
スクリプトの「configfile」属性を上書きします。この属性には、接続情報を含む構成XMLファイルへの絶対パスが格納されます。アクセス・テスターはこの構成ファイルを使用して、「接続」要素によって示されたポリシー・サーバーへの接続を確立します。 -Dcontrol.config="<file-name>" |
|
control.testname |
コマンドライン・モード |
「制御」要素の「testname」属性を上書きします。この属性には、出力スクリプト・ファイル、統計ファイル、およびログ・ファイルの命名に使用するテスト・シリーズの名前を表わす文字列が格納されます。出力ログ・ファイルは<testname>_<testnumber>で始まります。 -Dcontrol.testname="<String>" |
|
control.testnumber |
コマンドライン・モード |
出力スクリプト・ファイル、統計ファイル、およびログ・ファイルの命名に使用する制御番号を指定します。出力ログ・ファイルは<testname>_<testnumber>で始まります。 -Dcontrol.testnumber="<String>". 自動生成される文字列は現在のローカル時刻に基づく7桁の数値ですが（分数を示す2文字+秒数を示す2文字＋1/100秒を示す3文字）、ファイル名に使用できるものであれば任意の文字列を使用して制御番号を表わすことができます。 |
|
control.ignorecontent |
コマンドライン・モード |
スクリプトの「制御」要素の「ignorecontet」属性を上書きします。この要素は、アクセス・テスターがオリジナルのテスト・ケースと現在の結果における「コンテンツ」の違いを無視すべきであることを示します。 -Dcontrol.testname="true|false" |
|
control.loopback |
コマンドライン・モード |
確認済みのスクリプトを基準にアクセス・テスターの内部的な性能低下をテストするために、アクセス・テスターをループバック・モードで実行します。アクセス・テスターのユニット・テストに使用します。 -Dcontrol.loopback="true" |
グラフィカル・ユーザー・インタフェースを通じて手動でリクエストを行なって（結果を取り込み）リアルタイム応答を表示するには、コンソール・モードでテスターを開始します。コンソール・モードでもいくつかのシステム・プロパティを使用できますが、この手順ではすべて省略します。
jarファイルはデフォルトの開始クラスを定義します。クラス名を指定する必要はありません。oamtest.jarと同じディレクトリ内にnap-api.jarが存在することを確認してください。
システム・プロパティを使わずにコンソール・モードでシステム・テスターを開始する方法
アクセス・テスターのjarファイルが置かれたディレクトリで、次のコマンドを入力します。
java -jar oamtest.jar
詳細については以下のいずれかのトピックを参照してください。
この項は以下のトピックに分割されています。
テスト・スクリプトを実行したりアクセス・テスターの動作をカスタマイズしたりするには、コマンドライン・モードでテスターを開始し、Javaの-Dオプションを使ってシステム・プロパティを含めなければなりません。
コマンドライン・モードでアクセス・テスターを実行すると、アクセス・テスターは、テスト実行管理のためのシェル・スクリプトで使用できる完了コードを返します。コンソール・モードでアクセス・テスターを実行する時は、アクセス・テスターによって返されるコードに従う必要はありません。
特定のテスト・ケースを実行するためにアクセス・テスターをラップするシェル・スクリプトは、アクセス・テスターによって伝達される終了コードを認識し、これに従って動作することができなければなりません。コマンドライン・モードでは、アクセス・テスターはSystem.Exit (N)を使用して終了します。ここで、Nは以下のいずれかのコードとすることができます。
0は、不一致なしですべてのテスト・ケースが正常に終了したことを示します。これには、入力スクリプト内にテスト・ケースが定義されていない状況も含まれます。
3は、少なくとも1つの不一致ですべてのテスト・ケースが正常に終了したことを示します。
1は、エラーによってアクセス・テスターを実行できなかったこと、またはテスト・ケースを完了できなかったことを示します。これには、入力スクリプトが指定されていない、入力スクリプトを読み込めない、サーバー接続を確立できない、ターゲット・スクリプトを作成できないという状態が含まれます。
これらの終了コードは、アクセス・テスターを使って特定のテスト・ケースを実行するために作られたシェル・スクリプト（Bourneシェルの$?）によって取得することができます。これらの終了コードは、アクセス・テスターを使って特定のテスト・ケースを実行するために作られたシェル・スクリプト（Bourneシェルの$?）によって取得することができます。
以下の手順を使ってコマンドライン・モードでアクセス・テスターを開始し、Javaの-Dメカニズムを使用して任意の数の構成オプションを指定します。
システム・プロパティを指定してアクセス・テスターを開始する方法、またはコマンドライン・モードで開始する方法
アクセス・テスターのjarファイルが置かれたディレクトリで、使用環境に合った適切なシステム・プロパティを指定してコマンドを入力します。例:
java -Dscript.scriptfile="\tests\script.xml" -Dcontrol.ignorecontent="true" -jar oamtest.jar
開始後は、以下のいずれかのトピックを参照してください。
この項では、アクセス・テスター・コンソール、ナビゲーション、およびコントロールの概要を示します。
固定サイズのアクセス・テスター・コンソールを図10-3に示します。コンソール・モードでアクセス・テスターを開始した場合、ユーザーはこのウィンドウを通じてアプリケーションとの対話操作を行なうことができます。このウィンドウのサイズを変更することはできません。詳細については図の後の説明を参照してください。
メイン・ウィンドウの一番上にあるメニュー・バーにはメニュー名が表示されています。メニュー・バーの下にはツール・バーがあります。ツール・バー内にボタンで表示されているコマンドは、メニュー・コマンドとして選択することもできます。アクセス・テスター・コンソールは、表10-3に示すように4つのパネルに分割されています。
表10-3 アクセス・テスターのコンソール・パネル
| パネル名 | 説明 |
|---|---|
|
サーバー接続 |
OAMサーバー（1つのプライマリ・サーバーと1つのセカンダリ・サーバー）との接続を確立するために必要な情報を入力するためのフィールドと、「接続」ボタンがあります。 「アクセス・テスターとOAMサーバー間の接続の確立」も参照してください。 |
|
保護リソースのURI |
保護状態を検証する必要のあるリソースに関する情報が表示されます。リソース検証サーバー・リクエストを送信するには、「検証」ボタンを使用します。 「アクセス・テスター・コンソールからリソース保護を検証」も参照してください。 |
|
ユーザー・アイデンティティ |
資格証明を認証する必要のあるユーザーに関する情報が表示されます。「ユーザーの認証」サーバー・リクエストの送信には「認証」ボタンを使用します。 「アクセス・テスター・コンソールからユーザー認証をテスト」も参照してください。 |
|
ステータス・メッセージ |
ユーザーのリクエストに対してアプリケーションが表示するメッセージで構成された、スクロール可能なステータス・メッセージ・エリアが表示されます。ユーザーの認可サーバー・リクエストの送信には認可ボタンを使用します。 「リクエスト待機時間の監視」も参照してください。 |
テキスト・フィールドでは、右クリックによる「編集」メニューの表示、およびマウスとカーソルによるドラッグアンドドロップ操作が可能です。
OAMサーバーにテスト・リクエストを送信するために使用する4つのプライマリ・ボタンがあります。それぞれのボタンは、表10-4に示す指定アクションを開始するためのトリガとして働きます。
表10-4 アクセス・テスター・パネルのコマンド・ボタン
| パネル・ボタン | 説明 |
|---|---|
|
接続 |
接続情報を送信して接続を開始します。 |
|
検証 |
保護リソースのURIパネルに入力された情報を送信して、保護の検証を開始します。 |
|
認証 |
「ユーザー・アイデンティティ」パネルに入力された情報を送信して、認証の確認を開始します。 |
|
認可 |
「ユーザー・アイデンティティ」パネルに入力された情報を送信して、認可の確認を開始します。 |
アクセス・テスターのその他のボタンとその使用方法を表10-5に示します。ボタンの上にカーソルを合わせると、そのボタンに関するヒントが表示されます。
表10-5 その他のアクセス・テスター・ボタン
| コマンド・ボタン | 説明 |
|---|---|
 |
XMLファイル（デフォルトはconfig.xml）に保存された接続構成の詳細をロードします。 このボタンをクリックすると、コンソール内の情報をリフレッシュすることができます。 |
 |
接続構成の詳細をファイル（デフォルト名はconfig.xml）に保存します。このドキュメントの名前は、コマンド・ライン・モードで実行中のアクセス・テスターに正しい接続情報を提供するために、入力スクリプトに追加できます。 コンソールの一番下にある「保存」コマンド・ボタンは、「ステータス・メッセージ」パネルの内容をログ・ファイルに保存します。 |
 |
アイコンを含むパネル上のフィールドをクリアします。ツール・バーのボタンを使用すると、接続がすでに確立されている場合は接続フィールドを除くすべてのフィールドがクリアされます。 |
 |
最後に指定されたリクエストを取得し、これに対してOAMサーバーから受信したレスポンスとともに取得キューに入れます。リクエストとレスポンスを組み合わせてテスト・ケースが作成されます。 コンソールの一番下にある取得キューのステータスが更新されて、キュー内のテスト・ケースの数が反映されます。 取得キューの内容は保存することができ、「テスト」メニューのスクリプト作成コマンドまたはコマンド・ボタンを使用して、複数のテスト・ケースを含むテスト・スクリプトを作成することができます。 |
 |
現在取得キューに置かれているあらゆるテスト・ケースを含むテスト・スクリプトを作成して、キューをクリアするかどうかの確認を行います。キューは、すべてのテスト・ケースが取得されてテスト・スクリプトに保存されるまでクリアしないでください。 |
 |
現在のOAMサーバーに対してテスト・スクリプトを実行します。「ステータス」メッセージ・ウィンドウには、スクリプトが各テスト・ケースへ進むのに合わせて実行ステータスが表示されます。 |
 |
コピーされたURIを解析後にクリップボードからインポートし、URIパネルのフィールドに表示します。 |
 |
パスワードをクリア・テキストで表示するダイアログを表示します。 |
アクセス・テスターには表10-6に示すメニューがあります。すべてのメニュー項目にはニーモニックがあり、これはALTキーを押すことによって開くことができます（Wondowsシステム上）。また、各メニュー・コマンドに対して定義されたCTRLキーと<文字キー>の組み合わせを使用して、コマンド・アクセラレータ（キーボード・ショートカット）を利用することもできます。
表10-6 アクセス・テスターのメニュー
| メニュー名 | メニュー・コマンド |
|---|---|
|
ファイル |
注意: データ入力量をできるだけ少なくするために、「構成の保存」メニューと構成を開くメニュー（およびツールバーのコマンド・ボタン）を使用して、特定の接続、URI、およびアイデンティティ情報をファイルに保存したりファイルから読み出したりすることができます。したがって、複数構成の管理が極めて容易になります。また、コマンドライン・モードでアクセス・テスターを使用してテスト・スクリプトを実行する時は、構成ファイルをアクセス・テスターへの入力として使用することができます。 |
|
編集 |
フィールドに対して使用できる標準編集コマンドを提供します。
|
|
テスト |
注意: これらの機能を使用し、最後のリクエストと応答を取得してテスト・ケースを作成することができます。これらのテスト・ケースは、テスト・スクリプトに保存して後で実行することができます。 |
|
ヘルプ |
この項では、アクセス・テスターをOAMサーバーとともにコンソール・モードで使用して、クイック・スポット・チェックを行なう方法を説明します。
エージェントとOAMサーバー間の接続のスポット・チェックやトラブルシューティングを行えば、エージェントがOAMサーバーと通信できるかどうかの評価の助けとすることができます。これは、アップグレードや製品移行を行なった後は特に有効です。また、エージェントやOAMサーバーによるリソース保護のスポット・チェックやトラブルシューティングを行なえば、アプリケーション・ライフサイクルの間にポリシー構成のエンドツーエンド・テストを作成する助けとすることができます。
以下に、実行するタスクおよびシーケンスの概要と、各タスクの詳細について参照すべき箇所を示します。
|
注意: ユーザーは、それぞれのリクエストとレスポンスのペアを取得してテスト・ケースを作成し、そのテスト・ケースをスクリプト・ファイルに保存して後で実行することができます。詳細については「テスト・ケースおよびスクリプトの作成と管理」を参照してください。 |
タスクの概要: アクセス・テスター・コンソールからスポット・チェックを行なう。
「アクセス・テスターのインストールと起動」の説明に従ってアクセス・テスターを起動します。
「アクセス・テスターとOAMサーバー間の接続の確立」の説明に従って、「サーバー接続」パネルに関連詳細事項を入力します。
「アクセス・テスター・コンソールからリソース保護を検証」の説明に従って、保護リソースのURIペインに詳細を入力またはインポートします。
「アクセス・テスター・コンソールからユーザー認証をテスト」の説明に従って、「ユーザー・アイデンティティ」パネルに関連詳細事項を入力します。
認証が正常に終了したら、「アクセス・テスター・コンソールからユーザー認可をテスト」の説明に従って「ユーザー・アイデンティティ」パネルの認可をクリックします。
「リクエスト待機時間の監視」の説明に従って、リクエストの待機時間をチェックします。
OAMサーバーにリクエストを送信するには、アクセス・テスターとサーバ間の通信を確立しなければなりません。この項では、その接続を確立する方法を説明します。
エミュレートしようとしているOAMサーバーとエージェントに関する必要情報をアクセス・テスターの「接続」パネルに入力して、「接続」ボタンをクリックします。テスターが接続を開始して、「ステータス・メッセージ」パネルにステータスを表示します。接続が確立されると、その接続がその後のすべての操作に使われます。
|
注意: 接続が確立されると、アクセス・テスター・コンソールを再起動するまでその接続を変更することはできません。 |
「サーバー接続」パネルとコントロールを図10-4に示します。
接続の確立に必要な情報を表10-7に示します。実際の値についてはOAM管理コンソールの「システム構成」タブを参照してください。
表10-7 接続パネルの情報
| フィールド | 説明 |
|---|---|
|
IPアドレス |
このテスト・セットにおけるプライマリおよびセカンダリOAMプロキシのIPアドレスをリスニングします。 注意: 入力するのはプライムOAMプロキシの値だけにすることをお薦めします。セカンダリOAMプロキシが必要なのは、プライマリOAMサーバーとセカンダリOAMサーバー間のフェイルオーバーをテストする場合に限られます。ただし、OAP APIがプライマリOAMサーバーとセカンダリOAMサーバー間のロード・バランシングをサポートしている場合は、セカンダリ・サーバーをより実用的に利用することができます。 |
|
ポート |
プライマリおよびセカンダリOAMサーバーのポート番号を入力します。 |
|
最大接続数 |
アクセス・テスターが使用する物理的接続（TCP）ソケットの最大数です。アクセス・テスターはシングル・スレッド・エージェントをエミュレートします。 注意: デフォルト値の1を使用することをお薦めします。 |
|
最小接続数 |
アクセス・テスターが使用する物理的接続（TCP）ソケットの最小数です。アクセス・テスターはシングル・スレッド・エージェントをエミュレートします。 注意: デフォルト値の1を使用することをお薦めします。 |
|
タイムアウト |
接続の確立、あるいはOAMサーバーからのレスポンス受信のためにアクセス・テスターが待機する時間（ミリ秒）です。 注意: デフォルト値の使用をお薦めします。 |
|
モード |
エミュレートするエージェントに指定された通信セキュリティのレベル。 |
|
エージェントID |
テスターがシミュレートするOAMエージェントのアイデンティティを入力します。 |
|
エージェント・パスワード |
テスターがシミュレートするOAMエージェントのパスワードが設定されている場合は、そのパスワードを入力します。 |
 |
「接続」ボタンの横の緑色のチェック・マークは、「はい」のレスポンスを示します。この場合は接続が確立されています。「ステータス・メッセージ」パネルにも接続に関する「はい」のレスポンスが表示されます。 |
 |
「接続」ボタンの横の赤の円は、「いいえ」のレスポンスを示します。この場合、接続は存在しません。「ステータス・メッセージ」パネルにも接続に関する「いいえ」のレスポンスが表示されます。 |
情報を入力して接続を確立した後は、詳細を構成ファイルに保存して後で再利用することができます。
以下の手順を使用してOAMサーバーの接続の詳細を送信します。
前提条件
アクセス・テスターとOAMサーバー間の接続のテスト方法
「サーバー接続」パネル（表10-7）で、以下の情報を入力します。
プライマリおよびセカンダリOAMプロキシの詳細
タイムアウト時間
通信暗号化モード
エージェントの詳細
「接続」ボタンをクリックします。
「接続」ボタンの横に、接続の確立を示す緑色のチェック・マークが表示されていることを確認します。
「ステータス・メッセージ」パネルに「はい」のレスポンスが表示されていることを確認します。
まだ接続を確立できない場合は、トレース接続コマンド・モードを使用してアクセス・テスター・コンソールを起動し、接続ログ内の詳細を確認します。また、OAMサーバーのOAM管理者にポリシー・サーバー・ログの確認を依頼します。
良好な接続詳細の保存: 「テスト」メニューのスクリプト作成コマンドをクリックして、この構成ファイルの名前を入力します（またはデフォルト名のconfig.xmlを使用）。
ユーザーがリソースにアクセスできるようにするには、まず、リソースが保護されていることをエージェントが確認する必要があります。以下の説明に従い、ユーザーがアクセス・テスターを使用してエージェントの役を演じ、指定されたURIが保護されているかどうかをOAMサーバーに検証させて応答をアクセス・テスターに伝達させます。
検証しようとするリソースに関する必要情報をアクセス・テスターの保護リソースのURIパネルに入力し、「検証」ボタンをクリックします。
データ入力量をできるだけ少なくするために、URIはインポートできます。ブラウザからURIをコピーしてURIをインポートコマンド・ボタンをクリックしてください。テスターがクリップボードに保存されたURIを解析して、アクセス・テスターのURIフィールドに入力します。
リソースが保護されていることを検証するためにURI詳細を入力するパネルを図10-5に示します。これらのURIフィールドを組み合わせるとRFC表記に従った書式になります。例: http://oam_server1:7777/index.html
この評価を行なうために必要な情報を表10-8に示します。
表10-8 保護リソースURIパネルのフィールドとコントロール
| フィールドまたはコントロール | 説明 |
|---|---|
|
スキーム |
リソースに指定された通信セキュリティに応じてhttpまたはhttpsを入力します。 注意: アクセス・テスターはhttpまたはhttpsリソースだけをサポートします。アクセス・テスターを使用して、http以外のカスタム・リソースを保護するポリシーをテストすることはできません。 |
|
ホスト |
リソースの有効なホスト名を入力します。 注意: アクセス・テスター内に指定された<host:port>の組み合わせは、OAM管理コンソールにおけるホスト識別子の組み合わせと一致していなければなりません。このホスト識別子を確認できない場合、OAMはリソース保護を検証できません。 |
|
ポート |
URIに対する有効ポートを入力します。 注意: アクセス・テスター内に指定された<host:port>の組み合わせは、OAM管理サーバー内に定義されたホスト識別子の組み合わせと一致していなければなりません。このホスト識別子を確認できない場合、OAMはリソース保護を検証できません。 |
|
リソース |
URIのリソース部分を入力します（たとえば/index.htm）。このリソースは、OAM管理コンソールで認証および認可ポリシーに対して定義されたリソースと一致していなければなりません。 注意: 保護されている場合、ここに入力したリソース識別子は、OAM管理コンソールで認可ポリシーに指定された識別子と一致していなければなりません。 |
|
クリップボードに保存されたURIを解析してインポートするには、このボタンをクリックします。 |
|
操作 |
アクセス・テスターに示されたリストから、URIの操作部分を選択します。ただし、OAMサーバーはアクションの違いを認識しません。したがって、ここは「取得 」のままにしておいても問題ありません。 |
|
認証スキームを取得 |
保護リソースのセキュリティ保証に使用する認証スキームについて、その詳細を返すようOAMサーバーに要求するには、このチェック・ボックスを選択します。URIが保護されている場合、この情報は「ステータス・メッセージ」パネルに表示されます。 |
|
検証 |
「検証」ボタンをクリックしてOAMサーバーにリクエストを送信します。レスポンスを受信すると、アクセス・テスターはそのレスポンスを「ステータス・メッセージ」パネルに表示します。 |
|
「検証」ボタンの横の緑色のチェック・マークは、「はい」のレスポンスを示します。この場合、リソースは保護されています。「ステータス・メッセージ」パネルにはリソースのリダイレクトURLが表示されるほか、資格証明が必要とされることも表示されます。 注意: 認証スキームを取得ボックスを選択した場合は、「ステータス・メッセージ」パネルにもこのリソースを保護する認証スキームの名前とレベルが表示されます。 |
|
「検証」ボタンの横に表示される赤の円は、リソースが保護されていないことを示します。「ステータス・メッセージ」パネルにも「いいえ」のレスポンスが表示されます。 |
ユーザーは、それぞれのリクエストとレスポンスのペアを取得して複数のテスト・ケースを作成し、後で実行できるようにそのテスト・ケースをスクリプト・ファイルに保存します。
以下の手順を使用してリソース情報をOAMサーバーに送信し、「ステータス・メッセージ」パネルでレスポンスを検証します。
前提条件
リソースが保護されていることを確認する方法
アクセス・テスターの保護リソースのURIパネルで、自身のリソース情報を入力またはインポートします（表10-8）。
「検証」ボタンをクリックしてリクエストを送信します。
リソースの保護方法や保護レベルといったリソース関連のデータを含め、アクセス・テスターの出力を確認します。
「検証」ボタンの横に、リソースが保護されていることを示す緑色のチェック・マークが表示されていることを確認します。
「ステータス・メッセージ」パネルで、リダイレクトURL、認証スキーム、および資格証明が必要とされることを確認します。
「テスト・ケースおよびスクリプトの作成と管理」の説明に従ってリクエストと応答を取得し、後で使用できるテスト・ケースを作成します。
以下のいずれかの方法を使用し、データ入力とサーバーの処理をできるだけ少なくするためにURIを保存しておきます。
「アクセス・テスター・コンソールからユーザー認証をテスト」に進んでください。
この項の内容は次のとおりです。
ユーザーがリソースにアクセスできるようにするには、エージェントが、OAMサーバー上に定められた認証ポリシーに基づいてユーザーのアイデンティティを検証する必要があります。アクセス・テスターを使用すれば、ユーザーがエージェントの役を演じて、保護リソースに対する特定のユーザーIDをOAMサーバーに認証させることができます。このポリシー評価の際には、関係するすべての認証レスポンスが考慮されます。
テスト評価に必要な情報を入力するアクセス・テスター・パネルを図10-6 に示します。
入力が必要な情報を表10-9に示します。
表10-9 アクセス・テスターの「ユーザー・アイデンティティ」パネルのフィールドとコントロール
| フィールドまたはコントロール | 説明 |
|---|---|
|
IPアドレス |
ユーザー資格証明の検証を行なうユーザーのIPアドレスを入力します。OAMサーバーと通信するすべてのエージェントがエンド・ユーザーのIPアドレスを送信します。 デフォルト: 入力されるIPアドレスは、アクセス・テスターを実行するコンピュータに属するものです。 実際のユーザーのIPアドレスを必要とするポリシーをテストするには、デフォルトのIPアドレスを実際のIPアドレスに置き換えてください。 |
|
ユーザー名 |
資格証明の検証対象となる個人のユーザーIDを入力します。 注意: 資格証明を必要とする認証スキームによってリソースが保護されている場合、アクセス・テスターはそのユーザー名フィールドとパスワード・フィールドを有効（または無効）にします。それ以外の場合、これらのフィールドは無効になります。 |
|
パスワード |
資格証明の検証対象となる個人のパスワードを入力します。 |
|
? |
ポップアップ・ウィンドウ内にクリア・テキストでパスワードを表示するには、このボタンをクリックします。 |
|
ユーザー資格証明ストア |
資格証明を認証する必要のあるユーザーのX.509証明書を格納するファイル（PEMフォーマット）です。 X.509認証スキームによってURIが保護されている場合、アクセス・テスターは、ユーザー名/パスワードではなく（またはユーザー名/パスワードに加えて）PEMフォーマットのX.509証明書を資格証明として使用します。認証スキームがX.509証明書を必要としない場合、このフィールドは無効になります。 注意: 証明書ベースの認証を機能させるには、CA証明書とSSLキーストア証明書を使用してOAMサーバーを正しく構成する必要があります。OAM 11gサーバーとWebGatecan間の通信のセキュリティ確保の詳細については、付録Eを参照してください。 |
|
... |
ユーザー証明書ストア・パスのファイル・システムを表示するには、このボタンをクリックします。 |
|
認証 |
OAMサーバーにリクエストを送信して「ステータス・メッセージ」パネルでレスポンスを探すには、「認証」ボタンをクリックします。 注意: 提供される資格証明のタイプ（ユーザー名/パスワードまたはX.509証明書）は、URIを保護している認証スキームの要件と一致していなければなりません。 |
|
認可 |
ユーザーの資格証明の検証後に認可ボタンをクリックすれば、リソースに対するリクエストをOAMサーバーに送信することができます。レスポンスについては「ステータス・メッセージ」パネルを確認してください。 |
|
「認証」ボタンの横に表示される緑色のチェック・マークは認証が成功したことを示します。「ステータス・メッセージ」パネルにも認証が成功したことを示す「はい」のレスポンスが表示されるほか、ユーザーDNとセッションIDも示されます。 認可ボタンの横に表示される緑色のチェック・マークは認可が成功したことを示します。「ステータス・メッセージ」パネルにも認可が成功したことを示す「はい」のレスポンスが表示され、アプリケーション・ドメインの詳細も示されます。 |
|
「認証」ボタンの横に表示される赤の円は認証が失敗したことを示します。「ステータス・メッセージ」パネルにも認証に失敗したことを示す「いいえ」のレスポンスが表示されます。 認可ボタンの横に表示される赤の円は認可が失敗したことを示します。「ステータス・メッセージ」パネルにも認可にしっぱししたことを示す「いいえ」のレスポンスが表示されます。 |
ユーザーは、それぞれのリクエストとレスポンスのペアを取得して複数のテスト・ケースを作成し、後で実行できるようにそのテスト・ケースをスクリプト・ファイルに保存します。
以下の手順を使用してエンド・ユーザーの資格証明をOAMサーバーに送信し、認証を検証します。このポリシー評価の際には、関係するすべての認証レスポンスが考慮されます。
前提条件
コンソールに保持されたURI情報でアクセス・テスター・コンソールからリソース保護を検証
ユーザー資格証明による認証のテスト方法
アクセス・テスターの「ユーザー・アイデンティティ」パネルで、認証対象のユーザーに関する情報を入力します（表10-9）。
「認証」ボタンをクリックしてリクエストを送信します。
「認証」ボタンの横に、ユーザーが認証されたことを示す緑色のチェック・マークが表示されていることを確認します。
認証できない場合: 正しいユーザーIDとパスワードを入力したことを確認し、再度認証を試みてください。また、第12章の説明に従い、終了させる必要のあるアクティブ・ユーザー・セッションの有無をOAM管理コンソールで確認してください。
「テスト・ケースおよびスクリプトの作成と管理」の説明に従ってリクエストと応答を取得し、後で使用できるテスト・ケースを作成します。
URIとユーザー・アイデンティティ情報を保持して、「アクセス・テスター・コンソールからユーザー認可をテスト」へ進んでください。
ユーザーがリソースにアクセスできるようにするには、エージェントが、OAMサーバー上に定められたポリシーに基づいてユーザーの権限を検証する必要があります。アクセス・テスターを使用してユーザーがエージェントとしての役割を演じ、認証されたユーザー・アイデンティティにリソースへのアクセスを認可できるかどうかをOAMサーバーに検証させることができます。
以下の手順を使用して、認証済みエンド・ユーザーのリソースへのアクセス認可を検証します。このポリシー評価の際には、関係するすべての認可上の制約とレスポンスが考慮されます。
前提条件
コンソールに保持されたすべての情報でアクセス・テスター・コンソールからユーザー認証をテスト
|
注意: アクセス・テスターから保護リソースのURIが確認されてユーザーのアイデンティティが認証されれば、それ以外の情報は必要ありません。認可ボタンをクリックしてリクエストを送信してください。ただし、リソースが別のものに変更された場合は改めてシーケンスを開始して検証を行い、次いで認証と認可を行なう必要があります。 |
ユーザー認可のテスト方法
アクセス・テスターの「ユーザー・アイデンティティ」パネルで、ユーザーが認証されていることを確認します（表10-9）。
アクセス・テスターの「ユーザー・アイデンティティ」パネルで、認可ボタンをクリックします。
認可ボタンの横に、ユーザーが認可されたことを示す緑色のチェック・マークが表示されていることを確認します。
認可できない場合: OAM管理コンソールを使用して認可ポリシーを確認します。
「ステータス・メッセージ」パネルで、テスト実行に関する詳細を確認します。
「テスト・ケースおよびスクリプトの作成と管理」の説明に従ってリクエストとレスポンスを取得し、後で使用できるテスト・ケースを作成します。
以下の項目へ進みます。
OAMサーバーのパフォーマンスを理解するには、OAMサーバーがエージェントから渡されるリクエストをどの程度の効率で処理しているかを知る必要があります。サーバーのメトリックを明らかにする方法は数多くありますが、エージェントの立場からサーバーのパフォーマンスを明らかにするのが有効な場合もあります。これは、アクセス・テスターを使用して以下の手順により行なうことができます。
前提条件
タスクの概要: リクエスト待機時間の監視には以下のタスクが含まれます。
以下に示す実行ログファイル内、およびテスト実行中に作成されるその他のファイル内の待機時間情報を確認例:
... [2/3/10 11:03 PM][info] Summary statistics [2/3/10 11:03 PM][info] Matched 4 of 4, avg latency 232ms vs 238ms [2/3/10 11:03 PM][info] Validate: matched 2 of 2, avg latency 570ms vs 578ms [2/3/10 11:03 PM][info] Authenticate: matched 1 of 1, avg latency 187ms vs 187ms [2/3/10 11:03 PM][info] Authorize: matched 1 of 1, avg latency 172ms vs 188ms ...
以下の項目へ進みます。
テスト管理とは、管理者やシステムによっていつでも実行することのできる再現可能なテストを作成することを言います。クイック・スポット・チェックは、直面している問題のトラブルシュートを行なう上で非常に有効かつ効果的です。しかし、サーバーとポリシーの構成を検証する上で、より高い予測可能性と再現性を備えた方法が必要になることも少なくありません。この方法には、製品リビジョン後の性能低下に関するOAMサーバー構成のテスト、あるいはポリシー作成中やQAサイクルにおけるOAMサーバー構成のテストを含めることができます。
これらのテストを有効なものとするには、複数のユースケースをグループとして実行できるようにする必要があります。テスト・スクリプトが設計されて誤りのないことが確認されてしまえば、OAMサーバーに対して再度テストを行なうことは、ポリシー構成の質の低下を明らかにする助けとなります。
この項では、テスト管理を行なうために必要な情報を以下に示すトピックの中で示します。
テスト・ケースは、アクセス・テスターを使用してOAMサーバーに送信したリクエストと、OAMサーバーから受信した応答で作成します。さまざまなデータ要素がある中で、テスト・ケースにはリクエスト待機時間と、新旧のテスト・ケースの分析と比較を可能にするその他のアイデンティティ確認情報が含まれます。
取得したテスト・ケースは、新たな入力なしで再実行して新旧の結果を比較することができます。古い結果が「確認済み（Known Good）」としてマークされている場合は、それらの結果と差がテスト・ケースを失敗させる要素となります。
テスト・ケースのワークフローを図10-7に示します。
タスクの概要: テスト・ケースの作成と管理
アクセス・テスター・コンソールからは、OAMサーバーに接続して手動で個々のテストを行なうことができます。リクエストは、リクエストを送信してOAMサーバーから応答を受信した後に取得キューに保存することができます。他のテスト・ケースを取得は、テスト・スクリプトを作成して取得キューをクリアする前に続けて行なうことができます。取得したキューを保存せずにアクセス・テスターを終了しようとすると、終了前にテスト・ケースをテスト・スクリプトに保存するかどうかの確認が行なわれます。キューは、すべてのテスト・ケースの取得が終了するまでクリアしないでおくことをお薦めします。
テスト・スクリプトの作成後は、アクセス・テスター・コンソールまたはコマンド・ラインからそのスクリプトを実行することができます。
それぞれのテスト・ケースは、アクセス・テスターからOAMサーバーにリクエストを送信して応答を受信した後に、取得キューに保存することができます。個々のテスト・ケースは、テスト・ケースのグループの実行を自動化するテスト・スクリプトを作成する前に必要なだけ取得することができます例として、個別に取得しなければならない3つのテスト・ケースの概要を以下に示します。
検証のリクエストと応答
認証のリクエストと応答
認可のリクエストと応答
取得オプションの場所を表10-10に示します。
表10-10 アクセス・テスターの取得リクエストオプション
| ロケーション | 説明 |
|---|---|
|
「テスト」メニュー 最後の"..."リクエストを取得 |
「テスト」メニューからこのコマンドを選択して、発行した最後のリクエストと受信した結果を取得キューに追加します（後でテスト・スクリプトに含めるため）。 |
|
ツール・バーからこのコマンド・ボタンを選択して、発行した最後のリクエストと受信した結果を取得キューに追加します（後でテスト・スクリプトに含めるため）。 |
取得したキューを保存せずにアクセス・テスターを終了しようとすると、終了前にテスト・ケースをテスト・スクリプトに保存するかどうかの確認が行なわれます。アクセス・テスターの取得キューは、すべてのテスト・ケースの取得が終了するまでクリアしないでください。
1つまたは複数のテスト・ケースを取得する方法
「アクセス・テスター・コンソールからの接続性とポリシーのテスト」の説明に従い、アクセス・テスターからリクエストを発行します。
応答を受信したら、ツール・バーの「最後の"..."リクエストを取得」コマンド・ボタンをクリックします（または「テスト」メニューから同じオプションを選択）。
「ステータス・メッセージ」パネルで取得を確認し、さらにコンソールの一番下に表示される取得キューのテスト・ケース数を確認します。
ステップ1、2、3を繰り返して、テスト・スクリプトに必要な各テスト・ケースをキュー内に取得します。
「入力テスト・スクリプトの作成」へ進みます。
テスト・スクリプトは、アクセス・テスター・コンソールを使用して取得された個々のテスト・ケースの集合です。個々のテスト・ケースをグループにまとめた場合は、テスト範囲を自動化して特定のアプリケーションまたはサイトに関するポリシー構成を検証することが可能になります。
アクセス・テスターへの入力として使用するテスト・スクリプトを作成して、複数のテスト・ケースを自動処理することができます。スクリプト作成オプションを使用すれば、XMLファイルのテスト・スクリプトを作成して取得キューをクリアすることができます。取得したキューを保存せずにアクセス・テスターを終了しようとすると、終了前にテスト・ケースをテスト・スクリプトに保存するかどうかの確認が行なわれます。
|
注意: 取得キューは、スクリプトに含めようとしているすべてのテスト・ケースを取得するまでクリアしないでください。 |
アクセス・テスターへの入力として使用するテスト・スクリプトを作成して、複数のテスト・ケースを自動処理することができます。これらのスクリプトは以下の規則に従わなければなりません。
オペレータまたはシステムによるリプレイが可能
異なるポリシー・サーバーを作動させるテスト・スクリプトの共有を可能にするために、スクリプトを変更することなく異なるポリシー・サーバーへのリプレイが可能
「確認済み（Known Good）」の結果に対するテスト実行結果の比較が可能
スクリプト作成コマンドの場所を以下に示します。
前提条件
取得したテスト・ケースを含むテスト・スクリプトの作成方法
「テスト・ケースの取得」の説明に従い、スクリプトに含めたいリクエストを実行して取得します。
ツール・バーのスクリプト作成コマンド・ボタンをクリックして（または「テスト」メニューから同じオプションを選択して）、取得したすべてのテスト・ケースを含めます。
新しいダイアログ・ボックスで新しいXMLスクリプト・ファイルの名前を選択または入力し、「保存」をクリックします。
既存ファイルに上書きする場合は「はい」をクリックします（または「いいえ」をクリックしてウィンドウを閉じ、新しいファイル名を入力）。
「警告の保存」ダイアログ・ボックスで「いいえ」をクリックして取得キューをそのまま維持し、スクリプトへのテスト・ケースの追加を継続します（または「はい」をクリックしてすべてのテスト・ケースのキューをクリア）。
アクセス・テスターを終了する前にテスト・スクリプトの場所を確認します。
次に示すようにスクリプトの作成者、作成時期、作成理由などの詳細を含め、テスト・スクリプトをパーソナライズします。
この項では、テスト・スクリプトのパーソナライズ方法とカスタマイズ方法を説明します。
スクリプトにタグを付けてテスト実行時に使用する情報を指定するには、テスト・スクリプトの制御ブロックを使用します。スクリプトの作成者、作成時期、および作成理由についての詳細を含めたい場合も考えられます。また、1つまたは複数の制御パラメータを使ってスクリプトをカスタマイズしたい場合もあるかもしれません。
アクセス・テスターでは、スクリプトを変更することなくスクリプトの処理を変更するコマンドライン「制御」パラメータを使用することができます（テスト名やテスト番号など）。これにより、「確認済み（Known Good）」の入力テスト・スクリプトを変更することなくテスト実行を構成することが可能です。制御要素とこれらのカスタマイズ方法を表10-12に示します。
表10-12 テスト・スクリプト制御パラメータ
| 制御パラメータ | 説明 |
|---|---|
|
i |
オリジナルのOAMサーバー応答と最新の応答を比較する際に、ユースケースの「コンテンツ」セクションの違いを無視します。デフォルトでは「コンテンツ」セクションを比較します。このパラメータは、コマンドライン・モードで実行するときはコマンドライン・プロパティで上書きすることができます。 デフォルト: false（「コンテンツ」セクションを比較） 値: trueまたはfalse コマンドライン・モードでは、Ignorecontent=trueを使用して入力スクリプトの「制御」セクションの指定値を上書きしてください。 |
|
testname="oamtest" |
前の項に示したように、「結果バンドル」のファイル名に加える接頭辞を指定します。 コマンドライン・モードでは、Testname=nameを使用して「制御」セクションの指定値を上書きしてください。 |
|
Configfile="config.xml" |
アクセス・テスターによって過去に作成された構成XMLファイルへの絶対パスを指定します。 コマンドライン・モードでは、このファイルは、サーバー接続を確立するための接続詳細の場所を特定するためにアクセス・テスターが使用します。 |
|
Numthreads 今後使用予定です。 |
複数のテスト・スクリプトのコピーを実行するために、アクセス・テスターによって開始されるスレッドの数を示します。これはOAMサーバーのストレス・テストに使用します。 デフォルト: 1 |
|
Numiterations 今後使用予定です。 |
アクセス・テスターが実行するテストの繰返し回数を示します。これはOAMサーバーの寿命テストに使用します。 デフォルト: 1 |
前提条件
テスト・スクリプトのカスタマイズ方法
アクセス・テスターで作成したテスト・スクリプトを探して開きます。
スクリプトをカスタマイズまたはパーソナライズするために必要な詳細を追加します。
ファイルを保存して「テスト・スクリプトの実行」へ進みます。
「確認済み（Known Good）」のポリシー構成を基準にテスト・スクリプトを作成してこれを「確認済み」としてマークしたら、コンソールを使ってそれぞれのテストを手動で指定するのではなく、スクリプトを使ってアクセス・テスターを作動させることが重要です。この項の内容は次のとおりです。
テスト・スクリプトは、アクセス・テスター・コンソール内部から対話的に実行したり、コマンド・スクリプトにより自動でテストを実行したりすることができます。自動テスト実行は、オペレーティング・システムやApache JMeterなどのハーネスによるスケジュールが可能で、手動操作を加えることなく実行されます。コマンドライン・モードでの人間による入力がない点を除けば、これら2つの実行モードは同じものです。
|
注意: .bat（Windows）や.sh（Unix）などのスクリプトは、コマンドライン・モードでテスト・スクリプトを実行します。作成したテスト・スクリプトは、スクリプト実行メニュー・コマンドやアクセス・テスターのコマンドラインを使用して実行することができます。 |
テスト・スクリプトを実行するためのコマンドを表10-13に示します。
表10-13 テスト・スクリプト実行コマンド
| ロケーション | 説明 |
|---|---|
|
「テスト」メニュー スクリプト実行 |
保存したテスト・スクリプトを現在のポリシー・サーバーに対して実行するには、「テスト」メニューからスクリプト実行コマンドを選択します。「ステータス・メッセージ」パネルには、スクリプトの進行に伴って実行ステータスが表示されます。 |
|
保存したテスト・スクリプトを現在のポリシー・サーバーに対して実行するには、ツール・バーからスクリプト実行コマンド・ボタンを選択します。「ステータス・メッセージ」パネルには、スクリプトの進行に伴って実行ステータスが表示されます。 |
|
コマンドライン・モード |
.bat（Windows）や.sh（Unix）などのスクリプトは、コマンドライン・モードでテスト・スクリプトを実行します。作成したテスト・スクリプトは、スクリプト実行メニュー・コマンドやアクセス・テスターのコマンドラインを使用して実行することができます。 |
テスト実行時のアクセス・テスターの動作について以下に概要を示します。コマンドライン・モードでの人間による入力がない点を除けば、これら2つの実行モードは同じものです。
プロセスの概要: テスト・スクリプト実行時のアクセス・テスターの動作
アクセス・テスターが入力xmlファイルをロードします。
コマンドライン・モードでは、アクセス・テスターは入力テスト・スクリプトの「制御」要素内で定義された構成XMLファイルを開きます。
アクセス・テスターは、コンソールの「サーバー接続」パネル内の情報を使用してプライマリおよびセカンダリのOAMプロキシに接続します。
コマンドライン・モードでは、構成XMLファイル内の「接続」要素内の情報を使用します。
コマンドライン・モードでは、アクセス・テスターは入力スクリプトXMLファイルの「制御」要素をチェックして、コマンドラインで上書きされたものがないことを確認します（コマンドラインの値が優先されます）。
アクセス・テスターは、オリジナル・テスト・ケースのそれぞれについて以下の処理を行ないます。
新しいターゲット・テスト・ケースを作成します。
OAMサーバーにオリジナル・リクエストを送信してレスポンスを収集します。
以下の比較を行ないます。
新しいレスポンスとオリジナルのレスポンスを比較します。
レスポンス・コードを比較して、新しいターゲット・テスト・ケースのレスポンス・コードがオリジナル・テスト・ケースと異なる場合は、そのターゲット・テスト・ケースを「不一致（mismatced）」としてマークします。たとえば、オリジナル検証へのレスポンスが「はい」で新しい検証へのレスポンスが「いいえ」の場合は、不一致としてマークされます。
レスポンス・コードが同じで「ignorecontent」制御パラメータが「false」の場合、アクセス・テスターは「コンテンツ」を比較します（認証スキームの名前や各リクエスト後に記録される認可後のアクション）。「コンテンツ」セクションが異なる場合、新しいターゲット・テスト・ケースは「不一致」としてマークされます。
新しい経過時間を収集してそれをターゲット・ユースケースに保存します。
最後のサーバー・リクエストのすべての状態、およびオリジナル・テスト・ケースと同じ固有ID（UUID）を含む新しいターゲット・テスト・ケースを作成します。
ターゲット・テスト・ケースの統計値（リクエスト・タイプ、経過時間、不一致など）を使って内部統計表を更新します。
すべての入力テスト・ケースが終了すると、アクセス・テスターは以下の処理を行ないます。
結果のサマリーを表示します。
testnameとtestnumberを取得して組み合わせ、「結果バンドル」（<testname>_<testnumber>で始まる名前を持つ3つのファイル）の名前を作成します。
|
注意: テスト名とテスト番号のコマンドライン・パラメータを指定することにより、シェル・スクリプトを使用してバンドルの作成を自動化することができます。 |
コマンドライン・パラメータからtestnameを取得します。コマンドラインで指定されていない場合は、入力スクリプトの「制御」ブロックにあるtestname要素を使用します。
コマンドライン・パラメータからtestnumberを取得します。指定されていない場合のtestnumberのデフォルトは、現在のローカル時刻に基づく7文字の数値文字列となります。つまり、分数を表わす2文字、秒数を表わす2文字、および1/100秒を表わす3文字です。
「結果バンドル」、つまり<testname>_<testnumber>で始まる名前の3つのファイルを作成します。
ターゲットXMLスクリプトには新しいテスト・ケースが格納されます: <testname>_<testnumber_results.xml
統計XMLファイルには、テスト実行全体のサマリーと詳細、および「不一致（mismathed）」とマークされたテスト・ケースが格納されます: <testname>_<testnumber_stats.xml
「ステータス・メッセージ」パネルの情報が格納される実行ログ・ファイル: <testname>_<testnumber_log.log.
コマンドライン・モードでは、「アクセス・テスターのコマンドライン・モードについて」に示すようにアクセス・テスターは終了コードで終了します。
前提条件
テスト・スクリプトの実行方法
「入力テスト・スクリプトの作成」に示すように、アクセス・テスターを終了する前に保存テスト・スクリプトの場所を確認します。
以下のいずれかの方法を使い、処理のためにテスト・スクリプトを送信します。
アクセス・テスター・コンソールでツール・バーからスクリプト実行コマンド・ボタンを選択して（または「テスト」メニューのスクリプト作成を選択して）プロンプトに従い、スクリプトの実行に合わせて「ステータス・メッセージ」パネルに表示されるメッセージを確認します。
コマンドラインから、希望のシステム・プロパティが指定されたテスト・スクリプトを指定します。「コマンドライン・モードで使用するためのシステム・プロパティを指定してアクセス・テスターを開始する」を参照してください。
java -Dscript.scriptfile="\tests\script.xml" -Dcontrol.ignorecontent="true" -jar oamtest.jar
「スクリプト、ログ・ファイル、および統計の評価」に示すように、ログ・ファイルと出力ファイルを確認し、新たに作成された結果と入力スクリプトから取得した結果をアクセス・テスターが比較した後で、追加的な分析を行ないます。
この項の内容は次のとおりです。
テスト実行終了時には、3つのドキュメントからなる「結果バンドル」が作成されます。
ターゲット・スクリプト: 新しいテスト・ケースが格納されたXMLドキュメント
実行ログ: スクリプト実行時に表示されたメッセージが格納されたテキストファイル
実行統計: テスト・メトリックと不一致要素のリストが格納されたXMLドキュメント
オリジナル・スクリプトとターゲット・スクリプト内にあるテスト・ケースの一致ペアは、テスト・ケースIDを共有しています。このIDは、オリジナル・スクリプトとターゲット・スクリプト内の個々のテスト・ケースの比較を可能にするUUID（中略）で表わされます。詳細については「作成された入力テスト・スクリプトについて」を参照してください。
統計ドキュメントにはサマリー統計と詳細統計、および一致しなかったテスト・ケースのリストが格納されます。詳細統計は、さらに詳しい分析や結果履歴の記録に使用できます。サマリー統計はテスト実行の終了時に表示されるものと同じ統計で、テスト実行の結果を迅速に評価するために使用できます。統計ドキュメント内に作成される不一致テスト・ケースのリストには、表10-14に示すように、不一致をトリガしたテスト・ケースIDと不一致の理由が含まれています。
これは、「ファイル」メニューの「構成の保存」コマンドを使用して保存した出力ファイルです。
|
注意: 以下のトピックに示すように、入力テスト・スクリプト・ファイルも作成されます。構成ファイル名は、アクセス・テスターをコマンドライン・モードで実行した時に接続ファイル内に定義された接続情報を取得できるようにするために、入力テスト・スクリプト内で使われます。 |
例10-1 接続構成ファイル
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<oamtestconfig xmlns="http://xmlns.oracle.com/idm/oam/oamtest/schema"
version="1.0">
<connection timeout="30000" minnconn="1" mode="open">
<agent password="00030d05101b050c42" name="agent1"/>
<keystore rootstore="" keystore_password="" keystore=""
global_passphrase=""/>
<primary>
<server maxconn="1" port="2100" addr="oam_server1"/>
</primary>
<secondary>
<server maxconn="1" port="0" addr=""/>
</secondary>
</connection>
<uri getauthscheme="true">
<scheme>http</scheme>
<host>oam_server1</host>
<port>7777</port>
<resource>/index.html</resource>
<operation>Get</operation>
</uri>
<identity>
<id>admin1</id>
<password>00030d05101b050c42</password>
<ipaddr>111.222.3.4</ipaddr>
</identity>
</oamtestconfig>
入力テスト・スクリプトは、アクセス・テスターを使用してユーザー固有のテスト・ケースを取得することによって作成されます。「制御」要素の「configfile」属性は、OAMサーバーとの接続確立用にコマンドライン・モードで使用する接続構成ファイルを指定するために、作成後に更新されます。
例10-2 生成された入力テストスクリプト
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<oamtestscript xmlns="http://xmlns.oracle.com/idm/oam/oamtest/schema"
version="1.0">
<history description="Manually generated using agent 'agent1'"
createdon="2010-02-03T22:28:00.468-05:00" createdby="test_user"/>
<control numthreads="1" numiterations="1" ignorecontent="false"
testname="samplerun1" configfile="config.xml"/>
<cases numcases="4">
<case uuid="465a4fda-d814-4ab7-b81b-f3f1cd72bbc0">
<request code="Validate">
<uri getauthscheme="true">
<scheme>http</scheme>
<host>oam_server1</host>
<port>7777</port>
<resource>/index.html</resource>
<operation>Get</operation>
</uri>
</request>
<response elapsed="984" code="Yes">
<comment></comment>
<status>Major code: 4(ResrcOpProtected) Minor code:
2(NoCode)</status>
<content>
<line type="auth.scheme.id">LDAPScheme</line>
<line type="auth.scheme.level">2</line>
<line type="auth.scheme.required.creds">2</line>
<line type="auth.scheme.redirect.url">http://dadvmh0172.us.oracle.com:14100/oam/server/</line>
</content>
</response>
</case>
<case uuid="009b44e3-1a94-4bfc-a0c3-84a38a9e0f2a">
<request code="Authenticate">
<uri getauthscheme="true">
<scheme>http</scheme>
<host>oam_server1</host>
<port>7777</port>
<resource>/index.html</resource>
<operation>Get</operation>
</uri>
<identity>
<id>weblogic</id>
<password>00030d05101b050c42</password>
<ipaddr>192.168.1.8</ipaddr>
</identity>
</request>
<response elapsed="187" code="Yes">
<comment></comment>
<status>Major code: 10(CredentialsAccepted) Minor code:
2(NoCode)</status>
<content>
<line type="user.dn">cn=weblogic,dc=us,dc=oracle,dc=com</line>
</content>
</response>
</case>
<case uuid="84fe9b06-86d1-47df-a399-6311990743c3">
<request code="Authorize">
<uri getauthscheme="true">
<scheme>http</scheme>
<host>oam_server1</host>
<port>7777</port>
<resource>/index.html</resource>
<operation>Get</operation>
</uri>
<identity>
<id>weblogic</id>
<password>00030d05101b050c42</password>
<ipaddr>192.168.1.8</ipaddr>
</identity>
</request>
<response elapsed="188" code="Yes">
<comment></comment>
<status>Major code: 8(Allow) Minor code: 2(NoCode)</status>
<content/>
</response>
</case>
<case uuid="61579e47-5532-42c3-bbc7-a00828256bf4">
<request code="Validate">
<uri getauthscheme="false">
<scheme>http</scheme>
<host>oam_server1</host>
<port>7777</port>
<resource>/index.html</resource>
<operation>Get</operation>
</uri>
</request>
<response elapsed="172" code="Yes">
<comment></comment>
<status>Major code: 4(ResrcOpProtected) Minor code:
2(NoCode)</status>
<content/>
</response>
</case>
</cases>
</oamtestscript>
この例は、コマンドライン・モードでアクセス・テスターを実行して、取得した4つのテスト・ケースを実行するための入力としてscript.xmlファイルを指定することにより作成されたものです。
Dscript.scriptfile="script.xml" -jar oamtest.jar
例10-3のさまざまなセクションに注意してください。実行ログに示すようにこのテスト実行では不一致が見つからず、4つのリクエストのすべてが一致していることが示されています。
例10-3 テスト実行中に生成された出力ファイル
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<oamtestscript xmlns="http://xmlns.oracle.com/idm/oam/oamtest/schema"
version="1.0">
<history description="Generated from script 'script.xml' using agent 'agent1'"
createdon="2010-02-03T23:03:02.171-05:00" createdby="test_user"/>
<control numthreads="1" numiterations="1" ignorecontent="false"
testname="oamtest" configfile=""/>
<cases numcases="4">
<case uuid="465a4fda-d814-4ab7-b81b-f3f1cd72bbc0">
<request code="Validate">
<uri getauthscheme="true">
<scheme>http</scheme>
<host>oam_server1</host>
<port>7777</port>
<resource>/index.html</resource>
<operation>Get</operation>
</uri>
</request>
<response elapsed="969" code="Yes">
<comment></comment>
<status>Major code: 4(ResrcOpProtected) Minor code:
2(NoCode)</status>
<content>
<line type="auth.scheme.id">LDAPScheme</line>
<line type="auth.scheme.level">2</line>
<line type="auth.scheme.required.creds">2</line>
<line type="auth.scheme.redirect.url">http://dadvmh0172.us.oracle.com:14100/oam/server/
</line>
</content>
</response>
</case>
<case uuid="009b44e3-1a94-4bfc-a0c3-84a38a9e0f2a">
<request code="Authenticate">
<uri getauthscheme="true">
<scheme>http</scheme>
<host>oam_server1</host>
<port>7777</port>
<resource>/index.html</resource>
<operation>Get</operation>
</uri>
<identity>
<id>weblogic</id>
<password>00030d05101b050c42</password>
<ipaddr>111.222.3.4</ipaddr>
</identity>
</request>
<response elapsed="187" code="Yes">
<comment></comment>
<status>Major code: 10(CredentialsAccepted) Minor code:
2(NoCode)</status>
<content>
<line type="user.dn">cn=weblogic,dc=us,dc=oracle,dc=com</line>
</content>
</response>
</case>
<case uuid="84fe9b06-86d1-47df-a399-6311990743c3">
<request code="Authorize">
<uri getauthscheme="true">
<scheme>http</scheme>
<host>oam_server1</host>
<port>7777</port>
<resource>/index.html</resource>
<operation>Get</operation>
</uri>
<identity>
<id>weblogic</id>
<password>00030d05101b050c42</password>
<ipaddr>111.222.3.4</ipaddr>
</identity>
</request>
<response elapsed="172" code="Yes">
<comment></comment>
<status>Major code: 8(Allow) Minor code: 2(NoCode)</status>
<content/>
</response>
</case>
<case uuid="61579e47-5532-42c3-bbc7-a00828256bf4">
<request code="Validate">
<uri getauthscheme="false">
<scheme>http</scheme>
<host>oam_server1</host>
<port>7777</port>
<resource>/index.html</resource>
<operation>Get</operation>
</uri>
</request>
<response elapsed="171" code="Yes">
<comment></comment>
<status>Major code: 4(ResrcOpProtected) Minor code:
2(NoCode)</status>
<content/>
</response>
</case>
</cases>
</oamtestscript>
統計ファイル（_stats.xml）は、実行ログに示されたテスト実行時にターゲット出力スクリプトとともに作成されます。script.xmlファイルは、取得した4つのテスト・ケースを実行するための入力として使われます。このテスト実行では不一致は見つからず、4つのリクエストのすべてが一致していることが示されています。
サンプル統計ドキュメントを例10-4に示します。この実行の統計はさまざまなセクションに示されており、これらと過去の「確認済み（Known Good）」の統計と比較することができます。
例10-4 統計ドキュメントの例
A sample statistics document is shown here. Notice,
<oamteststats xmlns="http://xmlns.oracle.com/idm/oam/oamtest/schema"
version="1.0">
<history description="Generated from script 'script.xml' using agent
'agent1'" createdon="2010-02-03T23:03:02.171-05:00" createdby="test_user"/>
<summary>
<total>
<nummatched>4</nummatched>
<numtotal>4</numtotal>
<avgelapsedsource>238</avgelapsedsource
<avgelapsedtarget>232</avgelapsedtarget>
</total>
<validate>
<nummatched>2</nummatched>
<numtotal>2</numtotal>
<avgelapsedsource>578</avgelapsedsource>
<avgelapsedtarget>570</avgelapsedtarget>
</validate>
<authenticate>
<nummatched>1</nummatched>
<numtotal>1</numtotal>
<avgelapsedsource>187</avgelapsedsource>
<avgelapsedtarget>187</avgelapsedtarget>
</authenticate>
<authorize>
<nummatched>1</nummatched>
<numtotal>1</numtotal>
<avgelapsedsource>188</avgelapsedsource>
<avgelapsedtarget>172</avgelapsedtarget>
</authorize>
<summary>
<detail>
<source>
<validate>
<yes>2</yes>
<no>0</no>
<error>0</error>
<mismatch>0</mismatch>
<elapsed>1156</elapsed>
</validate>
<authenticate>
<yes>1</yes>
<no>0</no>
<error>0</error>
<mismatch>0</mismatch>
<elapsed>187</elapsed>
</authenticate>
<authorize>
<yes>1</yes>
<no>0</no>
<error>0</error>
<mismatch>0</mismatch>
<elapsed>188</elapsed>
</authorize>
</source>
<target>
<validate>
<yes>2</yes>
<no>0</no>
<error>0</error>
<mismatch>0</mismatch>
<elapsed>1140</elapsed>
</validate>
<authenticate>
<yes>1</yes>
<no>0</no>
<error>0</error>
<mismatch>0</mismatch>
<elapsed>187</elapsed>
</authenticate>
<authorize>
<yes>1</yes>
<no>0</no>
<error>0</error>
<mismatch>0</mismatch>
<elapsed>172</elapsed>
</authorize>
<target>
</detail>
<mismatch numcases="0"/>
</oamteststats>
このサンプル実行ログは、テスト実行時に4つのテスト・ケースを実行するscript.xmlを使用して、ターゲット出力スクリプトとともに作成されたものです。このテスト実行では不一致は見つからず、4つのリクエストのすべてが一致していることが示されています。
この例を見ると、アクセス・テスターの「ステータス・メッセージ」パネルに表示される情報と同じ情報で構成されていることが分かります。テスト・ケース、テスト名、接続構成ファイル、エージェント名、接続ステータス、リクエスト評価ステータス、認証スキーム、リダイレクトURL、求められる資格証明、認証ステータスとユーザーDN、セッションID、認証ステータス、検証ステータス、サマリー統計などを確認してください。また、この実行によってターゲット・スクリプトと統計ドキュメントが作成されていることにも注意してください。
例10-5 実行ログ
[2/3/10 11:02 PM][info] Setting up to run script 'script.xml' [2/3/10 11:02 PM][info] Loading test cases and control parameters from script [2/3/10 11:02 PM][info] Loaded 4 cases [2/3/10 11:02 PM][info] Control data for this test run: [2/3/10 11:02 PM][info] Test name : 'samplerun1' [2/3/10 11:02 PM][info] Configuration file : 'config.xml' [2/3/10 11:02 PM][info] Ignore content : 'false' [2/3/10 11:02 PM][info] Loading server configuration from file [2/3/10 11:02 PM][info] Loaded server configuration [2/3/10 11:02 PM][info] Connecting to server as agent 'oam_agent1' [2/3/10 11:03 PM][info][request] Connect : Yes ... [2/3/10 11:03 PM][info] Test 'samplerun1' will process 4 cases [2/3/10 11:03 PM][info][request] Validate : Yes [2/3/10 11:03 PM][info] Authentication scheme : LDAPScheme, level : 2 [2/3/10 11:03 PM][info] Redirect URL : http://oam_server1.us.company.com:2100/server/ [2/3/10 11:03 PM][info] Credentials expected: 0x01 (password) [2/3/10 11:03 PM][info][request] Authenticate : Yes [2/3/10 11:03 PM][info] User DN : cn=admin1,dc=us,dc=company,dc=com [2/3/10 11:03 PM][info] Session ID : -1 [2/3/10 11:03 PM][info][request] Authorize : Yes [2/3/10 11:03 PM][info][request] Validate : Yes [2/3/10 11:03 PM][info] Summary statistics [2/3/10 11:03 PM][info] Matched 4 of 4, avg latency 232ms vs 238ms [2/3/10 11:03 PM][info] Validate: matched 2 of 2, avg latency 570ms vs 578ms [2/3/10 11:03 PM][info] Authenticate: matched 1 of 1, avg latency 187ms vs 187ms [2/3/10 11:03 PM][info] Authorize: matched 1 of 1, avg latency 172ms vs 188ms [2/3/10 11:03 PM][info] Generated target script 'samplerun1_0302171__target.xml' [2/3/10 11:03 PM][info] Generated statistics log 'samplerun1_0302171__stats.xml'
