My issue is the same as the following email: I need to automate some 10+ tests on the same day, and just see how the responses vary day to day. Having to open the desktop client is a complete non-starter for me. I think there needs to be a way to extract the summary results. Thanks, Martin http://www.mail-archive.com/jmeter-user@jakarta.apache.org/msg24081.html On 09/04/2009, Woodcock, Simon <swood...@qualcomm.com> wrote: > When in NON-GUI mode is there any way that you can save the results of a > 'Summary Report' to file in the same format as it appears in the table when > viewed in GUI mode, i.e. one entry per differently named request with an > average total for each request. As opposed to what I seem to get when I > currently write to file, which is a unique entry for every thread request. > > I know I can 'Save Table Data' after the test has completed in GUI mode, > which gives me the desired format, however I want to run this in an automated > way in NON-GUI mode and then parse the results at a later date. > > Your help would be much appreciated, thanks in advance, Sorry, not possible; Listeners do not run in non-GUI mode. However you can save the raw data and reload into a Summary Report using the GUI. Or just write your own analysis of the data.
If you don't want all of the Summary Results columns, you can use: http://jakarta.apache.org/jmeter/usermanual/component_reference.html#Generate_Summary_Results to write some info to the log file, and you can use grep or similar to extract it.
Thanks, Sebb. I'd realised that. The one piece of information I need in order to mass test meaningfully is the standard deviation for any given run. Without this I can't tell whether something is awry on any given day. I'm in #jmeter on irc://irc.Freenode.net if you would like to talk. Thanks. Martin.
It's unlikely to be implemented in the near future, as it would mean changing the way that Listeners work. If you use CSV output (which is more efficient), it should be fairly easy to use a stats package to extract exactly what you want, and more. Or use a scripting language such as Perl or Python, both of which have Maths libraries.
Yup, doubtless I can post process. I noted that http://wiki.apache.org/jakarta-jmeter/LogAnalysis had a bunch of hacks for people wanting various data out of the system. jmeter desktop gui with functionality to calculate these figures, so duplicating the functionality in perl and other scripting languages is only going to cause duplication and rework. I realise that it is not on your roadmap and appreciate both the suggestion for workaround and listing as enhancement. Best, Martin.
> jmeter desktop gui with functionality to calculate these figures, so duplicating the functionality in perl and other scripting languages is only going to cause duplication and rework. I'm wondering: would it a lot of work to factor out the analysis code such that it can work on the raw data, and not hooked in via a listener? It seems that anything that wraps around jmeter, e.g. http://wiki.apache.org/jakarta-jmeter/JMeterMavenPlugin or http://jchav.blogspot.com/ for regression testing, must be wanting this and other key outputs in its result set. I am supposing that each is duplicating the work of the stddev numbers by test type. (Though I can't see the stddev output in the JChav, perhaps it was too much work, I've just asked on the blog.) Thanks, Martin
Since then, more tools have appeared, for instance http://jmeter-plugins.org/wiki/JMeterPluginsCMD/ , serving automation purposes. This issue may be closed, I suppose. Solutions exist and listed.
Since Bug 58653 and with Andrei answer I think we can close this one. *** This bug has been marked as a duplicate of bug 58653 ***
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2243