jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepak Shetty <shet...@gmail.com>
Subject Re: JDBC Request or PreProcessor driving variables for HTTP Request testing and validation
Date Tue, 14 Aug 2012 20:14:55 GMT
Hi
You should use Variable Name (
http://jmeter.apache.org/usermanual/component_reference.html#JDBC_Request)
result variable can also be used but needs BeanShell or some other scripting

However are you only going to get data that is needed for a single thread?
Usually you get a bunch of data that will be used over multiple threads. In
which case you'd rather write the response to a CSV file (probably in a
setup thread group) and use that in the next thread group

regards
deepak

On Tue, Aug 14, 2012 at 1:01 PM, Roberts, Jeremie <
Jeremie.Roberts@henryschein.com> wrote:

> Hi,
>
> I am trying to use a JDBC Request to get a list of variable values to
> drive my HTTP Request testing, then once I get the results from the HTTP
> Request, I want to validate the results against another JDBC Request.
>
> I have been looking at the documentation, and I am a bit confused as to
> how the Result Variable Name is used. It appears that this is what I want
> to use, but I can't find any good examples of how to really implement this.
> I believe I want to use a Loop Controller or ForEach Controller so that I
> can get the HTTP Request to iterate through the results of the JDBC Request.
>
> Do you have some recommendations or examples to help me configure these
> tests?
>
> Thanks,
>
> Jeremie Roberts
> Henry Schein Practice Solutions
>
>
>
>
> Please consider the environment before printing this email.
>
>
> E-mail messages may contain viruses, worms, or other malicious code. By
> reading the message and opening any attachments, the recipient accepts full
> responsibility for taking protective action against such code. Henry Schein
> is not liable for any loss or damage arising from this message.
>
> The information in this email is confidential and may be legally
> privileged. It is intended solely for the addressee(s). Access to this
> e-mail by anyone else is unauthorized.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message