Difference between revisions of "GXtest Executor User's Manual"

From GXtest Wiki
Jump to: navigation, search
m
Line 26: Line 26:
 
# tc1.xml
 
# tc1.xml
 
# tc1_detailed.xml
 
# tc1_detailed.xml
 
You can also search the results in GXtest Manager.
 
  
 
The first one simply says if it failed or passed for each step. If some mistake were made, each command will have an "Error Detail. Additionally, on error, there are attached the response html of the application and also the screenshot of the browser. You can see all this more detailed (parameters, input data, execution times, etc..) in the detailed file (tc1_detailed.xml).
 
The first one simply says if it failed or passed for each step. If some mistake were made, each command will have an "Error Detail. Additionally, on error, there are attached the response html of the application and also the screenshot of the browser. You can see all this more detailed (parameters, input data, execution times, etc..) in the detailed file (tc1_detailed.xml).
  
An important difference to consider whether to run a Task and a Test Case is that when running a Test Case results are stored in XML files as explained above, and if you run a Task results are stored in the GXtest Manager database (typically called "GXtestRepository"). In addition, the Task specified must be valid to run (for example, the specified instance of the task must not have been executed).
+
You can also search execution results in GXtest Manager.
 +
 
 +
An important difference to consider whether to run a Task and a Test Case is that when running a Test Case results are stored in XML files as explained above, and if you run a Task, results are stored in the GXtest Manager database too. In addition, the Task specified must be valid to run (for example, the specified instance of the task must not have been executed).

Revision as of 14:58, 16 August 2010


Setting GXtest Executor

Basically an Executor is a component that is "listening" to execute tests on the machine where it is installed. Once it is notified from the Manager that it is time to run a particular test, it starts to run those test cases, opening the browser for this.

Then, the Executor connects to the database to know the details of the test to run, using the connection data that GXtest Manager gave him when indicated to start running.

So, the main consideration in GXtest Executor is the port where is listening. To configure it you must double-click the icon in the System Tray and then enter the port number. The default is 6681. From that icon, you can also access to the log file.

Command Line Execution

The component to be used from GXtest Manager to run the tests is available to run it from any external application. This can be invoked by command line, and this runs a Test Case, or a Task, and saves a file containing the result of the test.

GXtestDaemon.exe {TaskId TaskInstance Path {-v VAR_1 VALUE_1 VAR_2 VALUE_2 ... }} | {ProjectName TestCaseName OutputPath ExecutorIP ExecutorPort}

For example, run:

cd 'C:\Program Files\Abstracta\GXtest Daemon'
GXtestDaemon.exe 1 1 'c:\temp'

Here, taskId = 1, and TaskInstance = 1 (task instance number must be different on each execution for each task)

The Executor executes the test cases and stores in the path at least 2 files, with a copy of the results:

  1. tc1.xml
  2. tc1_detailed.xml

The first one simply says if it failed or passed for each step. If some mistake were made, each command will have an "Error Detail. Additionally, on error, there are attached the response html of the application and also the screenshot of the browser. You can see all this more detailed (parameters, input data, execution times, etc..) in the detailed file (tc1_detailed.xml).

You can also search execution results in GXtest Manager.

An important difference to consider whether to run a Task and a Test Case is that when running a Test Case results are stored in XML files as explained above, and if you run a Task, results are stored in the GXtest Manager database too. In addition, the Task specified must be valid to run (for example, the specified instance of the task must not have been executed).