Writing functional tests to validate that your application returns expected results (which can be done using Unit Tests or Web Tests) is one thing but making sure when you go live and more users start using your application that it actually will run is a whole new ball game. That's why to avoid surprises and lots of costs, load testing should be part and parcel of every enterprise application development effort. And that's why Visual Studio 2008 provides the options of adding and running load tests, however that functionality is only available in Test Edition or Team Suite Edition. I used Visual Studio 2008 Team Suite Edition (90-day Trial) that can be downloaded from here. But to work with load tests you will also need a set of computers known as a rig, which are a controller and agents, and those must be installed separately using Visual Studio Team System 2008 Test Load Agent, which includes both agent and controller software (I used 90-day Trial that can be downloaded from here). A rig is required as an agent is used to run tests and generate simulated load whereas the controller is used to coordinate the agents and collect the test results. With that software installed, a load test can be created to test if your application:
- performs under light loads for short duration (smoke testing)
- will run successfully for a sustained duration under heavy load (stress testing)
- is responsive (performance testing)
Most commonly load tests will be executed against created Web Tests to determine how your Web Application / Web Server handles requests from a large number of users but it can be used with regular Unit Tests to see how your n-tier or application layer (ie. data layer) performs under stress. So a Load Test can be added as shown below:
That opens a wizard that walks you through the steps of creating and configuring a load test as shown below:
Next step is adding a scenario, which is the container within a load test where you specify load pattern, test mix, browser mix, and network mix. Scenarios are important because they provide you with flexibility in configuring test characteristics that allow for simulation of complex, realistic work loads as shown below:
First you specify the load pattern as shown below. This allows you to perform a test with the constant number of users or with the range of users to see how the application performs when more users utilize it.
Next you can choose a test mix model as shown below. You can choose that what test is being run by a user to be determined by a number of tests or number of users or user pace.
Next you can specify the probability of a virtual user running a given test in a load test scenario as shown below. This lets you simulate load more realistically. Instead of having just one workflow through your applications, you can have several workflows, which is a closer approximation of how end users interact with your applications. A virtual user randomly selects a test, based on the probability you specified in the mix. For example, if you have two tests, each 50% in the mix, then a new virtual user chooses to run the first test roughly half the time. In a 50/50 mix, if one test is long, and another is short, more load comes from the long test.
Next you can test how a web application performs when users use different browsers as shown below. That allows you better simulate the load when users start accessing your web application using different browsers.
Next you specify what network type will be used by users to run your application - intranet, internet, dial-up, etc, as shown below. When you create a load test, you might want to simulate that load is being generated through more than one type of network connection. A network profile is a simulation of network bandwidth at the application layer. It does not simulate latency.
Next, you specify what to monitor when performing the load test as shown below. You can specify what computers to monitor - controller, agent computers and other computers - hosts of your application - and then what results to gather, which is done by specifying performance counters for each computer.
And finally, you can specify run settings as shown below. You can have more than one run setting in a load test. Only one of the run settings may be active for a load test run, only because the run settings are a set of properties that influence the way a load test runs. You specify test run duration or the maximum number of request and response details of failed requests to store, or the highest level of validation rule that will run in a load test (validation rule are associated with web test requests and if this run setting is set to Medium, all validation rules marked as medium or low will be run).
By clicking Finish button you close the wizard and you can see the load test window as below with all the options that have been added.
Next, you can run the test and observe results - either as graphs or records in a table. Here you can see all monitored counters and any threshold validations.
That gives you a very good idea how your system will perform under going live with more realistic load than a few developers and testers. And although performing those kind of tests should be done by testers, the reality shows something else - that that's not the case in vast majority of situations. Most often testers are only knowledgeable to do functional testing and most complex testing like load testing of a large web application can only be done by a professional developer, especially in smaller companies where there are no testes at all. That's why each professional enterprise application developer should know how to use load tests not only to pass the 70-565 exam but to know how to test an application before going live to provide the best quality of service and return on investment by avoiding problems in production.
0 comments: