Device configuration

For general device configuration visit EEM Project with EEM Timer jobs

Example of a SmartBear device configuration

In the following example, the parameters for a device have been set for SmartBear tests as described in the EEM project infos section:

EEM Project job details

SmartBear project settings:

EEM Project parameters

The Linked EEM Timer Jobs section shows which EEM timers have been added to this EEM Project job. No timer jobs have been added yet in the above figure.

Remote Desktop Protocol (RDP) settings for measurements

RDP should be configured on the device that holds the EEM project job to avoid redundant settings on every single job. However, if a job needs different parameter settings, the device parameters can be overridden by parameters configured on the job:

EEM Project values and alarm limits

Adding timer jobs

The timer jobs represent the measurements to display in the SKOOR Engine or dashboard. A project can have multiple timer jobs such as the total time of all measurements, the login into an application and other use cases. The timers must be configured / programmed in the project. If the test project is available in one of the SKOOR Engine repositories or on the EEM robot in the configured scripts directory, the SKOOR Engine will try to extract the timers from the project and automatically configure them.

In the edit window of an EEM project job, click Add timer jobs:

The following screen appears and documents the found timers and actions done:

The timers have been configured below the EEM project job:

With the up and down keys, they can be ordered now as required.

Adding timer jobs manually

If timer jobs should be created before the EEM project is available on the SKOOR Engine and robot PCs, they can also be added manually. Click on the EEM project jobs name to get below the project job and add the timer using the function menu or the gear icon:

After that, the timer name must be configured exactly as defined in the project. The following screen shows a timer called totalTime:

EEM Timer parameters

EEM Timer values and alarm limits

EEM Timer details

Timers are introduced within a project to measure the outcome (OK/Failed/NotRun) and the time it took for a specific section of a test run. During the run the timers are written to a text file within the project directory. The file is structured in the following way:

========== 2017.11.30-12.43 =================
Name;Status;Time
----------------
Calc_Open;OK;6.26
Calc_Calculate;OK;1.69
Total;OK;8.47

For each timer, the name of the SKOOR Engine EEM Timer job, the actual timer name, its current status and the time in seconds it took to run the corresponding timer during the last run are printed.

There is also the possibility to have the project write a specific error string to the timer file which will then be parsed as a string value. This makes sense when a project encounters errors which occur frequently and are known but cannot be fixed in the tested application or website. In such a case the recognition of the error needs to be programmed into the project sequence and should write a specific error string to the timer file for the specific timer. An example of such a timer file is shown below:

========== 2017.11.30-12.43 =================
Name;Status;Time
----------------
Calc_Open;OK;6.26
Calc_Calculate;Known error encountered in Calculate sub-step;1.69
Total;OK;8.47

The second column of the Calc_Calculate line is interpreted as a known error on EEM timer job level.

These known errors can then be used in alarm limit configurations. An example of an encountered known error is shown in the following figure:

And in the values section on the corresponding EEM timer job:

The timer file, in this case calc.txt (its name must be identical to the Project name), is fetched via WinAgent and parsed for the states and values of each timer. But this happens only if timers with the corresponding names are configured. 

EEM Project results

After a run of the project on the EEM robot, the values section of the EEM Project job looks like this (differs with SikuliX projects):

or in case of an error during the project run:

By clicking the Timer file link, the fetched timer file can be viewed directly (see example file above).

By clicking the link next to MHT log file, the MHT summary log can be downloaded or viewed directly. Direct viewing is only possible, if the link is clicked from within an Internet Explorer browser. The following is an example of an MHT log:

Clicking the Result files link in the Values section will bring up the following new browser window or tab:

This page provides an overview of the tests that have run on the EEM robot. For each run where logs were collected by SKOOR Engine there is a line with a timestamp and a link to the corresponding MHT file. If there were errors during a run the link is placed in the Failed tests column, along with a tiny icon that can be clicked and which opens a new browser window with the a screenshot of the first error encountered during the run. This mostly gives a good idea about why a test run failed. If the most recent run failed, such as in this example, the screenshot is also displayed in large in the Last result section of this overview. Clicking the Screenshot link in the job’s Value section opens this screenshot image directly.

EEM Project example

Run a simple EEM Project with 3 EEM Timers

The following configuration assumes that the remote host has a TestComplete Project suite called Calc with a project called Calc underneath. The project output contains 3 timers and is run via the WinAgent installed on the remote host. WinAgent must be configured to allow execution of the testexecute.exe binary. The timers are added as individual EEM Timer jobs beneath the EEM Project job.

Output