Difference between revisions of "Manual de Usuario de GXtest Designer 1.0"

Latest revision as of 19:11, 1 March 2017

link= {{{3}}}

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

Introducción

El objetivo de GXtest Designer 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 detallados.

Adicional a ésto, en el modelo se pueden incluir casos de prueba anidados, permitiendo modularizar y reutilizar Casos de Prueba. Se pueden incluir también, nodos de decisión que permiten optar qué evento será el próximo en ejecutar de acuerdo al resultado de una validación. Todos estos conceptos se verán con mayor profundidad en este manual.

Interfaz Gráfica de GXtest Designer

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

• Main Panel: en esta área central de la aplicación se presentan los casos de prueba del proyecto y los resultados de las ejecuciones anteriores. Esta es el área principal de trabajo de la aplicación.
• Current Project: se encuentran todos lo elementos que constituyen un proyecto. Estos pueden ser Casos de prueba o DataPools.
• Elements: se encuentran los elementos que constituyen un caso de prueba. Estos elementos se pueden arrastrar sobre el área central para construir los casos de prueba.
• Commands: se presentan los comandos (acciones, validaciones y eventos) de los distintos elementos del caso de prueba.

Además de estas secciones principales GXtest presenta una serie de barras de herramientas con distintas utilidades y un control del tipo "Pan&Zoom" que permite desplazar y variar el zoom dentro del modelo.

Login / Conexiones

Al ejecutar GXtest se desplegará la siguiente pantalla:

En la misma se puede seleccionar a cuál Base de Datos se va a conectar GXtest y con qué usuario vamos a entrar a GXtest. En caso de que no existan usuarios en la base a la cual se va a conectar se podrá iniciar con el usuario Guest.

Manejo de Conexiones

Tal como se puede ver en la pantalla del login, al lado de la base a la cual nos vamos a conectar hay dos botones, uno para editar las conexiones y otro para agregar una nueva. Al presionar el botón de + nos permite agregar una nueva conexión y se despliega la siguiente pantalla:

En dicha pantalla podremos indicar:

• El nombre que le vamos a dar a la conexión
• La instancia de SQL Server sobre la cual nos vamos a conectar
• El nombre de la Base de Datos
• El modo de autenticación para entrar a la Base de Datos

Luego que se agrega una conexión la misma aparecerá listada en la pantalla de login, permitiendo al usuario trabajar en diferentes repositorios de proyectos y casos de prueba desde su máquina.

Proyectos

Lo primero que hay que hacer para poder comenzar a usar GXtest es crear un Proyecto. 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á. La URL por defecto tiene dos funcionalidades:

• por un lado sirve para cuando se comienza a grabar un caso de prueba, el browser sugiere dicha esa URL.
• por otro lado si en el caso de prueba se utiliza la variable urlHome, (la cual tiene como propósito tomar la url configurada en las distintas tareas de GXtest Manager), la misma tomará el valor de este campo del proyecto. Por más información sobre esta propiedad en GXtest Manager dirigirse al Manual de GXtest Manager

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 ésto no borrará las KB asociadas al proyecto.

Exportar e Importar un proyecto

GXtest permite exportar todos los casos de prueba de un proyecto y sus DataPools. Esto permite duplicar un proyecto en caso de que se requiera. Es importante tener en cuenta que la exportación no exporta la KB asociada al proyecto.

Para duplicar un proyecto se debe entonces exportar e importar el mismo siguiendo estos pasos:

1. Exportar el proyecto: ir a Project->Import&Export->Export Project. En ese momento se podrá seleccionar el proyecto a exportar y luego la ubicación del archivo que contendrá el proyecto exportado. Luego GXtest desplegará una ventana mostrando los casos de prueba y DataPools exportados.
2. Crear un proyecto nuevo: crear un proyecto y asociarle la misma KB que se tenía asociada al proyecto exportado en el paso 1.
3. Importar el proyecto: ir a Project->Import&Export->Import Project y seleccionar el proyecto creado en el paso 2. Luego GXtest pedirá que se seleccione el archivo zip con los datos exportados en el paso 1. Al finalizar GXtest desplegará una pantalla de resultados de la importación.

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, ésto permite por un lado tener una trazabilidad 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 -> Add KB.

En el caso de que no se quiera entregar el XPZ completo al equipo de pruebas, se podrá utilizar una funcionalidad para convertir el XPZ y enviar sólo la información que GXtest necesita. Para ésto seleccionar la opción del menú KB->Convert to GXtest

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.

GXtest puede tomar la KB de varias formas, mediante un xpz, mediante GXPublic o GXBL, o mediante un archivo .gxt.

Seleccionar el tipo de archivo que se quiere importar: (xpz, gxw o gxt). Para utilizar una KB en Genexus 8 o 9 se puede utilizar un xpz, un gxw, archivo que se encuentra en el directorio de la KB (GXtest se conectará vía GXPublic) o un gxt (archivo que contiene sólo la metadata de la KB que utiliza GXtest). Si se utiliza GeneXus X o superior se puede utilizar un gxt o indicar el gxw de la KB.

Luego seleccionar la ubicación de la KB.

GXtest Extension

GXtest Extension es una extensión de GeneXus X (Ev1, Ev2 y Tilo) que permite exportar una KB GeneXus en formato GXT.
Nota: No es estrictamente necesario instalar esta extensión en GeneXus ya que GXtest se puede conectar directamente con la aplicación GeneXus.
La principal ventaja de utilizar la extensión (en lugar de conectarse directamente a la KB), es que permite separar al tester del desarrollador. El tester no necesita tener GeneXus instalado, ni el desarrollador necesita tener GXtest para generar este archivo. Además, permite realizar exportaciones parciales (especificando solo algunos objetos de la KB).

Para instalarla se debe obtener el archivo Abtsracta.GXtestExtension.dll ubicado en la carpeta de instalación de GXtest Designer. Luego en GeneXus, desde Extension Manager, darle Add extension. Finalmente con una KB abierta ir a GXtest -> Full export. Esto realizará la exportación y al finalizar le preguntará la ubicación donde se desea dejar el archivo gxt

Puede descargar la correspondiente versión de la extensión, desde GeneXus Marketplace.

Modificar las Propiedades de la KB

Hay ocasiones en las que es necesario cambiar por ejemplo la ruta a la KB para actualizarla (cuando se da "Refresh KB" se toma del mismo lugar de donde se había importado). Para esto (con el proyecto en cuestión abierto), ir al Menú KB en el Designer y seleccionar la opción Edit Properties. Ahí seleccionar la KB a la cual se le quiere cambiar el path y luego ingresar el nuevo.

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 ésto en GXtest tenemos que ir al menú Knowledge Base->Update KB Information.

Puede ver un ejemplo completo en Cómo impactar los casos de prueba cuando cambia la KB GX

Utilizar una KB con GXFlow o con GXPortal

Cuando se utiliza una aplicación que está hecha con GXPortal (ya sea 8, 9, X, o superior) o GXFlow (para este caso solo si se encuentra en la X o superior) es necesario asociarle al proyecto de prueba dichas KB. Por este motivo el proyecto de prueba deberá quedar asociado a la KB de la aplicación y adicionalmente a la KB de Flow y/o Portal. En caso de que se utilice GXFlow de la Ev1 en este link puede encontrar la metadata de la KB para asociarla.

Si no se hace ésto, al hacer referencia en los Test Cases a elementos de Flow o Portal no se tendrán los objetos y GXtest fallará al grabar o ejecutar.

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 Recorder 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. Además, al momento de ejecutar se hace una validación de que la página visitada se corresponda con el objeto definido en la página (con el comando CheckMainObject).

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:

La primera vez que se llegue a 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 (Anidación)

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. Al incluir un TestCase dentro de otro Test Case se puede indicar a GXtest cuántas veces se va a ejecutar dicho caso de prueba. Este valor puede ser un número fijo o también puede ser extraído desde un DataPool. Al ser extraído desde un Datapool se puede lograr por ejemplo variar la cantidad de ítems de una factura dependiendo de un DataPool.

Es importante resaltar que si falla la ejecución de una de las iteraciones de un test case incluído y esto hace que corte esa ejecución, también hará que se corte la ejecución del test case que lo incluye.

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 GXtest Recorder. A su vez, con GXtest Recorder 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 Create New Test Case.

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 las 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.

Crear un Caso de Prueba con la GXtest Recorder

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

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

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 el mecanismo Off-Line permite crear un caso de prueba sin necesidad de tener GXtest Designer instalado. El resultado es un archivo ZIP o XML (desde v1.1.4), el cual es importado desde GXtest Designer.

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

Sólo resta seleccionar el archivo ZIP/XML antes generado.

La ventaja de esta modalidad es que no es necesario tener GXtest Designer 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 Recorder.

Validación de un caso de prueba

Previo a cualquier tipo de ejecución de un caso de prueba se realiza una validación del mismo. Si el caso de prueba no se encuentra en condiciones para ejecutar no se ejecuta. Algunas de las causas posibles para no poder ejecutar el caso de prueba son que no haya eventos en alguna arista o que no se encuentre conexo. Para validar un caso de prueba presionar Shift+F6 o presionar el siguiente botón en GXtest:

Ejecución de un caso de prueba

En GXtest Designer existen varias formas de ejecutar un caso de prueba, las mismas se describen a continuación.

Ejecución simple de un caso de prueba

La ejecución simple de un caso de prueba consiste en ejecutar un caso de prueba una sola vez. Para esto se debe presionar Shift+F5 o el botón que se muestra en la siguiente imagen:

De esa forma el caso de prueba abierto se ejecuta una sola vez.

Ejecución repetida de un caso de prueba

Permite ejecutar un caso de prueba tantas veces como se indique. Esto permite por ejemplo probar el uso de los DataPools. Para ejecutar el caso de prueba de manera repetida presionar Shift+F7 o presionar el botón que se muestra a continuación:

Nota: Al ejecutar N veces, al finalizar cada ejecución GXtest cerrará todas las ventanas que estén abiertas del navegador seleccionado para la ejecución.

Ejecutar en un navegador Abierto

Permite ejecutar un caso de prueba en un navegador que ya se encuentre abierto. Para hacer que un caso de prueba se ejecute en un navegador abierto presionar Ctrl+F5 o presionar el siguiente botón:

Nota: en caso de estar utilizando el navegador FireFox (GXtest 1.1 en adelante) solo se podrá utilizar esta funcionalidad con instancias del navegador abiertas por GXtest o configuradas para que inicien con la opción -jssh.

Ejecución en FireFox (a partir de la versión 1.1)

Para poder ejecutar pruebas en Firefox debe instalar la extensiónque se encuentra en el directorio de instalación de GXtest Designer\Firefox.

Por ejemplo: "C:\Program Files (x86)\Abstracta\GXtest Designer\Firefox\mozrepl-jssh.xpi" Si no sabe cómo instalar una extensión en FireFox puede recurrir a : http://www.wikihow.com/Install-Firefox-Extensions

Para versiones de FireFox inferior a 4: 2, 3, 3.5 y 3.6, se debe bajar el plug-in jssh e instalarlo (arrastrar el archivo descargado sobre el FireFox). El plug-in se puede descargar de los siguientes links:

• Jssh para Firefox 2.0
• Jssh para Firefox 3.0
• Jssh para Firefox 3.5
• Jssh para Firefox 3.6

Luego para indicarle a GXtest Desginer que ejecute en FireFox, cambiar en las propiedades del proyecto el tipo de navegador a FireFox.

Nota: Se recomienda deshabilitar las actualizaciones automáticas de FireFox y sus complementos para evitar fallas en los casos de prueba debido a dicho motivo. También se recomienda deshabilitar el diálogo que pregunta si quiere configurar el FireFox como navegador por defecto.

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 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.

Export/Import de un Test Case

En este artículo 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 artículo.

Enviar y Recibir Casos de prueba entre diferentes Bases

Como se menciona en la sección Login / Conexiones, en GXtest es posible configurar varias conexiones. Esto permite:

• intercambiar de manera sencilla casos de prueba entre las diferentes bases
• intercambiar casos entre las estaciones de trabajo y la base de GXtest Manager

Internamente lo que se realiza es una exportación e importación de los casos de prueba en las bases correspondientes.

Para enviar un caso de prueba se deben realizar los siguientes pasos:

1. Entrar en GXtest utilizando la conexión a la Base de Datos origen
2. Abrir el proyecto deseado
3. Ir a Test Cases-> Send & Receive-> Send To..
4. Seleccionar el caso de prueba que se desea enviar
5. Seleccionar la Base de Datos a la cual se desea enviar
6. Se mostrarán las opciones para la exportación (si se incluye datapools, casos de prueba de manera recursiva, etc.) Luego se debe presionar OK.
7. Se mostrarán los resultados de la exportación. Cerrar la ventana de resultados
8. Se mostrarán los resultados de la importación

Para recibir un caso de prueba realizar los siguientes pasos:

1. Entrar en GXtest utilizando la conexión a la Base de Datos origen
2. Abrir el proyecto deseado
3. Ir a Test Cases-> Send & Receive-> Recieve From ..
4. Seleccionar la Base de Datos desde la cual se va a recibir
5. Luego seleccionar el caso de prueba que se va a recibir y las opciones con las cuales se desea traer
6. El sistema mostrará una lista de resultados de la exportación realizada en la base de datos destino y luego el resultado de la importación realizada en la base de datos local

Comandos

Los comandos permiten expresar tanto las interacciones 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 interacciones. Los comandos pueden ser acciones, validaciones y eventos. Cada uno puede recibir parámetros que les indican qué 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 o no en la pantalla) o VerifyControlText (compara un valor de un control determinado en la pantalla con otro valor de referencia). 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 falle, 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 qué 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) Por otro lado existe una variable estándar llamada urlHome, la cual toma el valor definido en la propiedad url del proyecto en el caso de que se ejecute el caso de prueba desde GXtest Designer o el valor de la propiedad url asociada a la tarea en caso de ejecutarse desde GXtest Manager.

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 específica.

Parámetro SelectionByRow

Los comandos que ejecutan acciones sobre tablas reciben parámetros que les indican en qué 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 ese motivo este parámetro recibe un subparámetro de tipo DataPool, Valor o Variable. Dicho valor puede contener un número indicando el número de fila (empezando con el número 1 para la primera). Este valor también puede tener la palabra Last para indicar que seleccione la última fila de la grilla.

Parámetro SelectionByControl

El tipo de parámetro SelectionByControl sirve para indicar una fila en una grilla en base al 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 el 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, regex, etc.)
• Parámetro del tipo Variable, DataPool o Valor: es el valor con el cual se va a comparar.

Lista de Comandos

* Cuando se ejecuta un comando sobre un balloon, GXtest espera a que desaparezca el balloon para continuar con el siguiente comando a ejecutar.

Algunas consideraciones:

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

Custom Commands

Hay veces que se desarrollan funcionalidades extra de la interfaz gráfica, ya sean javascripts desarrollados a mano o simplemente HTML desarrollado a mano. En esos casos GXtest no reconocerá comandos sobre los mismos y es necesario que el usuario programe sus propios comandos. Para esto se pueden utilizar los llamados Custom Command. Por información más específica puede leer Crear un Custom Command.

Utilizar un comando para Invocar un Procedimiento GX

Muchas veces es útil utilizar un procedimiento Genexus para realizar manipulación de datos o validaciones de los mismos. Para más información ver como Crear un Comando para invocación a un Procedimiento GeneXus.

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 cómo 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 sólo 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.

Comandos asociados a los DataPools

Si bien la mayoría de los comandos pueden recibir parámetros de un DataPool, existen algunos comandos específicos de DataPools, los cuales son los siguientes:

• DPNext: Avanza a la próxima fila del DataPool. Siempre debe hacerse un DPNext antes de comenzar a utilizar el DataPool.
• DPReset: Hace que se comience nuevamente desde el principio del datapool.
• DPCompare: Es un comando de tipo validación que sirve para comparar un valor del datapool con otro valor.

"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. Por ejemplo se podría tener el siguiente DataPool:

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 (pepe en el ejemplo). Sin embargo si a ese datapool le defino datos específicos para el caso de prueba entonces utilizará esos datos específicos.

Teniendo en cuenta el DataPool anterior, imaginemos que en nuestros casos de prueba queremos utilizar distintos nombres de usuarios y contraseñas para ingresar al sistema. Entonces creamos el datapool Usuarios tal como se ve en la tabla anterior. 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.

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).

Utilizar datos relacionados (SETID)

Típicamente cuando se piensa o diseña un caso de prueba, se hace por un lado el caso de prueba conceptual y por otro los datos a utilizar para ese caso de prueba. Muchas veces los distintos conjuntos de datos a utilizar están relacionados, por ejemplo porque para un País dado queremos ingresarle las ciudades correspondientes.

Por ejemplo, si se quiere probar el alta país, luego que se tiene definido el caso de prueba conceptual, se puede decidir ejecutar la aplicación con los siguientes conjuntos de datos:

• Conjunto 1: País: Uruguay, Ciudades: Salto, Paysandú,Montevideo y Atlántida
• Conjunto 2: País: Argentina, Ciudades: Rosario, Bariloche, Buenos Aires y Victoria

En este tipo de casos puede ser interesante indicar en GXtest que tenemos un conjunto de datos en distintos datapools relacionados y no utilizar un único DataPool.

Esto se puede hacer con lo que se denomina SETID, identificador de conjunto. En este post se puede ver un ejemplo ilustrativo del uso de este tipo de datapools.

Para realizar ésto simplemente se debe crear un DataPool Paises, un DataPool Ciudades y agregarle a los mismos además de las columnas que interesen para las pruebas una columna llamada SETID.

De esta manera cuando se quiera agregar un conjunto de datos relacionados, se agregará un identificador de ese conjunto en cada fila de datos en los DataPools Paises y Ciudades en la columna SETID. Se debe respetar el siguiente formato:

Datapool master: Paises - SETID son identificadores. Ej: 1, 2, 3.
Datapool relacionado: Ciudades - SETID debe tener un indentificador del master, seguido de un "." (caracter punto) seguido de otro identificador. Ej: 1.1, 1.2, 1.3, 1.4, 2.1, 2.2, 2.3, 3.1

De esa manera se obtendrán los siguientes DataPools con los siguientes datos:

Luego si se utiliza el comando DPNext sobre el DataPool "master" (o sea, Países), provocará que se filtre en los demás datapools por el identificador de conjunto (SETID) al cual se avanzó.

Trabajo compartido - Muchos usuarios accediendo al mismo repositorio

Para poder manejar el acceso simultáneo de una base de datos de GXtest existe un esquema de bloqueo de los elementos sobre los que se está trabajando.

Cada elemento puede estar bloqueado por un usuario, el cual lo está usando, indicando que puede modificarlo y que sería deseable que nadie más lo modifique mientras él lo tenga en "su poder". Luego, cuando lo modifica y lo guarda puede "liberarlo" para que cualquier otro siga trabajando sobre el mismo.

Cuando un elemento está bloqueado cualquiera lo puede abrir en sólo lectura. Cuando alguien crea un elemento automáticamente lo bloquea para sí. Si alguien más quiere modificarlo es posible bloqueándolo explícitamente. Esto es útil si el que lo va a usar sabe que está bloqueado por alguien que realmente no lo está usando.

Para bloquear un elemento, botón derecho sobre el elemento, "Lock".
Para desbloquear un elemento, botón derecho sobre el elemento, "Unlock".

Los elementos que tenemos bloqueados tienen un ícono con fondo transparente, los que no están bloqueados por nadie aparecen con fondo gris, y los que alguien más tiene bloqueados aparecen con fondo rojo.