Modelo de proxy

Functional Tester interactúa con los controles de la aplicación sometida a prueba (AUT) a través de dos elementos: los objetos de proxy y los objetos de prueba.
Arquitectura del dominio

Interacción a través de objetos de proxy

Los objetos de proxy son parecidos a las clases contenedoras para los controles reales sometidos a prueba. Cualquier comunicación de la estructura de Functional Tester con los controles de la AUT tienen lugar a través de estos objetos de proxy. Los objetos de proxy se crean y colocan donde se puede acceder al control sometido a prueba y consultar su información. Un proxy se escribe como una clase de Java™ o de C#, que implementa la interfaz Functional Tester establecida para un objeto de prueba de la GUI en la AUT. Cuando la aplicación se habilita para las pruebas, las clases de proxy se cargan en la aplicación y forman parte de ella. Un objeto de proxy envuelve el objeto de prueba real de la GUI (el objeto nativo) de la aplicación, lo que permite que Functional Tester puede probarla.

La estructura de Functional Tester admite la creación de una nueva clase de ProxyObject o la ampliación de cualquier clase de ProxyObject disponibles para admitir realizar pruebas a nuevos controles.

Interacción a través de TestObject

TestObjects son los objetos de interfaz del script del control sometido a prueba. Un control se expone como un TestObjects al script de prueba. Por ejemplo, un control de botón se expone como GuiTestObject. Los controles de nivel superior, como recuadros de diálogo y marcos, se exponen como TopLevelTestObject.

La ejecución de los métodos de TestObject tienen lugar a su vez a través del ProxyObject correspondiente. Los TestObjects residen en el cliente de Functional Tester. Los TestObjects tienen una referencia al ProxyObject que a su vez se refiere al control de la AUT sometido a prueba.

Modelo de proxy

Los objetos de dominio se establecen para cada entorno de prueba admitido por Functional Tester, por ejemplo Java, HTML, .Net, Win32, Siebel y SAP. En cada dominio hay clases de ProxyObject para todos los controles admitidos de la AUT. La información de correlación entre las clases de ProxyObject y los controles de la AUT se almacenan en archivos de configuración en el directorio de instalación de Functional Tester. Estos archivos de personalización actúan como un directorio para Functional Tester con el fin de saber qué ProxyObject se utiliza para un control determinado de la AUT.

Nota: El archivo de correlación de personalización principal es rational_ft.rftcust. También existen otros archivos de personalización específicos del dominio con la extensión .rftcust.

Los ProxyObjects también se pueden ampliar para crear nuevas clases de ProxyObject y admitir controles de UI no admitidos. Por ejemplo, para admitir el control DataGridView de .Net 2.0, puede crear una nueva clase de proxy Rational.Test.Ft.Domain.Net.DataGridViewProxy e insertar la entrada de la correlación correspondiente en el archivo rational_ft.rftcust. El siguiente código es un ejemplo de la sección actualizada en el archivo de personalización.

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

Comentarios