As we are so much used to test web applications using commercial / open source tools, we sometimes forget that we are testing at network communication protocol level. As web applications are usually HTTP or HTTPS, all performance testing tools readily supports this protocol. As we capture & replay the network communications between the client and the server, any UI level, client side (browser-side) rendering time or processing time or loading time of JS/CSS requests are not usually captured by performance testing tools.
A Desktop application is built using any of the below 3 architectural styles –
- Monolithic or 1 tier application (all the necessary components / interfaces are built in a single machine without the need for network communication. Hence the installed application is used by 1 user at any time).
- 2 tier application (either a thin client which is not a browser is used by the end user which communicates with the server through a network or a rich thick client is used by the end user, Microsoft Outlook is the best example which communicates with the server over a network).
Incase of monolithic application, there is no need for carrying out multi-user performance testing. Performance testing for such application should focus on system performance across different system hardware configurations. Measuring system resource (CPU, Memory & Disk) consumption levels becomes vital incase of monolithic application performance analysis.
Incase of 2 tier client-server (thin or thick client) application, there is a network communication involved to communicate with the server. The type of communication varies depending upon the implementation technology. Hence, understanding the application internals, technology stack, upstream architectural components & its communication protocols, ports used, etc are very important to finalize on the performance testing tool. System design document or thick client installation manual contains some of these required details specifying the application dependencies & client libraries used.
If the client uses web service endpoints to communicate with application server or directly communicates with database server over network, then server performance testing creating realistic user load becomes essential.
For client-server applications implemented using .NET technology stack, usage of VSTS tool (using record/playback or Coded UI mode) could be the best choice for performance testing. Coded UI mode would be the final choice if client-server communications could not be easily recorded & played back. Open source tools like JMeter can also be used for testing web services (SOAP / REST / WCF) or for database level performance testing.
If the thin or thick client application makes HTTP calls to external server, the prevalent approach is to use tools like Fiddler or Apache JMeter with proxy settings (thick client application should also uses the same proxy) or HP LoadRunner to record all the network communication traces & analyze how the communication calls can be reproduced during performance testing. This approach is very similar to web application performance testing. JMeter's "HTTP Proxy Server" can be used to record the network calls while using thin or thick client and can be played back. The recorded script has to undergo customization like test data parameterization, dynamic value handling through correlation, response validation through assertions, adding realistic think times using Timers, etc in order to run realistic performance tests.
In commercial segment, HP Load Runner is the most preferred option as it provides various protocols like WinSock, RDP, Citrix, TrueClient, etc other than HTTP Web protocol. These protocols are useful for desktop application performance testing. Usage of HP LoadRunner’s protocol advisor is prevalent to finalize the right protocol to be used for carrying out performance tests for desktop applications.
Here are some of the key tools to be considered for desktop application performance testing:
- Apache JMeter
- HP LoadRunner
- MS VSTS
- Login VSI (for VDI environments)
- SOAPUI /LoadUI (for web services)
- WCFStorm (for WCF web services)
If none of the above tools support, we need to have development skills to write our own test utility using any of the scripting languages like Perl or Python, etc or sometimes in .NET or Java programming languages.