Logo
blank Skip to main content

Peculiarity of terminal session applications testing

QA

In this article, we will try to help those who are going to test client-server application that uses terminal sessions. Not only QA specialists but also developers will find some useful information in this article โ€“ at least there are some details that should be taken into account when developing in order not to be in the testers black list of โ€œBug makersโ€.

To perform such testing one should know RDP and MSTSC โ€“ the brief review of them is given in the appendix. More detailed information can be found by links mentioned in the end of the article and by asking a question to the Mr. Google.

 

Problem statement

So letโ€™s consider the scheme of an application that we are going to test.

In my practice, most of applications that used terminal sessions had the client-server architecture. Thus, there are always server and client part and the installation for both of them.

We also know information about what kind of client we have: thin or thick one. In the case of the thin client all operations are performed by the server, while thick clients do everything themselves.

There is also a question of whose resources will be used โ€“ it depends on the concrete design of the application that uses terminal sessions. Resources can be not only memory but also some software: drivers, codecs, coding etc.

A lot of programs include RDP functions, others improve some of the standard functions. And while testing will be different for the different applications there are some basic tests that can be used for all.

Work schemes of applications using terminal session

Fig. 1

Figure 1

Nuances and main points of testing the application using terminal sessions

First we should check the requirement list:

  • List of the OS supported by the server and client.
  • How application depends on MSTSC.
  • What resources will be shared on the server?
  • Whose resources โ€“ client or server โ€“ are used for operation execution?
  • What users can work with the application (all or just one)?

Application functioning for different users

When application supports an option of installation for all users in the system it can be really surprising to find out that it doesn’t start or work for the other user (different from the user whoโ€™s installed it) especially for that who doesnโ€™t have the administrator wrights.

This checking can be performed in the Installation Testing block as well as in the Functional Testing.

The most probable bugs here are writing to the wrong registry branch (for example HKEY_CURRENT_USER) or to the wrong directory, or wrong component registration.

For example, our application should work for the Guest user. Then we include such a test:

Test Name: Permissions _Connect to Server as Guest

Pre-conditions:

Client is a client machine where the client part of tested Application is installed

Server is a server machine where the server part of tested Application is installed.

 

 

Step name

DescriptionExpected result
Step 1Connect to Server from Client via RDP by Guest userThe terminal session starts successfully on Client.
Step 2Start an Application and check its basic functionalityAn Application starts and works correctly according to Guest permissions.

Surely, expected result will be described accordingly to the requirements and application functionality.

Testing client and server cross-platform support

The hidden danger in such testing can be in the case when server part of the application is installed not on the server operating system (Windows2000, XP, Vista, Seven + a lot of different SPs). So itโ€™s better to clear it out at once in order to be prepared. If requirements include such option you should test the corresponding cases with special attention.

The most common situation is when the server part is installed on the server OS (Windows Server2000\2003\2008 + a lot of SPs) and the client has not the server OS.

It is convenient to use two dimensional tables to control this testing process:

 

 

client\server

Server 2003 Server 2008

Windows XP

Windows VistaWindows Sevenโ€ฆ
Windows 2000      
Windows XP      
Windows Vista      
Windows Seven      
โ€ฆ..      

In Configuration Testing you can consider single OS as well as OS with different RDP versions. We will tell about it in the next section.

Testing with different RDP versions

Testing of applications that are the add-ons for MSTSC devends much on the RDP version (5.0, 5.1, 5.2, 6.0 or 6.1).

In this case we should include function checking for different clients into the Functional Testing. Fortunately version of RDP depends on the OS. Thus checking with RDP versions can be included into the Configuration Testing.

client\serverServer 2003 Server 2008

Windows XP

Windows VistaWindows Sevenโ€ฆ
Windows 2000      
Windows XP RDP 5.0      
Windows Vista

 

RDP 6.0

      
Windows Seven

 

RDP 6.1

      
โ€ฆ..      

Testing multiuser scenarios

One of the key points in the client-server application functioning is the options to work by 1:1, 1:M, M:1, M:M schemas.

When testing these schemas you should check:

  • Optimal usage of resources of the client terminal and server.
  • Correct usage of the shared resources: libraries, memory, files.
  • System performance.

Letโ€™s consider the case when several clients are connected to the server.

Here can be the danger when server part takes almost all machine resources (CPU Usage, PF usage, Network Utilization etc.). As the result client can wait for the server answer for a long time. The average time of the answer for different client number should be checked.

Another point is the critical number of the clients connected. Of course the server is not made from gum โ€“ so there is such critical client number when the system will just crash. There is always such number even for the brilliant performance system โ€“ but if it is less then 10 it is the worth thinking about fact.

Sometimes application uses another scheme when two clients connect to the different servers from the one terminal. This scheme is commonly used for the thick client.

Such test cases can be the basic ones here:

  • Maximum allowed count of sessions to one server
  • Two sessions from two clients to one server
  • Two sessions from one client to two servers
  • Two sessions from one client to one server

The usage of the shared resources can be performed both by the application inside itself and by the user. So we should check both variants.

When several users work with the same file several dangers can appear:

  • Access denied;
  • Waiting till another user finishes his operations;
  • Server cannot deal with such loading.

System performance is especially important for the corporate systems with the great number of users. So research of the system maximal performance should be performed thoroughly.

Check time of terminal session Log in

The important usability factor is the way how application effects on the time of logging in/off the terminal session. This time should not be much longer then it is without our application installed.

Stress test set for terminal session applications

Test set for the Stress Testing can be formed from the common stress tests for the client-server applications plus some specific ones:

– Disconnect caused by hardware;

– Disconnect caused by software (enable\disable network).

These tests are double because they should be performed both on the client and server sides.

And more:

– Server reboot;

– Terminal session disconnect (close, disconnect, kill process);

– Terminal session closure (using log off function from the terminal session).

The last point is the additional peculiarity of the terminal session application testing.

Conclusion

As the final thought I want mention that the clear requirements make the testing process much more effective and easy. The testing of applications that use terminal sessions is not something very special or something to be afraid of. To perform it you should be acquainted with the client-server application testing โ€“ and learn some details.

Useful Links

Appendix A: Some knowledge about RDP

Protocol RDP.

Remote Desktop Connection provides remote control above any computer, running under the Microsoft Windows system in a TCP/IP local area network or the Internet. The user can see a remote desktop on his own machine, use its resources and devices according to settings and assigned permissions and have mouse and keyboard control above the remote computer.

This connection is implemented by RDP protocol.

There are many versions of RDP. The most popular are the following: 5.0, 5.1, 5.2, 6.0, and 6.1[1]. There is a new version 6.1.7000 for Windows 7[2].

Features

Main Remote Desktop features are:

  • Display features:
Fig. 2

Figure 2

  • Local devices and resources redirection:
Fig. 3

Figure 3

  • Remote Programs starting feature:

This feature allows to start remote programs from specified folder within terminal session

Fig. 4

Figure 4

  • Advanced Remote Desktop features:

TS Gateway servers – A gateway that enables authorized users to connect to remote computers in a corporate network from any computer by using Internet connection with secure HTTPS protocol, using port 443 instead of default port 3389 for Remote Desktop Connection and allowing RDP connections without a VPN or firewall.

Fig. 5

Figure 5

Deploying Remote Desktop

  • Remote Desktop Connection client is a part of all editions of modern Windows OS by default. There are two files C:\windows\system32\ mstsc.exe and C:\windows\system32\mstscax.dll which are executable files of RDC client. Change them to get new version of terminal service client.
  • Enable Remote Desktop on a remote computer. Check the โ€˜Allow users to connect remotely to this computerโ€™ checkbox via System Properties -> Remote tab (see pic5)
  • Enable users to connect to the remote computer. Add remote desktop users via System Properties -> Remote tab-> Remote Desktop Users.

You must have Administratorโ€™s permissions to make these deploying.

Fig. 6

Figure 6

Appendix B: Samples of the Test Cases

Testing multiuser scenarios

  • Multi sessions _ Two sessions from one client to one server

Pre-conditions:

Client1 is a client machine where the client part of the Application is installed.

Server1 is a server machine where the server part of the Application is installed.

 

 

Step name

DescriptionExpected result
Step 1Connect to Server1 from Client1 via RDP to start Session1The terminal session1 starts successfully.

 

CPU and Virtual Memory Usage on Client and Server are in norm.

Step 2Run the Application and check its basic functionality in Session1The Application starts and works correctly in Session1.

 

CPU and Virtual Memory Usage on Client and Server are in norm.

Step 3Connect to Server1 from Client1 via RDP to start Session2Session2 starts successfully. There are two opened remote desktops on Client1.

 

CPU and Virtual Memory Usage on Client and Server are in norm.

Step 4Run the Application and check its basic functionality in Session1The Application starts and works correctly in Session2 and Session1 simultaneously.

 

CPU and Virtual Memory Usage on Client and Server are in norm.

  • Multi sessions _ Two sessions from one client to two servers

Pre-conditions:

Client1 is a client machine where the client part of the Application is installed.

Server1 is the first server machine where the server part of the Application is installed.

Server2 is the second server machine where the server part of the Application is installed.

Step nameDescriptionExpected result
Step 1Connect to Server1 from Client1 via RDP to start Session1The terminal session starts successfully.

 

CPU and Virtual Memory Usage on Client and Server are in norm.

Step 2Start an application and check its basic functionality in Session1The application starts and works correctly in Session1

 

CPU and Virtual Memory Usage on Client and Server are in norm.

Step 3Connect to Server2 from Client1 via RDP to start Session2The terminal session starts successfully. There are two opened remote desktops on Client1.

 

CPU and Virtual Memory Usage on Client and Server are in norm.

Step 4Start the Application and check its basic functionality in Session2The application starts and works correctly in Session2 and Session1 simultaneous.

 

CPU and Virtual Memory Usage on Client and Server are in norm.

  • Multi sessions _ Two sessions from two clients to one server

Pre-conditions:

Client1 is the first client machine where the client part of the Application is installed.

Client2 is the second client machine where the client part of the Application is installed.

Server1 is a server machine where the server part of the Application is installed.

Step nameDescriptionExpected result
Step 1Connect to Server1 from Client1 via RDP to start Session1The terminal session starts successfully on Client1.

 

CPU and Virtual Memory Usage on Client and Server are in norm.

Step 2Start an Application and check its basic functionality in Session1An Application starts and works correctly in Session1.

 

CPU and Virtual Memory Usage on Client and Server are in norm.

Step 3Connect to Server1 from Client2 via RDP to start Session2The terminal session starts successfully on Client2.

 

CPU and Virtual Memory Usage on Client and Server are in norm.

Step 4Start the application and check its basic functionality in Session2The application starts and works correctly in Session2 and Session1 simultaneous.

 

CPU and Virtual Memory Usage on Client and Server are in norm.

  • Multi sessions _ Maximum allowed count of sessions to one server

Pre-conditions:

Client1 is the first client machine where the client part of the Application is installed.

Client2 is the second client machine where the client part of the Application is installed.

Client N is the umpteenth client machine where the client part of the Application is installed.

Server1 is a server machine where the server part of the Application is installed. Maximum allowed count of remote sessions to Server1 is N.

Step nameDescriptionExpected result
Step 1Connect to Server1 from Client1 via RDP to start Session1The terminal session starts successfully on Client1.

 

CPU and Virtual Memory Usage on Client and Server are in norm.

Step 2Start an Application and check its basic functionality in Session1An Application starts and works correctly in Session1.

 

CPU and Virtual Memory Usage on Client and Server are in norm.

Step 3Connect to Server1 from Client2 via RDP to start Session2The terminal session starts successfully on Client2.

 

CPU and Virtual Memory Usage on Client and Server are in norm.

Step 4Start an Application and check its basic functionality in Session2An Application starts and works correctly in Session2 and Session1 simultaneous.

 

CPU and Virtual Memory Usage on Client and Server are in norm.

โ€ฆโ€ฆโ€ฆ
Step NConnect to Server1 from ClientN via RDP to start SessionNThe terminal session starts successfully on Client N.

 

CPU and Virtual Memory Usage on Client and Server are in norm.

Step N+1Start an Application and check its basic functionality in Session NAn Application starts and works correctly in Session1, Session2 โ€ฆ Session N simultaneous.

 

CPU and Virtual Memory Usage on Client and Server are in norm.

Application functioning for the different users

  • Permissions _Connect to Server as Guest

Pre-conditions:

Client is a client machine where the client part of the Application is installed

Server is a server machine where the server part of the Application is installed.

 

 

Step name

DescriptionExpected result
Step 1Connect to Server from Client via RDP by Guest userThe terminal session starts successfully on Client.
Step 2Start an Application and check its basic functionalityAn Application starts and works correctly according to Guest permissions.
  • Permissions _Connect to Server as User

Pre-conditions:

Client is a client machine where the client part of the Application is installed

Server is a server machine where the server part of the Application is installed. There is a User on the server with usual user rights.

 

 

Step name

DescriptionExpected result
Step 1Connect to Server from Client via RDP by UserThe terminal session starts successfully on Client.
Step 2Start an Application and check its basic functionalityAn Application starts and works correctly according to User permissions.
  • Permissions _Connect to Server as Administrator

Pre-conditions:

Client is a client machine where the client part of the Application is installed

Server is a server machine where the server part of the Application is installed. There is an Administrator user on the server with usual administrator rights.

 

 

Step name

DescriptionExpected result
Step 1Connect to Server from Client via RDP by AdministratorThe terminal session starts successfully on Client.
Step 2Start an Application and check its basic functionalityThe application starts and works correctly according to Administrator permissions.

Sterss test set for the application with terminal

  • Stress testing _Close a RDP session

Pre-conditions:

Client is a client machine where the client part of the Application is installed

Server is a server machine where the server part of the Application is installed.

 

 

Step name

DescriptionExpected result
Step 1Connect to Server from Client via RDPThe terminal session starts successfully on Client.
Step 2Start an Application.The Application starts and works correctly.
Step 3Close RDP session while Application is working.โ€œDisconnect Windows sessionโ€ message appears.
Step 4Click the OK button.The RDP session is closed.
Step 5Again connect to Server from Client via RDP.The terminal session starts successfully on Client.
Step 6Start an Application and check its basic functionalityAn Application starts and works correctly according to Administrator permissions.
  • Stress testing _ Disable network

Pre-conditions:

Client is a client machine where the client part of the Application is installed

Server is a server machine where the server part of the Application is installed.

 

 

Step name

DescriptionExpected result
Step 1Connect to Server from Client via RDPThe terminal session starts successfully on Client.
Step 2Start an Application.The application starts and works correctly.
Step 3Disable network while Application is working.Network is disabled.

 

RDP session soon closes.

Step 4Again connect to Server from Client via RDP.The terminal session starts successfully on Client.
Step 5Start The application and check its basic functionalityThe application starts and works correctly according to Administrator permissions.
  • Stress testing _ Unplug a network cable

Pre-conditions:

Client is a client machine where the client part of the Application is installed

Server is a server machine where the server part of the Application is installed.

 

 

Step name

DescriptionExpected result
Step 1Connect to Server from Client via RDPThe terminal session starts successfully on Client.
Step 2Start an Application.The application starts and works correctly.
Step 3Unplug a network cable while Application is working.Network is disabled. The RDP session is closes in some time.
Step 4Again connect to Server from Client via RDPThe terminal session starts successfully on Client.
Step 5Start The application and check its basic functionalityThe application starts and works correctly according to Administrator permissions.
  • Stress testing _Disconnect a RDP session

Pre-conditions:

Client is a client machine where the client part of the Application is installed

Server is a server machine where the server part of the Application is installed.

 

 

Step name

DescriptionExpected result
Step 1Connect to Server from Client via RDPThe terminal session starts successfully on Client.
Step 2Start an Application.The application starts and works correctly.
Step 3Disconnect a RDP session while Application is working.The RDP session is closed.
Step 4Connect to Server from Client via RDP.The terminal session starts successfully on Client.
Step 5Start The application and check its basic functionalityThe application starts and works correctly according to Administrator permissions.
  • Stress testing _Log off a RDP session

Pre-conditions:

Client is a client machine where the client part of the Application is installed

Server is a server machine where the server part of the Application is installed.

 

 

Step name

DescriptionExpected result
Step 1Connect to Server from Client via RDPThe terminal session starts successfully on Client.
Step 2Start an ApplicationThe application starts and works correctly
Step 3Log off from RDP session while Application is workingThe Log off Windows message appears
Step 4Click the Log off buttonThe RDP session is closed
Step 5Connect to Server from Client via RDP again.The terminal session starts successfully on Client.
Step 6Start the application and check its basic functionalityThe application starts and works correctly according to Administrator permissions.
  • Stress testing _Restart a Server

Pre-conditions:

Client is a client machine where the client part of the Application is installed

Server is a server machine where the server part of the Application is installed.

 

 

Step name

DescriptionExpected result
Step 1Connect to Server from Client via RDPThe terminal session starts successfully on Client.
Step 2Start an ApplicationThe application starts and works correctly
Step 3Restart Server from RDP session while Application is workingServer restarts successfully. The RDP session is closed.
Step 4Connect to Server from Client via RDP again.The terminal session starts successfully on Client.
Step 5Start the application and check its basic functionalityThe application starts and works correctly according to Administrator permissions.

Have a question?

Ask our expert!

Tell us about
your project

...And our team will:

  • Process your request within 1-2 business days.
  • Get back to you with an offer based on your project's scope and requirements.
  • Set a call to discuss your future project in detail and finalize the offer.
  • Sign a contract with you to start working on your project.

Do not have any specific task for us in mind but our skills seem interesting? Get a quick Apriorit intro to better understand our team capabilities.