Alexander Podelko, a well know personality in performance testing world. I like the way he explains the performance testing stuff. Luckily, I found his one of the finest document in which he described the PTLC term by dividing the things into small parts. Although you are a performance testing expert, still read this wonderful document once.
How to conduct Stress Test?
During Performance testing, stress test has its own place to find out the uppercut of application capability. But what is the approach you should follow to conduct Stress and then conclude the result? Kirk Pepperdine has articulated these stuff very well in his article.
Stress Test: The main idea behind stress testing is to determine the failure of the system. Stress testing is a kind of negative testing where we load the software with a large number of concurrent users/processes which cannot be handled by the systems hardware resources. This testing is also known as Fatigue testing. It puts greater emphasis on robustness, availability, and error handling under a heavy load, rather than on what would be considered correct behaviour under normal circumstances.
Impact of Cache on Application Performance
Cached data is nothing but files, images, scripts and other media files stored on your devices by the website or app. Data is stored on your devices in a reserved space, so the next time when you are visiting the app or website, information is already available. Cache plays an important role in Performance Testing World. Because to improve the application's performance cache helps a lot! How? Read the LinkedIn article shared by Deepanshu Mittal:
Identification of Performance Bottleneck
Identification of performance bottleneck is an art and how a performance tester can enhance his/her skill to identify the bottlenecks is very well articulated by Scott Barber. Read this article to know what are the usual performance bottleneck and how to detect them?
Performance Bottleneck: Performance Bottlenecks are the causes which degrade the system or application performance in term of slowness in response time, low throughput, low user load etc.
Common Mistakes in Performance Testing
Hi Expert,
Today, I am sharing the common mistake which we do during performance testing planning, preparation and execution. There are 13 common mistakes which are listed by Mark D Anderson. If you are aware of these mistakes then you can save time and effort.
Performance Improvement from 10 to 1 to 0.1
Response Time; a simple but one of the key terms in performance testing world. During performance testing window; all the conversations are revolved around this key metric to meet it and post-testing the work started to tune it (if issue found). Response Time is a first and foremost metric which we consider in PT. But do you know what are the categories in which you can categorize the response time and on that basis, you can divide the responsiveness of your AUT (application under test) or pages?
These categories have been followed since long back and today I am sharing an old article (1993) which described it in brief. I guess some of you would have not been born when this article was written. This article will help you once you started thinking as a performance engineer and how you can jump the AUT from 10 to 1 and 1 to 0.1?
Refer the link to read the article.
Requirement vs Goal vs Objective
1. Performance requirements - criteria that are absolutely non-negotiable due to contractual obligations, service level agreements or business needs. Only those criteria whose sub-par performance would unquestionably lead to a decision to delay a release are absolutely required.
2. Performance goals - criteria desired for release, but negotiable under certain circumstances. For instance, if a response time goal for a particular transaction is set at 3 seconds, but the actual response time is determined to be 3.3 seconds, it is likely stakeholders will choose to release the application and defer performance tuning of that transaction for a future release.
3. Performance testing objectives - items that add value to the team through the process of performance testing but are not intrinsically quantitative. For example, one objective might be to provide certain data to systems administrators to assist them in tuning systems under their purview. Another objective might be to determine peak application usage that the existing network can support.
The above content has been taken from a white paper "Get performance requirements right - think like a user" written by Scott Barber and published by Compuware. The reference document can be accessed via this link.
2. Performance goals - criteria desired for release, but negotiable under certain circumstances. For instance, if a response time goal for a particular transaction is set at 3 seconds, but the actual response time is determined to be 3.3 seconds, it is likely stakeholders will choose to release the application and defer performance tuning of that transaction for a future release.
3. Performance testing objectives - items that add value to the team through the process of performance testing but are not intrinsically quantitative. For example, one objective might be to provide certain data to systems administrators to assist them in tuning systems under their purview. Another objective might be to determine peak application usage that the existing network can support.
The above content has been taken from a white paper "Get performance requirements right - think like a user" written by Scott Barber and published by Compuware. The reference document can be accessed via this link.
Subscribe to:
Posts (Atom)