Performance testing tool for Desktop applications
I am suffering to find the best performance testing tool for my application. Now I am working on Desktop application installed in Windows XP and is developed by using infragistic tools. I tried loadrunner, jmeter and VSTS tools. In these tools VSTS coded UI test recognizing infragistic tools. But I failed to run the loadtest on multiple instances.
Please suggest any other tool to record infragistic tools and run the loadtest on multiple simultaneous users.
I am eagerly waiting for your respone. Thanks in advance.
Re: Performance testing tool for Desktop applications
Infragistics is a GUI level item. Most test tools work at the protocol level so you do not have to run a full GUI for each set of requests representing a client data flow. I have worked on a lot of apps with custom controls from various vendors for display purposes, but at the protocol level they were all the same.
If you have to operate the third party custom GUI control then you will have to use a GUI tool. If you are willing to consider the path normally traversed by performance testing tools, operating at the protocol level, you will likely find that tools can be completely ignorant of the controls. This is true of LoadRunner (which I have used with Infragistics controls), SilkPerformer, QALoad (Does this tool even exist any longer) and SilkPerformer.
Look to the architecture of your desktop application. What is the next upstream component that the Desktop application communicates with? Is this a database server? Is this an application server? How is the connection made? Oftentimes you can find information on how the connection is made by the installation guide for the application which lists depedencies, such as ODBC, SQL Server Client, ORACLE Client, DCOM version xxxxx, etc....
The next upstream component combined with the communication information can provide insight as to which protocol you need to record. As you have LoadRunner, you can also use a Windows Sockets virtual user to find out what the next upstream component is from the desktop client. How? All client communications libraries announce themselves as part of the protocol handshake from client to server as part of the first couple of send/recv buffers which are passed back and forth. If a standard server is connected to, such as a database server, then the server will usually announce itself (along with its version). This protocol negotiation/handshake which takes place upon connection can provide great insight into the protocol selection. The only complication is whether a mapping layer, such as ODBC, is used on top of the actual communication. In such a case you may have the luxury of selecting either ODBC or the native communications protocol.
Replace ineffective offshore contracts, LoadRunnerByTheHour
. Starting @ $19.95/hr USD.
Put us to the test, skilled expertise is less expensive than you might imagine.
Twitter: @LoadRunnerBTH @PerfBytes