GXtest Designer User's Manual 1.0
This page discusses the main functions of GXtest Designer.
Contents
|
Introduction
The objective of GXtest Designer is to easily model a Test Case and do the same for application made with GeneXus on different platforms and with different versions of GeneXus.
Test Cases are modeled on an as a diagram made up of a cluster of Nodes and Edge Lines, where the nodes represent the pages of an application and the edge lines represent the events that happen going from one Page to another. These elements (pages and events) can have commands associated with them. There are three types of commands: actions, validations and events. The three types are explained in more detail in the Commands section. In addition, you can include embedded Test Cases in a model to create modules that can be reused. You can also include Decision nodes that choose which action to be taken depending on the result of a Validation. All of these concepts will be explained in more detail in the manual.
GXtest Designer GUI
The image below shows the different parts of the GXtest Designer GUI.
- Main Panel: the main panel displays the Test Cases and the results of their execution. It is the program main work area.
- Projects: This panel contains all project elements such as Test Cases and Data Pools.
- Elements: This panel contains all elements of a Test Case. The elements can be dragged to the main panel in order to build Test Cases.
- Commands: This panel displays the commands (actions, validations and events) of each element of a Test Case .
Besides these four main panels, the image also shows a toolbar used to help build Test Cases as well as the Pan & Zoom feature that allows navigation and zooming within the Test Case.
Login / Connections
hen the GXtest program is run it brings up the following screen:
Imagen:login.jpg
Here it is possible to choose which database GXtest will connect to and with which user you will connect. If user accounts don’t exist in the specified database it is possible to connect with the username Guest.
Connection Management
In the same Login screen, next to the list of databases there are two buttons, the first is used to edit connections and the second adds a new connection. Pressing the + button brings up the following window:
Imagen:AddConnection.jpg
In this window you can indicate:
- The name of the new connection
- The instance of the SQL Server that will be used to connect
- The name of the database
- The authentication mode used to access the Database
Once you have added the connection it will appear in the Login window allowing users to work with different project repositories and Test Cases directly from their machine.
Projects
The first step to begin using GXtest is to create a project. To do this click on Project > New Project. In the new window you can specify the project’s properties.
- Name of the project
- The KBs associated with the project (see also how to import a GeneXus KB)
- Default Browser
- Default URL
The name entered will identify the project. The KBs (Knowledge Bases – GeneXus source code) are the applications to be tested. You can choose a several KBs when an application is made up of more than one for example applications that use GXportal o GXflow. A KB imported into GXtest can only be used in one project and cannot be shared. The default browser that will be used (you can only use Internet Explorer with the beta version). The default URL has two functions:
- First it is used when you begin to record a Test Case, the browser will suggest this URL.
- Second, if a Test Case uses the variable urlHome, (which will be used in tasks done by GXtest Manager), the default URL will be used for this variable. For more information about this property in GXtest Manager see the GXtest Manager Manual.
You can open a project by going to Project > Open Project. If you decide to delete the open project, go to Project > Delete Project. Remember that this will not delete the KBs associated with the project.
Exporting and Importing a project
GXtest allows you to export all the Test Cases of a project and its Data Pools. This allows you to duplicate a project if it is necessary. It important to remember that the export will not export the KBs associated with the project. In order to duplicate a project you must export it and then import it using the following steps:
- To export a project go to Project > Import & Export > Export Project. Here you can choose the project to be exported and where you would like to export the file that contains the exported project. GXtest then opens a new window displaying the test cases and Data Pools that were exported.
- Creating a new project: Create a project and associate it with the same KBs as the project exported in step 1.
- To import the project go to Project > Import & Export > Import Project and select the project created in step 2. GXtest will then ask you to choose the ZIP file that contains the data from the project exported in step 1. When finished, GXtest will display the results of the import.
GXtest and GeneXus KBs
GXtest automates applications by relating user’s actions with the KB’s objects instead of HTML objects like traditional programs do. This allows it to have traceability between Test Cases and to use the Test Cases independently of the technology used similar to using GeneXus.
| Important: Each KB that is imported into GXtest can be associated with only one project, that being so if you create a new project you will only be able to associate with it KBs that are not being used by any other project. |
|---|
Importing a GeneXus KB into GXtest
To work with GXtest you need to import the information from the KB or KBs into the application to be tested. The information needed from the KB are the WebForm controls for Transactions and WebPanels. It doesn’t use anything else related to the programming, events or anything else.
Just go to KB > Add KB. Imagen:ImportarKB.jpg
If you don’t want to import an entire XPZ, you can use the convert function to send only the data needed by GXtest. To do this go to KB > Convert to GXtest.
Note: It is recommended that when importing KBs they should be accessed locally because network access creates a large increase in the response time.
Importing a KB from GeneXus 8 or 9
These kinds of KBs can be imported into GXtest by using an XPZ or GXPublic.
If you want to import it using an XPZ, select File in the Type dropdown box and then choose the location of the file. Imagen:ImportKBFile.jpg
If you want to import using GXPublic, select GX Public from the same drop-down box and then choose the location of the file. Imagen:importKBGXPublic.jpg
Once you have selected the location, the models in the KB are shown and you can select which ones you want to work with.
Importing a KB from GeneXus X or GeneXus X Ev1
If you are working with GeneXus X you must install the GXtest Extension and use it to export a KB. The extension will only export an GXT extension file with the necessary information to be used in GXtest. After this is done the file must be imported into GXtest.
GXtest Extension
GXtest Extension is a GeneXus X extension that allows you to export KBs in GXT format. To install, copy the file [GXtest Extension.dll] for GeneXus U4 (if you need an extension for a different version of GeneXus please contact technical support) into the Packages folder in the GeneXus program files. After restarting GeneXus with the KB open go to Extensions > GXtest. The export will begin and when it is finished it will ask you where you would like to save the exported file.
Updating a KB: Impacting the KB’s change on Test Cases
On you automate a set of tests, the development team will continue developing and changing an application. Therefore it may be necessary to update the information in the KB that GXtest is working with and impact the Test Case. Just go to KB > Refresh.
Choosing a KB
This will open the following window. Imagen:ImpactKB_Paso1.jpg
In this window choose the KB that you want to update of the list of KBs associated with the project.
After you choose the KB press the Next button.
List of objects to be deleted
This window displays all of the objects that are to be deleted because they aren't found in the current KB. These objects aren’t part of any Test Case and therefore can be deleted without any negative effect. These objects may have been deleted or renamed. After review the list click 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.
Impacto a nivel de los Controles
En esta pantalla se van a poder recorrer los distintos objetos que han sido afectados con los cambios. Si se observa en la parte superior se puede navegar por los distintos objetos.
Para cada objeto se tiene un esquema similar al de la pantalla anterior en donde se puede indicar que controles han sido renombrados, o sustituidos por otros.
Aquellos controles que permanezcan en la lista de Conflicted Controls cuando se presione el botón next serán reemplazados en los casos de prueba por el control MissingControl y dichos casos de prueba no podrán ser ejecutados.
Reporte
Por último se muestra un reporte donde se visualiza el resultado de la actualización realiada
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.
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 (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 cuantas 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 items de una factura dependiendo de un DataPool.
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 Add 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 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 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 independientemente 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 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 Designer instalado. El resultado es un archivo ZIP, el cual es importado desde GXtest Designer.
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.
Solo resta seleccionar el archivo ZIP 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 center
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 ejemplos 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:
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:
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
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.
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
| Es importante tener en cuenta que los nombres de los proyectos en los cuales se encuentran los casos de prueba a transferir deben ser iguales. |
|---|
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:
- Entrar en GXtest utilizando la conexión a la Base de Datos origen
- Abrir el proyecto deseado
- Ir a Test Cases-> Send & Receive-> Send To..
- Seleccionar el caso de prueba que se desea enviar
- Seleccionar la Base de Datos a la cual se desea enviar
- 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.
- Se mostrarán los resultados de la exportación. Cerrar la ventana de resultados
- Se mostrarán los resultados de la importación
Para recibir un caso de prueba realizar los siguientes pasos:
- Entrar en GXtest utilizando la conexión a la Base de Datos origen
- Abrir el proyecto deseado
- Ir a Test Cases-> Send & Receive-> Recieve From ..
- Seleccionar la Base de Datos desde la cual se va a recibir
- Luego seleccionar el caso de prueba que se va a recibir y las opciones de con las cuales se desea traer.
- 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 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) 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 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 |
| DPNext | Avanza a la próxima fila del DataPool. Siempre debe hacerse un DPNext antes de comenzar a utilizar el DataPool. Si bien a este comando se le pasa un DataPool y una columna, la columna no tiene ningún efecto sobre el comportamiento del comando. |
| DPReset | Hace que se comience nuevamente desde el principio del datapool. Si bien a este comando se le pasa un DataPool y una columna, la columna no tiene ningún efecto sobre el comportamiento del comando. |
| Eventos | |
| Back | Es análogo a presionar el botón de Atrás en el navegador. |
| 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. |
| PressKey | Simula que el usuario presione una tecla en la pantalla. Por más información de como indicar las distintas teclas mirar la siguiente referencia |
| 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 |
| DPCompare | Compara el valor de un DataPool contra otro valor |
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.
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. Si bien a este comando se le pasa un DataPool y una columna, la columna no tiene ningún efecto sobre el comportamiento del comando.
- DPReset: Hace que se comience nuevamente desde el principio del datapool. Si bien a este comando se le pasa un DataPool y una columna, la columna no tiene ningún efecto sobre el comportamiento del comando.
- 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:
| Scope | Nombre | Contraseña |
|---|---|---|
| Global | pepe | pepe |
| CasoA | juan | juan |
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 dato 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).
| 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. |
|---|
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 ejercitar la aplicación con los siguientes conjuntos de datos:
- Conjunto 1: País: Uruguay, Ciudades: Salto, Paisandú,Montevideo y Atlantida
- 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 esto 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. Luego se deberá agregar un DataPool llamado DATASETS el cual tendrá una única columna llamada SETID. De esta manera cuando se quiera agregar un conjunto de datos relacionados, se agregará un identificador de ese conjunto en el DataPool DATASETS y luego por cada fila de datos en los DataPools Paises y Ciudades se pondrá en la columna SETID el identificador correspondiente.
De esa manera se obtendrán los siguientes DataPools con los siguientes datos:
| DATASETS | Paises | Ciudades | ||
|---|---|---|---|---|
| SETID | SETID | NombrePais | SETID | NombreCiudad |
| 1 | 1 | Uruguay | 1 | Montevideo |
| 2 | 2 | Argentina | 1 | Salto |
| 3 | 3 | Brasil | 1 | Paysandú |
| 1 | Canelones | |||
| 2 | Buenos Aires | |||
| 2 | Rosario | |||
| 2 | Bariloche | |||
| 3 | Sao Paulo | |||
Luego si se utiliza el comando DPNext sobre el DataPool DATASETS, esto provocará que se filtre en los demás datapools por el identificador de conjunto (SETID) al cual se avanzó en la tabla DATASETS.
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.
