| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
|
前 |
次 |
テスト管理とは、管理者やシステムによっていつでも実行することのできる再現可能なテストを作成することを言います。クイック・スポット・チェックは、直面している問題のトラブルシュートを行う上で非常に有効かつ効果的です。しかし、サーバーとポリシーの構成を検証する上で、より高い予測可能性と再現性を備えた方法が必要になることも少なくありません。
この方法には、製品リビジョン後の性能低下に関するOAMサーバー構成のテスト、あるいはポリシー作成中やQAサイクルにおけるOAMサーバー構成のテストを含めることができます。
これらのテストを有効なものとするには、複数のユースケースをグループとして実行できるようにする必要があります。テスト・スクリプトが設計されて誤りのないことが確認されてしまえば、OAMサーバーに対して再度テストを行うことは、ポリシー構成の質の低下を明らかにする助けとなります。
この項では、テスト管理を行うために必要な情報を次に示すトピックの中で示します。
テスト・ケースは、アクセス・テスターを使用してOAMサーバーに送信したリクエストと、OAMサーバーから受信した応答で作成します。様々なデータ要素がある中で、テスト・ケースにはリクエスト待機時間と、新旧のテスト・ケースの分析と比較を可能にするその他のアイデンティティ確認情報が含まれます。テスト・スクリプトは、アクセス・テスター・コンソールから構成、実行および生成できます。
取得したテスト・ケースは、新たな入力なしで再実行して新旧の結果を比較することができます。古い結果が「確認済(Known Good)」としてマークされている場合は、それらの結果と差がテスト・ケースを失敗させる要素となります。
テスト・ケースのワークフローを図26-7に示します。
タスクの概要: テスト・ケースの作成と管理
アクセス・テスター・コンソールからは、OAMサーバーに接続して手動で個々のテストを行うことができます。リクエストは、リクエストを送信してOAMサーバーから応答を受信した後に取得キューに保存することができます。他のテスト・ケースを取得は、テスト・スクリプトを作成して取得キューをクリアする前に続けて行うことができます。取得したキューを保存せずにアクセス・テスターを終了しようとすると、終了前にテスト・ケースをテスト・スクリプトに保存するかどうかの確認が行われます。キューは、すべてのテスト・ケースの取得が終了するまでクリアしないでおくことをお薦めします。
テスト・スクリプトの作成後は、アクセス・テスター・コンソールまたはコマンド行からそのスクリプトを実行することができます。
それぞれのテスト・ケースは、アクセス・テスターからOAMサーバーにリクエストを送信してレスポンスを受信した後に、取得キューに保存できます。テスト・ケースのグループの実行を自動化するテスト・スクリプトを作成する前に、個々のテスト・ケースを必要なだけ取得できます。
例として、個別に取得する必要がある3つのテスト・ケースの概要を次に示します。
検証のリクエストと応答
認証のリクエストと応答
認可のリクエストと応答
表26-10に、取得オプションの場所を示します。
表26-10 アクセス・テスターの取得リクエスト・オプション
| 場所 | 説明 |
|---|---|
テスト・メニュー 最後の"..."リクエストを取得 |
「テスト」メニューからこのコマンドを選択して、発行した最後のリクエストと受信した結果を取得キューに追加します(後でテスト・スクリプトに含めるため)。 |
青色の上向き矢印 |
ツール・バーからこのコマンド・ボタンを選択して、発行した最後のリクエストと受信した結果を取得キューに追加します(後でテスト・スクリプトに含めるため)。 |
取得したキューを保存せずにアクセス・テスターを終了しようとすると、終了前にテスト・ケースをテスト・スクリプトに保存するかどうかの確認が行われます。アクセス・テスターの取得キューは、すべてのテスト・ケースの取得が終了するまでクリアしないでください。
1つまたは複数のテスト・ケースを取得する方法
テスト・スクリプトは、アクセス・テスター・コンソールを使用して取得された個々のテスト・ケースの集合です。個々のテスト・ケースをグループにまとめた場合は、テスト範囲を自動化して特定のアプリケーションまたはサイトに関するポリシー構成を検証することが可能になります。
アクセス・テスターへの入力として使用するテスト・スクリプトを作成して、複数のテスト・ケースを自動処理することができます。スクリプト作成オプションを使用すれば、XMLファイルのテスト・スクリプトを作成して取得キューをクリアすることができます。取得したキューを保存せずにアクセス・テスターを終了しようとすると、終了前にテスト・ケースをテスト・スクリプトに保存するかどうかの確認が行われます。次の各項では、さらに詳細を説明します。
ノート:
取得キューは、スクリプトに含めようとしているすべてのテスト・ケースを取得するまでクリアしないでください。
アクセス・テスターへの入力として使用するテスト・スクリプトを作成して、複数のテスト・ケースを自動処理することができます。
これらのスクリプトは次の規則に従わなければなりません。
オペレータまたはシステムによるリプレイが可能
異なるポリシー・サーバーを作動させるテスト・スクリプトの共有を可能にするために、スクリプトを変更することなく異なるポリシー・サーバーへのリプレイが可能
「確認済(Known Good)」の結果に対するテスト実行結果の比較が可能
スクリプト作成コマンドの場所を次に示します。
表26-11 スクリプト作成コマンド
| コマンドの場所 | 説明 |
|---|---|
テスト・メニュー スクリプトの生成 |
「テスト」メニューからスクリプト作成を選択して、取得したテスト・ケースを含むスクリプトの作成を開始します。 |
ペーパー・スクリプト・スクロール |
ツール・バーからスクリプト作成コマンド・ボタンを選択して、取得したテスト・ケースを含むスクリプトの作成を開始します。スクリプトの名前を指定または選択すると、取得キューをクリアするかどうかの確認が行われます。取得キューは、テスト・ケースがすべてスクリプトに保存されるまでクリアしないでください。 |
テスト・スクリプトに含めるテスト・ケースを取得し、記録できます。
この項では、テスト・スクリプトのパーソナライズ方法とカスタマイズ方法を説明します。
スクリプトにタグを付けてテスト実行時に使用する情報を指定するには、テスト・スクリプトの制御ブロックを使用します。スクリプトの作成者、作成時期、および作成理由についての詳細を含めたい場合も考えられます。また、1つまたは複数の制御パラメータを使ってスクリプトをカスタマイズしたい場合もあるかもしれません。
アクセス・テスターでは、スクリプトを変更することなくスクリプトの処理を変更するコマンド行「制御」パラメータを使用することができます (テスト名やテスト番号など)。これにより、「確認済(Known Good)」の入力テスト・スクリプトを変更することなくテスト実行を構成することが可能です。制御要素とこれらのカスタマイズ方法を表26-12に示します。
表26-12 テスト・スクリプト制御パラメータ
| 制御パラメータ | 説明 |
|---|---|
|
オリジナルのOAMサーバー応答と最新の応答を比較する際に、ユースケースの「コンテンツ」セクションの違いを無視します。デフォルトでは「コンテンツ」セクションを比較します。このパラメータは、コマンド行モードで実行するときはコマンド行プロパティで上書きすることができます。 デフォルト: false(「コンテンツ」セクションを比較) 値: trueまたはfalse コマンド行モードでは、ignorecontent=trueを使用して入力スクリプトの制御セクションの指定値を上書きしてください。 |
testname="oamtest" |
前の項に示したように、「結果バンドル」のファイル名に加える接頭辞を指定します。 コマンド行モードでは、Testname=nameを使用して「制御」セクションの指定値を上書きしてください。 |
configfile="config.xml" |
アクセス・テスターによって過去に作成された構成XMLファイルへの絶対パスを指定します。 コマンド行モードでは、このファイルは、サーバー接続を確立するための接続詳細の場所を特定するためにアクセス・テスターが使用します。 |
numthreads="1" |
複数のテスト・スクリプトのコピーを実行するために、アクセス・テスターによって開始されるスレッド(仮想クライアント)の数を示します。スレッドごとにポリシー・サーバーへの固有の接続プールが開きます。この機能はポリシー・サーバーのストレス・テストが目的で、コマンド行モードでのみ使用できます。 デフォルト: 1 GUIモードでテスト・スクリプトを実行する場合、スレッドの数は無視され、1つのスレッドのみが開始されてテスト・スクリプトを1回実行します。 |
numiterations="1" |
アクセス・テスターが実行する繰返し回数を示します。この機能はポリシー・サーバーのストレス・テストおよび寿命テストが目的で、コマンド行モードでのみ使用できます。 デフォルト: 1 |
アクセス・テスターで生成したテスト・スクリプトをパーソナライズできます。
「確認済(Known Good)」のポリシー構成を基準にテスト・スクリプトを作成してこれを「確認済」としてマークしたら、コンソールを使ってそれぞれのテストを手動で指定するのではなく、スクリプトを使ってアクセス・テスターを作動させることが重要です。
この項では次のトピックを記載しています:
テスト・スクリプトは、アクセス・テスター・コンソール内部から対話的に実行したり、コマンド・スクリプトにより自動でテストを実行したりすることができます。
自動テスト実行は、オペレーティング・システムやApache JMeterなどのハーネスによるスケジュールが可能で、手動操作を加えることなく実行されます。コマンド行モードでの人間による入力がない点を除けば、これら2つの実行モードは同じものです。
ノート:
.bat (Windows)や.sh (Unix)などのスクリプトは、コマンド行モードでテスト・スクリプトを実行します。作成したテスト・スクリプトは、スクリプト実行メニュー・コマンドやアクセス・テスターのコマンド行を使用して実行することができます。
テスト・スクリプトを実行するためのコマンドを表26-13に示します。
表26-13 テスト・スクリプト実行コマンド
| 場所 | 説明 |
|---|---|
テスト・メニュー スクリプトの実行 |
保存したテスト・スクリプトを現在のポリシー・サーバーに対して実行するには、「テスト」メニューからスクリプト実行コマンドを選択します。「ステータス・メッセージ」パネルには、スクリプトの進行に伴って実行ステータスが表示されます。 |
緑色の矢印が付いたペーパー・スクリプト・スクロール |
保存したテスト・スクリプトを現在のポリシー・サーバーに対して実行するには、ツール・バーからスクリプト実行コマンド・ボタンを選択します。「ステータス・メッセージ」パネルには、スクリプトの進行に伴って実行ステータスが表示されます。 |
コマンド行モード |
.bat (Windows)や.sh (Unix)などのスクリプトは、コマンド行モードでテスト・スクリプトを実行します。作成したテスト・スクリプトは、スクリプト実行メニュー・コマンドやアクセス・テスターのコマンド行を使用して実行することができます。 |
テスト実行時のアクセス・テスターの動作について次に概要を示します。コマンド行モードでの人間による入力がない点を除けば、これら2つの実行モードは同じものです。
プロセスの概要: テスト・スクリプト実行時のアクセス・テスターの動作
アクセス・テスターが入力xmlファイルをロードします。
コマンド行モードでは、アクセス・テスターは入力テスト・スクリプトの「制御」要素内で定義された構成XMLファイルを開きます。
アクセス・テスターは、コンソールの「サーバー接続」パネル内の情報を使用してプライマリおよびセカンダリのOAMプロキシに接続します。
コマンド行モードでは、構成XMLファイル内の「接続」要素内の情報を使用します。
コマンド行モードでは、アクセス・テスターは入力スクリプトXMLファイルの「制御」要素をチェックして、コマンド行で上書きされたものがないことを確認します(コマンド行の値が優先されます)。
アクセス・テスターは、オリジナル・テスト・ケースのそれぞれについて次の処理を行います。
新しいターゲット・テスト・ケースを作成します。
OAMサーバーにオリジナル・リクエストを送信してレスポンスを収集します。
次の比較を行います。
新しいレスポンスとオリジナルのレスポンスを比較します。
レスポンス・コードを比較して、新しいターゲット・テスト・ケースのレスポンス・コードがオリジナル・テスト・ケースと異なる場合は、そのターゲット・テスト・ケースを「不一致(mismatched)」としてマークします。たとえば、オリジナル検証へのレスポンスが「はい」で新しい検証へのレスポンスが「いいえ」の場合は、不一致としてマークされます。
レスポンス・コードが同じで「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ファイルには、テスト実行全体のサマリーと詳細、および「不一致(mismatched)」とマークされたテスト・ケースが格納されます: <testname>_<testnumber_stats.xml
「ステータス・メッセージ」パネルの情報が格納される実行ログ・ファイル: <testname>_<testnumber_log.log.
マルチスレッド・モードで実行する場合、統計XMLファイルと実行ログ・ファイルのみが生成されます。
コマンド行モードでは、「アクセス・テスターのコマンド行モードについて」に示すようにアクセス・テスターは終了コードで終了します。
