On 3 October 2013 07:10, 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).
Access to arbitrary sample responses would require keeping them in memory.
> 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.
One could use a scripting pre-processor to set the properties that are
used to save the values of the GUI fields.
Many sampler fields have setters; those that don't can be set using
the appropriate property name.
> 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.
Perhaps.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
