このセクションでは、Web アプリケーションをスキャンするように SOAtest を設定する方法について説明します。「静的解析の実行」で説明しているように、アクセスされたページに対して静的解析を実行できます。
このセクションの内容:
スキャニング テストとは、テスト ケースが実行されるときに、指定した Web アプリケーションをスキャンするテストのことです。Web アプリケーションをスキャンするよう SOAtest を構成するには、次のようにスキャニング テストを追加します。
[FTP] または [ローカル] を選択した場合、フィールドの入力が完了すれば、構成は完了です。残りのステップはスキップできます。
FTP ソースを指定するとき、次のオプションがあります。
|
URL のユーザー名とパスワードが「*」として入力された場合、SOAtest はまず「この URL の直前の URL で同じドメインに属する URL」に使用されるのと同じ認証情報を使用しようとします。この認証情報がこの URL に適用しない場合、SOAtest はレルム パスワード ダイアログを開き、正しい認証情報の入力をユーザーに求めます。
.urls ファイルの書式は次のとおりです。URL は別々の行で指定します。URL に認証情報を指定する場合、「URL、ユーザー名、パスワード」の順番で URL と同じ行で指定しなければなりません。URL、ユーザー名、およびパスワードはカンマで区切ります。これらの項目でカンマを使用している場合、その項目を二重引用符で囲む必要があります。これらの項目で二重引用符を使用している場合、二重引用符をさらに別の二重引用符でエスケープし、項目全体を二重引用符で囲む必要があります。例: |
ここまでの操作が終了すると、テスト スイートまたは個別のスキャニング ツールに対して任意のテスト コンフィギュレーションを実行できます。 テストを実行すると、SOAtest は静的ページと動的ページを網羅し、アクセスした各ページのインスタンスを少なくとも 1 つロードします。
推奨される HTTP 構成オプションを選択していて、サイトにフォームがある場合、フォーム入力ダイアログからフォームにデータを投入できます。サイトのロード中にフォーム入力ダイアログが表示された場合、「Populating Forms」の説明にあるように入力します。
このセクションでは、以下の特別なロードの問題に対処する方法について説明します。
[許可/制限する URL] テーブルに許可または制限を追加することで、SOAtest がロードまたは無視するサイト URL をコントロールできます。
URL が「制限する」として指定されている場合、SOAtest のスキャン中にその URL は無視されます。特定のディレクトリやファイルを SOAtest にアクセスさせたくない場合、それらを「制限 URL」 として指定できます。たとえばログアウト ページがある場合、このページを制限 URL として指定すれば、他のページのロードが妨げられたり他のページが不正になることを防止できます。パスを作成したり仮想ユーザーを使ってサイトを実行したりするときなどに、SOAtest は制限 URL を回避します。サイトに Web サーバー ソースがある場合にはサイトにロードする前に制限 URL を指定できます (このセクションで説明します)。
URL が「許可する」としてマークされている場合、SOAtest はスキャン中にその URL に遭遇すると、その URL をロードします。[開始 URL] フィールドで指定した URL の最も深いディレクトリ URL パターンが自動的に「許可 URL」として追加されます。この URL を「許可するサブディレクトリ URL」と呼びます。ここで http(s)://... を使って URL を HTTP と HTTPS の両方で許可または制限することができます。詳細については「URL Restriction Examples」を参照してください。
さらに許可 URL を追加することもできます。この機能は、関連サイトをロードするよう SOAtest を設定するのに特に役立ちます。関連サイト とは、プロジェクトのサイトにリンクされているサイトで、ホスト名がプロジェクト サイトとは異なるサイトのことです。たとえば、プライマリ プロジェクト ソースが http://www.parasoft.com であり、このサイトが http://forums.parasoft.com と http://www2.parasoft.com にリンクしている場合、これらの 2 つのサイトは現行プロジェクトの関連サイトです。現行プロジェクトのコンテキストで SOAtest が関連サイトに遭遇したときに自動的に関連サイトをロードするには、関連サイトを許可 URL に指定する必要があります。
制限と許可はどちらも Scanning Tool の [許可/制限する URL] テーブルで指定します。許可はプラス記号でマークされ、制限はマイナス記号でマークされます。許可と制限は大文字と小文字を区別します。
制限と許可を組み合わせて、高度なスキャニング方法を作成できます。許可/制限は順番に処理されます。テーブルの先頭のエントリから開始し、テーブルの最後のエントリで終了します。
[許可/制限する URL] テーブルにエントリを追加するには、次の操作を行います。
許可する URL パターンに一致しない JavaScript ファイルと CSS ファイルはプロジェクト ツリーに表示されません。ただし、Web ページを正しく処理するためにこれらのファイルにアクセスする必要がある場合、(たとえそれらのファイルがプロジェクトに追加されなくても) SOAtest はそれらのファイルにアクセスします。 |
[許可/制限する URL] テーブルのエントリの位置を変更するには:
[許可/制限する URL] テーブルのエントリを削除するには:
以下は http(s)://... の制限の例です。
以下はワイルドカードの使い方の例です。
一致させる項目 | このようなエントリを使用する |
---|---|
任意のプロトコル | *www.parasoft.com/dir1/dir2/index.html |
HTTP または HTTPS プロトコル | http(s)://www.parasoft.com/dir1/dir2/index.html |
ドメイン内の任意のページ | http://www.parasoft.com/* |
最も深いサブ ディレクトリ中の任意のページ | http://www.parasoft.com/dir1/dir2/* |
ドメイン内の任意のプロトコルとページ | *www.parasoft.com/* |
任意のページ名 index.html | *index.html |
'dir' という単語を含む任意のリンク | *dir* |
任意のリンク | * |
*.parasoft.com は www.parasoft.com および articles.parasoft.com に一致します。
*parasoft* は www.parasoft.com、www.parasoft.net、parasoft.com などに一致します。
direc*ry/* は directory/dir2、direcHELLOry/dir2/dir3、および direc12345fry/images に一致します。
プロジェクトのスキャンとリフレッシュの最中、可能性のある URL が [許可/制限する URL] テーブルに対して照合され、その URL にアクセスするべきかどうかが判断されます。URL にアクセスするべきかどうかの判断は、以下のように行われます。
「スキャン中に許可または制限する URL の設定」で説明している [許可/制限する URL] テーブルでは、サイトのどの部分をスキャンするかをコントロールできます。たとえば、サイト中のある部分にある特定の URL を「禁止」にして、本来であればスキャンされる URL をスキャン対象から外すことができます。あるいは、サイト中のある場所にある特定の URL に対してスキャンを許可し、本来であればスキャンされない URL をスキャンすることができます。
http://www.dev.parasoft.com/products/dir/page.html は、上記のテーブルの以下の URL に一致します。
+ http(s)://www.dev.parasoft.com/* - http(s)://www.dev.parasoft.com/products/* + http(s)://www.*.com/products/dir/* |
最後に一致する URL は http(s)://www.*.com/products/dir/* です。この URL はプラス記号であるため (つまり許可 URL であるため)、http://www.dev.parasoft.com/products/dir/page.html は許可されます。
URL http://www.dev.parasoft.com/products/soap.html は上記のテーブルからの以下の URL に一致します。
+ http(s)://www.dev.parasoft.com/* - http(s)://www.dev.parasoft.com/products/* |
最後に一致する URL は http(s)://www.dev.parasoft.com/products/* です。この URL はマイナス記号であるため (つまり制限 URL であるため)、http://www.dev.parasoft.com/products/soap.html は制限されます。この URL はプラス記号であるため (つまり許可 URL であるため)、http://www.dev.parasoft.com/products/dir/page.html は許可されます。
サイト http://www.dev.parasoft.com には、数千種類のソフトウェアに関連する情報があります。しかし、2 種類のハードウェア (ルーターとディスク) だけにスキャンを制限したいものとします。また、サイト中の古い部分を除き、他のすべての部分を処理したいものとします。
URL http://www.dev.parasoft.com/index.html からスキャンを開始するには、この URL を [開始 URL] フィールドに入力します。
許可 URL は [許可/制限する URL] テーブルに自動的に追加されます。
+ http(s)://www.dev.parasoft.com/* |
hardware ディレクトリ内の Routers フォルダーと Disks フォルダーだけをスキャンするには、以下の順序で以下のエントリをテーブルに追加する必要があります。
- http(s)://www.dev.parasoft.com/newdir/hardware/* + http(s)://www.dev.parasoft.com/newdir/hardware/Routers/* + http(s)://www.dev.parasoft.com/newdir/hardware/Disks/* |
古いディレクトリのスキャンを制限するには、以下のエントリを追加する必要があります。
- http(s)://www.dev.parasoft.com/olddir/* |
操作が完了すると、テーブルは次のようになります。
[スキャンを開始 URL の下層ディレクトリに制限する] オプションがオンの場合、SOAtest は自動的に開始 URL を取り、最も深いサブ ディレクトリに対して許可 URL を作成します。そしてこの URL を [許可/制限する URL] テーブルの先頭に追加します。このオプションをオフにした場合、デフォルトの「許可するサブディレクトリ URL」が [許可/制限する URL] テーブルに追加されます。また、最初のリダイレクト先が、同じ完全修飾ドメイン名の URL である場合にも、SOAtest はこのように動作します。
例:
開始 URL | サブディレクトリの制限 |
---|---|
http://www.parasoft.com/dir1/dir2/ | + http(s)://www.parasoft.com/dir1/dir2/* |
http://www.parasoft.com/dir1/dir2 | + http(s)://www.parasoft.com/dir1/* |
http://www.parasoft.com/dir1/page.html | + http(s)://www.parasoft.com/dir1/* |
http://www.parasoft.com/dir1/page.html?count=1 | + http(s)://www.parasoft.com/dir1/* |
指定された開始 URL がリダイレクトである場合、SOAtest はそのリダイレクトとそれに続くリダイレクトをロードします。さらに、それらのリダイレクトごとに、許可するサブディレクトリ URL を自動的に追加します。これらのエントリはすべて [許可/制限する URL] テーブルの先頭に追加されます。
URL として追加されないリダイレクトを追うよう SOAtest を設定するには、[テーブルで制限されていないリダイレクトに従う] オプションをオンにします。このオプションがオンの場合、スキャン中にリダイレクトに遭遇し、このリダイレクトが [許可/制限する URL] テーブルで指定されていない場合、リダイレクトはロードされます。SOAtest は、このリダイレクトに対する許可するサブディレクトリ URL を [許可/制限する URL] テーブルに追加します。
JavaScript を含むサイトをロードする前に、[JavaScript の読み込み] チェックボックスがオンであることを確認します (このオプションはデフォルトでオンです)。このオプションがオンの場合、SOAtest は JavaScript を実行し、関連するリンクをロードします。
このオプションがオンであることを確認するには、次の操作を行います。
JavaScript イベント (他のウィンドウのオープンとクローズ、タイマーの実行など) を SOAtest がシミュレートする方法をカスタマイズしたい場合、このタブで JavaScript オプションを変更することができます。以下の表に従って、どのオプションを選択するかを決定してください。
目的 | オプションの設定 |
---|---|
デフォルトの引数を使って、各ハンドラーを 1 回実行する。 | [JavaScript のイベントをシミュレート] から [1 回だけ] を選択します。 |
新しいリンクを発見するためにサイトをロードする最中に、複数の種類のイベントを作成する。 | [JavaScript のイベントをシミュレート] から [毎回] を選択します。 |
JavaScript イベントをシミュレートしないようにする。 | [JavaScript のイベントをシミュレート] から [しない] を選択します。 |
サイトのスキャン中に JavaScript の Alert、Confirm、または Prompt メッセージに遭遇すると、SOAtest は GUI パネルの右側の結果エリアにメッセージを出力し、デフォルトのアクションを実行します。デフォルトでは、SOAtest は次のメッセージを出力し、次のアクションを実行します。
JavaScript メッセージ | SOAtest メッセージ | デフォルトのアクション |
---|---|---|
JavaScript Alert | JavaScript Alert: "message" | [OK] ボタンをクリックする |
JavaScript Prompt | JavaScript Prompt: "message" | [キャンセル] ボタンをクリックする |
JavaScript Confirm | JavaScript Confirm: "message" | [キャンセル] ボタンをクリックする |
これらのメッセージの処理方法を変更したい場合、スクリプトを使ってカスタム動作を定義することができます。詳細については、「スクリプト フックによるスキャンのカスタマイズ」を参照してください。
HTTP の設定の [アクティブな入力を手動で入力] チェックボックスをオンにした場合 (デフォルトはオンです)、SOAtest はユーザー入力が必要なフォームを検出するたびに、フォーム入力ダイアログを表示します。フォームがサブミットされた後に返されるページを SOAtest で解析したい場合、フォームのさまざまな入力要素 (テキスト フィールド、選択ボックス、チェックボックス、ラジオボタンなど) に SOAtest がどのようにデータを投入するかを設定する必要があります。ロード処理中にダイアログで入力の固定値を指定することで、この設定を行うことができます。
各フォームでテスト入力を追加する必要はありません。サイトのすべての主要エリアにアクセスするために必要な入力だけを追加することを推奨します。必要に応じてダイアログをスキップできます。さらに、特定のフォーム入力をサブミットすることなくすべてのサイト エリアに SOAtest が到達できる場合、ロード処理中にフォーム入力をユーザーが指定する必要はありません。
どのフォームにも入力を指定しないことを設定するには、次の操作を行います。
一部またはすべてのフォームで入力を指定するには、次の操作を行います。
目的 | 必要な操作 |
---|---|
入力サブミッションにラベルを付ける | [フォーム テスト名] フィールドで新しい名前を入力します。 |
現在のフォームに対して入力を指定する |
入力を追加すると、同じフォーム ダイアログが再び表示され、さらに入力を追加することができます。 |
現在のフォーム対してもう入力を指定しないことを示す | [スキップ] をクリックします。 |
現在のフォームまたはこのフォームの他のインスタンスに対してもう入力を指定しないことを示す | [フォームをスキップ] をクリックします。 |
このサイト中のフォームに対してもう入力を指定しないことを示す | [すべてスキップ] をクリックします。 |
現在のフォームに関連するページを参照する | [ページの表示] をクリックします。 |
サイトがフォームを使用していて、フォームがサブミットされた後に返されるページを SOAtest でロードしてテストしたい場合、フォームのさまざまな入力要素 (テキスト フィールド、選択ボックス、チェックボックス、ラジオボタンなど) にどのようにデータを投入するかを指定する必要があります。より多くの異なるページ インスタンスをテストしたければ、フォームへのデータ投入に使用するために、より多くの異なる入力が必要です。
フォームにデータを投入する方法はいくつかあります。
表示されたフォーム入力パネルで固定値を追加または変更するには、次の操作を行います。
認証が必要なページに SOAtest が到達した場合、パスワード ダイアログが表示されます。有効なユーザー名とパスワードを入力できます。
有効なユーザー名とパスワードを入力し、プロジェクト ファイルにパスワードを保存するかどうかを指定して [OK] をクリックします。
[許可/制限する URL] テーブルの使用は、Web サイトのどの部分をスキャンするかを決定します。Web プロジェクトの自動スキャン中、可能性のある URL がそれぞれ [許可/制限する URL] テーブルに対して照合され、その URL を訪問するべきかどうかが以下の方法で決定されます。URL にアクセスするべきかどうかの判断は、以下のように行われます。 1.[許可/制限する URL] テーブルで最後に一致する URL を探します。 このメカニズムによって、サイトのどの部分をスキャンするかをコントロールできます。たとえば、サイト中のある部分にある特定の URL を「禁止」にして、本来であればスキャンされる URL をスキャン対象から外すことができます。あるいは、サイト中のある場所にある特定の URL に対してスキャンを許可し、本来であればスキャンされない URL をスキャンすることができます。 注意: [許可/制限する URL] テーブルのエントリは、大文字と小文字を区別します。 |
使用できます。URL 中の任意の箇所でワイルド カードのアスタリスク (*) を使って、0 個以上の文字と一致させることができます。アスタリスク (*) を組み合わせて [許可/制限する URL] テーブルのエントリを作成できます。 アスタリスク (*) の使用例 :
|
許可ドメイン URL は、そのドメイン内のすべてのページをロードするように、SOAtest に通知します。たとえば、サイトが http://www.parasoft.com であり、許可ドメイン URL は http(s)://www.parasoft.com/* になります。ここで、ワイルドカードのアスタリスクはこのドメイン内の任意のリンクを表します。 スキャンの最中、ドメイン内のあらゆるリンクがロードされます。 許可ドメイン URL は、開始 URL を入力するときに、[許可/制限する URL] テーブルに自動的に追加されます。 |
何をスキャンするかをコントロールするには、[許可/制限する URL] テーブルにエントリを追加する必要があります。数千種類のハードウェアに関する情報が Web サイトにあるものとします。しかし、2 種類のハードウェア (ルーターとディスク) だけにスキャンを制限したいものとします。また、サイト中の古い部分を除き、他のすべての部分を処理したいものとします。 例:
操作が完了すると、 [許可/制限する URL] テーブルは次のようになります。
詳細については、「スキャン中に許可または制限する URL の設定」 を参照してください。 |
サイトのスキャン中に他の Web サイトをロードできるようにするには、[許可/制限する URL] テーブルに外部サイトを追加する必要があります。許可 URL にアスタリスク (*) を追加して、すべてのサイトをロードするようにできます。 |
ユーザーが開始 URL を入力すると、SOAtest は許可するドメイン制限 (つまり http(s)://www.parasoft.com/*) を [許可/制限する URL] テーブルに自動的に追加します。 指定した URL の http と https の両方が許可または制限されるように、http(s)://... が使用されます。 アスタリスクを削除するか 's' で置き換えることで、暗号化されないバージョンと暗号化されるバージョンのいずれかにサイトのスキャンを制限することができます。 |
リダイレクトは [許可/制限する URL] テーブルに対して照合され、追跡するかどうかが確認されます。 |
[許可/制限する URL] テーブルに URL が自動的に追加される場合は 2 種類あります。
|
指定された開始 URL がリダイレクトである場合、SOAtest はそのリダイレクトとそれに続くリダイレクトをロードします。さらに、それらのリダイレクトごとに許可するサブディレクトリ URL を自動的に追加します。これらのエントリはすべて [許可/制限する URL] テーブルの先頭に追加されます。 詳細については、「スキャン中に許可または制限する URL の設定」 を参照してください。 |
サイト中にログアウト ページがある場合、SOAtest のスキャンが停止することがあります。この種のページに遭遇すると、SOAtest はユーザーをログアウトします。その結果、ユーザーがログインしていないために他のページにアクセスできなくなります。ログアウト ページをロードしないようにすることで、スキャン中にこの状況が起こるのを防ぐことができます。 イベントを含むページの URL 制限を [許可/制限する URL] テーブルに追加することができます。たとえば、ログアウト ページが http://www.parasoft.com/logout.html である場合、これを制限 URL として追加し、ロードされないようにできます。 |
ユーザー入力が必要なフォームを検出するたびに、SOAtest はフォーム入力ダイアログを表示します。 詳細については、「フォームへのデータ投入」 を参照してください。 |
SOAtest はスキャン中に以下のテクノロジの実行をエミュレートできます。
このリストはスキャンのためにサポートされるテクノロジに特化しているので注意してください。静的解析のためにサポートされるテクノロジと同じではありません。 |
SOAtest のスキャン動作をカスタマイズできます。それには、SOAtest を設定して、「フック」に関連付けられたイベントが SOAtest プログラム内で発生したときにカスタム スクリプトを実行するようにします。
カスタマイズしたフックを使って、スキャニング ツールの特定の実行ポイントで渡される値を記録したり変更したりすることができます (たとえば、警告ダイアログが開いたときにユーザーは応答を求められたりパスワード入力を求められたりします)。
たとえば、SOAtest のフックのひとつに Alert フックがあります。Alert フックは、SOAtest のスキャニング ツールが JavaScript の alert に遭遇するたびに呼び出されます。SOAtest でこの警告情報を記録して SOAtest Message ウィンドウにレポートしたい場合、Alert フックを定義したスクリプトを作成し、Alert フックに遭遇したときの SOAtest の振る舞いを記述します。このスクリプトが呼び出された後、SOAtest はこのスクリプトにアクセスし、指定された JavaScript の alert に遭遇するたびに、指定されたアクション、つまり警告情報の記録とレポートを実行します。
フックは、カスタム メソッドを使用したスクリプトで定義してカスタマイズします。同じファイル内に複数のフックを定義できます。1 つのフックに 2 つ以上のメソッドを追加した場合、フックを呼び出すと、そのフックで定義されたすべてのメソッドが実行されます。
SOAtest で他のスクリプトを作成、適応、呼び出すときと同じ方法で、フックを定義するスクリプトを作成、適応、呼び出すことができます。起動時 (JavaScript および Jython スクリプトだけ)、Extension Tool を作成し適用することによって、および指定のパス ノードにスクリプトを追加することによって、作成、適応、呼び出しが可能です。ユーザーは、目的の機能を使用するために、その時々にフックを呼び出すことができます。たとえば、SOAtest のすべてのプロジェクトとサイトでスクリプトのフック機能を使用したい場合、そのフックを定義して使用する JavaScript または Jython のスクリプトを <soatest_install_dir>/plugins/com.parasoft.xtest.libs.web_<soatest_version>/root/startup ディレクトリに追加します。すると、プログラムがフックを呼び出すときに、関連付けられたユーザー定義メソッドが実行されます。メソッドは、フックで clear () を呼び出すまで実行されます。
一般的なフック オプションの完全な説明については、SOAtest Extensibility API を参照してください。それには、[Parasoft] メニューの [ヘルプ] をクリックし、 [Parasoft SOAtest Extensibility API] ブックを探します。
SOAtest では、以下のフックをスクリプトで定義して操作できます。
JavaScript の alert() メソッドに遭遇したとき、デフォルトでは SOAtest は [OK] ボタンをクリックして SOAtest のコンソール ビューに JavaScript Alert:
"message" を出力します。Alert フックを使用すると、このデフォルト動作を変更できます。
デフォルトでは、Alert フックは SOAtest が JavaScript の alert に遭遇するたびに呼び出されます。Alert フックにメソッドを追加することで、JavaScript の alert に遭遇したときに SOAtest がどのように振る舞うかを決定します。Alert フックが呼び出されると、SOAtest はスクリプト中で指定された場所に JavaScript Alert:
"message" メッセージを出力します (場所が指定されていない場合は SOAtest コンソール ビューに出力します)。
Alert フックは一般的に、 alert メッセージの結果を特別な SOAtest メッセージ ウィンドウに出力するために使用されます。たとえば、"Alert Messages" という SOAtest メッセージ ウィンドウにすべての alert メッセージをレポートしたい場合、次の Jython スクリプトを作成して <soatest_install_dir>/plugins/com.parasoft.xtest.libs.web_<soatest_version>/root/startup ディレクトリに追加できます。
from com.parasoft.api import Application def myAlertHook(msg): # Print the alert message to SOAtest Messages Application.showMessage(" JavaScript Alert: %s" % str(msg)) # Add the contents of the alert message to a Result Window named # "Alert Messages". This ResultWindow can later be used # as part of a test suite in a regression test, to make sure the # contents of the window, which contains the alert message, # are what you expect them to be. Application.report("Alert Messages", str(msg)) # Add your method to the Alert Hook Application.getHook("Alert").set(myAlertHook) |
myAlertHook メソッドに渡される引数は alert メッセージです。これは、alert が持つメッセージ文字列です。
また、Alert フックを使用すると、不正なフォーム値をユーザー (または SOAtest) がサブミットしたときに、不正なデータの入力を警告する警告ダイアログをアプリケーションが表示することを検証できます。このテストを実装するには、SOAtest メッセージ ウィンドウに警告メッセージを記録する (上記のような) スクリプトを作成して呼び出します。次に、次のテスト ケースを使って SOAtest メッセージ ウィンドウの内容をチェックするテスト スイートを実装します。
#Script to return text of result window named "Alert Messages" from soaptest.api import * def return(): return SOAPUtil.getResultWindowText("Alert Messages") #Script to clear text of result window named "Alert Messages" from soaptest.api import * def clear(): SOAPUtil.clearResultWindow("Alert Messages") |
JavaScript の confirm() メソッドに遭遇したとき、デフォルトでは SOAtest は [キャンセル] ボタンをクリックし、false を返し、SOAtest コンソール ビューに JavaScript Confirm:
"message" を出力します。JavaScript の prompt() メソッドに遭遇したときは、[キャンセル] ボタンをクリックし、null を返し、SOAtest コンソール ビューに JavaScript Prompt:
"message" を出力します。Confirm フックまたは Prompt フックをスクリプトで定義してカスタマイズすることで、このデフォルト動作を変更できます (使用されるフックは、戻り値を変更したい JavaScript メソッドによって決まります)。
Confirm
Confirm フックをカスタマイズすることで、confirm() メソッドに遭遇したときに SOAtest がどのように振る舞うかを決定します。
たとえば、confirm() メソッドに遭遇するたびに、カスタマイズされた (デフォルトではない) レスポンスを SOAtest が返すようにする方法のひとつは、以下のステップを実行することです。
まず、startup.py という Jython ファイルを作成し、1 個の引数を取る 1 個のメソッドを定義します。この引数は、JavaScript の confirm() メソッドがこの引数に渡すのと同じ値を持ちます。 必要なロジックに基づいて、confirm() が true を返すのか false を返すのかを決定し、定義したメソッドからその値を返します。定義したメソッドを SOAtest が使用するようにするには、以下の方法で Confirm フックにメソッドを追加します。ここで、 set に渡す引数は定義したメソッドの名前です。この例では、定義したメソッドの名前を myConfirmHook とします。
from com.parasoft.api import Application # msg will have the same value that gets passed to confirm() def myConfirmHook(msg): if msg == "Yes or no?": return 1 return 0 Application.getHook("Confirm").set(myConfirmHook) |
次に、このファイルを <soatest_install_dir>/plugins/com.parasoft.xtest.libs.web_<soatest_version>/root/startup ディレクトリに追加します。次回 SOAtest を起動したとき、confirm() メソッドに遭遇するたびに上記のスクリプトが実行されます。
Confirm フックが呼び出されると、確認アクションに従って、SOAtest はスクリプトで指定された場所に次のいずれかのメッセージを出力します (場所が指定されていない場合は SOAtest コンソール ビューに出力します)。
Based on the script, SOAtest clicked the "OK" button
Based on the script, SOAtest clicked the "CANCEL" button
Prompt
Prompt フックをカスタマイズすることで、prompt() メソッドに遭遇したときに SOAtest がどのように振る舞うかを決定します。
Prompt フックの動作は Confirm フックに非常に似ています。ひとつの違いは、Prompt フックは 2 個の引数を取り、この引数を JavaScript の prompt() メソッドに渡すことです。もうひとつの違いは Confirm フックに定義するメソッドは論理値を返しますが、 Prompt フックに定義するメソッドは文字列または "null" (Jython では "None") を返さなければならないことです。
prompt() メソッドに渡される引数に基づいて返却値を決定するロジックを定義できます。"null" を返すことは、prompt() メソッドが呼び出されたときにブラウザーが開くダイアログで [キャンセル] をクリックすることに相当します。confirm() のためのカスタム メソッドを追加したときと同じように、Prompt フックにメソッドを追加します。以下は、prompt() の値として "http://www.parasoft.com" を返すスクリプトの例です。
from com.parasoft.api import Application def myPromptHook(msg, defaultMsg): return "http://www.parasoft.com" Application.getHook("Prompt").set(myPromptHook) |
Prompt フックが呼び出されると、prompt の応答に従って、SOAtest はスクリプトで指定された場所に次のいずれかのメッセージを出力します (場所が指定されていない場合は SOAtest コンソール ビューに出力します)。
Based on the script, SOAtest entered "[message- string that the script returns]"
Based on the script, SOAtest clicked the "CANCEL" button
異なる状況で異なる値を返却
Confirm フックまたは Prompt フックのために定義するメソッドに適切なロジックを追加することで、異なる状況で異なる confirm() または prompt() の値を SOAtest が返すようにできます。 Confirm または Prompt フックに追加しているメソッドへの第一引数のテキストを使って、どの値を返すかを決定します。たとえば、"Enter a URL" という問い合わせ (prompt) には http://www.parasoft.com を返したいが、 "Enter your name" という問い合わせには John を返したいものとします。この機能は以下のように実装できます。
def myPromptHook(msg, defaultMsg): if msg == "Enter a URL": return "http://www.parasoft.com" elif msg == "Enter your name": return "John" else: return None |
Realm Password フックは、以下のすべての条件が満たされたときに呼び出されます。
これらの条件を満たす前にカスタムの Realm Password フックを定義した場合、SOAtest は、手動でのパスワード入力をユーザーに求める前にカスタム フック メソッドを実行します。このメソッドが (プロジェクト中のサイト、または負荷テスト仮想ユーザーに) パスワードを追加する場合、SOAtest はそのパスワードを使用し、ユーザーにパスワードの入力を求めません。以前にパスワードが入力されている場合、このフックは実行されません。フックに対して定義したパスワードを必ず SOAtest が使用するようにしたい場合、フックから新しいパスワードを SOAtest に追加させる前に、サイト パスワードを消去するべきです。
特定のコンテキストによってユーザー名とパスワードを変化させたい場合にこのフックは特に役立ちます (たとえば使用している特定のパスに基づいて、あるいは仮想ユーザーの負荷テストのコンテキストでは異なるユーザー名とパスワードを使用したい、など)。
以下の Java のサンプル ファイルは、Realm Password フックのとても基本的な例です。このスクリプトは、コンテキストに関係なく同じパスワードを追加します。
import com.parasoft.api.*; import java.lang.reflect.*; import java.net.*; import soaptest.api.*; public class RealmPasswordHook { static public void returnPassword(String realm, String url, boolean ntlm, Context context) throws MalformedURLException { SOAPUtil.addSitePassword(realm, "user1", "password1", url, ntlm); } public void setHook() throws UserMethodException, NoSuchMethodException { Hook hook = Application.getHook("RealmPassword"); Method userMethod = getClass().getMethod("returnPassword", new Class[] {String.class, String.class, boolean.class, Context.class}); hook.set(userMethod); } } |
以下の Jython のサンプル ファイルは、前の Java ファイルに似ています。ただし、この Jython スクリプトは Realm Password フックにアクセスするときに既存のすべてのパスワードを消去します。
from com.parasoft.api import * from soaptest.api import * def returnPassword(realm, url, ntlm, context): SOAPUtil.addSitePassword(realm, "user1", "password1", url, ntlm) def setHook(): hook = Application.getHook("RealmPassword") hook.set(returnPassword) // Remove all previous passwords to the new one being added above is the one that gets used. SOAPUtil.removeSitePasswords() |
以下の JavaScript のサンプル ファイルは、フックがアクセスされたときに (仮想ユーザーの負荷テストが実行されるときに)、既存のレルム パスワードを削除し、現在アクセスされている URL に基づいてパスワードをサブミットします。
// This method uses a different password based on the URL. var Application = Packages.com.parasoft.api.Application function returnPassword(realm, url, ntlm, context) { Packages.soaptest.api.SOAPUtil.removeSitePasswords() // Adds password to a virtual user in load test if (url.indexOf("http://toad.parasoft.com:90" == 0) { Packages.soaptest.api.SOAPUtil.addSessionPassword(realm, "user1", "password1", url, ntlm, context) } else { Packages.soaptest.api.SOAPUtil.addSessionPassword(realm, "user2", "password2", url, ntlm, context) } } function setHook() { var hook = Application.getHook("RealmPassword") hook.set(returnPassword) Packages.soaptest.api.SOAPUtil.removeSitePasswords() } |
|
URL Logging フックは、SOAtest が URL を訪問するたびに呼び出されます。このフックを使って、 SOAtest がアクセスした各 URL を出力することができます。
URL Logging フックにアタッチするメソッドは、3 個または 4 個の引数を持つ必要があります。 第一引数は、訪問した URL を指定する文字列にします。第二引数は、URL を使ってサブミットされる POST データにします (これは NULL の可能性があります)。第三引数は java.util.Hashtable であり、リクエストで送られた他の HTTP プロパティを持ちます (たとえば referer)。第四引数はオプションであり、メソッドのシグニチャに追加する場合、com.parasoft.api.Context です。
さらに、SiteUtil.enableLogging を true に設定し、UrlLogging を Application.getHook() に渡す必要があります。
たとえば、SOAtest が訪問した各 URL をコンソール ビューに出力したい場合、以下の Jython スクリプトを作成して <soatest_install_dir>/plugins/com.parasoft.xtest.libs.web_<soatest_version>/root/startup ディレクトリに追加できます。
from com.parasoft.api import * from webtool.site import SiteUtil count = 1 def setHook(): SiteUtil.enableLogging = 1 hook = Application.getHook("UrlLogging") hook.set(loggingHook) def loggingHook(url, post, props): global count if post: Application.showMessage(str(count) + ". " + url + " [POST=" + post + "]") else: Application.showMessage(str(count) + ". " + url) count = count + 1 setHook() |