New Features: Virtual User Think Time and Unique Parameterization
Due to requests from many of our users, we’ve rolled out two new features to BrowserMob:
- The ability to specify “think time” for virtual users with the setSpeed and pause commands.
- The option to reference the unique “virtual user” ID, which makes testing sites that don’t allow concurrent user logins much easier to test.
Here’s a brief summary of each feature. You can consult our documentation or our support team if you have any additional questions.
New Think Time Support
BrowserMob has always had support for the setSpeed and pause commands that are bundled in to Selenium, but until now those artificial delays encoded in the script would be interpreted as simply slow loading pages. Of course, this is not ideal for our users who wish to simulate real user behavior, complete with think time, but still want to know what the raw page load times were.
Now these commands will still work as expected, but instead the detailed data captured will differentiate between active and paused time. That is, you can determine how much time was spent actively interacting with the page (clicks, downloads, page load times, etc) and how much was spent waiting. This data is available at both the page level and the transaction level.
If you’re not familiar with the setSpeed and pause commands, check out the Selenium reference command documentation embedded inside of Selenium IDE. In short, setSpeed allows you to control the default pause between every single action (open, click, type, dragAndDrop, etc). The pause command is similar, but instead is a one-time pause rather than for every command.
The times specified for both is in milliseconds, so “setSpeed 5000” would instruct BrowserMob to wait five seconds in between each command. Similarly, “pause 3000” would tell BrowserMob to make all virtual users pause for three seconds when running tests.
Unique Virtual User Identification
Parameterizing/randomizing data in a load test is very common. BrowserMob supports this with some simple JavaScript code, as demonstrated in our recent video blog post. But sometimes random data won’t work. For example, some applications only allow one user to be logged in at a time. If we randomly selected usernames for each run of a test, there is a chance two virtual users could log in at the same time with the same username, causing an artificial test failure.
The solution to this problem is to support locking parameterized data to each virtual user. Then if you have 100 VUs in a test, then you’d have an array of 100 usernames, each one assigned a virtual user. BrowserMob now supports this technique with the new #{browserNum} variable.
For example, this command randomly types in one of 10 usernames in to a login field:
storeEval [‘bob’, ..., ‘mary’][Math.floor(Math.random() * 10)] randomUser
type username_field ${randomUser}
But if we wanted to ensure that each VU got it’s own username, we’d do:
storeEval [‘bob’, ..., ‘mary’][#{browserNum}] randomUser
type username_field ${randomUser}
The #{browserNum} variable will always be the same for each virtual user. It is also guaranteed to be unique across all active virtual users. With the above code, we’ve now ensured that no username will be used in overlapping test scripts.
Summary
We hope you enjoy these new features. Please remember that we’re always working to make BrowserMob the most realistic and easiest load testing service available. If you have feature ideas, please don’t hesitate to let us know.
Explore posts in the same categories: Announcements