GXtest and Performance Testing
 |
 |
 |
Contents |
Introducing Performance Testing
An essential point to consider about performance tests is that, for many reasons, it is impossible to test every functionality of an application. Having that in mind a new problem comes up: Which functionalities should we test? Which test cases should we select to automate and include in a performance test?
To solve these problems we can resort to historical data taken for the previous system (in case there is a previous version running), to get an idea of the active users, the number of times each functionality is used, etc. If we don’t have that possibility, we can always turn to our application’s expert’s knowledge (project managers, developers, users, or any other person who can estimate which functionalities are the most adequate to be included in our tests).
After we have selected which test cases to run, we have to automate them. Making the scripts is generally the most time consuming part of the project. Luckily, GXtest helps us in this task, reducing our efforts considerably.
When do we use performance testing?
Basically, there are two strategies we can use to approach performance testing. The traditional one is to start automating our test cases after the product is finished, so there won’t be changes in the source code. This strategy has the advantage of not having to waste time in maintaining our automated test cases, given that the system version will not suffer any changes. However, its main drawback is that we could find a design or architectural problem late in the developing process that will require a major effort to reconstruct the system.
The other way to approach a performance project is starting with the tests alongside the development stage, while the main functionalities are being released. This has the advantage of being a proper time to discover any design, architectural or even functional errors, implying less effort in solving them. Nevertheless, the cost of maintaining the performance test cases can grow considerably, given that they need to be adapted every time a change in development takes place. When maintaining the test cases, the use of GXtest as an automation tool is fundamental, due to the fact that it allows us to quickly adapt our automated test cases to the changes in the system.
GXtest and Performance Testing
First thing we need to clarify is that for performance testing we need a specific tool designed for this.
The second clarification needed is that GXtest is not a tool designed for performance testing: is specifically designed for functional testing.
Having said that, GXtest helps us generate performance tests (which execute in other tools), reducing about 80% of the time it would take to generate the tests manually.
The performance test tools run scripts (which have a series of steps) with requests at protocol-level (commonly HTTP), which simulate the interaction of a user with the application. Since the tool must be able to simulate hundreds or thousands of users simultaneously, the interaction with the server is done through these requests, without using the browser (as a real user would). The problem with these scripts is that they are expensive to write; the coding, the analysis of responses, parameterization of the test data, etc. are time-consuming.
GXtest generates these performance scripts automatically from a functional test case, so we can import the script in our performance tool and execute them.
Currently, GXtest supports the generation of performance scripts for JMeter and OpenSTA, two free performance testing tools that are highly widespread in testing communities worldwide.
Enable performance scripts generation in GXtest
In order to generate the required files for the performance tests using OpenSTA or JMeter, it is necessary to enable the generation in the menu Options -> Local Settings.
There we can enable or disable the file generation, and also configure the location of the Fiddler tool and the OpenSTA Modeller.
