We'll borrow a website created by the wonderful folks at Excilys, a company
focused on delivering skills and services in IT (http://www.excilys.com/). It's
a light banking web application created for illustrative purposes. Let's start a new test plan, set up the test script recorder as we did earlier, and start recording:

Let's start with the following steps:

1. Point your browser to http://bank.jmeterbook.com/public/login.html
2. Enter the username and password in the login form, as follows:
   • Username: user1
   • Password: password1
3. Click on the PERSONNAL_CHECKING link.
4. Click on the Transfers tab.
5. Click on My Accounts.
6. Click on the Transfers tab.
7. Click on the Cards tab.
8. Click on the Operations tab.
9. Click on the Log out button.
10. Stop the proxy server by clicking on the Stop button.

This concludes our recorded scenario. At this point, we can add listeners for gathering results of our execution, and then replay the recorded scenario, as we did earlier. If we do, we will be in for a surprise (that is, if we don't use the bundled recorder template). We will have several failed requests after login, since we have not included the component to manage sessions and cookies needed to successfully replay this scenario. Thankfully, JMeter has such a component, and it is called HTTP Cookie Manager. This seemingly simple, yet powerful component helps maintain an active session through HTTP cookies once our client has established a connection with the server after login. It ensures that a cookie is stored upon successful authentication and passed around for subsequent requests, hence, allowing those to go through. Each JMeter thread (that is, user) has its own cookie storage area. That is vital since you won't want a user gaining access to the site under another user's identity. This becomes more apparent when we test for websites requiring authentication and authorization (like the one we just recorded) for multiple users. Let's add this to our test plan by right-clicking on Test Plan and navigating to Add | Config Element | HTTP Cookie Manager.

Once added, we can now successfully run our test plan. At this point, we can simulate more load by increasing the number of threads at the thread group level; let's go ahead and do that. If executed, the test plan will now pass, but this is not realistic. We have just emulated one user, repeating five times essentially. All threads will use the credentials of user1, which means that all threads log in to the system as user1; that's not what we want. To make the test realistic, what we want is each thread authenticating as a different user of the application. In reality, your bank creates a unique user for you, and only you or your spouse will be privileged to see your account details. Your neighbor down the street, if he uses the same bank, won't get access to your account (at least we hope not!). So, with that in mind, let's tweak the test to accommodate such a scenario.