In the particular case of this paper, we built some tests for GeneXus Ruby applications. As Ruby generates the presentation layer (html) apart from the business logic layer (ruby source code), making web stress tests for ruby is a little bit different than making them for the other generators. That's because the Ruby interface is made up of html files, which cannot be used in the simulation of hitting the page n times concurrently. The solution is to call the Ruby application directly bypassing the html invocation.
This does not apply to the rest of the generators (.NET or Java), where you call directly the .aspx or servlet, respectively.
Nevertheless, the technique to build the POST test scripts by using ProxyTrace (as you will see later in this document) is valid for all the generators.
Configure the Thread Group regarding the concurrency you want to simulate. Take into consideration the definition of the different parameters that Apache Jmeter needs to run (see the documentation if necessary).
Besides, configure all the listeners you consider appropriate to trace the results, and take a look at the meaning of the different measures .
As previously explained, in the case of the Ruby generator you have to use the real invocation to the application logic. In order to know the URL to use, one alternative is to use FireFox with the FireBug plugin installed, and inspect the real URL invocation, as shown in the figure below:
So, just do the following:
1. Paste the usual URL you want to test in the browser (http://server/easydebugRubyEnvironmet/customer.html?UPD,7)
2. Inspect the POST URL in the FireBug console , by clicking "Copy location with parameters"
3. Paste that location in Jmeter, as shown in the figure:
In this case we'll build a script for inserting data through a transaction form.
The steps are the following:
1. As we did in the previous section, we'll get the invocation URL of the transaction in insert mode -by using FireBug for example, or any other similar tool. You can get the same results by using proxytrace, for instance:
2. Suppose we want to automate the insertion of the following form:
After confirming, a POST will be sent to the server, so you need a way to know the parameters of that POST, in order to build the test script to automate it afterwards.
What you need is any proxy tool like tcptrace or proxytrace to intercept the dialog between client and server and inspect the parameters that have to be specified in the POST.
Note that in this case there are four parameters with their corresponding information, that are sent in the body of the POST request (they are signaled with different colors):
3. Add the test case in Apache Jmeter as follows, regarding the parameters explained above. Specify the invocation URL in the path (the call to the transaction in insert mode)
