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.
Tasks definition
The suites are scheduled to be executed in GXtest Manager. This can be done in the WorkWith Task or on the calendar. When you are creating a Task you have to indicate the Suites to execute and in what order.
If you want to remove a Suite you have to remove the corresponding line of the grid, and you can do this with a right click on the row, and then Delete option. When you do that the row is marked with a cross. After clicking Confirm it will be deleted. The same applies when editing a Task.
By creating the Task we also have to associate it with an Executor where the Task will be executed, and for this we have to create previously the Executor instance in GXtest Manager, indicating IP and Port to connect.
There are three types of loops to define the tasks:
- Once: to run it once.
- Weekly: to run it every week, the indicated days.
- Daily: to run it every day.
For the last two cases it is necessary to indicate start and end date. For any of the three cases it is necessary to indicate a time of execution.
You can optionally indicate the estimated number of minutes that the execution of the test could last. This is requested mainly in order to improve the visualization of the tasks in the calendar, so you can see if they overlap.
The tasks are also associated with a user who is interested in receiving emails with the results after each run.
We also need to indicate the Application Settings to use. This provides the Task certain information to run related with the execution environment of the application under test.
