One scenario represents one type of user. Put another way, each scenario will click on different pages or submit various forms because that’s how real users behave on your site. It is common for web applications to have some users login and perform advanced functions, while other users are just casually viewing some content anonymously.
We recommend that you analyze any data you have currently regarding the types of users and their traffic patterns on your site. Then try to create a test plan that emulates those patterns as closely as possible in order to achieve load testing that demands system resources like real users will. Most people create several scenarios to accurately reflect different types of users. Scenarios within a test plan execute simultaneously in order to hit your site with the correct mix of traffic.
You control the weighting of each scenario by giving it a number relative to the others. For example, if you have 2 scenarios and you give one a weighting of 4 and the other a weighting of 1, then the first will generate 80% of the traffic and the second 20%. This 80/20 could be realistic for an retail e-commerce site where most of the people (80%) are browsing the product catalog, while a minority of people (20%) are going through a buying experience. You can of course throw in a low-weight scenario to represent some internal employees adding products or issuing refunds.
There is no limit to the number of scenarios you can create in a test plan. We encourage you to build as many as necessary to accurately reflect the real traffic patterns on your site. That will give you the most meaningful metrics for tuning your applications.
We also simulate the user “think time” with random pauses between steps. Real users click on something, then read the page or fill in a form, and then click on something else. Thus, you don’t want to have a simulated virtual user clicking on something every .5 seconds – it would not give you meaningful results if you want to see how your site holds up in the real world.