BrowserMob supports the ability to pass in parameterized data in your load test scripts and some of the ways of handling this have been explained in an earlier post.
But many a time we come across scenarios which require a unique login per transaction, such as that of a University where a unique user ID is required to fill out a college admission form. A login used once cannot be re-used in these situations. In this post, we’ll explain one way of handling parameterization for these types of scenarios.
Consider the following basic RBU script that uses a fixed username and password of ‘joe’ and ‘password’:
var selenium = browserMob.openBrowser(); browserMob.beginTransaction(); browserMob.beginStep(“Step 1”); selenium.open(“http://example.com/login”); selenium.type(“username”, “joe”); selenium.type(“password”, “password”); selenium.clickAndWait(“login”); browserMob.endStep(); browserMob.endTransaction();
Let’s look at how we can parameterize the username and password fields ensuring that the script uses a unique username/password combination every time it runs.
To start with we need to estimate the number of logins needed per concurrent user or in other words number of estimated transactions per concurrent user during the course of the test. This, of course, depends on a lot of factors such as average page load times, average think time between steps, number of steps in the scenario, etc. Below is a sample illustration of how to calculate this number.
Number of steps in scenario = 10 Total number of intervals = 10 Length of each interval = 360 seconds Average page load time = 3 seconds Average think time between steps = 5 seconds Total transaction length = Total number of steps * (Average page load time + Average think time between steps) = 80 seconds Transactions per interval per concurrent user = Length of each interval/Total transaction length = 360/80 = 4.5 (rounding off to 5)
Total number of transactions per concurrent user for the entire test = Transactions per interval per concurrent user * Total number of intervals = 5 * 10 = 50
Since this number is based purely on the above assumptions and because the load times could vary during the actual test, it is always better to bump this number up a bit to ensure you have enough unique ids to cover all the possible transactions.
Hence, assuming we are testing with 50 concurrent users and 100 transactions per concurrent user during the course of the test, here is how we can go about with the parameterization:
var loginsPerUser = 100; var userNum = browserMob.getUserNum(); //starts from index 0 var txCount = browserMob.getTxCount(); //starts from index 1 var id = (userNum*loginperuser) + txCount; // Since the ‘userNum’ starts from index 0, for the first user, we just append the ‘txCount’ // whereas, the ‘id’ from above is appended for the remaining users if (userNum == 0) { var userId = ‘test_’ + txCount; } else { var userId = ‘test_’ + id; }
This way ‘test_1′ to ‘test_100′ will be utilized for user 1, ‘test_101′ to ‘test_200′ will be utilized for user 2 and so on. The biggest advantage of this method is that there is no need to reference any external csv file for the parameterization although you do need to ensure that these logins exist in your database ahead of the test.
Here is the parameterized script:
var selenium = browserMob.openBrowser(); browserMob.beginTransaction(); browserMob.beginStep(“Step 1”); selenium.open(“http://example.com/login”); selenium.type(“username”, userId); selenium.type(“password”, “password”); //we are assuming that the password is the same for all users selenium.clickAndWait(“login”); browserMob.endStep(); browserMob.endTransaction();