Difference between revisions of "GXtest Designer User's Manual 1.0"

Revision as of 17:35, 25 November 2009

This page discusses the main functions of GXtest Designer.

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:

1. 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.
2. Creating a new project: Create a project and associate it with the same KBs as the project exported in step 1.
3. 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.

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

Imagen:ImpactKB_Paso2.jpg

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.

Object Level Impact

Imagen:ImpactKB_Paso3.jpg

In this window there are four sections:

• Conflicted objects: This is a list of objects that are used en a Test Case but that cannot be found in the new Test Case. Therefore there are considered to be have a conflict. It is a good idea to match any available objects with objects that have conflicts..
• Suggested objects: when you select a conflicted object it will suggest a list of possible objects
• Resolved conflicts: when you match a conflicted object with a new object the conflicted object will be removed form the list of Conflicted objects and will move to the Resolved conflicts list. As well the available object will be removed from the list of available objects.
• Available objects: Displays a list of the available objects (new objects that have not been matched with a conflicted object)

To match up a conflicted object to an available object, select the conflicted object from the list and then an available or suggested object from the list. Then click Resolved.

Once you have resolved all of the conflicts click the Next button. After clicking Next, all objects that remain in the list of conflicted objects will be deleted. The Test Cases will make reference to a “special" object called MissingObject.

Control Level Impact

Imagen:ImpactKB_Paso4.jpg

This windows displays the objects that have been affected by the changes made. At the top of the window it is possible to navigate through the different objects using the arrow buttons.

Each object has a similar layout to the previous window where you can choose which controls have been renamed o substituted for others.

The controls that remain in the list of Conflicted Controls will be replaced in the Test Cases with the control MissingControl upon clicking the Next button. These Test Cases with missing controls will not be run.

Report

Imagen:ImpactKB_Paso5.jpg

Lastly the report screen displays the results of the changes made.

Test Cases

Within each project there are the Test Cases for the application to be tested. Each Test Case is an automated workflow for an application, which can be used to automate regression tests. See also advice for when to automate.

Test Case Objects

Page

A Page refers to a page of an application and can have a list of actions and a list of validations.

Each page can be associated with a GeneXus object. Test Cases generated with the Recorder will always have the GeneXus object associated and even when you do it manually it is not always necessary to select the object. The only time it is completely necessary to select it is when there is more than one frame in the same window or when there is more that one window (for example a popup) at the time of running a command. In that case you must select the object.

Edge Line

Each Edge Line represents the transition from one page to the next. Each one has exactly one event. It can also have a list of actions and a list of validations.

One perculiarity about edge lines is that they have a specific order. Each Edge Line has a letter that indicates the order in case there is more than one Edge Line for a node. Take for example the folloing case: center

The first time you go to the Home page you will follow the edge line ClickLinkTable, but when you return to that same page a second time you will follow the edge line ClickButton.

Test Case (Inclusion)

A Test Case object allows you to embed a Test Case within another Test Case. This allows you to reuse Test Case models. To see and example of an embedded Test Case consult the following article. When embedding an Test Case within another Test Case you can tell GXtest how many times you want to run the embedded Test Case. This value can be a specific number or it can be taken from a Data Pool. When it is taken from a Data Pool you are able to, for example, vary the quantity of items in a invoice depending on the Data Pool.

Decision

A decision object allows you two follow two different workflows within an application based on certain conditions. For example, if our Test Case sends a notification to a client if he/she is from Uruguay but sends nothing if the client is from another country, we can use a Decision to follow one workflow or another depending on where the client is from.

To see an example using Decision see Creating a Test Case with Bifurcation

Creating a Test Case

A Test Case can be created many ways. It can be done manually or by recording it with GXtest Recorder. GXtest Recorder can record a Test Case two ways: on-line and off-line.

Creating a Test Case manually

To create a Test Case manually, select Add Test Case from the Test Case menu in the project panel.

This creates a Test Case that will remain open in the Models panel. In this new blank page you can begin to model the Test Case. To do so you must draw the workflow to be automated by creating the pages to be visited and connecting them with Edge Lines.

Once the workflow is ready, you must define the commands that will be run for each Edge Line and each Page.

See also list of available commands.

Creating a Test Case with GXtest Recorder

The difference between On-Line and Off-Line is that the former uses GXtest Recorder together with GXtest Designer so that when you record a Test Case it remains in GXtest Designer ready to use. Whereas using the Off-Line method, GXtest Recorder works separately from GXtest designers and generates a file that later must be imported into GXtext Designer.

On-line Method

To record a Test Case using the On-Line method select Record New Test Case form the Test Cases menu. center

This will open a window that allows you to enter a name for the Test Case and the URL where you want to begin to record. Once you click the Record button a new browser window will open where you can begin to perform the necessary actions. Once you have finished the workflow that you want ot automate simply close the browser window.

Off-line Method

As explained before the Off-Line method allows you to create a Test Case without having to have GXtest Designer installed. This will create a ZIP file that can be imported into GXtest Designer.

Once the ZIP file is created you must create a new Test Case by selecting Add Recorded Test Case from the Test Cases menu (in the project Panel).

Then choose the ZIP file created previously.

The advantage to this method is that it is not necessary to have GXtest Designer installed in order to automate, you only have to install the extension in Internet Explorer. This also makes it easier for any user to record a workflow for an application if they need technical support or if they are defining acceptance tests etc. For more details see GXtest Recorder User's Manual.

Test Case Validation

Before running a Test Case you should perform a validation. If a Test Case does not meet all the conditions to run it will not be run. Some of the possible causes for a Test Case to not be able to run are that there are no events on a certain Edge Line or that a connection is missing. To validate a Test Case press Shift+F6 or click the following button in GXtest:

Running a Test Case

In GXtest Designer there a several ways of running a Test Case which are described below.

Simple Running of a Test Case

You can run Test Case once by pressing Shift+F5 or clicking the button shown below center

This will run the open Test Case one time.

Running a Test Case repeatedly

This allows you to run a Test Case as many times as you decide which allows you, for example, to use Data Pools. To repeatedly run a Test Case press Shift+F7 or click the button shown below:

Running a Test Case in an open browser window

This allows you to run a Test Case in a browser window that is already open. To run a Test Case in an open browser press Ctrl+F5 or click the following button:

Advice for working with Test Cases

The following lists a couple pieces of advice concerning editing Test Cases.

• Copy and Paste commands with Drag&Drop: in GXtest its possible to move commands from one element to another by simply dragging them and dropping them. You can also copy commands by holding down the Ctrl key while dragging and dropping.
• Changing the order an element’s associated commands: click on the element in the commands panel and drag the commands placing them in the desired order.

Exporting and Importing a Test Case

This article shows the specific steps for importing and exporting a Test Case. If you would like more detailed information about XML generators and exporting Test Cases you can consult this article.

Sending and Recieving Test Cases between databases

As mentioned in the Login / Connections section, in GXtest it is possible to configure several connections. This allows:

• an easy exchange of Test Cases between databases
• exchange of Test Cases between workstations and the GXtest Manager database

Internally what happens is an export and then an import of the Test Cases into the corresponding databases. To send a Test Case follow these steps:

1. Open GXtest using the connection for the original database
2. Open the project
3. Go to Test Cases > Send & Receive > Send To
4. Select the Test Case that you want to send
5. Choose the data that you want to send it to
6. It will now show the export options (they include Data Pools, recurring Test Cases, etc.) Then click OK
7. It will now show the results of the export. Close the results window when finished.
8. It will now show the results of the import.

To receive a Test Case follow these steps:

1. Open GXtest using the connection for the original database
2. Open the project
3. Go to Test Cases > Send & Receive > Receive From
4. Choose the database that is going to receive the Test Case
5. Then choose the Test Case that is going to be received and the options that you want.
6. You will then see the results of the export and then the results of the import in the local database.

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

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:

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

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:

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.