Jmeter Reporting
We perform load and performance tests to make certain that our hard work designing, programming, building and creating websites and applications do not fail when they go live.
We need to ensure that these apps and sites are ready to be deployed on a production server, that they can handle the varying loads or influx of concurrent users.
And load testing reports? .
Usually, we run our performance test check, then analyze the report. And the performance reports better have lots of pertinent info and they had better be as clear to read and analyze as a blue sky on a sunny morning.
Only after analyzing the report (and tests in action) can the right decisions be made as to whether the app or site is ready to go live.
Load testing is the dress rehearsal before the live show.
Technical level report
This level of reporting should include the following sections:
I.The scenario description with main breakpoints during test runs.
Why?
The person who will read the report did not perform the tests and may have little to no knowledge about what was tested. So, be as clear as possible.
II.The total number of testing cycles.
III.Both the inscope and outscope;
IV.Graphs;
Do not add all graphs rendered after testing. The best testing reports should have a few select graphs, generally those that will prove optimal output at the end of the article presented.
V.Interpretation;
If your report contains only raw statistics, it is almost impossible to understand the test results. The performance tester is the point person, obviously, who must provide the interpretation.
VI.Some formulas (if they are applicable to the particular test results); Reports that are full of formulas are very challenging. It’s extremelly difficult for the non-tester to wholly understand what lies behind the many sequences of math symbols.
VII.Comparison with baseline or previous results ;
Is the current situation better or worse? What changed since the last execution? What changes were made in the application code?
VIII.Identification of bottlenecks in the application;
If any issues were found, then an investigation to debug and test again should begin.
IX.Recommendations as to how to resolve the bottleneck;
Add recommendations regarding what should be checked and which parameters should be adjusted.
Which performance metrics should be added to a load test report?
While it is definitely up to the individual performance tester, we suggest several of the most common:
- Response time Vs Running vUsers;
- Throughput and Hits per second;
- Error vs Running vUsers;
- Number of failures Vs running vUsers;
Management level report
This type of report should have another tier of detail added. On the other hand, it has another target audience altogether.
That’s why it’s not good to include a lot of statistics, because managers may not have the need or understand it.
Most important to include:
- Provide a summary that is management based, highlights risks and areas of further investigation.
- Describe the scenario as a Use Case(or user story) that contains action items which may perform like the real users of your system. This will show if the tests matches user actions.
- GO\NO-GO decision. Managers should know whether the system is release ready or not at any given moment, in the current state. Time is money.
- In other words, management level reports should be like a business summary which can be extended with technical details, if needed. And it should run between 1-2 pages, no more.
Venkat Matta 