38

Hints on setting up test systems

This chapter provides some hints how to set up your test systems and processes in order to get a stable test execution.

38.1

Using the task scheduler

In order to execute tests or similar processes on a regular basis it is very common to set up a Windows service. Unfortunately those services have the disadvantage that they don't run in an active Windows user session. Because of this such processes should never be started as services, because running GUI tests without an active user session brings up very subtle problems during test execution. You can find further technical details at FAQ 14.

We recommend to define a scheduled task via the task scheduler instead of using services. This can be directly applied via the graphical UI of the task scheduler. The following instruction should work on Windows 7, Windows 8, Windows 8.1 and Windows 10. There might be a few differences depending on the exact operation system:

1. Start the Windows Task scheduler via 'System Control Panel' -> 'Administrative Tools' -> 'Task Scheduler'.
2. Click "Create Task" on the right.
3. At the "General" tab define a "Name", e.g. QF-Test.
4. Now click at the "Change User or Group" button and select the user for the session which should be used to run QF-Test. Do not use the System- or Service session but a real user session.
5. Press OK to close the dialog.
6. Now select "Run only when user is logged in".
7. Do not select "Run with highest privileges".
8. Choose the correct Windows version for your task.
9. Now select the "Triggers" tab. Click "New.." and define the desired time/trigger at "Begin the task".
10. Click "OK" to close.
11. Now select the "Actions" tab, click at "New." and specify "Start a program" as "Action" and "Browse" to the .cmd or .bat file you've just created.
12. Press "OK" to close this dialog.
13. You can now have a look at the "Conditions" and "Settings" tab if you need anything else from your side.
14. If you have finished the setup press "OK" and the task has been created.

It is very important that the user which is configured to run that process is logged in correctly. This user can be logged in manually or automatically (see section 38.3). It is recommended to use a virtual system for running GUI tests. On such virtual systems the user needs to be logged in only on the guest system and the host can be locked.

38.2

Remote access to Windows systems

Accessing remote Windows systems via RDP is subject to some restrictions and requires a dedicated configuration of your systems. That's because the implemented RDP server of Windows desktop versions allows only one active user. Thus the (virtual) monitor will be locked as soon as you access the system via RDP. After closing the RDP session the monitor of the test system remains locked. Usually you cannot use a graphical user interface at a locked screen, thus you cannot test it, too.

Note On Windows 10 or Windows Server 2016 systems you can make use of RDP if you modify the Registry. Therefore navigate to HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client or HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client and add a new value RemoteDesktop_SuppressWhenMinimized as DWORD having the value 2. Once that setting has been set you are allowed to minimize RDP connections, but you have to keep the connection alive. The tests will still fail if you disconnect or close the session.

Instead of this approach you should use the capabilities your virtual server provides. For VMware server the vSphere client would be the first choice. With VirtualBox you can connect to VirtualBox with RDP (not with the Windows client). Of course this kind of RDP connection has not the impacts on the test system as explained above.

38.3

Automated logon on Windows systems

A simple possibility to get an active user session is to logon a test user automatically after start-up of your system. This chapter describes how to configure your system for that purpose.

Note An automatic logon at Windows is always a security risk. Therefore you have to ensure that the corresponding test systems are not accessible from outside the test environment.

Although this guidance is generally valid it will be used commonly together with virtual systems which will be accessed remotely. What to keep in mind for this remote access will be explained at section 38.2.

The following method is running with Windows 7, Windows 8, Windows 8.1 and Windows 10. There might be a few differences depending on the exact operation system:

1. Start the command line interface with administrator privileges.
2. Enter control userpasswords2.
3. Now the dialog 'User Accounts' appears.
4. Remove the check at the checkbox 'Users must enter user name and password'.
5. In the next appearing dialog ('Automatic Logon') enter the user password twice.
6. Click the 'Ok' button to finish the configuration.

Of course also other methods exist to get the same result. Thus you could modify the corresponding registry entry directly. Or you could download the 'Autologon' tool from Microsoft from https://technet.microsoft.com/en-us/sysinternals/bb963905. But all those different methods lead to the same result, which is the modified registry entry. We recommend to use the method explained above as in this way no download is needed and a type mismatch in the registry entry is avoided. By the way, an automated logon will never run for domain users. In fact this would be quite awkward in conjunction with test system. This may be an information which may calm your administrators down.

38.4

Test execution on Linux

On Linux systems you can set up virtual displays using tools like VNC server. A very useful window manager for those displays could be xfce.

Last update: 9/10/2024 Copyright © 1999-2024 Quality First Software GmbH