>That's more or less how I did it in the end. Still I feel a little frustrated by the impossibility to programmatically "navigate" through the sampler responses like you can do in the gui with the View Results Tree, for example. Create a (for e.g. beanshell) listener and store the responses wherever you want in whatever format you want that allows you the navigation you need
On Wed, Oct 2, 2013 at 11:10 PM, Nicola Ambrosetti Brolin < [email protected]> wrote: > On 3 October 2013 00:03, sebb <[email protected]> wrote: > > > > > Use Regex Post-Processor to extract the information and store it in > > variables, one for each sample. > > > > Then use Response Assertion to compare the JMeter variables against each > > other. > > Provide one variable using the variable name, and the other as the > > text to match using the ${varname} syntax. > > > > That's more or less how I did it in the end. Still I feel a little > frustrated by the impossibility to programmatically "navigate" through the > sampler responses like you can do in the gui with the View Results Tree, > for example. In soapUI you can access any test step programmatically and > even configure it or rerun it, from any other test step (though that might > not be a good idea with maintainability and readability in mind). In Jmeter > it seems that to configure a sampler programmatically all one can do is set > a variable (for example in a preprocessor) which then is evaluated with the > ${variable} notation inside the corresponding field. However this cannot be > done for checkboxes, option boxes, drop-downs, etc. > > I suspect that most of these restrictions are heritage of the fact that > Jmeter is (correct me if I'm wrong) first and foremost a performance and > load testing tool, where scripting (which is typically much slower) should > be reduced to a minimum. >
