Modèle de proxy

Functional Tester interagit avec les contrôles de l'application testée (AUT) via deux types d'élément : les objets de proxy et les objets de test.
Architecture du domaine

Interaction via des objets de proxy

Les objets de proxy sont similaires aux classes encapsuleur pour les véritables contrôles testés. Toute communication entre une structure Functional Tester et des contrôles AUT survient via ces objets de proxy. Les objets de proxy sont créés et placés à l'endroit où le contrôle testé est accessible et interrogé. Un proxy est écrit sous forme de classe Java™ ou C#, qui implémente l'interface Functional Tester prescrite pour un objet de test d'interface graphique dans l'application testée (AUT). Lorsque votre application est activée pour le test, les classes de proxy sont chargées dans l'application ; elles en font alors partie. Un objet de proxy encapsule l'objet de test d'interface graphique courant (l'objet natif) dans votre application et fait en sorte qu'il puisse être testé par Functional Tester.

La structure Functional Tester prend en charge la création d'une classe ProxyObject ou l'extension de toute classe ProxyObject disponible en vue de la prise en charge du test de nouveaux contrôles.

Interaction via des objets de test

Les objets de test (TestObject) sont des objets d'interface côté script pour le contrôle testé. Un contrôle se présente sous forme d'objet de test (TestObject) au script de test. Par exemple, un contrôle button se présente sous forme d'objet de test d'interface graphique (GuiTestObject). Les contrôles de niveau supérieur, tels que les boîtes de dialogue et les cadres, se présentent sous forme d'objet de test de niveau supérieur (TopLevelTestObject).

L'exécution des méthodes d'objet de test (TestObject) a lieu ensuite via l'objet de proxy (ProxyObject) correspondant. Les objets de test se trouvent du côté client de Functional Tester. Ils référencent l'objet de proxy (ProxyObject) qui, quant à lui, référence le contrôle AUT testé.

Modèle de proxy

Pour chaque environnement de test pris en charge par Functional Tester, tel que Java, HTML, .Net, Win32, Siebel et SAP, des objets de domaine sont définis. Dans chaque domaine, des classes ProxyObject existent pour tous les contrôles AUT pris en charge. Les informations de mappage entre les classes ProxyObject et les contrôles AUT sont stockées dans des fichiers de personnalisation qui se trouvent dans le répertoire d'installation de Functional Tester. Ces fichiers de personnalisation permettent à Functional Tester de savoir quel est l'objet de proxy (ProxyObject) utilisé pour un contrôle AUT donné.

Remarque : Le fichier de mappage de personnalisation principal est rational_ft.rftcust. Il existe d'autres fichiers de personnalisation propres à un domaine dont l'extension est .rftcust.

Vous pouvez également étendre les objets de proxy (ProxyObject) pour créer des classes ProxyObject afin de prendre en charge des contrôles d'interface utilisateur non pris en charge. Par exemple, pour prendre en charge le contrôle .Net 2.0 DataGridView, vous pouvez créer une classe de proxy Rational.Test.Ft.Domain.Net.DataGridViewProxy et insérer l'entrée de mappage correspondante dans le fichier rational_ft.rftcust. Le code suivant est un exemple de section mise à jour dans le fichier de personnalisation.

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

Retour d'informations