The Test Studio Execution Server is the Test Runner instance of Test Studio Standalone installation or the Test Studio Run-Time Edition installation. An Execution Server is ready for use when configured and registered with your Scheduling Server. Because of this, the first requirement to cover is to successfully configure a Scheduling Server.
An Execution Server (ES) could be any physical or virtual machine. Multiple Execution Servers could be connected to a single Scheduling Server (SS) to allow you to execute multiple test lists simultaneously. Differences in operating systems and browsers between the machines running the SS and the ES are allowed. Though, each ES must be running the same version of Test Studio as the SS.
Few things to consider when choosing an ES machine:
- An active and unlocked desktop session is required - you must be logged on with an Administrator account at all times, you can disconnect from the ES but not log off. This article explains further details on the topic.
- Ensure that the Execution Server machine has sufficient space on disk to store a copy of any project you schedule for execution on that Execution Server.
- If you plan to use 'Get Latest from TFS' on scheduled test runs, make sure the Test Studio Execution Server is running under an account with access to log on to the TFS repository.
The Test Studio Test Runner gets installed with a standard Test Studio Standalone product installation or Test Studio Run-Time Edition installation. To start the Test Runner, type in the Windows Start Menu > Start Execution Server.
If you get prompted that the Test Runner is already running, you can right click the Test Studio icon in the Windows Task Bar and click Show.
Once the Test Studio Test Runner window appears, there are multiple options you can customize as per the specifics of the particular environment.
Status - shows the current status of the Execution Server and if it is connected to the listed Scheduling server.
Scheduling URL - shows the URL of the current configured Scheduling server, to which the Execution server is connected. To change this address, click the 'Change' button (the three dots button) next to the listed Scheduling service address.
Type the address for the machine which hosts the Scheduling Service under Scheduling Service URI with the correct port it is configured on and click on 'Change' to connect to that Scheduling Server.
- Temp Folder - the process of executing tests on a remote machine includes deployment of the project files in a temporary folder. You can choose where this temp folder will be located on the disc - click the 'Change' button (the three dots button) next to the listed folder and browse the desired one. The Reset button will set the default temporary location on the execution machine.
Note: It is important to allow access to the newly set location for all users.
The section contains details for the Execution Server machine - status, Test Studio version, machine name, OS version, machine stats.
You can access the logging of the Execution Server - enable, disable or view the generated log.
All available and supported browsers on the Execution Server are listed in this section. You can calibrate these or restore their default settings. If using an older version of Edge, you can browse here the WebDriver folder location on disc.
The Run on start up option allows you to decide whether the Test Runner should be started automatically on machine startup.
Test Studio allows you to apply different configurations for the user session on the execution machines. That way you can make sure the machine is available and ready to execute UI tests.
If this option is enabled, as long as the Test Studio Scheduling Client process is running, it will prevent your machine from falling to sleep, locking or showing screensaver. This will prevent them from breaking your UI tests.
Once the option is disabled or the Test Studio Scheduling Client process is stopped, the operating system will be able to get to sleep/lock normally.
Note: This functionality will not prevent the user to manually lock the machine or put it to sleep. Note: Using this functionality could be a security risk since it will prevent the machine from locking when expected by your security policy. Please consider if leaving the test machine unlocked for prolonged periods is acceptable for your organization before using the feature (especially when using Test Studio on your local physical machine).
When running tests on a remote virtual or physical machine, users would usually connect to that machine via Remote Desktop Connection (RDC) to start and configure the Test Studio Scheduling Client. If after that the user closes their RDC window, their user session on the virtual machine will be switched to 'disconnected' state and will lose access to the graphical user interface (GUI). This will prevent UI tests to be executed normally, whenever an interaction to the GUI is needed (e.g. performing real mouse click or keyboard actions, dialog interaction, etc.).
When the 'Reconnect to Console on Disconnect' feature is enabled, Test Studio will try to reconnect your disconnected session to the local console session, regaining access to the GUI.
Note: When your session gets connected to the local console session, if there is a physical monitor, attached to the Windows machine, your session will be displayed on it. If there is another user, that has physical access to the machine, they will be able to view your screen or interact with it. This could be a security issue, so please consider carefully if that is acceptable for your organization before using the feature. Note: This feature will not have effect if you keep your Remote Desktop Connection session open, but minimized. You can see this article for information on handling this case.
See Also: You may find additional notes on the topic in our blog post Improve Your Remote Test Execution with Test Studio User Session Configuration.