jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Kavadias" <>
Subject RE: help
Date Tue, 10 Sep 2002 01:13:45 GMT
Rohit wrote:

 - Sample Test Plan
   - Thread Group
     - HTTP Request -> jsp/login.jsp
     - HTTP Request -> jsp/pageView.jsp?workItemId=2334&workFlowId=14
     - HTTP Request -> jsp/nextPage.jsp?workItemId=.*&workFlowId=.*
       - HTML Link Parser
     - HTTP Request -> jsp/thirdPage.jsp?workItemId=.*&workFlowId=.*
       - HTML Link Parser
     - HTTP Request -> jsp/fourthPage.jsp?workItemId=.*&workFlowId=.*
       - HTML Link Parser
     - HTTP Request -> jsp/fifthPage.jsp?entityItemId=<Value of 
       - HTML Link Parser

> Is the above example possible?

Yes, the intent of the plan is possible in JMeter.

> 1) Do I need to use HTML Link Parser for all the subsequent HTTP requests to grab the
value of 'workItemId'?

When structuring your plan around HTML Link Parser capabilities, I think so. 

The Path of the HTTP Request is important to the substitution of '.*', not just the parameter
name. I found this out the hard way.

I think if you use __regexFunction() to drive your test sequence, you won't need to use any
HTML Link Parsers and will make JMeter do less work to get the outcome you want.

However using regex may have implications for the durability of your test plan if the application
changes. This is an issue only you can judge properly.

> 2) I'm not well aware of regex maybe I need to go through some documentation before I

If you do not know regex, here is a pointer:

If this is too steep or terse, try reading a manual page or article about sed or awk, or follow
the link on the page above to the Perl documentation. Be aware that sed and awk regex (or
RE) have a more limited syntax and thus not as terse as Perl regex.

> but meanwhile if you can you let me know if I can grab value of 'workItemId' and pass
it to 'entitityItemId' using regex .. that would be actually great. 

Yes. I'll try and show how by evolving your test plan in two steps.

OK, my habit in organising test trees is to have the HTML Link Parser precede the HTTP request
that USES the results of its parsing. So I would suggest:

 - Sample Test Plan
   - Thread Group
     - HTTP Request -> jsp/login.jsp
A    - HTTP Request -> jsp/pageView.jsp?workItemId=2334&workFlowId=14
B    - HTML Link Parser
C    - HTTP Request -> jsp/nextPage.jsp?workItemId=.*&workFlowId=.*
D    - HTML Link Parser
E    - HTTP Request -> jsp/thirdPage.jsp?workItemId=.*&workFlowId=.*
F    - HTML Link Parser
G    - HTTP Request -> jsp/fourthPage.jsp?workItemId=.*&workFlowId=.*
H    - HTML Link Parser
I    - HTTP Request -> jsp/fifthPage.jsp?entityItemId=<Value of workItemId>&workFlowId=.*

The HTML Link Parsers are preceding siblings of the HTTP Requests in this setup, rather than
immediate children.

[[ Anyone more in the know, please comment on whether this makes a difference. I expected
that it would, given the JMeter manual examples are structured more like this than Rohit's
original. I cannot be more definite as I have read little of the JMeter source and don't know
its structure and strategies for compiling and executing test plans. ]]

OK, now your problem will be that you need to generate

  entityItemId=<Value of workItemId>

as a parameter to the last HTTP Request, labelled 'I'.

The substitution of '.*' for HTTP Request vs the results of the most recent HTML Link Parse
cannot do this for you, I think. The URL path and parameter names must match for substitutions
to occur. You would end up with a generated parameter value of '.*'.

So, I would drop the HTML Link Parser labelled 'H' and use something like this, specified
as the value field of parameter entityItemId of HTTP Request labelled 'I':


The first parameter in the comma separated list is the regex. The second is the substitution
value, the 'output' of the function invocation.

There is one (parethesised) group in the regex: (\d+). The $1$ in the substitution value will
expand to the string matched by \d+. $1$ matches the first parenthesised group, $2$ the second
(if present), etc. $0$ is the whole regex match.

To explain the rest of the argument list, the documentation on __regexFunction is here (or
use the JMeter doc from your build of JMeter):

You may want RAND as the third argument rather than 1. This depends on the details of you

The general documentation on JMeter functions is here:

[[ Create the function string with the JMeter Function Helper Dialog, which allows you to
encode the function string. Copy the generated encoded string and paste it into the HTTP Request
parameter value field. ]]

Now, the LAST argument to __regexFunction() 'tags' the particular regex invocation and give
you a handle to the results of the most recent execution of the function.

So, the last complete match, which you would reference as $0$ in the second argument of __regexFunction,
is available as ${wiidREF_g0}.

The 'sub-matches' made by parenthesised groups in the regex are available as ${wiidREF_g1}.
${wiidREF_g2} does not exist in our example, but in general _g2 for the sub-match of the second
group, _g3 for the third, etc.

Now, you can see that if your Id parameters in you request URLs are fixed for the entire request
sequence, you need only extract them once from the first response that contains them, with
a single ${__regexFunction()} call. For the rest of the sequence just use the ${tag_gN} mechanism.

What you lose in comparison with HTML Link Parser is the requirement to match the Path of
the current request in the content of the previous response. Depending on the precise content
of your response, you may be able to extend the regex approach to regain this.

Is THAT the time?
See you all later.
John Kavadias.
View raw message