Virtual Browser Tutorial #1:
First Recording

This site exists for users of Web Performance Load Tester to practice performance testing.

1. Record a Test Case

Start recording by clicking on the red record button:


A dialog will pop up where you can select either virtual or real browsers to record with.  Since this is a Virtual Brower tutorial select one of the browsers in the Virtual Browser section:


Next, simply browse through a couple of the posts on this site, being careful not to do anything too complicated for your first time.  While you record, the URLs will show up in the test case editor.  When you’re done recording, click on the black stop button:

Screen Shot 2013-10-01 at 3.56.52 PM

The newly recorded test case will show up in the Navigator Tab in the “Testcases” folder with the other virtual browser test cases.


2. Replay Test Case

To see if the recorded test case does what you expect, click on the green replay button, and watch the test case play back in the Content View:


Congratuations!  You’ve just recorded your first working test case and done a replay with a single user.   Before continuing, but sure to click on the “back” button to view the original test case and not the replay.


3. Load Test

You can generate a quick load test with up to 25 concurrent users by clicking on the Load Test button to bring up the Load Test Configuration Dialog.



Customize the load test, click OK, and you’re ready to run your first load test by clicking on the green Start button:

Screen Shot 2013-10-01 at 5.48.01 PM

The Load Configuration will show up in the Navigator Section in the Load Configurations folder:

Screen Shot 2013-10-03 at 10.18.14 PM

The load testing screen will show up, and you can click on the Load Engines tab to see details about the load generation, or configure a server monitor in the Servers Tab.

4. View Report

Once the test case is finished you’ll be prompted to view the report, but you can access it any time by expanding the Load Configuration to show the test case report and the date and time it was run.  You’ll want to rename this to reflect what you were testing at the time.

Screen Shot 2013-10-03 at 10.19.59 PM

To navigate to the various sections of the report click on the  dropdown at the top of the report window:

Screen Shot 2013-10-03 at 10.32.53 PM

5. Learn More

This is just the most basic operation, so you’ll want to play around or follow the other tutorials on this site or check out the huge list of tutorials at

Screen Shot 2013-10-03 at 9.41.32 PM


Virtual Browser Tutorial #2:

In this tutorial you’ll learn how to customize a test case so that each virtual user logs into WordPress with a separate account.

1. Record Test Case

Start recording by clicking on the red record button, and navigate to


Next, click on the Login to Post link:            Screen-Shot-2013-10-03-at-8.41.27-PM

This of course goes to the login screen, where the username is “demo”, and the password is “p@perdoll”.

Screen Shot 2013-10-07 at 4.31.37 PM

Clicking the blue “Log In” button will take you a form where you can make a blog post:


Click Publish, and then log out by clicking in the upper right-hand corner and selecting Log Out from the menu:


The test case is over, so stop the recording by clicking on the black stop button:

Screen Shot 2013-10-01 at 3.56.52 PM

2. Create Dataset

Now that the test case is recorded, its time to customize it so that each virtual user has a separate username, password, and blog post title.  This type of customization information is kept in a “dataset”, or a collection of data in rows and columns like a database.  Datasets are stored in the Datasets folder in the Navigation Tab:

Screen Shot 2013-10-03 at 9.02.38 PM

In this tutorial you’ll be shown how to create the needed dataset, but if you want to save time, feel free to use the provided dataset with the title “Login and Post on Blog”, and skip down to Section 3, Customize Test Case.

If you want to learn how to create a dataset, right-click on the repository, and select New->Dataset:

Screen Shot 2013-10-01 at 5.19.31 PM

The dataset editor will now show up in the main window area.  Next, you’ll want to rename the default field name “field” to be “Username” by first clicking on the Field column, below:

Screen Shot 2013-10-01 at 5.22.35 PM

and then clicking on the field name editor icon in the middle:

Screen Shot 2013-10-01 at 5.23.01 PM

which brings up editor:

Screen Shot 2013-10-07 at 5.06.56 PM

Click on the green cross to add one more field named “Blog Post Title”.

The next step is to generate values for each column.  Start by clicking on the “Username” field and then clicking fill:

Screen Shot 2013-10-01 at 5.26.09 PM

You can create data in several different ways.  In this case it makes sense to use a sequence from 1 to 25 with a prefix of “user”:

Screen Shot 2013-10-03 at 9.08.41 PM

Click the “Generate values” button to generate the parameters, and then “OK” insert them into the Username field.

Next, click on the head for the Blog Post Title field, and click on the “Fill” button again.  Again, just the sequence method from 1 to 25 and a prefix to create unique blog post titles.  (Anything would do, as long as its unique.)

Screen Shot 2013-10-03 at 9.10.33 PM

Click “OK”, and the dataset should look like this:

Screen Shot 2013-10-03 at 9.12.03 PM

The final step is to rename the dataset from “New Dataset” to “Logins” by right-clicking on the dataset in the Navigator Tab and selecting “Rename”.

3. Customize Test Case

Once there’s a dataset,  the next step is to locate the parts of the test case you want to customize.  First up is the login page, which you can find by clicking on the web pages until the following appears in the Content Tab:


Click on the Username field, and the field configuration dialog pops up.  Set the Datasource to be “Dataset”, and select either the dataset you configured or the provided dataset “Login and Post on Blog”, and then select the Username field.


Next, select the page after that with the form for creating a blog post:


Click on the blog title form, which should “enter title here” in light grey, and again bring up the field configuration dialog.  Use the same dataset as before, but this time select the field with the title  ”Blog Post Title”.


 4. Replay Test Case

After any customization of a test case you’ll want to see it work with a single user before doing a load test.  Use the down arrow on the button to select various replay options such as Fast Play.


If the replay was successful you’ll see this at the bottom of the test case window:


At this point click on the “Rewind” button to view the original load test:


5. Load Test

To start a load test from the test case window, click on the Load Test button:


This will bring up the load test configuration dialog:

Screen Shot 2013-10-01 at 5.46.45 PM

Click ok to go to the main load test window where you click on the Start button to start the load test.

Screen Shot 2013-10-01 at 5.48.01 PM


Virtual Browser Tutorial #3:
Debugging Test Cases

This tutorial shows a little about what happens when the test case doesn’t do what you think it should be doing.  The test case is making a comment on a blog post, but the WordPress logic won’t allow two identical comments on the same post.

1. Record Test Case

First start recording by clicking on the red record button:


Pick a browser, and navigate to and login as before using “demo” and “p@perdoll”.

Screen Shot 2014-02-25 at 1.58.25 PM


Navigate back to and scroll down for the comment field.  Fill out the field as shown below:

Screen Shot 2014-07-08 at 12.20.37 PM

Click on the Post Comment button, and then click on the black stop recording button:

Screen Shot 2013-10-01 at 3.56.52 PM

Once the recording is finished, it will show up in the Navigator Tab:


2. Replay Test Case

The next step is to replay the test case and see how it works.  The problem is that WordPress contains a method to reject identical comments. Luckily, Load Tester will detect the problem and give you a head’s up comparison so you can see the error: “duplicate comment detected”.

On Windows a head’s up display will appear showing that the website is now giving a “duplicate content” error instead of allowing the post like it did when recorded.


On Mac OSX the error looks like this:

Screen Shot 2014-03-02 at 5.46.49 PM

To view the error on OSX click OK, go to the Errors Tab, and right click on the error, selecting Transaction Compare->Response Content.


A window will appear comparing the replay HTML to the original:


Before editing the test case to fix this issue, you’ll want to click on the “back button” to view the original test case, not the replay.


The solution is to configure the test case so that each comment is unique.  To customize the comment field,  first select the web page with the comment form.  In the sample test case of the same time, the form is in the second web page from the top:

Screen Shot 2014-03-02 at 5.53.37 PM

The web page will be rendered below in the Fields Tab, where you can scroll down and find the the comment field where “What’s up, Doc” was original entered.  You then just double-click on “What’s Up, Doc?” to bring up the editor.


When the Edit Field dialog comes up, change the datasource to Concatenation. Then add press the green ‘+’ button to add a Date/Time datasource. Note that you may need to resize the dialog to see the ‘+’ button on the right.

Edit Field dialog screenshot

The above shows two data sources will be used for this comment field. The second is the current date and time, which will randomize the comment enough so that the test doesn’t trigger identical comment errors.  The first data source the original text constant. Alternatively, you could make the comment unique by reading it from a dataset of comments.

Click OK and then run the replay again.  The comment will now be unique and the error is gone.

3. Load Test

Click on the Load Test button to create a Load Configuration:


Start the load test and notice that errors are starting to show up in the Errors Tab. Note that in this case “errors” means a problem with the test case, not a software bug.


To see the error right click on the first one, and select Transaction Compare->Visual Compare:


The compare window will clearly show that WordPress has thrown up a message that didn’t occur in the recording.  What’s happening is WordPress has a built-in mechanism to prevent anonymous users from putting in comments too quickly, probably to deter spambots.


To fix this issue with the test case, the solution is to follow the instructions from Tutorial #2 so that each virtual user logs in with a unique username and password.