Manual de Usuario de GXtest Designer 1.0

Esta página muestra los conceptos principales de GXtest Client.

Introducción

El objetivo de GXtest Client es poder modelar un caso de prueba de manera sencilla y ejecutar el mismo para aplicaciones generadas con Genexus en varias plataformas y con distintas versiones de Genexus.

Los casos de prueba se modelan con un grafo orientado (conjunto de nodos y aristas), en el cual los nodos representan las páginas de la aplicación y las aristas representan los eventos que hacen pasar de una página a otra. A su vez dichos elementos (páginas y eventos) pueden tener asociados comandos. Existen tres tipos de comandos: acciones, validaciones y eventos.

En la sección Comandos se encuentran los mismos mejor detallado

Adicional a esto, en el modelo se pueden incluir casos de prueba anidados, a modo de modularizar y reutilizar Casos de Prueba, y se pueden incluir nodos de decisión, en donde se puede decidir que eventos ejecutar de acuerdo al resultado de una validación. Todos estos conceptos se verán con mayor profundidad en este manual.

Interfáz Gráfica de GXtest Client

En la siguiente imagen se pueden ver los distintos sectores de la interfaz gráfica de GXtest Client.

• Panel Central: en esta área central de la aplicación se van a visualizar los casos de prueba que tengamos, así como también los resultados de las ejecuciones de los mismos. Está área es el área principal de trabajo de la aplicación.
• Proyectos: en donde se encuentran todos lo elementos que constituyen un proyecto. Estos pueden ser Casos de prueba o DataPools.
• Elementos: en donde están los elementos que constituyen un caso de prueba. Estos elementos se pueden arrastrar sobre el área central para construir los casos de prueba.
• Comandos: en donde se pueden visualizar los comandos (acciones, validaciones y eventos) de los distintos elementos del caso de prueba.

Además de estás secciones principales se puede ver en la imagen un conjunto barras de herramientas con distintas utilidades y un control del tipo "Pan&Zoom" que permite movernos en el caso de prueba o variar el zoom sobre el mismo.

Proyectos

Lo primero que hay que hacer para poder comenzar a usar GXtest es crear un Proyecto. Para esto ir a Project -> New Project. En esta ventana se pueden seleccionar las propiedades del Proyecto.

• Nombre del Proyecto
• Conjunto de KB asociadas al proyecto (véase también cómo importar una KB de Genexus)
• Browser por defecto
• URL por defecto

El nombre identifica al proyecto. Las KB (Knowledge Base - código fuente de la aplicación Genexus) son las de la aplicación a probar. Se permite seleccionar un conjunto de KB porque en ocasiones las aplicaciones están compuestas por más de una, como es el ejemplo de aplicaciones que usan GXportal o GXflow. Una KB importada a GXtest se puede utilizar en un sólo proyecto, no se pueden compartir. El browser por defecto que se utilizará (en la versión beta sólo se puede utilizar Internet Explorer). La URL sirve para cuando se comienza a grabar un caso de prueba, el browser va directamente a esa URL.

Todos los proyectos creados se pueden volver a abrir en cualquier momento seleccionando de la lista que aparece en el menú Project -> Open Project.

Luego, si se desea eliminar un proyecto se puede hacer sobre el Proyecto abierto, botón derecho sobre el nodo del Proyecto -> Delete Project. Considerar que esto no borrará las KB asociadas al proyecto.

GXtest y la KB GeneXus

GXtest automatiza la aplicación relacionando las acciones del usuario con los objetos de la KB, en lugar de con los objetos HTML como lo hacen las herramientas tradicionales, esto permite por un lado tener una terazabilidad entre los casos de prueba y la aplicación GeneXus y por otro lado permitir al igual que GeneXus utilizar los mismos casos de prueba independientemente de la tecnología utilizada.

Importar la KB de Genexus en GXtest

Para trabajar con GXtest entonces, se necesita importar la información de la/las KB de la aplicación a probar. La información de la KB que se necesita son los Controles de los WebForms de las Transacciones y WebPanels. No se utiliza nada relacionado a la programación, eventos, ni otros.

Simplemente hay que ir a KB -> Import KB. Imagen:ImportarKB.jpg

En el caso de que no se quiera entregar el XPZ completo al equipo de pruebas, se podrá utilizar una funcionalidad para "recortar" el XPZ y enviar sólo la información que GXtest necesita. Véase para esto Recortar el XPZ.

Nota: Se recomienda acceder localmente a la KB a importar, pues el acceso por la red genera un notorio incremento en el tiempo de respuesta de la funcionalidad.

Importar una KB de GeneXus 8 o 9

GXtest puede tomar la KB de dos formas, mediante un xpz o mediante GXPublic.

Si se quiere importar mediante un XPZ indicar como tipo de importación un archivo y seleccionar la ubicación de dicho archivo. Imagen:ImportKBFile.jpg

Si se quiere importar mediante GXpublic, indicar que el tipo de importación es mediante GXpublic y luego seleccionar la ubicación de la KB. Imagen:importKBGXPublic.jpg Una vez que se selecciona la ubicación se leen los distintos modelos en dicha KB y el usuario indicará con cual se trabajará.

Importar una KB de GeneXus X o GeneXus X Ev1

Si se trata de Genexus X, es necesario instalar #GXtest Extension, y con la misma exportar la KB. Esta extensión sólo exporta en un archivo de extensión GXT la información necesaria para que GXtest pueda trabajar. Luego de realizar esto se debe importar este archivo en GXtest.

GXtest Extension

GXtest Extension es una extensión de GeneXus X que permite exportar una KB GeneXus en formato GXT. Para instalarla se debe copiar el archivo [GXtest Extension.dll] para GeneXus U4 (en caso de requerir la extension para otra versión de GeneXus ponerse en contacto con el soporte) en la carpeta Packages de la instalación de GeneXus. Luego al reiniciar GeneXus, y con unan KB abierta ir a Extensions->GXtest. Esto realizará la exportación y al finalizar le preguntará la ubicación donde se desea dejar el archivo de exportación

Actualizar la KB: Impactar los cambios de la KB en los casos de prueba

Una vez que automatizamos un conjunto de pruebas, al cabo de un tiempo seguramente el equipo siga desarrollando y por lo tanto cambiando la aplicación. En ese caso será necesario actualizar la información de la KB con la cual trabaja GXtest e impactar los casos de prueba. Para esto en GXtest tenemos que ir a KB->Refresh.

Selección de la KB

Esto nos abrirá la siguiente ventana. Imagen:ImpactKB_Paso1.jpg

En dicha pantalla seleccionaremos la KB a actualizar, por este motivo se listarán todas las KBs asociadas al proyecto actual.

Luego de seleccionar la KB se debe presionar el botón Next.

Lista de objetos a eliminar

En dicha pantalla se muestran todos los objetos que se van a eliminar porque no se encuentran en el la KB actual. Dichos objetos no intervienen en ningún caso de prueba y por lo tanto se pueden eliminiar sin ningún inconveniente. Estos objetos pueden haber sido o bien borrados, o bien renombrados. Luego de observar los objetos presionar Next.

Impacto a nivel de los objetos

En esta pantalla se pueden observar cuatro secciones:

• Objetos con conflictos: contiene la lista de objetos que son utilizados en algún caso de prueba pero no se encuentran en la nueva KB. Por ese motivo estos objetos se consideran en conflicto. Para cada uno de estos objetos será deseable indicar a cuál de los objetos disponibles se corresponde el mismo.
• Objetos sugeridos: cuando se selecciona una objeto en conflicto se sugiere en caso de ser posible objetos posibles
• Conflictos resueltos: cuando se indica que un objeto en conflicto se corresponde con un nuevo objeto, el objeto en conflicto se va de la lista de Objetos con conflictos y pasa a la lista Conflictos resueltos, a su vez el objeto disponible sale de la lista de objetos disponibles.
• Objetos disponibles: muestra la lista actual de objetos disponibles (objetos nuevos que no se ha indicado que se correspondan con algún objeto en conflicto)

Para indicar que un objeto en conflicto se corresponde con un objeto disponible, marcar el objeto en conflicto y luego marcar el objeto disponible o sugerido. Luego presionar el botón Resolved.

Cuando se haya terminado de resolver los conflictos se deberá presionar el botón Next. En ese momento todos aquellos objetos que hayan quedado en la lista de objetos en conflictos, y por lo tanto se usen en algún caso de prueba, serán eliminados. Los casos de prueba quedarán haciendo referencia a un objeto "especial" denominado MissingObject.

Casos de Prueba

Dentro de cada proyecto tendremos los casos de prueba para nuestra aplicación a probar. Cada caso de prueba (Test Case) es la automatización de un flujo sobre la aplicación, el cual resulta interesante automatizar para las pruebas de regresión. Véase también los consejos de cuándo automatizar.

Objetos de un caso de Prueba

Page

Una Página hace referencia a una página de la aplicación y puede tener una lista de acciones y una lista de validaciones.

Cada Page puede tener asociado un objeto GeneXus. En el caso de los casos de prueba generados con la IEToolbar estos siempre tendrán el objeto GeneXus asociado, pero si se hace manualmente no siempre es necesario indicarlo. El único caso en que es indispensable indicarlo es cuando a la hora de ejecutar un comando hay más de un frame en la misma ventana, o cuando hay más de una ventana (por ejemplo, popups). En ese caso hay que indicar el Objeto sobre el cual está el control al que se le quiere aplicar el comando.

Edge Line

Cada arista(Edge Line) representa la transición de una página a otra. Cada una tiene exactamente un evento. Puede tener además una lista de acciones y una lista de validaciones.

Una particularidad de las aristas es que tienen un orden. En cada una de las aristas se puede observar una letra, la cual indicará el orden para el caso en que haya más de una arista de salida en un nodo. De esta manera si tenemos por ejemplo el siguiente caso: center

La primera vez que se llegue la página Home se seguirá la arista ClickLinkTable, pero la segunda vez que se retorne a esta página se seguirá la arista ClickButton.

Test Case

El objeto de tipo Test Case permite incluir en un caso de prueba otro caso de prueba. De esta manera se permite reutilizar modelos de casos de prueba. Para ver un ejemplo de anidación de casos de prueba se puede consultar el siguiente artículo.

Decision

Un objeto de tipo Decision permite seguir dos flujos distintos dentro de la aplicación de acuerdo a una condición dada. Por ejemplo si nuestro caso de prueba requiere que si el cliente pertenece a Uruguay, entonces se le mande una notificación, pero si pertenece a otro país no se le envíe nada, entonces podemos utilizar las decisiones para seguir uno u otro flujo distinguiendo por el país del cliente.
Para ver un ejemplo sobre Decision consultar Crear un Caso de Prueba con Bifurcación

Crear un Caso de Prueba

Un caso de prueba se puede crear de varias formas. Puede hacerse de forma manual, o grabando con la GXtest IEToolbar. A su vez, con la IEToolbar se puede grabar de forma On-line y Off-line.

Crear un Caso de Prueba Manualmente

Para crear un caso de prueba manualmente, se debe seleccionar en el menú contextual sobre Test Cases en el panel de Proyecto la opción Add Test Case.

File:AddTC.jpg

Esto hace que se cree un nuevo Caso de Prueba el cual queda abierto en el panel de Modelos. Justamente en esta nueva hoja es que vamos a modelar el caso de prueba. Para esto dibujaremos el flujo a automatizar representando con nodos las páginas a visitar, y con aristas el recorrido entre estas páginas.

Luego de tener el flujo listo, hay que definir los comandos que se quieren ejecutar en cada arista y en cada nodo.

Véase también la lista de comandos disponibles.

El Drag and Drop de Comandos nos facilita la construcción de los casos de prueba en el Editor de Modelos, es la posibilidad de arrastrar los comandos creados entre los distintos componentes (aristas y nodos). Esto nos permite mover o copiar (si se usa la tecla Control).

Crear un Caso de Prueba con la GXtest IEToolbar

La distinción entre On-Line y Off-Line es simplemente porque en el primero se utiliza GXtest IEToobar en conjunto con GXtest Client, de manera que cuando se termina de grabar el caso de prueba ya queda inmediatamente plasmado en GXtest Client. Sin embargo de la manera Off-Line, GXtest IEToolbar funciona independientemente de GXtest Client y genera un archivo que luego debe importarse en GXtest Client.

Mecanismo On-line

Para grabar un caso de prueba de manera On-Line se debe seleccionar el menú contextual de Test Cases y seleccionar Record New Test Case center

En ese momento se abrirá una ventana que nos permite ingresar el nombre del caso de prueba a grabar y la url donde queremos comenzar a grabar. Luego se debe presionar el botón de Record y se abrirá un navegador para comenzar a realizar las acciones necesarias sobre el navegador. Una vez que se termine de recorrer el flujo que se desea automatizar se debe simplemente cerrar el navegador.

Mecanismo Off-line

Como se explicó anteriormente en el mecanismo Off-Line permite crear un caso de prueba sin necesidad de tener GXtest Client instalado. El resultado es un archivo ZIP, el cual es importado desde GXtest Client.

Luego de que se genera el archivo ZIP, hay que crear un nuevo Caso de Prueba, seleccionando en el menú contextual de Test Cases (sobre el panel de Proyecto), y seleccionar Add Recorded Test Case.

File:AddRecordedTC.jpg

Solo resta seleccionar el archivo ZIP antes generado.

La ventaja de esta modalidad es que no es necesario tener GXtest Client instalado para automatizar, sólo hace falta instalar la extensión al Internet Explorer. Esto incluso facilita el caso en que un usuario cualquiera desee grabar un flujo sobre la aplicación, ya sea porque necesita soporte, o porque está definiendo pruebas de aceptación, etc.

Por más detalles ver Manual de Usuario de GXtest IEToolbar.

Consejos para trabajar con los casos de prueba

A continuación se listan algunos consejos para la edición de los casos de prueba

• Copiar y pegar comandos con Drag&Drop: en GXtest es posible pasar comandos de un elemento a otro simplemente arrastrando los mismos desde el elemento origen al elemento destino. También se pueden copiar dichos comandos si mientras se realiza esto se mantiene apretada la tecla Ctrl.
• Cambiar el orden de los comandos asociados a un elemento: simplemente se debe hacer clic arriba del elemento en el panel comandos y arrastrarlo con el mouse hasta el lugar deseado

Comandos

Los comandos permite expresar tanto las intereacciones que el usuario puede realizar con la aplicación como las validaciones, o estado esperado de la aplicación luego de cada una de estas intereacciones. Los comandos pueden ser acciones, validaciones y eventos. Cada uno de estos puede recibir parámetros que le indican que deben ejecutar sobre la aplicación.

Las acciones son las cosas que hace el usuario sobre una página Web sin que eso lo haga ir a otra página. Algunos ejemplos de acciones son FillInput (para ingresar un valor en un campo de la página) y Check (para hacer un check en un checkbox).

Por otro lado tenemos los eventos, que son aquellas interacciones que hacen pasar de una página a otra. Algunos ejemplos de eventos son Go (equivale a escribir una dirección Web en el navegador), ClickLink (se utiliza para hacer clic en un link dentro de la página) y ClickButton (se utiliza para hacer clic en un botón determinado).

Por último, tenemos las validaciones, las cuales se utilizan para validar que el estado de la aplicación sea el que nosotros esperamos. Algunos ejemplos de validaciones son AppearText (valida si un texto se encuentra no en la pantalla) o VerifyControlText (compara un valor de un control determinado en la pantalla con otro valor de referencia). A todas las validaciones tienen siempre además de los parámetros propios de cada validación, dos parámetros obligatorios:

• Parámetro de Descripción del error: es una descripción que se mostrará en caso de que la misma fallé, de esa manera cuando se ejecuta un caso de prueba y el mismo falla en una validación se puede tener un mensaje claro de por que falló esa validación.
• Parámetro de Negación de la validación: sirve para indicar que el resultado esperado es la negación de la validación. Por ejemplo si negamos la validación AppearText, lo que se expresa es que no se quiere que aparezca un texto determinado.

Parámetros

Cada comando recibe una lista de parámetros. Los tipos de parámetros que pueden recibir los comandos se enumeran a continuación:.

Parámetro Control

Este tipo de parámetro indica un control dentro de un objeto GeneXus. Los objetos de tipo Transacción y WebPanel en GeneXus tienen asociado un WebForm, dicho WebForm tiene asociado un conjunto de controles que especifican la información a mostrar y la interacción que el usuario podrá tener con dicho objeto. Por ejemplo, un botón o un campo en donde se pueden ingresar valores son controles dentro de un WebForm de un objeto.

Parámetro Valor

Un parámetro de tipo Valor, se refiere a un valor fijo ya sea texto o número que se desea utilizar en el comando.

Parámetro Variable

GXtest permite capturar valores devueltos por la aplicación y almacenarlos en variables. Estas variables luego son utilizadas en otros comandos.(Véase Crear un Caso de Prueba con Variables para más información)

Parámetro DataPool

Los Data Pools permiten tomar datos externos para ser usados en el caso de prueba. El parámetro de tipo DataPool permite entonces indicar a un comando que se tome un valor de una fuente de datos especifica.

Parámetro SelectionByRow

Los comandos que ejecutan acciones sobre tablas reciben una parámetros que les indica en que fila de la tabla se debe ejecutar dicho comando. Ese parámetro llamado de forma genérica regla de selección (SelectionRule) puede ser actualmente de dos tipos SelectionByRow o SelectionByControl. El tipo SelectionByRow sirve para especificar la fila en la cual se va a actuar, en base al número de fila. De esta manera se puede modelar en GXtest acciones como "Hacer clic en la primera fila de la grilla". Por este motivo este parámetro recibe un subparámetro de tipo DataPool, Valor o Variable.

Parámetro SelectionByControl

El tipo de parámetro SelectionByControl sirve para indicar una fila en una grilla en base a el valor en una de sus columnas. Por ejemplo, se puede indicar a GXtest que seleccione la fila cuyo número de empleado sea 59. GXtest recorrerá todas las filas de la grilla y la primera que coincida con el criterio establecido será la seleccionada. Para esto este parámetro recibe dos subparámetros:

• Parámetro del Tipo Control: indica la columna en la grilla sobre la cual se va a analizar la condición
• Tipo de Comparación y comparador: se indica si se va comparar un texto o un número y el comparador que se va a utilizar (igual, mayor, menor, contiene, etc.)
• Parámetro del tipo Variable, DataPool o Valor: es el valor con el cual se va a comprar.

Lista de Comandos

Acciones
Check	Permite tildar o marcar un CheckBox
CheckTable	Análogo al Check pero para un control que se encuentre dentro de una tabla
Choose	Permite seleccionar una opción de un RadioButton
FillInput	Sirve para ingresar un valor en un campo
FillInputTable	Sirve para ingresar un valor en un campo dentro de una tabla
GetValue	Permite obtener un valor devuelto por la aplicación y almacenarlo en una variable para luego ser utilizado en otro comando.
GetValueTable	Análogo a GetValue pero para un valor que se encuentra dentro de una tabla
Select	Permite seleccionar un valor de una lista de valores (combobox)
SelectTable	Permite seleccionar un valor de una lista de valores (combobox) que se encuentra dentro de una tabla
SelectRow	Permite seleccionar una fila en una table.
UnCheck	Permite des-tildar o desmarcar un CheckBox
UnCheckTable	Análogo al UnCheck pero para un control que se encuentre dentro de una tabla
Eventos
Go	Es análogo a introducir una dirección web (URL) en el navegador.
GoAndLogin	Es análogo al comando Go pero aparte permite ingresar usuario y contraseña para las aplicaciones que así lo requieran.
Click	Hace un clic en un control GeneXus.
ClickLinkByCaption	Hace un clic en un link. La diferencia con el anterior es que hay veces por como está construida la aplicación, el mismo control aparece con más de un nombre en la pantalla. En esos casos se utiliza el ClickLinByCaption para indicar el nombre del link además del control.
ClickInTable	Permite realizar un clic en un control que se encuentra en una tabla.
ClickPrompt	Permite abrir un prompt para seleccionar los valores desde una lista.
ClickPromptInTable	Análogo al anterior pero para campos que aparecen en una tabla.
ClickPortalMenu	Permite ingresar a un menú especifico de una aplicación desarrollada con GXPortal.
ClickToolbarButton	Permite realizar un clic en un botón de una toolbar en una aplicación realizada con GeneXus X y que utilice un User Control con ExtJS.
LoginPortal	Permite logearse en una aplicación que utiliza GXPortal para la seguridad.
ClickTreeMenu	Permite ingresar a un menú desarrollado con el TreeMenu de ExtJS (en una aplicación realizada con GeneXus X y que utilice un User Control con EXTJS).
Close	Cierra una ventana.
DummyEvent	No realiza nada. Se utiliza para pasar de una página a otra sin realizar ningun evento.
Validaciones
AppearText	Valida si un determinado texto se encuentra o no en la pantalla. También se puede utilizar para las validaciones que se realizan por Ajax. En caso de que se indique el Objeto Genexus asociado en el nodo donde se ejecuta el comando, entonces buscará el texto en el frame que tiene este Objeto. Si no se indica, entonces buscará en el frame principal.
TableOrderedBy	Chequea que la tabla este ordenada por una columna dada
TableRowsNumber	Chequea la cantidad de filas de una tabla
VerifyControlEnable	Verifica que un control este habilitado
VerifyControlVisible	Verifica que un control este visible
VerifyControlText	compara el valor que muestra un control con otro valor
VerifyControlTable	Idem al VerifyControlText pero para un control dentro de una tabla

Algunas consideraciones:

• Considerar que las validaciones con String NO son Case Sensitive.

Data Pools

Un DataPool es un conjunto de datos que pueden ser utilizados en un caso de prueba. Por ejemplo si deseamos hacer un caso de prueba que ingresa al sistema 100 clientes nuevos podemos crear el datapool Clientes que contenga las columnas Nombre, CI y Tel. De esta manera luego creamos un caso de prueba cuyos comandos utilicen el datapool definido para ingresar los valores en la aplicación y cada vez que se ejecute el caso de prueba se utilizará un dato distinto del datapool. Para ver como crear un DataPool y un caso de prueba que lo utilice se puede consultar la página Crear un Caso de Prueba con DataPools.

Los DataPools son los responsables de poder utilizar en GXtest el testing dirigido por datos. Esto se debe a que pueden ser utilizados no solo para datos de entrada que toma la aplicación, sino también para validar el resultado esperado de la aplicación así como para seleccionar las distintas acciones a realizar de acuerdo a los mismos.

"Scope" de los datos

Un concepto importante dentro de los datapool es el "Scope" o jerarquía de los datos que tiene almacenado un datapool. Este scope puede ser de dos tipos Global o por caso de prueba. Si utilizo un datapool en un caso de prueba que no tiene definidos datos específicos para ese caso de prueba, entonces estaré utilizando los datos globales. Sin embargo si a ese datapool le defino datos específicos para el caso de prueba entonces utilizará esos dato específicos.

Llevemos un poco más a tierra esto. Imaginemos que en nuestros casos de prueba queremos utilizar distintos nombres de usuarios y contraseñas para ingresar al sistema. Entonces creamos un datapool Usuarios con las columnas Nombre y Contraseña. Ahora bien supongamos que la mayoría de los casos de prueba utilizan el usuario pepe y la contraseña pepe pero hay solamente un caso (llamemosle CasoA) de prueba que utiliza el usuario juan y la contraseña juan. Lo que se hace para resolver este caso es ingresar el usuario pepe y contraseña pepe como datos globales y el usuario juan como específico del CasoA.

O sea si miramos en formato tabular los datos del datapool veríamos lo siguiente:

Scope	Nombre	Contraseña
Global	pepe	pepe
CasoA	juan	juan

Si utilizamos este datapool en caso de prueba CasoB, al pedirle un valor nos devolverá (pepe,pepe) que son los valores globales, pero si lo utilizamos en el CasoA, entonces nos devolverá (juan,juan).

Importante: si un DataPool tiene N datos para un caso de prueba y yo realizo N+1 iteraciones, entonces el datapool comenzará con el primer dato nuevamente.

Export/Import de un Test Case

En este articulo se muestran las particularidades de importar y exportar un Test Case. Por otro lado si se quiere conocer con mayor detalle los xml generados al exportar un Test Case se pude consultar en este articulo.

Soporte

Por soporte sobre esta herramienta por favor envíenos un mail a gxtestbeta@abstracta.com.uy. Todas las sugerencias o errores que se reporten serán muy importantes para que mejoremos nuestros productos y así lograr la satisfacción de nuestros clientes.