GXtest Manager User's Manual
This page shows the main concepts of GXtest Manager.
Contents |
Introduction
GXtest Manager allows you to group the test cases modeled with GXtest Designer, and schedule them for execution. Then it lets you see the results of each of these executions.
For this, consider certain fundamental concepts:
TestCase: This is a test case generated with Gxtest Designer. It consists of a series of steps to execute on the application under test, with certain data and certain expected results.
Suite: is a collection of Test Cases (within the same project). Optionally, you can define an execution order for the Test Cases and the number of times that each of them will run. See also Creating a Suite.
To visualize this consider the following example:
| Suite 1 | |
|---|---|
| Test case 1 | 5 |
| Test case 2 | 15 |
| Test case 3 | 4 |
In this case the suite 1 includes three test cases, the first one execute 5 times, after the end of that execution will run the test case 2 exactly 15 times and finally the test case 3 is executed 4 times.
Task: is a set of scheduled suites in a fixed time for execution. They can be scheduled in different modes (single time, daily, weekly).
Executor: machine to conduct the execution of a Task, which must have GXtest Executor installed. This component allows you to run tests parallely and in different environments, because we can schedule various tests (other tasks) on different machines.
Start GXtest Manager
To start GXtest Manager is required to indicate the user and project which you want to work. If it is not specified you only can work with generic things, but if you want to create test suites or schedule tasks, you need to register in the system.
Configurations
Users
GXtest Manager allows you to define users. The main reason for defining users is to associate them with Suites and Tasks, to receive an email with a summary of the results after each run.
Executors
The test execution is performed in a distributed way on each machine that has installed the GXtest Executor. This is an application that listens expecting to be directed to execute a task. To perform executions over these distributed components is necessary to create them in GXtest Manager, giving them a name and indicating the IP and Port where they listen.
Application Settings
You can define the parameters that the Task should receive to run.
This includes the URL where the Test Cases will execute, which is what defines our system under test. This parameter will be loaded to run on the Executor in the URLhome variable in each Test Case.
You can also define the DBMS used by the application, in order to register this data in the results and then it could be used (in the future) as a further dimension to statistics.
You can also configure a set of Datapools to be filled before the execution of the execution of the Task. This is useful if the data to use in the Datapool is dependent on application state, and is required to load immediately prior to the execution and use of this data. This functionality is not yet complete.
In addition, you can define a bat file to invoke prior to the execution of the Task, so in this bat file you could prepare the state of the application to test. This can include things like restore the state of the database from a previous backup, run SQL scripts, copy files, etc.. This functionality is not yet complete.
General Configuration
In the General Configuration menu you can define the directory where the GXtest Manager saves the log. If not defined the route is saved in the same directory where the application is deployed.
SMTP
You need to configure the SMTP server in order to let GXtest Manager to sends the emails with the results. You must indicate:
- SMTP Host
- SMTP Port
- SMTP User
- SMTP Password
Also the variable URLExec must be configured. This is setted in the installation, and gives you access to the Executor to the component that sends the emails.
Example:
http://abstracta00/GXTestManager/aprocessexecutionresult.aspx
Browsers, DBMS, Operative Systems
It is necessary to define values for these elements in order to recording information. When you define the Executors you have to tell which browser and operating system this machine has. When you define the Application Settings you have to associate a DBMS.
The GXtest Manager installation will include standard definitions, in order not to be necessary for the user to create this kind of instances, and just use them when you need them.
Suites and Test Cases
From GXtest Manager you can view the available Test Cases. These are the ones who were created in the GXtest Designer and loaded at the data base of the Manager. In the WorkWith Test Cases you can navigate between the different suites that include the Test Case.
Projects
You can view the defined projects and their properties. These projects were created in GXtest Designer. Each of the elements that can be linked (Test Cases, Suites, Datapools, etc..) are associated with a project and have visibility within it (it is not possible to include Test Cases from different projects in a Suite).
Suites
The concept of Suite is proper of GXtest Manager (it doesn't exist in GXtest Designer level), and this is where you create and edit them. As mentioned above, a suite is an ordered set of test cases, which also indicates the number of times to execute each test case.
Definición de Tasks
En GXtest Manager se agendan las Suites a ejecutar. Esto se puede hacer en el WorkWith Task o en el calendario. Al crear una Task se le indica qué Suites ejecutar y en qué orden.
Si se desea quitar una Suite ya agregada se debe eliminar la línea correspondiente de la grilla, y para esto se hace botón derecho sobre las filas, opción Delete. Al hacer esto queda marcada la fila con una cruz. Al dar confirmar se eliminará. Esto mismo aplica al momento de editar una Task.
Al crear la Task se le indica también en qué Executor ejecutar, y para esto se tuvo que haber creado previamente en GXtest Manager, indicando IP y Puerto para poder conectarse.
Existen tres tipos de recursiones para la definición de las tareas:
- Once: para que la Task se ejecute una sola vez.
- Weekly: para que se ejecute todas las semanas, los días que se indique.
- Daily: para que se ejecute todos los días.
Para los últimos dos casos se puede indicar día de inicio y fin. Para cualquiera de los tres casos se indica una hora de ejecución.
Se puede indicar en forma opcional la cantidad de minutos estimada que va a demorar la ejecución de la prueba. Esto sirve más que nada para poder visualizar mejor en el calendario las tareas, y así ver si se superponen.
A las tareas también se les asocia un usuario, el cual está interesado en recibir mails con los resultados después de cada ejecución.
Se debe indicar también el Application Settings a utilizar. Este le provee de cierta información a la Task para ejecutar relacionada al ambiente de ejecución de la aplicación bajo pruebas.
