Transcript
Tool: Mercury LoadRunner 8.0 Portocols: Siebel and HTTP/HTML (web). Modes of recording: URL based scripting and HTML based scripting. Things Known in Brief: Performance Engineering Basics Load Testing: Virtual User Technology Load Runner Scripting Load Testing: Load Runner Controller, Analysis, Monitors Roles and responsibilities as performence tester: 1>Recording scripts in Vugen on 2 protocols i.e., Siebel and HTTP/HTML(web) and All Parameterization and corelation is covered. 2>Generating Data for loadtest/data preparation for loadtest. 3>Recording scripts on both HTTPS and HTTP Web Application. 4>Recording scripts in Siebel CRM Application. 5>Planning Performance test/Loadtest for an Application. 6>Finding and reporting performance defect to the developer in an Application 7>And also helping them to fine tune Application*,Web and DB(database) servers b y indentifying key first buffer time breakdown and network bandwidth. 8>Monitoring the CPU Utlization of the different servers in controller. 9>Merging and comparing of graphs in Analysis for better Understanding of result s. 10>Preparing Performance test result document for Client. 11>Also Compiling on stress test, FailOver test, Soak Test, Load test, performan ce test and destructive test.
Few more points which can be added in resume: 1>Identification of Functional Test scenarios for loadtest. 2>Creation of UAT/load Test Plan & Test cases. 3>Test data preparation for UAT/E2E loadest. 4>Defect management & defect status reporting ************************************************************************ Load Tests Load Tests are end to end performance tests under anticipated production load. The primary objective of this test is to determine the response times for variou s time critical transactions and business processes and that they are within doc umented expectations (or Service Level Agreements - SLAs). The test also measur es the capability of the application to function correctly under load, by measur ing transaction pass/fail/error rates. This test is one of the most fundamental load and performance tests and needs to be well understood. This is a major test, requiring substantial input from the business, so that ant icipated activity can be accurately simulated in a test situation. If the proje ct has a pilot in production then logs from the pilot can be used to generate usa ge profiles that can be used as part of the testing process, and can even be used to drive large portions of the Load Test. Load testing must be executed on today s production size database, and optionally wi th a projected database. If some database tables will be much larger in some mont hs time, then Load testing should also be conducted against a projected database
. It is important that such tests are repeatable as they may need to be execute d several times in the first year of wide scale deployment, to ensure that new r eleases and changes in database size do not push response times beyond prescribe d SLAs. Failover Tests : Failover Tests verify of redundancy mechanisms while under load. For example, s uch testing determines what will happen if multiple web servers are being used u nder peak anticipated load, and one of them dies. Does the load balancer react quickly enough? Can the other web servers handle the sudden dumping of extra loa d? This sort of testing allows technicians to address problems in advance, in t he comfort of a testing situation, rather than in the heat of a production outag e. Soak Tests (a.k.a. Endurance Testing): Soak testing is running a system at high levels of load for prolonged periods of time. A soak test would normally execute several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and per formance problems that appear after a large number of transactions have been exe cuted. Also, due to memory leaks and other defects, it is possible that a syste m may stop working after a certain number of transactions have been processed. It is important to identify such situations in a test environment. Stress Tests :
Stress Tests determine the load under which a system fails, and how it fails. T his is in contrast to Load Testing, which attempts to simulate anticipated load. It is important to know in advance if a stress situation will result in a catast rophic system failure, or if everything just goes really slow . There are various varieties of Stress Tests, including spike, stepped and gradual ramp-up tests. Catastrophic failures require restarting various infrastructure and contribute t o downtime, a stress-full environment for support staff and managers, as well as possible financial losses. This test is one of the most fundamental load and p erformance tests and needs to be well understood. Targeted Infrastructure Test : Targeted Infrastructure Tests are Isolated tests of each layer and or component in an end to end application configuration. It includes communications infrast ructure, Load Balancers, Web Servers, Application Servers, Crypto cards, Citrix Servers, Database allowing for identification of any performance issues that woul d fundamentally limit the overall ability of a system to deliver at a given perf ormance level. Each test can be quite simple, For example, a test ensuring that 500 concurrent (idle) sessions can be maintained by Web Servers and related equipment, should b e executed prior to a full 500 user end to end performance test, as a configurat ion file somewhere in the system may limit the number of users to less than 500. It is much easier to identify such a configuration issue in a Targeted Infrast ructure Test than in a full end to end test. Performance Tests :
Performance Tests are tests that determine end to end timing (benchmarking) of v arious time critical business processes and transactions, while the system is un der low load, but with a production sized database. This sets best possible perfo rmance expectation under a given configuration of infrastructure. It also highl
ights very early in the testing process if changes need to be made before load t esting should be undertaken. For example, a customer search may take 15 seconds in a full sized database if indexes had not been applied correctly, or if an SQ L 'hint' was incorporated in a statement that had been optimized with a much sma ller database. Such performance testing would highlight such a slow customer se arch transaction, which could be remediated prior to a full end to end load test . Network Sensitivity Tests : Network sensitivity tests are tests that set up scenarios of varying types of ne twork activity (traffic, error rates...), and then measure the impact of that tr affic on various applications that are bandwidth dependant. Very 'chatty' appli cations can appear to be more prone to response time degradation under certain c onditions than other applications that actually use more bandwidth. For example , some applications may degrade to unacceptable levels of response time when a c ertain pattern of network traffic uses 50% of available bandwidth, while other a pplications are virtually un-changed in response time even with 85% of available bandwidth consumed elsewhere. This is a particularly important test for deployment of a time critical applicat ion over a WAN. Volume Tests: Volume Tests are often most appropriate to Messaging, Batch and Conversion proce ssing type situations. In a Volume Test, there is often no such measure as Resp onse time. Instead, there is usually a concept of Throughput. A key to effective volume testing is the identification of the relevant capacity drivers. A capacity driver is something that directly impacts on the total pro cessing capacity. For a messaging system, a capacity driver may well be the siz e of messages being processed. For batch processing, the type of records in the batch as well as the size of the database that the batch process interfaces wit h will have an impact on the number of batch records that can be processed per s econd. Destructive testing: Main article: Destructive testing Destructive testing attempts to cause the software or a sub-system to fail, in o rder to test its robustness. Please Refer this: http://www.loadtest.com.au/types_of_tests.htm http://en.wikipedia.org/wiki/Software_testing