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
workItemId>&workFlowId=.*
- 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 understand
If you do not know regex, here is a pointer:
http://jakarta.apache.org/oro/api/org/apache/oro/text/regex/package-summary.html#package_description
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':
${__regexFunction(workItemId=(\d+)\D,$1$,1,,NOMATCH,wiidREF)}
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):
http://jakarta.apache.org/jmeter/usermanual/component_reference.html#__regexFunction
You may want RAND as the third argument rather than 1. This depends on the details of
you application.
The general documentation on JMeter functions is here:
http://jakarta.apache.org/jmeter/usermanual/functions.html
[[ 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.
