Web Application’s Performance & Load Testing

Using Visual Studio

Steps to Go:

In Visual Studio, there are separate test types for Web Performance Test and for Load Test. The

difference seems subtle, but they are massively different. Web Performance Tests are to create

HTTP calls to replicate user behavior while using a web site. A load test take automated tests

(Web Performance Tests, Coded UI Tests and Unit Tests etc.) and creates different scenarios to

test.

Basically, Web Performance Testing verifying the website responses for each request and

responses in multiple scenarios such as slow network speed, rendering on different browsers or

with different numbers of users at a given point in time. This helps us to identify the problems

and rectify them before they happen in the actual production environment. Web Performance

Testing also helps in finding out if the hardware can handle the maximum expected amount of

requests at a time or needs additional hardware to handle the traffic and respond to multiple

user requests.

I will create a simple web test and scenario to run. To start, we will use Visual Studio (load testing

is only available in the Ultimate version) and create a new Web Performance and Load Test

Project.

Procedure:

First of all we have to launch visual studio 2013& we have to select new project.

Figure 1: Launch Visual Studio After Selecting the new project the new window will come up front of us this way.

Figure 2: Create a new Web Performance and Load Test Project from the New Project dialog After Creating the Project successfully the system will throw a new window of our project. In there we can rename our project & after pressing OK a new project window open.

Figure 3: web test recording page After creating the project we need to add a database server to store the result for analysis. For this we have to go to the LOAD TEST tab and press Manage test Controllers. Select Browse button. Then enter the Database Server name or location, Database server username and password and Select the Database name in which we want to store our result from the dropdown menu.

Figure 4: Select Database to store result of the test. By default, the project creates a blank WebTest1.webtest. In here we rename webtest Item to Cash_Transaction. Now we have to add request for every page that we have to enter & that we want to test by right clicking of WebTest item. Actually in here we add request to and Map a Url (Individual URL of our page) of our project individually .Now We will run the test for cash transaction page. At first we have to add request for Login page & after login user go to the home page. So we have to add request for home page & at last we have to add request for cash transaction page& at last we add the request of our login page because after sign out the user will be redirect on login page. So we add same login page as the fourth request on our project.So we added four Requests on Cash_Transaction. In here we have to set False on Follow Redirect properties at first page on each new request.

Figure 4: Add request & add requested page url & check the follow redirects properties False Now we have to record our requests as our scenario by using record button (red button).Basically its capture the flow of your request/scenario.

Figure 5: Start recording using Record button After pressing the Record button the new browser will be opened in new window. In there we have to record total scenario. After completing the record, close the browser and stop the

recording. Once it is done go ahead and click the Run Test button in the toolbar to ensure that the test will succeed. After running the test scenario, test result window look like that.

Figure 6: Test result after running the test scenario. Now we know that we have a working web test that we can start to use with a load test. We will want to create a new load test by right-clicking on the test project, select opening the Add menu, and then selecting the Load Test option.

Figure 7: Create a new load test for the project This will bring up the New Load Test Wizard which will walk us through creating a scenario. Let’s walk through the wizard:

Figure 8: Click next to move past the welcome page. We can go ahead and just click Next on the welcome page.

Figure 9: Set the name of your scenario, choose the think time profile, and choose how much

think time between the test iterations

This page will allow us to choose what we want to name this scenario – I chose

Cash_Transaction_load_test for mine – as well as the scenario’s think time profile and how much

time in between our test iterations. I’m going to use the recorded think times from the web test

I just created as well as put a one second think time between the test iterations.

Figure 10: Choose whether we want a constant load, or if we want to step load the system

I am going to choose to a constant load of 1 user for my load test. This is most likely not the case

for the actual use of a website. A more real-life scenario is to have a certain amount of users for

some time, and then that user concurrency loads up until peak time. We can replicate this using

step loading. We can also use step loading to see when our system starts to degrade.

Figure 11: Choose test mix model for the load test

Each of these options is how the tests are run during the load test. When selecting each one, the

description in the bottom right, as well as the graphic used, will explain further what each means.

I’m going to choose the Based on the number of virtual users & move Next.

Figure 12: Choose the test(s) that I want to add to the load test

This is where we would add the tests that we want to run during the load test. Any test that is

within the project will be populated on the left. Select the test, or tests that we want to add and

then click the right arrow to add it to the test. We will then be able choose the distribution of

each test during the load test. Because this is the only test, keep it at 100% and click next.

Now I am going to the next two wizard screens which allows us to choose which network we

want to use from the test machine as well as what sort of browser mix we want to have during

the tests. Once past these, we can then choose our counter sets. By default, the controller

computer and agent computers are automatically added to the load test, even if it is a local run

and not connected to test controllers. We also have the option to add a computer individually –

for computers that do not have a test agent installed on them.

Figure 13: Add network types to a load test scenario & edit the network mix.

Figure 14: Add browser types to a load test scenario & edit the browser mix.

Figure 15: Add computers that do not have agents installed on them, or for local execution, to

collect counters from.

I’m not going to add any computers here at first to see what sort of data we get back, if we only

run locally with no other computers with counters being collected. The last page of the wizard is

to set the run settings for the load test.

Figure 16: Set the run duration of the test as well as the sampling

I am going to reduce my run duration from 10 minutes down to two, so it will faster for me to

run the load test. Actual load tests will want to run longer than that to get more, sustained data

from the test. The sampling rate is how often the performance counters are queried by the

controller for the test. Five seconds is the default, as well as the lowest this rate can go. Once

done, click finish.

Figure 17: The created load test after initial wizard

This creates the load test for us. We will want to just go ahead and run it to ensure that it works,

and to see what sort of counters we see. Go ahead and click the run button in the tool bar of the

load test.

Figure 18: Load test results for our initial run

Figure 19: Final results of our Load test run

After running the test, we will get some data back, but not everything that we want. Note that

all of counters that we see here are from my local machine because I ran a local execution of the

load test. Also, we never added any other computers into the load test, so we shouldn’t expect

to see anything other than the counters from our local machine. Because we may, or may not,

have permissions to pull the counters from servers, we will want to set up our remote execution

settings first. This way, the account the Test Controller service is running under queries will be

the performance counters, and we know that account has the correct permissions to do that.

The final step to run a successful Web performance and load test is to analyze the graph properly.

Here are some hints about the graph which will be helpful for analyzing the load test.

Graphical view •Key Indicators: This graph shows the data collected for average response time, threshold violations per second, errors per second, and the user load. The details about the graph are given below the four graphs section, which describe the actual counter data collected during the test with the corresponding color coding with minimum, maximum, and average value for the counter.

• Page Response Time: This graph explains how long the response for each request took in different URLs. •System under Test: This is the graph which presents data about different computers or agents used in the test. The data include readings such as the available memory and the processing time. In this test we didn’t use any different computers so the graph is empty. •Controller and Agents: The last graph presents details about the system or machine involved in the Load Test. The data collected should be the processor time and the available memory. •Transaction Response Time: This is the average time taken by the transactions in Load Testing. Summary view: •Test Run Information: This section provides the overall test run details such as start date and time, end date and time, test duration, the number of agents used for the test, and the settings used for the entire test. •Overall Results: Provides information such as the maximum user load, the number of tests per second, requests and pages per second, and the average response time during the test run. •Test Results: This section shows status information such as the number of tests conducted for each test selected for Load Testing. For example, out of 100 tests run for the Web Performance Test selected for Load Testing, the number of tests passed and the number of tests failed. •Page Results: This section reports information about the different URLs used during the test. This result gives the number of times the page is requested and the average time taken for each page. The detail includes the test name to which the URL belongs. •Transaction Results: The transaction is the set of tasks in the test. This section in the summary view shows information such as the scenario name, test name, the elapsed time for testing each transaction tests, and the number of times this transaction is tested. •System under Test Resources & Controller and Agents Resources: This section reports information about the systems involved in testing and the processor time for the test, and the amount of memory available at the end of test completion. •Errors: This section gives a list of errors that occurred during the test, information such as the error type, sub type, number of times the same error has occurred during the test, and the last message from the error stack.

Analyzing Load Test Result:

1. Key Indicators:

User Load: This graph shows the details about the user load of the specific test.

Pages/sec: This graph shows the data collected for pages/sec.

Average Page Time: This graph shows the data collected for average page time.

Errors per second: This graph shows the details of errors generated per second for a

specific test. In this specific test no error was generated.

Threshold Violations: This graph shows the details of threshold violations generated

per second for a specific test. In this specific test no threshold violations was

generated.

2. Page Response Time: This graph explains how long the response for each request took in

different URLs. Each URL has its own maximum and minimum response time. Page

response time should be minimum to meet the performance criteria.

3. Test Response Time: This graph shows the average test time for the specific scenario.

4. Controllers & Agents: The last graph presents details about the system or machine involved in the Load Test. The data collected should be the processor time and the available memory.

Identify Performance Acceptance Criteria:

Identifying performance acceptance criteria is most valuable when initiated early in the

application’s development life cycle. It is frequently valuable to record the acceptance criteria for

your application and store them in a place and format that is available to the entire team for

review and comment.

Page Response time. For example, login page must be displayed in less than 3 seconds. Throughput. For example, the system must support 100 transactions per second. Maximum user load. This test objective determines how many users can run on a

specific hardware configuration

By

Ahsan Kabir