This is the sentence I have learnt on the latest Loadrunner training I was teaching. University students study C and C++ programming language optionally nowadays and when they do, they only use it for a semester. Moreover they are quickly seduced by programming languages running in managed environments (Java, .Net). No surprise: these environments pamper to the new breeds of programmer, these new entries never have to deal with the inner workings of pointers, memory allocation problems or bogus string magic.
I often hear devs and QAs using Loadrunner complaining about using C.
String handling, dynamic memory handling and lack of regular expressions are just a few of these complaints.
There are several techniques in Loadrunner that can be successfully used to work around some of these conditions.
- Use local (stack) variables whenever possible (instead of dynamically allocated memory). Local allocations are automatically released as the function is finished. This mitigates memory allocation issues (leaks).
- Loadrunner parameters are versatile and powerful tools. Memory allocation for Loadrunner parameters is handled out-of-the-box, the script author does not have to worry about internal allocation and clean up .
- Accordingly, lr_eval_string() can be used to compose strings conveniently (as an alternative to C’s sprintf()). Lr_eval_string() allocates memory for the result string, and those allocations are released at the end of the user iteration automatically.
I fully understand, coding certain actions in a VuGen C script can be tiring sometimes. However with VuGen, the choice is yours to create the script in Java or in C. It brings up the question, why do Loadrunner testers choose C extenze pills instead of the comfort of Java? Well it looks like Mercury made its own choice - and voted for C.
VuGen has two Java-based script-types: Java Vuser and Java Record Replay. Java Vuser is a raw Vuser, implemented in Java. Every C function in the Loadrunner API has a Java counterpart, so manual coding should not be a problem.
Java Record replay script-type promises the ability to record applications written in Java. However the recording capability is restricted to only certain protocols, like CORBA, RMI, JMS. The recorder is responsible for starting the (Java) application, and network traffic belonging to these protocols are recorded.
For an unknown reason recording does not support HTTP, therefore recording websites (and web services) is not supported. However, VuGen offers a SED script to transform C-based web recordings to Java. For this you have to grab a C-based Action recorded in a Http/WEB script, manually let SED do the transformation, then paste the result into a Java-based script.
With this step Java programmers get quickly out of their comfort zone, not to mention the hassle of updating scripts when user actions are required to be re-recorded. Also worth considering, that a Java vuser may consist of only one single Java file, which can grow to an unmanageable size in case of a long user scenario. Decomposition seem not to be supported.
The Bottom line is this: VuGen web scripts belong to the realm of senior programmers and to those young professionals who endeavour to script in C. The rest of the planet composes web-scenarios via point and click using tools such as Loadrunner AJAX Truclient…