JavaScript is rapidly becoming the driving force behind the Internet. Any website, small or large, has some parts written with JavaScript to enhance the user experience. Browser vendors constantly improve the speed in which JavaScript is parsed and executed in their browsers. This increase in speed is now to the point that it’s become one of the key benchmarks for every browser version. When we performance test a website, a web application, or even a REST service we can be sure that JavaScript plays some role in the business process we are about to test.
HP LoadRunner uses C as the native language for scripting HTTP/HTML scripts, but it allows integration and use of JavaScript code with relative ease. To learn more about this integration, consult Using the LoadRunner JavaScript Engine chapter in the HP LoadRunner User Guide.
Why would we want to use JavaScript in our script?
There are four main reasons:
JavaScript often offers a more intuitive experience which is easier to implement than in C.
The JavaScript regular expression library simplifies the challenge of working with regular expressions.
Numerous JavaScript libraries that assist with any coding task (e.g. string manipulation) are available.
Client-side logic is often implemented in JavaScript. Inserting snippets of the original JavaScript code means you don’t have to translate the JavaScript client logic into C code.
This article explores the following scenario: We are testing a web server application which is used for authentication. Our goal is to receive an authentication token from the server and use the token in all future communication with the server. The authentication process is as follows:
Send an HTTP GET request to the “/challenge” REST API to get a challenge string.
Perform some calculation on that string and generate a unique password using a proprietary encryption algorithm.
Send a GET request to the “/token” REST API passing the password generated in step 2 as a query parameter.
For this scenario we run a simple web server which serves static values (using Node.js). The server code is available as an attachment to this article (web_js_example_server.zip).
Getting the challenge string
Our first goal is to obtain the challenge string from the server. We type the following step into our script to make the required REST API call:
web_custom_request("challenge",
"URL=http://localhost:3000/challenge",
"Method=GET",
"RecContentType=application/json",
LAST);
We want to capture the server response in a parameter. To this end, we add a web_reg_save_param step before our request and save the response body into a parameter named “challenge”:
web_reg_save_param("challenge","LB=","RB=","Search=Body",LAST);
Calculating the password
Now that we have the challenge string we can use some JavaScript manipulations to generate the password.
First we need to enable JavaScript for our script. To do this, open the Run-Time Settings (F4) and go to Internet Protocol > Preferences > Set advanced options. Click on Options…, and in the dialog that opens (scroll all the way down), set Enable running JavaScript code to Yes (as in the screenshot below) and then click OK on both dialogs.
Next we need to create a new JavaScript file that contains our code. Right-click the Extra Files node in the Solution Explorer and select Create new file… Name the new file calcPassword.js and press OK.
We know that the string returned by the server is a JSON object which contains an array with some strings. The last member of that array is a number which tells us the index of the string we want to extract from the array and encrypt using the proprietary algorithm. We add a new JavaScript function that extracts the value from the array.
function getPassword(stringData){
var data = JSON.parse(stringData);
var index = data[data.length - 1];
var value = data[index];
}
The required value is stored in the “value” variable, and now we have to apply the encryption function. Luckily for us, the server code is written in JavaScript since it runs on Node.js and it already has a module called crypto.js which implements the proprietary cryptographic algorithm. Import the crypto.js file into the script by right-clicking the Extra Files node in theSolution Explorer and selecting the Add files to script… option. Select the file crypto.js from our server folder (you would typically ask for this file from the R&D team). Edit the file so that it contains only the function we need (this step is not mandatory and is performed for clarity, we could use the original file):
function encrypt(data) {
return data.toString().split("").reverse().join("");
}
(I don’t recommend using this function as a real life encryption method as it only reverses the input string J)
Now we can update our getPassword function to call the encrypt function:
function getPassword(stringData){
var data = JSON.parse(stringData);
var index = data[data.length - 1];
var value = data[index];
return encrypt(value);
}
Now we just add the web_js_run step to run our JavaScript code:
web_js_run(
"Code=getPassword(LR.getParam('challenge'));",
"ResultParam=password",
SOURCES,
"File=crypto.js", ENDITEM,
"File=calcPassword.js", ENDITEM,
LAST);
The parameters are straightforward but you can always consult the product documentation if you are not sure. In this case we call the getPassword function defined in the JavaScript file. We want to pass it the parameter we got from the REST API call. We use the LR.getParam utility function (implemented in JavaScript) to pass that parameter as string to thegetPassword function. The result of the function is stored in the parameter defined by the ResultParam argument (“password” in our case). Finally we have the source files that contain our JavaScript code added as “File=…” arguments separated by the ENDITEM constant.
Obtaining the token
Our final step is obtaining the token from the server. We could just use the password parameter to create the URI, but that would be a mistake because we need to encode the URI first. We can do it easily using another web_js_run call (since JavaScript natively supports URI encoding). This time the call is quite simple:
web_js_run(
"Code='http:/'+'/localhost:3000/token?password=' + encodeURI(LR.getParam('password'));",
"ResultParam=uri",
LAST);
(Note that we split up the ‘//’ string in the ‘Code’ parameters into two separate sub-strings. If we were to pass it in as a single string “//”, LoadRunner would report error -26312, “Using "//" line comments in argument of type 'code' is illegal/unsupported”)
Now we add the step that makes the final call with the calculated URI to the appropriate
REST API:
web_custom_request("get token",
"URL={uri}",
"Method=GET",
"RecContentType=application/json"
LAST);
The result from the server is as expected:
Action.c(25): t=1987ms: 38-byte response body for "http://localhost:3000/token?password=damhA" (RelFrameId=1, Internal ID=4)
Action.c(25): "4f6dfbce-412f-4c6c-8bac-7d7d66a6b822"
Conclusion:
Enhancing your HTTP/HTML script with JavaScript code is easy and useful. There are numerous scenarios where this capability can be employed to shorten scripting time and create a much more robust script. The HP LoadRunner User Guide is key to understanding the full potential of this feature as it includes a built in function library that links the JavaScript code to your test script’s code.
