navigator-tab

Real Browser Tutorial #1:
First Recording

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

1. Start Recording

Start recording by clicking on the red record button, and a selection dialog will appear showing available Real Browser and Virtual Browser recording options.

step-two-record

Since this is a Real Browser tutorial select Chrome from the Real Browser section on top, shown below.

real-browser-selection

2. Browse

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 “Browser Testcases” folder:

real browser testcases

3. Replay Test Case

To see if the recorded test case does what you expect, click on the green replay button.  A live browser window will appear you can  watch the test case play back.

Don’t mess with the browser while its playing back or you could put the browser in a different state and cause it to fail.

replay button

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 black “Stop” button to officially end the replay and get rid of the browser window.

stop-button

4. Load Test

You can generate a quick load test with up to 5 concurrent users by clicking on the Load Test button to bring up the Load Test Configuration Dialog.  Simulating more than 5 concurrent on your desktop with real browsers isn’t advisable since the browser measurements wouldn’t be accurate, and the windows take over your computer.

step-four-run

Screen Shot 2013-10-01 at 5.46.45 PM

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.

5. 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

6. 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 www.webperformance.com.

Screen Shot 2013-10-03 at 9.41.32 PM

login

Real Browser Tutorial #2:
Usernames and Passwords

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

step-two-record

Start recording by clicking on the red record button, and select the Chrome icon in the Real Browsers section to start a Real Browser recording.

real-browser-selection

Browse to http://demo6.webperformance.com, click on the Login link in the bottom left-hand side of the page:

Screen Shot 2014-02-25 at 1.58.25 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

Click the blue “Log In” button, then click on Posts, and then click on Add New:

Screen Shot 2014-02-25 at 2.12.28 PM

From there enter a title and post content:

Screen Shot 2014-02-25 at 2.14.06 PM

When you’re finished click on the blue Publish button:

Screen Shot 2014-02-25 at 3.09.52 PM

The post has been published and the test case is complete, 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 where you entered the username and password:

Screen Shot 2014-02-25 at 4.26.15 PM

Select the line “Type demo into element with ID = “user_login” and then click on the edit button shown below in red.

Screen Shot 2014-02-25 at 4.26.30 PM

This will popup and editor dialog;

Screen Shot 2014-02-25 at 4.26.59 PM

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 line for typing in the blog post title.  You can see it below “Type “Test Post #4″ into element with ID = “title:

Screen Shot 2014-02-25 at 4.41.10 PM

This will be up the editor at the top of the window:

Screen Shot 2014-02-25 at 4.42.22 PM

Click on the circled button in red to bring up the field configuration dialog.  Use the same dataset as before, but this time select the field with the title  ”Blog Post Title”.

Screen Shot 2014-02-25 at 4.44.18 PM

 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.

Screen Shot 2014-02-25 at 4.46.16 PM

While the replay runs a browser window will popup, and the fields being manipulated will blink red.  Don’t touch the browser during this process or it could change the webpage and cause the test case replay to malfunction.

When the test case has finished playing back click on the black “stop” button to finish.

Screen Shot 2014-02-25 at 4.51.49 PM

5. Load Test

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

Screen Shot 2014-02-25 at 4.53.43 PM

This will bring up the load test configuration dialog. Note that the demo is limited to playing back 5 real browsers at one time.

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

real-browser-debugging

Real Browser Tutorial #3:
Debugging

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 simple:  login to wordpress, hover over the user icon in the top right-hand corner, and then click on Logout.  This will fail because the recorder does not capture mouse movements. If it did, your test cases would be littered with mouse movement commands and 99% of those would unneeded. This tutorial shows you what happens when a test case fails, and then demonstrates how to fix it.

1. Record Test Case

First start recording by clicking on the red record button:

step-two-record

Click the Chrome Real Browser, and navigate to http://demo6.webperformance.com.

real-browser-selection

Click on the Login link:

Screen Shot 2014-02-25 at 1.58.25 PM

 

And then enter the username “demo” and password “p@perdoll”:

Screen Shot 2014-02-26 at 4.51.23 PM

Once you’ve logged in immediately hover over the text Howdy, Demo User in the top right-hand corner of the site:

Screen Shot 2014-02-26 at 4.52.48 PM

 

This will cause the Logout link to appear:

Screen Shot 2014-02-26 at 4.53.48 PM

 

Click on the “Log Out” menu item and then stop recording.

 

Screen Shot 2013-10-01 at 3.56.52 PM

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

real browser testcases

 

Remember to right-click on “New Recording” and change the name to something more appropriate.

2. Replay Test Case

The next step is to replay the test case and see how it works.  Click on the green replay button, below, and watch the browser attempt to login to WordPress.

Screen Shot 2014-02-25 at 4.46.16 PM

When the browser tries to find the “Log Out” link, however, this error will appear because this link only appears after a hover.

Screen Shot 2014-02-26 at 4.45.14 PM

3. Fix Test Case

The problem occurred because the Real Browser Recorder doesn’t do hover mouse events.  If it did the recording would be littered with mouse events making the test case difficult to read and edit.  The solution is to insert a “Hover” event right before clicking on “Log Out”.

First, select the test case line right before the error:

Screen Shot 2014-02-28 at 12.08.02 PM

Then add a step by clicking on the add step button:

Screen Shot 2014-02-28 at 12.09.41 PM

Choose Mouse Move as the type:

Screen Shot 2014-10-14 at 11.19.52 AM

Change the locator type to “text”, and type in Howdy, which will match the first part of the area where you want the mouse to hover.  As the element is matched it will be highlighted in yellow in the browser:

Screen Shot 2014-10-14 at 11.23.12 AM

Now its almost ready to go.  The remaining issue is that after moving the mouse, the user must wait for the menu to appear. To do this, configure a wait condition on the step.  Open the step properties by choosing Properties from the pop-up menu (left-click the mouse move step). Choose the Measurement tab. Choose Element is Clickable from the drop-down and choose from next step in the next drop-down that appears:

SetIsClickableCondition

The test case is now ready to try out by clicking on the replay button:

Screen Shot 2014-02-25 at 4.46.16 PM

virtual-browser-selection

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:

step-two-record

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:

start-recording

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.

virt-browser-nav

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:

step-three-replay

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.

Screen-Shot-2013-10-14-at-3.19.05-PM

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.

step-four-run

Screen-Shot-2013-10-01-at-5.46.45-PM

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 www.webperformance.com.

Screen Shot 2013-10-03 at 9.41.32 PM

login

Virtual Browser Tutorial #2:
Usernames/Passwords

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 http://demo.webperformance.com.

step-two-record

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:

Screen-Shot-2013-10-03-at-8.43.34-PM

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

Screen-Shot-2013-10-03-at-8.52.59-PM

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:

Screen-Shot-2013-10-03-at-9.27.08-PM

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.

Screen-Shot-2013-10-03-at-9.27.59-PM

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

Screen-Shot-2013-10-03-at-9.29.58-PM

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”.

Screen-Shot-2013-10-03-at-9.31.31-PM

 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.

step-three-replay

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

Screen-Shot-2013-10-03-at-9.46.33-PM

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

Screen-Shot-2013-10-14-at-3.19.05-PM

5. Load Test

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

step-four-run

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

additional-config

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:

step-two-record

Pick a browser, and navigate to http://demo6.webperformance.com and login as before using “demo” and “p@perdoll”.

Screen Shot 2014-02-25 at 1.58.25 PM

 

Navigate back to http://demo6.webperformance.com 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:

Screen-Shot-2013-10-01-at-3.58.07-PM

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.

Screen-Shot-2013-10-01-at-4.51.12-PM

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.

errors-view

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

duplicate-content-text

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.

Screen-Shot-2013-10-14-at-3.19.05-PM

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.

whatsupdoc

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:

step-four-run

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.

Screen-Shot-2013-10-03-at-10.48.05-PM

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

Screen-Shot-2013-10-03-at-10.48.35-PM

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.

Screen-Shot-2013-10-03-at-10.49.40-PM

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.