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

From GXtest Wiki
Jump to: navigation, search
(→‎Impacto a nivel de los Controles)
m (Sebagra moved page GXtest Designer User's Manual to GXtest Designer User's Manual 1.0 without leaving a redirect: New version of GXtest Designer User's Manual)
 
(82 intermediate revisions by 6 users not shown)
Line 1: Line 1:
−
[[category:Guías de GXtest]]
+
{{Idiomas
−
This page discusses the main functions of GXtest Designer.
+
| Manual de Usuario de GXtest Designer
 +
| GXtest Designer User's Manual
 +
}}
 +
[[category:GXtest Guides]]
 +
This page discusses the main features of GXtest Designer.
  
 
== Introduction ==
 
== Introduction ==
Line 23: Line 27:
  
 
== Login / Connections ==
 
== Login / Connections ==
−
hen the GXtest program is run it brings up the following screen:<br>
+
When the GXtest program is run it brings up the following screen:<br>
−
[[Imagen:login.jpg]]
+
[[image:login.jpg| center]]
  
 
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.  
 
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.  
Line 30: Line 34:
 
=== Connection Management ===
 
=== 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: <br>
 
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: <br>
−
[[Imagen:AddConnection.jpg]]
+
[[image:AddConnection.jpg| center]]
  
 
In this window you can indicate:  
 
In this window you can indicate:  
Line 37: Line 41:
 
* The name of the database  
 
* The name of the database  
 
* The authentication mode used to access 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.  
+
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 ==
 
== Projects ==
Line 48: Line 52:
 
[[image:createNewProject.jpg|center]]
 
[[image:createNewProject.jpg|center]]
  
−
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:  
+
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 (this version allows you just to use Internet Explorer). The default URL has two functions:  
 
* First it is used when you begin to record a Test Case, the browser will suggest this URL.  
 
* 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 [[Manual_de_Usuario_de_GXtest_Manager#Application_Settings | GXtest Manager Manual]].
+
* 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 User's Manual#Application_Settings | GXtest Manager Manual]].
  
 
You can open a project by going to Project > Open Project.  
 
You can open a project by going to Project > Open Project.  
Line 56: Line 60:
  
 
=== Exporting and Importing a 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.  
+
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 is 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:  
 
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.   
 
# 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.   
Line 63: Line 67:
  
 
== GXtest and GeneXus KBs ==
 
== 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.
+
GXtest automates applications by relating user’s actions with the KB’s objects instead of HTML objects like traditional testing tools 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.
  
 
{| border="1" cellpadding="5" cellspacing="0" align="center"
 
{| border="1" cellpadding="5" cellspacing="0" align="center"
Line 73: Line 77:
  
 
Just go to KB > Add KB.   
 
Just go to KB > Add KB.   
−
[[Imagen:ImportarKB.jpg]]
+
[[image: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.
 
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.
Line 79: Line 83:
 
Note: It is recommended that when importing KBs they should be accessed locally because network access creates a large increase in the response time.  
 
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, GXPublic, GXBL, or .gxt file.  
−
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.
+
[[image:ImportKBFile.jpg|center]]
−
[[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.
+
Choose the location and the file type: (gxt, gxw o gxt)<br>
−
[[Imagen:importKBGXPublic.jpg]]
+
In GeneXus 8 or 9 you can use xpz files, gxw files (its in the KB folder) or a gxt file (gxt file its a XML file that contains only the KB that GXtest use).<br>
 +
In GeneXus X o higher you can use a gxt file or gxw file.
  
−
Once you have selected the location, the models in the KB are shown and you can select which ones you want to work with.
+
[[image:AddKBFileTypes.jpg|center]]
  
−
==== Importing a KB from GeneXus X or GeneXus X Ev1 ====
+
Once you have selected the type and location, click Ok.
−
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 =====
−
GXtest Extension is a GeneXus X extension that allows you to export KBs in GXT format. To install, copy the file [[ftp://guest_abstracta.com.uy:guest_@abstracta.com.uy/Extension/GXtest%20Extension.dll 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.
+
GXtest Extension is a GeneXus X extension that allows you to export KBs in GXT format.<br>
 +
Note: extension installation is optional, GXtest can connect to KB directly.<br>
 +
To install it, copy the ''GXtest Extension.dll'' file located in the GXtest Designer installation folder to Packages in GeneXus directory. After restarting GeneXus, go to Extension Manager in Genexus an check in the extension name. Then restart GeneXus again and open the KB and 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.<BR>
  
−
=== Updating a KB: Impacting the KB’s change on Test Cases ===
+
You can also download this extension in GeneXus Marketplace.
−
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 ====
+
=== Modify Knowledge Base Properties ===
−
This will open the following window.
+
Sometimes you need to change the path to the KB in order to update it (when select "Refresh KB" GXtest uses the same path that you selected at the moment of importing the KB).  
−
[[Imagen:ImpactKB_Paso1.jpg]]
+
To do that (with the Project already opened), go to KB menu and select "Edit Properties". Then select the KB and insert the new path.
  
−
In this window choose the KB that you want to update of the list of KBs associated with the project.  
+
=== Updating your 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 the menu Knowledge Base -> Update KB Information.  
  
−
After you choose the KB press the Next button.
+
You can see an entire example of KB update here: [[Impact on Test Cases when the GX KB changes | Impact on Test Cases when the GX KB changes]]
  
−
==== List of objects to be deleted ====
+
=== Use KB that uses GXFlow or GXPortal ===
−
[[Imagen:ImpactKB_Paso2.jpg]]
+
When your application uses GXPortal (in Genexus 8, 9, X or higher) or GXFlow (in GeneXus X o higher) you need to bind those KBs to the project. The GXtest project must be binded to the application KB plus the GXFlow's KB and/or GXPortal's KB. The metadata of GXFlow's KB for the GeneXus Ev1 is [[Media:gxflowEV1.zip|here]].
  
−
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.  
+
If you don't do that, GXtest is going to fail trying to record or execute test cases who need references to objects from those KBs.
  
−
==== Object Level Impact ====
+
== Test Cases ==
−
[[Imagen:ImpactKB_Paso3.jpg]]
+
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]].
  
−
In this window there are four sections:
+
=== Test Case Objects ===
−
* 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.. 
+
==== Page ====
−
* Suggested objects: when you select a conflicted object it will suggest a list of possible objects
+
A Page refers to a page of an application and can have a list of actions and a list of validations.  
−
* 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.  
+
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. When there are more than one frame in the same window or when there are more than one window (for example a popup) at the time of running a command, in those cases you must select the object.
 +
In addition, while it is running a validation is performed that the page corresponds to the object defined on the page (with the command CheckMainObject).
  
−
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.
+
==== 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.
  
−
==== Control Level Impact ====
+
One peculiarity 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:
−
[[Imagen:ImpactKB_Paso4.jpg]]
+
[[image:PageWithMultipleEdges.jpg|center]]
  
−
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.
+
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.
  
−
Each object has a similar layout to the previous window where you can choose which controls have been renamed o substituted for others.
+
==== Test Case (Inclusion)====
 +
A Test Case object allows you to embed a Test Case within another Test Case (modularize). This allows you to reuse Test Case models. To see and example of an embedded Test Case consult the following [[Crear un Caso de Prueba Anidado | 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.
  
−
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.
+
An important aspect to highlight is that a failure of the execution of one of the iterations of an included test case that is configured to stop the execution when fails, it also will stop the execution of the test case that includes it.
  
−
==== Reporte ====
+
==== Decision ====
−
[[Imagen:ImpactKB_Paso5.jpg]]
+
A decision object allows you to 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.  
  
−
Por último se muestra un reporte donde se visualiza el resultado de la actualización realiada
+
To see an example using Decision see  [[Crear un Caso de Prueba con Bifurcación| Creating a Test Case with Bifurcation]]
  
−
== Casos de Prueba ==
+
=== Creating a Test Case ===
−
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 [[Por qué Automatizar?| los consejos de cuándo automatizar]].
+
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.  
  
−
=== Objetos de un caso de Prueba ===
+
==== Creating a Test Case manually ====
−
==== Page ====
+
To create a Test Case manually, select ''Create New Test Case'' from the Test Case menu in the project panel.  
−
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.
+
[[image:Record_test_case.jpg|center]]
  
−
==== Edge Line ====
+
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.
−
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.
+
Once the workflow is ready, you must define the commands that will be run for each Edge Line and each Page.
−
De esta manera si tenemos por ejemplo el siguiente caso:
+
−
[[Imagen:PageWithMultipleEdges.jpg|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.
+
See also list of [[#Commands|available commands]].
  
−
==== Test Case (Anidación)====
+
{| border="1" cellpadding="5" cellspacing="0" align="center"
−
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 [[Crear un Caso de Prueba Anidado | siguiente]] artículo.
+
! style="background:#efefef;" | The Drag and Drop commands allow for easy construction of Test Cases in the Model editor, it is possible to simply drag and drop commands between different components (Edge Lines and Pages). This allows you to move or copy if you hold down the Control key.  
−
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 ====
+
==== Creating a Test Case with GXtest Recorder ====
−
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.<br>
+
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.  
−
Para ver un ejemplo sobre Decision consultar [[Crear un Caso de Prueba con Bifurcación]]
+
  
−
=== Crear un Caso de Prueba ===
+
===== On-line Method =====
−
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.
+
To record a Test Case using the On-Line method select ''Record New Test Case'' form the Test Cases menu.
  
−
==== Crear un Caso de Prueba Manualmente ====
+
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.
−
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''.
+
  
−
[[image:AddTC.jpg|center]]
+
===== 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 or XML (since v1.1.4) file that can be imported into GXtest Designer.  
  
−
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.  
+
Once the ZIP/XML file is created you must create a new Test Case by selecting ''Import'' from the Test Cases menu (in the project Panel).  
  
−
Luego de tener el flujo listo, hay que definir los comandos que se quieren ejecutar en cada arista y en cada nodo.
+
Then choose the ZIP/XML file created previously.  
  
−
Véase también [[#Comandos|la lista de comandos disponibles]].
+
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]].
  
−
{| border="1" cellpadding="5" cellspacing="0" align="center"
+
=== 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:
−
! style="background:#efefef;" | 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 ====
+
[[Image:BotonValidarTC.jpg|center]]
−
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 =====
+
=== Running a Test Case ===
−
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''
+
In GXtest Designer there a several ways of running a Test Case which are described below.
−
[[Imagen:MenuRecordNewTC.jpg|center]]
+
==== Simple Running of a Test Case ====
 +
You can run Test Case once by pressing Shift+F5 or clicking the button shown below
  
−
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.
+
[[image:ejecutar.JPG|center]]
−
Una vez que se termine de recorrer el flujo que se desea automatizar se debe simplemente cerrar el navegador.
+
  
−
===== Mecanismo Off-line =====
+
This will run the open Test Case one time.
−
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''.
+
==== 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:
  
−
[[image:addRecordedTC.jpg|center]]
+
[[Image:BotonEjecutarN.jpg|center]]
  
−
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.
+
''Note: When you run N times, after each execution GXtest will close all open windows of the browser selected for execution.''
  
−
Por más detalles ver [[Manual de Usuario de GXtest Recorder]].
+
==== Running a Test Case in an opened 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:
  
−
=== Validación de un caso de prueba ===
+
[[Image:BotonPlayInIE.jpg|center]]
−
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:
+
−
[[Image:BotonValidarTC.jpg]]
+
  
−
=== Ejecución de un caso de prueba ===
+
Note: If you are using Firefox browser (GXtest 1.1 or upper) this functionality can only be used with browser instances opened for GXtest or setted to start with-jssh.
−
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
+
−
[[Imagen:ejecutar.JPG|center]]
+
  
−
De esa forma el caso de prueba abierto se ejecuta una sola vez.
+
==== Execution in FireFox (from version 1.1) ====
 +
To run tests over Firefox you must install the Firefox Extension that can be found over GXtest installation folder : GXtest Designer\Firefox.
  
−
==== Ejecución repetida de un caso de prueba ====
+
"C:\Program Files (x86)\Abstracta\GXtest Designer\Firefox\mozrepl-jssh.xpi"
−
Permite ejecutar un caso de prueba tantas veces como se indique. Esto permite por ejemplos probar el uso de los DataPools.
+
To find a way to install Firefox extensions you may want to take a look at: http://www.wikihow.com/Install-Firefox-Extensions
−
Para ejecutar el caso de prueba de manera repetida presionar Shift+F7 o presionar el botón que se muestra a continuación:
+
−
[[Image:BotonEjecutarN.jpg]]
+
  
−
==== Ejecutar en un navegador Abierto ====
+
Para versiones de firefox inferior a 4: 2, 3, 3.5 and 3.6, you should download the plug-in jssh and install it. The plugin can be downloaded at the following links:
−
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:
+
* [[Media:jssh-WINNT-2.x.xpi  |Jssh for Firefox 2.0]]
−
[[Image:BotonPlayInIE.jpg]]  
+
* [[Media:jssh-20080708-WINNT.xpi |Jssh for Firefox 3.0]]
 +
* [[Media:jssh-3.5.x-WINNT.xpi |Jssh for Firefox 3.5]]
 +
* [[Media:jssh-3.6.x-WINNT.xpi |Jssh for Firefox 3.6]]
 +
 +
Then to tell GXtest Desginer to run using FireFox, change the project properties to the type of browser FireFox.
  
−
=== Consejos para trabajar con los casos de prueba ===
+
Note: We recommend disabling automatic updates and "Set as default" dialog in FireFox to avoid failures in the test cases due to this reason.
−
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 [[Exportar e Importar un TestCase|este]] articulo se muestran las particularidades de importar y exportar un Test Case.
+
{| border="1" cellpadding="5" cellspacing="0" align="center"
−
Por otro lado si se quiere conocer con mayor detalle los xml generados al exportar un Test Case se pude consultar en [[Test Cases - XML|este]] articulo.
+
|-
 +
! style="background:#efefef;" | Important: while running a test case in any browser, GXtest is going to close automaticaly any popup like "do you want to activate autocomplete" or similar ones.
 +
|}
  
 +
=== 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.
  
−
=== Enviar y Recibir Casos de prueba entre diferentes Bases===
+
=== Exporting and Importing a Test Case ===
 +
This [[Exporting_and_Importing_a_Test_Case|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 [[Test Cases in XML|article]].
  
−
Como se menciona en la sección [[#Login / Conexiones | Login / Conexiones]], en GXtest es posible configurar varias conexiones. Esto permite :
+
=== Sending and Recieving Test Cases between databases ===
−
* intercambiar de manera sencilla casos de prueba entre las diferentes bases
+
As mentioned in the Login / Connections section, in GXtest it is possible to configure several connections. This allows:  
−
* intercambiar casos entre las estaciones de trabajo y la base de GXtest Manager
+
* an easy exchange of Test Cases between databases
 +
* exchange of Test Cases between workstations and the GXtest Manager database
  
 
{| border="1" cellpadding="5" cellspacing="0" align="center"
 
{| border="1" cellpadding="5" cellspacing="0" align="center"
 
|-
 
|-
−
! style="background:#efefef;" | 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.
+
! style="background:#efefef;" | It is important to keep in mind that the names of the projects that contain the Test Cases that are to be transferred ought to be the same.  
 
|}
 
|}
  
−
Internamente lo que se realiza es una exportación e importación de los casos de prueba en las bases correspondientes.
+
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:
 +
# Open GXtest using the connection for the original database
 +
# Open the project
 +
# Go to Test Cases > Send & Receive > Send To
 +
# Select the Test Case that you want to send
 +
# Choose the data that you want to send it to
 +
# It will now show the export options (they include Data Pools, recurring Test Cases, etc.) Then click OK
 +
# It will now show the results of the export. Close the results window when finished.
 +
# It will now show the results of the import.
  
−
Para enviar un caso de prueba se deben realizar los siguientes pasos:
+
To receive a Test Case follow these steps:  
−
# Entrar en GXtest utilizando la conexión a la Base de Datos origen
+
# Open GXtest using the connection for the original database
−
# Abrir el proyecto deseado
+
# Open the project
−
# Ir  a Test Cases-> Send & Receive-> Send To..
+
# Go to Test Cases > Send & Receive > Receive From
−
# Seleccionar el caso de prueba que se desea enviar
+
# Choose the database that is going to receive the Test Case
−
# Seleccionar la Base de Datos a la cual se desea enviar
+
# Then choose the Test Case that is going to be received and the options that you want.  
−
# 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.
+
# You will then see the results of the export and then the results of the import in the local database.
−
# 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:
+
== Commands ==
−
# Entrar en GXtest utilizando la conexión a la Base de Datos origen
+
Commands allow you to express the interactions that you want an application to perform as well as validations of the expected state of an application after each of the interactions. Commands can be actions, validations and events. Each of these can have parameters that indicate when they should run within an application.  
−
# 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 ==
+
Actions are done by a user within a webpage and don’t move you to another page. Some examples of actions are FillInput (to insert a value into a field on the page) and Check (to tick a checkbox).  
−
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 [[Glosario#Pagina Web|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).  
+
There are also events that are interactions that cause you to move from one page to another. Some example of events are Go (the same as typing a URL into a browser), ClickLink (used to click a link within a page) and ClickButton (used to click a specific button).  
  
−
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).
+
Lastly there are validations which are used to validate that the resulting state of an application is what was expected. Some examples of validations are AppearText (checks if a text is present or not) or VerifyControlText (compares the value of a control on the screen with a reference value). Validations always have two mandatory parameters in addition to their other parameters.
 +
* Error Description Parameter: this is shown if a validation fails and describe why the failure occurred.
 +
* Negation Description Parameter: this shows that the expected result is the negation of the validation. For example if you negate the validation AppearText it says that you don’t want a certain text to appear. 
  
−
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).
+
=== Parameters ===
−
A todas las validaciones tienen siempre además de los parámetros propios de cada validación,  dos parámetros obligatorios:
+
Each command recieves a list of parameters. The kinds of parameters that a command can have are described below:  
−
* 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.
+
==== Control Parameter ====
−
* 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.
+
This kind of parameter is used to create a control within a GeneXus object. Transaction and WebPanel objects in GeneXus have an associated WebForm, this WebForm has an associated set of controls that specify the information to be shown and the interaction that the user can have with the object. For example, a button or a field where you can enter values are controls within a WebForm object.  
−
 
+
−
 
+
−
 
+
−
=== 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''====
+
==== Value Parameter ====
−
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.
+
Value parameters refer to a fixed value, be it text or a number, that you want to use in a command.  
  
−
==== ''Parámetro Variable''====
+
==== Variable Parameter ====
−
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)
+
GXtest allows you to capture values returned by an application and store them as variables. These variables are then used in other commands. (See [[Creating a Test Case with Variables]] for more information.) There is a standard variable called urlHome that uses the value defined in the project’s URL property when the Test Case is ran with GXtest Designer or that uses the value defined by the [[GXtest Manager User's Manual#Application_Settings|URL property]] associated with the task when it is run with GXtest Manager.
−
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 [[Manual_de_Usuario_de_GXtest_Manager#Application_Settings| propiedad url]] asociada a la tarea en caso de ejecutarse desde GXtest Manager
+
  
−
==== ''Parámetro DataPool''====
+
==== Data Pool Parameter ====
−
Los [[#Data Pools| 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.
+
Data Pools allow you to use external data in a Test Case. Data Pool parameters allow you to tell a command to take values from a specific data source.
  
−
==== ''Parámetro SelectionByRow'' ====
+
==== SelectionByRow Parameter ====
−
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.
+
Commands that are run within tables have a parameter the tells them which row within a table they should use to run an action. This parameter referred to generically as SelectionRule can actually be two types SelectionByRow or SelectionByControl. SelectionByRow is used to specify the row where the action will take place and is indicated by the row number. In this way you can model in GXtest actions such as “Click on the first row of the grid.” Because of this the parameter has a Data Pool subparameter, value or variable.
−
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".
+
This parameter can be a positive number which indicates the row (where the first row is referenced by number 1). If you want to select the last row you can use the keyword "last" instead of a number.
−
Por este motivo este parámetro recibe un subparámetro de tipo DataPool, Valor o Variable.
+
  
−
==== ''Parámetro SelectionByControl'' ====
+
==== SelectionByControl Parameter ====
−
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.
+
The SelectionByControl parameter is used to specify the row in table to be used based on a value in one of its columns. For example you can tell GXtest to select the row which contains Employee Number 59. GXtest will search the table and select the row with the first instance that matches the established criteria. This parameter has two subparameters:  
−
Para esto este parámetro recibe dos subparámetros:
+
* Control Type Parameter indicates the column where GXtest will begin to search for the established criteria
−
* Parámetro del Tipo Control: indica la columna en la grilla sobre la cual se va a analizar la condición
+
* Type of Comparison and comparer indicates if what is to be compared is text or a number and the comparison that will be used (equal to, more then, less than, contains, etc.)  
−
* 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.)
+
* Variable Type Parameter, Data Pool or Value: it’s the value that is going to be compared.
−
* Parámetro del tipo Variable, DataPool o Valor: es el valor con el cual se va a comprar.
+
  
−
=== Lista de Comandos ===
+
=== List of Commands ===
 
{| border="1" cellpadding="5" cellspacing="0" align="center"
 
{| border="1" cellpadding="5" cellspacing="0" align="center"
 
|-
 
|-
−
! style="background:#efefef;" colspan="2" | Acciones
+
! style="background:#efefef;" colspan="2" | Actions
 
|-
 
|-
−
| Check  || Permite tildar o marcar un CheckBox
+
| Check  || Allows you to tick or check a CheckBox
 
|-
 
|-
−
| CheckTable  || Análogo al Check pero para un control que se encuentre dentro de una tabla
+
| CheckTable  || Same as Check but used for controls that are located in tables
 
|-
 
|-
−
| Choose || Permite seleccionar una opción de un RadioButton
+
| Choose || Allows you to select an option from a RadioButton
 
|-
 
|-
−
| FillInput || Sirve para ingresar un valor en un campo
+
| Concatenation || Allows concatenation of fixed values, variables and values from DataPools
 
|-
 
|-
−
| FillInputTable || Sirve para ingresar un valor en un campo dentro de una tabla
+
| Execute || Execute a process (exe, bat, etc)
 
|-
 
|-
−
| GetValue || Permite obtener un valor devuelto por la aplicación y almacenarlo en una variable para luego ser utilizado en otro comando.
+
| FillInput || Used to insert a value into a field
 
|-
 
|-
−
| GetValueTable  || Análogo a GetValue pero para un valor que se encuentra dentro de una tabla
+
| FillInputTable || Used to insert a value into a field within a table
 
|-
 
|-
−
| Select || Permite seleccionar un valor de una lista de valores (combobox)
+
| GetValue || Allows you to obtain a value returned from an application and store it in a variable to later be used in another command
 
|-
 
|-
−
| SelectTable || Permite seleccionar un valor de una lista de valores (combobox) que se encuentra dentro de una tabla
+
| GetValueTable  || Same as GetValue but used for values that are located in tables
 
|-
 
|-
−
| SelectRow  || Permite seleccionar una fila en una table.
+
| Pause || Sleep the execution for some time. You should indicate the length of the pause in miliseconds
 
|-
 
|-
−
| UnCheck  || Permite des-tildar o desmarcar un CheckBox
+
| PressKey || Simulates a keystroke made by a user.  For more information on how to specify different keys see the following [http://msdn.microsoft.com/en-us/library/8c6yea83(VS.85).aspx reference]
 
|-
 
|-
−
| UnCheckTable || Análogo al UnCheck pero para un control que se encuentre dentro de una tabla
+
| Random || Generates random sequences of numbers and characters of a given length
 
|-
 
|-
−
| 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.
+
| SelectCombo || Allows you to select a value from a list of values (combobox)
 
|-
 
|-
−
| 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.
+
| SelectComboInTable || Allows you to select a value from a list of values (combobox) that are found within a table
 
|-
 
|-
−
! style="background:#efefef;" colspan="2" | Eventos
+
| Summarize || Summarize a group of values
 
|-
 
|-
−
| Back || Es análogo a presionar el botón de Atrás en el navegador.
+
| SelectRow  || Allows you to select a row in a table
 
|-
 
|-
−
| Go || Es análogo a introducir una dirección web (URL) en el navegador.
+
| SetGridContext || Allows you to execute actions over controls in grids within grids. You can find more information in [[Inputs in Grids within Grids]].
 
|-
 
|-
−
| GoAndLogin || Es análogo al comando Go pero aparte permite ingresar usuario y contraseña para las aplicaciones que así lo requieran.
+
| UnCheck  || Allows you to uncheck a CheckBox
 
|-
 
|-
−
| 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 [http://msdn.microsoft.com/en-us/library/8c6yea83(VS.85).aspx referencia]
+
| UnCheckTable ||Same as UnCheck but used for controls that are located in tables
 
|-
 
|-
−
| Click || Hace un clic en un control GeneXus.
+
| DPNext || Move to the next row of a Data Pool. You should always use DPNext before you begin to use a Data Pool, indicating the name of Data Pool
 
|-
 
|-
−
| 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.
+
| DPReset || Returns to the beginning of a Data Pool.  
 
|-
 
|-
−
| ClickInTable || Permite realizar un clic en un control que se encuentra en una tabla.
+
| DragAndDrop || Drag a control to another one
 
|-
 
|-
−
| ClickPrompt || Permite abrir un prompt para seleccionar los valores desde una lista.
+
| StoreValue || Save a value or variable inside one DataPool in execution time
 
|-
 
|-
−
| ClickPromptInTable || Análogo al anterior pero para campos que aparecen en una tabla.
+
! style="background:#efefef;" colspan="2" | Events
 
|-
 
|-
−
| ClickPortalMenu || Permite ingresar a un menú especifico de una aplicación desarrollada con GXPortal.
+
| Back || The same as clicking the Back button in a browser
 
|-
 
|-
−
| 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.
+
| Go || The same as typing a web address (URL) into a browser
 
|-
 
|-
−
| LoginPortal || Permite logearse en una aplicación que utiliza GXPortal para la seguridad.
+
| GoAndLogin || The same as the Go command except that it allows you to enter a username and password for applications that require it
 
|-
 
|-
−
| 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).
+
| Click || Clicks on a GeneXus control
 
|-
 
|-
−
| Close || Cierra una ventana.
+
| ClickLinkByCaption || Clicks on a link. The difference between this event and the previous is that sometimes because of how an application is constructed the same control has more than one name. In these cases ClickLinkByCaption is used to specify the name of the link to be controlled
 
|-
 
|-
−
| DummyEvent || No realiza nada. Se utiliza para pasar de una página a otra sin realizar ningun evento.
+
| ClickMenu ||Allows you to click in a menu item
 
|-
 
|-
−
! style="background:#efefef;" colspan="2" | Validaciones
+
| ClickTable || Allows you to click on a control that is located in a table
 
|-
 
|-
−
| 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.
+
| ClickPrompt || Allows you to open a prompt to select values from a list
 
|-
 
|-
−
| TableOrderedBy || Chequea que la tabla este ordenada por una columna dada
+
| ClickPromptInTable || The same as the above except for fields that are located in a table
 
|-
 
|-
−
| TableRowsNumber || Chequea la cantidad de filas de una tabla
+
| ClickPortalMenu || Allows you to open a specific menu of an application developed with GXPortal
 
|-
 
|-
−
| VerifyControlEnable || Verifica que un control este habilitado
+
| ClickToolbarButton || Allows you to click on a toolbar button in an application made with GeneXus X and that uses a User Control with ExtJS
 
|-
 
|-
−
| VerifyControlVisible || Verifica que un control este visible
+
| LoginPortal || Allows you to login to an application that uses GXPortal for security
 
|-
 
|-
−
| VerifyControlText || compara el valor que muestra un control con otro valor
+
| ClickTree || Allows you to open a menu developed with ExtJS TreeMenu (in an application made with GeneXus X and that uses a User Control with ExtJS)
 
|-
 
|-
−
| VerifyControlTable || Idem al VerifyControlText pero para un control dentro de una tabla
+
| Close || Closes a window
 
|-
 
|-
−
| DPCompare || Compara el valor de un DataPool contra otro valor
+
| PressKey || Idem to the action, but for those keys that produces a transition to other page (like an enter) 
 +
|-
 +
| DummyEvent || Does nothing. Used to go form one page to another without performing an event
 +
evento.
 +
|-
 +
|SeleniumCommand || Allows to define Selenium commands for execute in GXtest.
 +
|-
 +
! style="background:#efefef;" colspan="2" | Validations
 +
|-
 +
| AppearText || Checks if a specific text is or is not on the screen. It can also be used for validations performed by Ajax. If it indicates a GeneXus object associated with the node where the command is being run, it will search the text in the frame that contains this object.  If it is not indicated then it will look in the main frame
 +
|-
 +
| IsItemInList || Verifies if an especific item exists in a list of items
 +
|-
 +
| TableOrderedBy || Checks to see if a table is sorted by a given column
 +
|-
 +
| TableRowsNumber || Checks the number of rows of a given table
 +
|-
 +
| VerifyColumnVisible || Verifies if a column is visble in a grid
 +
|-
 +
| VerifyControlEnable || Verifies that a control is enabled
 +
|-
 +
| VerifyControlEnableTable || Same as VerifyControlEnable but used for controls that are found in a table
 +
|-
 +
| VerifyControlVisible || Verifies that a control is visible
 +
|-
 +
| VerifyControlVisibleTable || Same as VerifyControlVisible but used for controls that are found in a table
 +
|-
 +
| VerifyControlFocus || Verifies if the current application focus is in the right control
 +
|-
 +
| VerifyControlFocusTable || Same as VerifyControlFocus but used for controls that are found in a table
 +
|-
 +
| VerifyControlText || Compares a value displayed by a control with another value
 +
|-
 +
| VerifyControlTextTable || Same as VerifyControlText but used for controls that are found in a table
 +
|-
 +
| VerifyControlValidation* || Compares a value displayed in a balloon in a control
 +
|-
 +
| VerifyControlValidationTable* || Similar to VerifyControlValidation  but used for controls within grids
 +
|-
 +
| AppearBalloon* || Checks if a balloon appears on a control
 +
|-
 +
| AppearBalloonTable* || Similar to AppearBalloon but used for controls within grids
 +
|-
 +
| Equals|| Compares each other two Data Pool, Variables or values
 +
|-
 +
| VerifyItemsInList || Checks the list of elements in a list
 +
|-
 +
| VerifyItemsInListTable || Same as VerifyItemsInList but used for controls within grids
 +
|-
 +
| VerifyItemsInSuggestion || Checks the list of elements in a input suggestion list.
 +
|-
 +
| VerifyItemsInSuggestionTable || Same as VerifyItemsInSuggestion but used for controls within grids
 
|}
 
|}
  
−
Algunas consideraciones:
+
'''* When execute a command above a balloon, GXtest waits to disappear the balloon to continue with the next command to execute.'''
−
* Considerar que las validaciones con String NO son [http://es.wikipedia.org/wiki/Case_sensitive Case Sensitive].
+
  
−
== Data Pools ==
+
=== Custom Commands===
−
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.
+
Sometimes extra features are developed to improve the user interface, using Javascripts or HTML by hand. In those cases GXtest it is not going to recognice the commands over these controls, and it is necessary that the user prepare his own GXtest commands. To do that you can use "Custom Commands". To learn more about it check [[Creating a Custom Command]].
−
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.
+
=== Use a command to invoke a Genexus Procedure ===
 +
Many times it is very useful to invoke a Genexus Procedure to manage data or validations over that data. To learn more about it check [[Creating a command to use a GeneXus Procedure]].
 +
 
 +
 
 +
== Data Pools ==
 +
A Data Pool is a set of data that can be used in a Test Case. For example if we want to make a Test Case that enters into the system 100 new clients we can create a Data Pool called Clients that contains their name, ID number and telephone number. If you create a Test Case that uses the Data Pool to insert values into an application, every time that it is run the Test Case will use a different piece of data from the Data Pool. To see how to create a Data Pool and a Test Case that uses it see the page [[Crear un Caso de Prueba con DataPools| Creating a Test Case with Data Pools]].  
  
−
=== Comandos asociados a los DataPools ===
+
Data Pools are used in GXtest testing when working with data. They can be used not only to enter data into an application but also to validate the expected results of an application in order to choose which action to be performed.  
−
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 ===
+
=== Commands associated with Data Pools ===
 +
The majority of the commands can have parameters from Data Pools but there are also certain commands specific for Data Pools which are the following:
 +
* DPNext Move to the next row of a Data Pool. You should always use DPNext before you begin to use a Data Pool, indicating the name of Data Pool
 +
* DPReset Returns to the beginning of a Data Pool.
 +
* DPCompare: it is a validation type command that is used to compare a value from a Data Pool con another value
  
−
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.  
+
=== Scope of the data ===
−
Por ejemplo se podría tener el siguiente DataPool:
+
An important concept within a Data Pool is the scope or the hierarchy of the data stored in a Data Pool. The scope can be of two types Global or by Test Case. For example you could have the following Data Pool:  
  
 
{| class="wikitable" border="0"
 
{| class="wikitable" border="0"
 
|-
 
|-
 
! ''Scope''
 
! ''Scope''
−
! ''Nombre''
+
! ''Name''
−
! ''Contraseña''
+
! ''Password''
 
|-
 
|-
 
| ''Global''
 
| ''Global''
Line 428: Line 472:
 
| pepe
 
| pepe
 
|-
 
|-
−
| ''CasoA''
+
| ''Case A''
 
| juan
 
| juan
 
| 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.
+
If you use a Data Pool in a Test Case that doesn’t have specific data assigned to it, you will use the global data (pepe in the example). Nevertheless if you assign specifc data to a Test Case then it will use that data.  
  
−
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.
+
Keeping in mind the previous Data Pool, imagine that in our Test Case we want to use different names and passwords to access a system. You can create a Data Pool called Users similar to the previous example. Assume now that the majority of the Test Cases use the username pepe and the password pepe and there is only one Test Case (Case A) that uses the username juan and the password juan. In order to resolve this issue you must enter the username pepe and the password pepe as global data and the username juan is entered as specifc to Case A.  
  
−
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).
+
If you use this Data Pool in Test Case Case B, it will return the value (pepe,pepe) which are the global values, but if you use it in Case A, it will return the value (juan,juan).
  
 
{| border="1" cellpadding="5" cellspacing="0" align="center"
 
{| border="1" cellpadding="5" cellspacing="0" align="center"
 
|-
 
|-
−
! style="background:#efefef;" | 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.
+
! style="background:#efefef;" | Important: if a Data Pool has N data for a Test Case and you perform N+1 iterations, then the Data Pool will begin again with the first piece of data.  
 
|}
 
|}
  
−
=== Utilizar datos relacionados (SETID) ===
+
=== Using related data (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.
+
Typically when you think of or design a Test Case, you do it conceptually and you do it in order to use data in the Test Case. Many times the different data sets are related, for example for a given country you want to enter it’s corresponding cities.  
−
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:
+
For example if you want to test the country, once you have the test case defined conceptually, you can decide to run the application with the following datasets:
−
* Conjunto 1: País: Uruguay, Ciudades: Salto, Paisandú,Montevideo y Atlantida
+
* Set 1: Country: Uruguay, Cities: Salto, Paisandú, Montevideo and Atlantida  
−
* Conjunto 2: País: Argentina, Ciudades: Rosario, Bariloche, Buenos Aires y Victoria
+
* Set 2: Country: Argentina, Cities: Rosario, Bariloche, Buenos Aires and Victoria  
 +
In this case it you need to tell GXtest that you are using a dataset in different yet related datapools and not using only one datapool.
  
−
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.
+
This can be done using what is called SETID, set identifier. In [http://blog.abstracta.com.uy/2009/07/datapools.html this post] there is an example of how to use this kind of datapool. 
  
−
Esto se puede hacer con lo que se denomina SETID, identificador de conjunto.
+
To perform this simply create two datapools, one named Countries and another named Cities, with the previous data and add to them a column called SETID. Now when you add a related dataset you just add an identifier for the related dataset in each row of data in the Countries and Cities datapools in the SETID column. It should be according the following format:
−
En [http://abstracta-soft.blogspot.com/2009/07/datapools.html 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.
+
Master Datapool: Country - SETIDs are identifiers. i.e.: 1, 2, 3. <br>
−
Luego se deberá agregar un DataPool llamado DATASETS el cual tendrá una única columna llamada SETID.
+
Related Datapool: Cities - SETIDs must be a master indentifier, followed by "." (a dot) followed by another identifier. i.e.: 1.1, 1.2, 1.3, 1.4, 2.1, 2.2, 2.3, 3.1  <br>
−
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:
+
 
 +
Doing so you will get the following datapools with the following data:  
  
 
{| class="wikitable" style="text-align:center; " border="1"
 
{| class="wikitable" style="text-align:center; " border="1"
 
|-
 
|-
−
! '''DATASETS'''
+
! colspan="2"| '''Country'''  
−
! colspan="2"| '''Paises'''  
+
! colspan="2" | '''Cities'''  
−
! colspan="2" | '''Ciudades'''  
+
 
|-
 
|-
 
! SETID
 
! SETID
 +
! Country Name
 
! SETID
 
! SETID
−
! NombrePais
+
! City Name
−
! SETID
+
−
! NombreCiudad
+
 
|-
 
|-
−
| 1 || 1 || Uruguay || 1 || Montevideo  
+
| 1 || Uruguay || 1.1 || Montevideo  
 
|-
 
|-
−
| 2 || 2 || Argentina || 1 || Salto  
+
| 2 || Argentina || 1.2 || Salto  
 
|-
 
|-
−
| 3 || 3 || Brasil || 1 || Paysandú
+
| 3 || Brasil || 1.3 || Paysandú
 
|-
 
|-
−
|colspan="3" style="border-top:1px solid black; border-right:0px solid black; border-bottom:0px solid black; border-left:0px solid black;"|
+
|colspan="2" style="border-top:1px solid black; border-right:0px solid black; border-bottom:0px solid black; border-left:0px solid black;"|
−
| 1 || Canelones
+
| 1.4 || Canelones
 
|-
 
|-
−
|colspan="3" style="border-top:0px solid black; border-right:0px solid black; border-bottom:0px solid black; border-left:0px solid black;"|
+
|colspan="2" style="border-top:0px solid black; border-right:0px solid black; border-bottom:0px solid black; border-left:0px solid black;"|
−
| 2 || Buenos Aires
+
| 2.1 || Buenos Aires
 
|-
 
|-
−
|colspan="3" style="border-top:0px solid black; border-right:0px solid black; border-bottom:0px solid black; border-left:0px solid black;"|
+
|colspan="2" style="border-top:0px solid black; border-right:0px solid black; border-bottom:0px solid black; border-left:0px solid black;"|
−
| 2 || Rosario
+
| 2.2 || Rosario
 
|-
 
|-
−
|colspan="3" style="border-top:0px solid black; border-right:0px solid black; border-bottom:0px solid black; border-left:0px solid black;" |
+
|colspan="2" style="border-top:0px solid black; border-right:0px solid black; border-bottom:0px solid black; border-left:0px solid black;" |
−
| 2 || Bariloche
+
| 2.3 || Bariloche
 
|-
 
|-
−
|colspan="3" style="border-top:0px solid black; border-right:0px solid black; border-bottom:0px solid black; border-left:0px solid black;" |
+
|colspan="2" style="border-top:0px solid black; border-right:0px solid black; border-bottom:0px solid black; border-left:0px solid black;" |
−
| 3 || Sao Paulo
+
| 3.1 || Sao Paulo
 
|}
 
|}
  
 +
Then if you use the DPNext command on the Paises datapool, it will filter the datapools by the set identifier (SETID) .
  
−
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.
+
== Shared workspaces - Many users accessing the same repository ==
−
 
+
  
 +
In order to handle concurrent access of the GXtest database scheme there is a lock/unlock system over the artifacts on which they are working.
 +
Each element can be blocked by a user who is using it, indicating that he can change and is better if anybody else modify it. Then when he already modified it and saved it, he can "release" it to let the rest of the team work on it.
 +
When an item is checked out anyone can open it as read-only item. When someone creates an item automatically locks it for himself. If nobody else wants to modify it, it is possible to block it explicitly. This is useful when the one who wants to use it knows that it is  blocked but nobody is really using it.
  
−
==Soporte==
+
To lock an item, right click on the item, "Lock".
−
Por soporte sobre esta herramienta por favor envíenos un mail a gxtestbeta@abstracta.com.uy.
+
To unlock an item, right click on the item, "Unlock".
−
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.
+
The elements that were blocked have an icon with transparent background, which are not blocked by anyone appear with a gray background, and if someone else has blocked it is displayed with red background.

Latest revision as of 12:13, 17 October 2013

Spanish.gif
English.gif
link= {{{3}}}

This page discusses the main features 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.

Gxtest full view.jpg
  • 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

When the GXtest program is run it brings up the following screen:

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:

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

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 (this version allows you just to use Internet Explorer). 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 is 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 testing tools 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. 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.

These kinds of KBs can be imported into GXtest by using an XPZ, GXPublic, GXBL, or .gxt file.

ImportKBFile.jpg

Choose the location and the file type: (gxt, gxw o gxt)
In GeneXus 8 or 9 you can use xpz files, gxw files (its in the KB folder) or a gxt file (gxt file its a XML file that contains only the KB that GXtest use).
In GeneXus X o higher you can use a gxt file or gxw file.

AddKBFileTypes.jpg

Once you have selected the type and location, click Ok.

GXtest Extension

GXtest Extension is a GeneXus X extension that allows you to export KBs in GXT format.
Note: extension installation is optional, GXtest can connect to KB directly.
To install it, copy the GXtest Extension.dll file located in the GXtest Designer installation folder to Packages in GeneXus directory. After restarting GeneXus, go to Extension Manager in Genexus an check in the extension name. Then restart GeneXus again and open the KB and 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.

You can also download this extension in GeneXus Marketplace.

Modify Knowledge Base Properties

Sometimes you need to change the path to the KB in order to update it (when select "Refresh KB" GXtest uses the same path that you selected at the moment of importing the KB). To do that (with the Project already opened), go to KB menu and select "Edit Properties". Then select the KB and insert the new path.

Updating your 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 the menu Knowledge Base -> Update KB Information.

You can see an entire example of KB update here: Impact on Test Cases when the GX KB changes

Use KB that uses GXFlow or GXPortal

When your application uses GXPortal (in Genexus 8, 9, X or higher) or GXFlow (in GeneXus X o higher) you need to bind those KBs to the project. The GXtest project must be binded to the application KB plus the GXFlow's KB and/or GXPortal's KB. The metadata of GXFlow's KB for the GeneXus Ev1 is here.

If you don't do that, GXtest is going to fail trying to record or execute test cases who need references to objects from those KBs.

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. When there are more than one frame in the same window or when there are more than one window (for example a popup) at the time of running a command, in those cases you must select the object. In addition, while it is running a validation is performed that the page corresponds to the object defined on the page (with the command CheckMainObject).

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 peculiarity 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:

PageWithMultipleEdges.jpg

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

An important aspect to highlight is that a failure of the execution of one of the iterations of an included test case that is configured to stop the execution when fails, it also will stop the execution of the test case that includes it.

Decision

A decision object allows you to 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 Create New Test Case from the Test Case menu in the project panel.

Record test case.jpg

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.

The Drag and Drop commands allow for easy construction of Test Cases in the Model editor, it is possible to simply drag and drop commands between different components (Edge Lines and Pages). This allows you to move or copy if you hold down the Control key.

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.

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 or XML (since v1.1.4) file that can be imported into GXtest Designer.

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

Then choose the ZIP/XML 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:

BotonValidarTC.jpg

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

Ejecutar.JPG

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:

BotonEjecutarN.jpg


Note: When you run N times, after each execution GXtest will close all open windows of the browser selected for execution.

Running a Test Case in an opened 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:

BotonPlayInIE.jpg

Note: If you are using Firefox browser (GXtest 1.1 or upper) this functionality can only be used with browser instances opened for GXtest or setted to start with-jssh.

Execution in FireFox (from version 1.1)

To run tests over Firefox you must install the Firefox Extension that can be found over GXtest installation folder : GXtest Designer\Firefox.

"C:\Program Files (x86)\Abstracta\GXtest Designer\Firefox\mozrepl-jssh.xpi" To find a way to install Firefox extensions you may want to take a look at: http://www.wikihow.com/Install-Firefox-Extensions

Para versiones de firefox inferior a 4: 2, 3, 3.5 and 3.6, you should download the plug-in jssh and install it. The plugin can be downloaded at the following links:

Then to tell GXtest Desginer to run using FireFox, change the project properties to the type of browser FireFox.

Note: We recommend disabling automatic updates and "Set as default" dialog in FireFox to avoid failures in the test cases due to this reason.


Important: while running a test case in any browser, GXtest is going to close automaticaly any popup like "do you want to activate autocomplete" or similar ones.

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
It is important to keep in mind that the names of the projects that contain the Test Cases that are to be transferred ought to be the same.

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.

Commands

Commands allow you to express the interactions that you want an application to perform as well as validations of the expected state of an application after each of the interactions. Commands can be actions, validations and events. Each of these can have parameters that indicate when they should run within an application.

Actions are done by a user within a webpage and don’t move you to another page. Some examples of actions are FillInput (to insert a value into a field on the page) and Check (to tick a checkbox).

There are also events that are interactions that cause you to move from one page to another. Some example of events are Go (the same as typing a URL into a browser), ClickLink (used to click a link within a page) and ClickButton (used to click a specific button).

Lastly there are validations which are used to validate that the resulting state of an application is what was expected. Some examples of validations are AppearText (checks if a text is present or not) or VerifyControlText (compares the value of a control on the screen with a reference value). Validations always have two mandatory parameters in addition to their other parameters.

  • Error Description Parameter: this is shown if a validation fails and describe why the failure occurred.
  • Negation Description Parameter: this shows that the expected result is the negation of the validation. For example if you negate the validation AppearText it says that you don’t want a certain text to appear.

Parameters

Each command recieves a list of parameters. The kinds of parameters that a command can have are described below:

Control Parameter

This kind of parameter is used to create a control within a GeneXus object. Transaction and WebPanel objects in GeneXus have an associated WebForm, this WebForm has an associated set of controls that specify the information to be shown and the interaction that the user can have with the object. For example, a button or a field where you can enter values are controls within a WebForm object.

Value Parameter

Value parameters refer to a fixed value, be it text or a number, that you want to use in a command.

Variable Parameter

GXtest allows you to capture values returned by an application and store them as variables. These variables are then used in other commands. (See Creating a Test Case with Variables for more information.) There is a standard variable called urlHome that uses the value defined in the project’s URL property when the Test Case is ran with GXtest Designer or that uses the value defined by the URL property associated with the task when it is run with GXtest Manager.

Data Pool Parameter

Data Pools allow you to use external data in a Test Case. Data Pool parameters allow you to tell a command to take values from a specific data source.

SelectionByRow Parameter

Commands that are run within tables have a parameter the tells them which row within a table they should use to run an action. This parameter referred to generically as SelectionRule can actually be two types SelectionByRow or SelectionByControl. SelectionByRow is used to specify the row where the action will take place and is indicated by the row number. In this way you can model in GXtest actions such as “Click on the first row of the grid.” Because of this the parameter has a Data Pool subparameter, value or variable. This parameter can be a positive number which indicates the row (where the first row is referenced by number 1). If you want to select the last row you can use the keyword "last" instead of a number.

SelectionByControl Parameter

The SelectionByControl parameter is used to specify the row in table to be used based on a value in one of its columns. For example you can tell GXtest to select the row which contains Employee Number 59. GXtest will search the table and select the row with the first instance that matches the established criteria. This parameter has two subparameters:

  • Control Type Parameter indicates the column where GXtest will begin to search for the established criteria
  • Type of Comparison and comparer indicates if what is to be compared is text or a number and the comparison that will be used (equal to, more then, less than, contains, etc.)
  • Variable Type Parameter, Data Pool or Value: it’s the value that is going to be compared.

List of Commands

Actions
Check Allows you to tick or check a CheckBox
CheckTable Same as Check but used for controls that are located in tables
Choose Allows you to select an option from a RadioButton
Concatenation Allows concatenation of fixed values, variables and values from DataPools
Execute Execute a process (exe, bat, etc)
FillInput Used to insert a value into a field
FillInputTable Used to insert a value into a field within a table
GetValue Allows you to obtain a value returned from an application and store it in a variable to later be used in another command
GetValueTable Same as GetValue but used for values that are located in tables
Pause Sleep the execution for some time. You should indicate the length of the pause in miliseconds
PressKey Simulates a keystroke made by a user. For more information on how to specify different keys see the following reference
Random Generates random sequences of numbers and characters of a given length
SelectCombo Allows you to select a value from a list of values (combobox)
SelectComboInTable Allows you to select a value from a list of values (combobox) that are found within a table
Summarize Summarize a group of values
SelectRow Allows you to select a row in a table
SetGridContext Allows you to execute actions over controls in grids within grids. You can find more information in Inputs in Grids within Grids.
UnCheck Allows you to uncheck a CheckBox
UnCheckTable Same as UnCheck but used for controls that are located in tables
DPNext Move to the next row of a Data Pool. You should always use DPNext before you begin to use a Data Pool, indicating the name of Data Pool
DPReset Returns to the beginning of a Data Pool.
DragAndDrop Drag a control to another one
StoreValue Save a value or variable inside one DataPool in execution time
Events
Back The same as clicking the Back button in a browser
Go The same as typing a web address (URL) into a browser
GoAndLogin The same as the Go command except that it allows you to enter a username and password for applications that require it
Click Clicks on a GeneXus control
ClickLinkByCaption Clicks on a link. The difference between this event and the previous is that sometimes because of how an application is constructed the same control has more than one name. In these cases ClickLinkByCaption is used to specify the name of the link to be controlled
ClickMenu Allows you to click in a menu item
ClickTable Allows you to click on a control that is located in a table
ClickPrompt Allows you to open a prompt to select values from a list
ClickPromptInTable The same as the above except for fields that are located in a table
ClickPortalMenu Allows you to open a specific menu of an application developed with GXPortal
ClickToolbarButton Allows you to click on a toolbar button in an application made with GeneXus X and that uses a User Control with ExtJS
LoginPortal Allows you to login to an application that uses GXPortal for security
ClickTree Allows you to open a menu developed with ExtJS TreeMenu (in an application made with GeneXus X and that uses a User Control with ExtJS)
Close Closes a window
PressKey Idem to the action, but for those keys that produces a transition to other page (like an enter)
DummyEvent Does nothing. Used to go form one page to another without performing an event

evento.

SeleniumCommand Allows to define Selenium commands for execute in GXtest.
Validations
AppearText Checks if a specific text is or is not on the screen. It can also be used for validations performed by Ajax. If it indicates a GeneXus object associated with the node where the command is being run, it will search the text in the frame that contains this object. If it is not indicated then it will look in the main frame
IsItemInList Verifies if an especific item exists in a list of items
TableOrderedBy Checks to see if a table is sorted by a given column
TableRowsNumber Checks the number of rows of a given table
VerifyColumnVisible Verifies if a column is visble in a grid
VerifyControlEnable Verifies that a control is enabled
VerifyControlEnableTable Same as VerifyControlEnable but used for controls that are found in a table
VerifyControlVisible Verifies that a control is visible
VerifyControlVisibleTable Same as VerifyControlVisible but used for controls that are found in a table
VerifyControlFocus Verifies if the current application focus is in the right control
VerifyControlFocusTable Same as VerifyControlFocus but used for controls that are found in a table
VerifyControlText Compares a value displayed by a control with another value
VerifyControlTextTable Same as VerifyControlText but used for controls that are found in a table
VerifyControlValidation* Compares a value displayed in a balloon in a control
VerifyControlValidationTable* Similar to VerifyControlValidation but used for controls within grids
AppearBalloon* Checks if a balloon appears on a control
AppearBalloonTable* Similar to AppearBalloon but used for controls within grids
Equals Compares each other two Data Pool, Variables or values
VerifyItemsInList Checks the list of elements in a list
VerifyItemsInListTable Same as VerifyItemsInList but used for controls within grids
VerifyItemsInSuggestion Checks the list of elements in a input suggestion list.
VerifyItemsInSuggestionTable Same as VerifyItemsInSuggestion but used for controls within grids 
* When execute a command above a balloon, GXtest waits to disappear the balloon to continue with the next command to execute.

Custom Commands

Sometimes extra features are developed to improve the user interface, using Javascripts or HTML by hand. In those cases GXtest it is not going to recognice the commands over these controls, and it is necessary that the user prepare his own GXtest commands. To do that you can use "Custom Commands". To learn more about it check Creating a Custom Command.

Use a command to invoke a Genexus Procedure

Many times it is very useful to invoke a Genexus Procedure to manage data or validations over that data. To learn more about it check Creating a command to use a GeneXus Procedure.


Data Pools

A Data Pool is a set of data that can be used in a Test Case. For example if we want to make a Test Case that enters into the system 100 new clients we can create a Data Pool called Clients that contains their name, ID number and telephone number. If you create a Test Case that uses the Data Pool to insert values into an application, every time that it is run the Test Case will use a different piece of data from the Data Pool. To see how to create a Data Pool and a Test Case that uses it see the page Creating a Test Case with Data Pools.

Data Pools are used in GXtest testing when working with data. They can be used not only to enter data into an application but also to validate the expected results of an application in order to choose which action to be performed.

Commands associated with Data Pools

The majority of the commands can have parameters from Data Pools but there are also certain commands specific for Data Pools which are the following:

  • DPNext Move to the next row of a Data Pool. You should always use DPNext before you begin to use a Data Pool, indicating the name of Data Pool
  • DPReset Returns to the beginning of a Data Pool.
  • DPCompare: it is a validation type command that is used to compare a value from a Data Pool con another value

Scope of the data

An important concept within a Data Pool is the scope or the hierarchy of the data stored in a Data Pool. The scope can be of two types Global or by Test Case. For example you could have the following Data Pool:

Scope Name Password
Global pepe pepe
Case A juan juan

If you use a Data Pool in a Test Case that doesn’t have specific data assigned to it, you will use the global data (pepe in the example). Nevertheless if you assign specifc data to a Test Case then it will use that data.

Keeping in mind the previous Data Pool, imagine that in our Test Case we want to use different names and passwords to access a system. You can create a Data Pool called Users similar to the previous example. Assume now that the majority of the Test Cases use the username pepe and the password pepe and there is only one Test Case (Case A) that uses the username juan and the password juan. In order to resolve this issue you must enter the username pepe and the password pepe as global data and the username juan is entered as specifc to Case A.

If you use this Data Pool in Test Case Case B, it will return the value (pepe,pepe) which are the global values, but if you use it in Case A, it will return the value (juan,juan).

Important: if a Data Pool has N data for a Test Case and you perform N+1 iterations, then the Data Pool will begin again with the first piece of data.

Using related data (SETID)

Typically when you think of or design a Test Case, you do it conceptually and you do it in order to use data in the Test Case. Many times the different data sets are related, for example for a given country you want to enter it’s corresponding cities.

For example if you want to test the country, once you have the test case defined conceptually, you can decide to run the application with the following datasets:

  • Set 1: Country: Uruguay, Cities: Salto, Paisandú, Montevideo and Atlantida
  • Set 2: Country: Argentina, Cities: Rosario, Bariloche, Buenos Aires and Victoria

In this case it you need to tell GXtest that you are using a dataset in different yet related datapools and not using only one datapool.

This can be done using what is called SETID, set identifier. In this post there is an example of how to use this kind of datapool.

To perform this simply create two datapools, one named Countries and another named Cities, with the previous data and add to them a column called SETID. Now when you add a related dataset you just add an identifier for the related dataset in each row of data in the Countries and Cities datapools in the SETID column. It should be according the following format:

Master Datapool: Country - SETIDs are identifiers. i.e.: 1, 2, 3.
Related Datapool: Cities - SETIDs must be a master indentifier, followed by "." (a dot) followed by another identifier. i.e.: 1.1, 1.2, 1.3, 1.4, 2.1, 2.2, 2.3, 3.1


Doing so you will get the following datapools with the following data:

Country Cities
SETID Country Name SETID City Name
1 Uruguay 1.1 Montevideo
2 Argentina 1.2 Salto
3 Brasil 1.3 Paysandú
1.4 Canelones
2.1 Buenos Aires
2.2 Rosario
2.3 Bariloche
3.1 Sao Paulo

Then if you use the DPNext command on the Paises datapool, it will filter the datapools by the set identifier (SETID) .

Shared workspaces - Many users accessing the same repository

In order to handle concurrent access of the GXtest database scheme there is a lock/unlock system over the artifacts on which they are working. Each element can be blocked by a user who is using it, indicating that he can change and is better if anybody else modify it. Then when he already modified it and saved it, he can "release" it to let the rest of the team work on it. When an item is checked out anyone can open it as read-only item. When someone creates an item automatically locks it for himself. If nobody else wants to modify it, it is possible to block it explicitly. This is useful when the one who wants to use it knows that it is blocked but nobody is really using it.

To lock an item, right click on the item, "Lock". To unlock an item, right click on the item, "Unlock". The elements that were blocked have an icon with transparent background, which are not blocked by anyone appear with a gray background, and if someone else has blocked it is displayed with red background.

Retrieved from "http://gxtest.abstracta.com.uy/wiki/index.php?title=GXtest_Designer_User%27s_Manual_1.0&oldid=3082"