250 likes | 517 Views
Structured Load Tests for Web Applications. Martin Lugan QC Engineering Team Status: 20.06.2013. Speaker. Martin Lugan is a Test Engineer in the Quality Control domain at Haufe-Lexware in Freiburg
E N D
Structured Load Tests for Web Applications Martin Lugan QC Engineering Team Status: 20.06.2013
Speaker • Martin Lugan is a Test Engineer in the Quality Control domain at Haufe-Lexware in Freiburg • He is responsible for topics such as PLS tests, test environment virtualisation and test data anonymisation . • Contact information: • Martin Lugan • Haufe-Lexware GmbH & Co. KG • Munzinger Str. 9 • 79111 Freiburg • Telephone +49 761 898-5209 • E-Mail Martin.Lugan@haufe-lexware.com • Web http://www.haufe-lexware.com/
Agenda • Why do we carry out structured Performance, Load and Stress tests (PLS) • The Test Types for PLS Tests • Requirements for Structured Performance and Load Tests • Test Planning: Mandatory information and risks • Test Execution • Result Assessment • Test Reports and Validation • Appendix
Why do we carry out structured Performance, Load and Stress tests?
Performance Management in Application Lifecycle Management (ALM) Test types and test environment design Definition of non-functional requirements (Performance) Lab and module test Performance (End2End) Monitoring Performance, Load and Stress test according to demand
Overload • Stability • Elasticity Typical response time wave
Results Assessment - Successful test run • Even for an ever-increasing load generated by an increasing number of virtual users, the response times will only grow marginally. • However, the individual transactions with strongly differing response times are not satisfactory.
Results Assessment - Typical resource problem from the server side • The increasing number of vUsers means longer response times.
Results assessment - further errors In this test, the load was raised in the first hour. Afterwards, the load remained the same. After 1:30, we can see a significant drop in the load times. The cause was an incorrectly configured caching of database accesses.
Results Assessment - further errors • In this test run, the DB connections were not closed by the application (see monitoring graph above - test run starting at 12:30). The result is, that after reaching the configured maximum DB connections, the server had to be restarted twice.
Validation • In order to check if the tests have delivered realistic and meaningful results, a validation of results should be done. • e.g. by comparing the resource load on the test and live system. • Do we encounter load or performance problems in the live system that we did not encounter in the test execution? <- CPU Load Test system <- CPU Load Test system on a normal Monday morning
Appendix • References: • The slides 6, 17 were taken from „PLS-Roadshow” – Markus Lobreyer & Pandora Project • Translation into English: Victor Giurgiu