プロキシー・モデル

Functional Tester は、プロキシー・オブジェクトおよびテスト・オブジェクトという 2 つのエレメントを介して、テスト対象アプリケーション (AUT) コントロールと対話します。
ドメイン・アーキテクチャー

プロキシー・オブジェクトを介した対話

プロキシー・オブジェクトは、実際のテスト対象のコントロールのラッパー・クラスに似ています。 AUT コントロールとの Functional Tester フレームワーク通信はすべて、これらのプロキシー・オブジェクトを介して行われます。 プロキシー・オブジェクトが作成および配置され、そこで、テスト対象のコントロールにアクセスして情報を照会することができます。 プロキシーは Java™ または C# クラスとして書かれ、GUI テスト・オブジェクト用の指定された Functional Tester インターフェースを AUT にインプリメントします。 テストでアプリケーションが使用可能な場合、プロキシー・クラスはアプリケーションにロードされ、そのアプリケーションの一部になります。 プロキシー・オブジェクトは、アプリケーション内の実際の GUI テスト・オブジェクト (ネイティブ・オブジェクト) をラップし、Functional Tester でテストできるようにします。

Functional Tester フレームワークは、新規の ProxyObject クラスの作成、または使用可能な ProxyObject クラスの拡張をサポートすることによって、新規のコントロールのテストをサポートします。

TestObject を介した対話

TestObject は、テスト対象コントロール用のスクリプト・サイドのインターフェース・オブジェクトです。 コントロールは TestObject としてテスト・スクリプトに公開されます。例えば、ボタン・コントロールは GuiTestObject として公開されます。ダイアログおよびフレームのようなトップレベルのコントロールは、TopLevelTestObject として公開されます。

TestObject メソッドの実行は、対応する ProxyObject を介して行われます。TestObject は、Functional Tester クライアント・サイドにあります。TestObject は ProxyObject を参照し、ProxyObject はテスト対象の AUT コントロールを参照します。

プロキシー・モデル

Java、HTML、.Net、Win32、Siebel、および SAP などの、Functional Tester がサポートするテスト環境ごとに、ドメイン・オブジェクトが確立されます。 各ドメインの下には、サポートされるすべての AUT コントロールのための ProxyObject クラスが存在します。 ProxyObject クラスと AUT コントロールとの間のマッピング情報は、Functional Tester インストール・ディレクトリーのカスタマイズ・ファイル内に保管されます。 これらのカスタマイズ・ファイルは、Functional Tester のディレクトリーとして機能し、指定された AUT コントロールにどの ProxyObject が使用されるかを識別します。

注: メインのカスタマイズ・マッピング・ファイルは rational_ft.rftcust です。 拡張子 .rftcust の付いた他のドメイン固有のカスタマイズ・ファイルも存在します。

ProxyObject を拡張して、サポートされていない UI コントロールをサポートするための新規の ProxyObject クラスを作成することもできます。 例えば、.Net 2.0 DataGridView コントロールをサポートする場合、新規のプロキシー・クラス Rational.Test.Ft.Domain.Net.DataGridViewProxy を作成し、対応するマッピング・エントリーを rational_ft.rftcust ファイルに挿入することができます。 以下のコードは、カスタマイズ・ファイルの更新済みセクションの例です。

<Obj L=".Proxy">
<ClassName>[WhidbeyControls]Rational.Test.Ft.Domain.Net.DataGridViewProxy</ClassName>
	<Replaces/>
		<UsedBy>[System.Windows.Forms]System.Windows.Forms.DataGridView</UsedBy>
</Obj>

フィードバック