RE: Using csv data as input

[Dan Yuen <dy...@yahoo.com>]

Just wanted to send in a message to thank everyone for
their responses (they really helped) and let anyone
interested know what we decided on doing.

I've researched the different suggested approaches
over the last few days to see which would work best
for us and found that the __CSVRead functions looks
like it will come in quite handy.

I'm looking at using a TestPlan that has the following
general layout.

Test Plan
|-- Thread Group
....|-- A bunch of Listeners
....|-- Loop Controller
........|-- User Parameters (preprocessor)
........|-- HTTP Request
............|-- Some Response Assertions
........|-- Regular Expression
Extractor(postprocessor)

The loop controller is set to cycle through the csv
file.  The User Parameters create a parameter for each
column of the csv line.  The HTTP Request and
associated response assertion uses those parameters. 
And the Post Processor doesn't do anything except that
it is a convenient place to call __CSVRead to go to
the next line.  (Is there a better place that I should
be putting the __CSVRead(file, next) call?)

I'm happy that this solution did not require any
modifications to jMeter (though I'll be extending the
Tree View a bit to meet our reporting needs).

The only thing I'm less than thrilled about is that I
have to tell the loop controller to stop looping by
manually entering the number of lines in the CSV file.
 It'd be nice if I could figure out a way to have the
loop controller stop looping when the end of the file
had been reached.  

Thanks, everyone, for all your help.

Dan Yuen

--- "BAZLEY, Sebastian"
<Se...@london.sema.slb.com> wrote:
> JMeter also has functions and variables, which can
> be used to parameterise
> just about anything, including Samplers and
> Assertions.
> 
> If your test cases consist of lots of similar
> samples and assertions, and
> the only variation is in the parameters to same,
> then you can create a
> generic test plan, and feed it the required values
> from files at run-time.
> 
> We have run tests with up to 1 million different
> values. Most of the test
> plans are relatively simple, with only a few
> samplers. The variable data is
> held in several external files which we read using
> the _StringFromFile
> function, often into a User Parameter form.
> 
> JMeter also has functions to get properties, and you
> can set properties on
> the command line. It is very easy to write a generic
> test script that can be
> run with any number of threads, and any number of
> loops, and with any
> desired throughput and/or wait times.
> 
> There is also a BeanShell sampler, which may be
> useful - that can do
> whatever java can do.
> [I'll probably add a BeanShell Assertion element in
> due course.]
> 
> Are you mainly performing functional, or performance
> testing?
> 

Mostly functional testing.

> S.
> -----Original Message-----
> From: mstover1@apache.org
> [mailto:mstover1@apache.org]
> Sent: 31 October 2003 01:51
> To: JMeter Users List
> Subject: Re: Using csv data as input
> 
> 
> I see two good options for you:
> 1.  There is a new LogParser Sampler (and now a
> LogParser Controller soon to
> be added) 
> that reads access logs and creates HTTPSamplers on
> the fly.  The LogParser
> and Generator 
> are interfaces you could implement to parse your CSV
> files.  The downside
> here is that it's not 
> a great solution for load testing, since the parsing
> is somewhat heavy.  It
> also doesn't support 
> making assertions on the fly.
> 2. JMeter has routines to load .jmx files and
> convert them into JMeter
> TestElement classes.  
> You could implement a new loading mechanism that
> likewise reads your csv
> files and creates 
> TestElements.  To do this, you'd just have to make a
> new action class (like 
> org.apache.jmeter.gui.action.Load) that does this -
> most of the code exists
> and you can 
> copy/extend it, but add your own file parsing. 
> You'd then also have to add
> a new menu option 
> (ie Open CSV, or something).  The downside here is
> that you'd be digging a
> little deeper into 
> the internals of JMeter's GUI system, which has a
> somewhat steep learning
> curve.  It could 
> also result in very high memory usage if you have
> large csv files that
> represent many 
> samplers and assertions.
> 
> -Mike
> 
> On 30 Oct 2003 at 16:54, Dan Yuen wrote:
> 
> > We are considering moving our application testing
> over
> > to jMeter and are looking at how we would need to
> > modify jMeter to fit our company needs. 
> Specifically,
> > we have a test generation tool that produces a csv
> > file which contains, among other things, inputs
> for
> > test cases (which I'm thinking would convert into
> > Samplers) and expected outputs (which I'm thinking
> > would get converted into Assertions for those
> > Samplers).  
> > 
> > What would be the best way to convert the csv data
> > into Samplers and Assertions?  Are there certain
> > classes that can easily be extended so that I can
> read
> > a csv file and convert each line into a Sampler
> with
> > associated Assertions and add them to my Test
> Plan? 
> > Or would it be much easier and quicker to just
> write a
> > csv to jmx converter?  
> > 
> > It seems the latter would be quicker in the short
> run
> > but would require running the converter as an
> > intermediate step before we run jMeter.  So,
> before we
> > make a decision on which road to take, I'm trying
> to
> > get my arms around what would be involved with
> > extending jMeter to use the csv file directly.
> > 
> > Can you help?  If so, thanks for any
> advice/direction
> > you can give.
> > 
> > Dan Yuen
> > 
> > __________________________________
> > Do you Yahoo!?
> > Exclusive Video Premiere - Britney Spears
> > http://launch.yahoo.com/promos/britneyspears/
> > 
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> jmeter-user-help@jakarta.apache.org
> > 
> 
> 
> 
> 
> --
> Michael Stover
> mstover1@apache.org
> Yahoo IM: mstover_ya
> ICQ: 152975688
> AIM: mstover777
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jmeter-user-help@jakarta.apache.org
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jmeter-user-help@jakarta.apache.org
> 


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org

RE: Using csv data as input

[Dan Yuen <dy...@yahoo.com>]

Quick addendum:  Turns out, I'm able to avoid manually
entering the number of csv lines into the loop
controller by writing a function, using
org.apache.jmeter.functions.StringFromFile as my
guide, to determine how many lines are in the csv
file.

Thanks.

Dan Yuen
--- Dan Yuen <dy...@yahoo.com> wrote:
> Just wanted to send in a message to thank everyone
> for
> their responses (they really helped) and let anyone
> interested know what we decided on doing.
> 
> I've researched the different suggested approaches
> over the last few days to see which would work best
> for us and found that the __CSVRead functions looks
> like it will come in quite handy.
> 
> I'm looking at using a TestPlan that has the
> following
> general layout.
> 
> Test Plan
> |-- Thread Group
> ....|-- A bunch of Listeners
> ....|-- Loop Controller
> ........|-- User Parameters (preprocessor)
> ........|-- HTTP Request
> ............|-- Some Response Assertions
> ........|-- Regular Expression
> Extractor(postprocessor)
> 
> The loop controller is set to cycle through the csv
> file.  The User Parameters create a parameter for
> each
> column of the csv line.  The HTTP Request and
> associated response assertion uses those parameters.
> 
> And the Post Processor doesn't do anything except
> that
> it is a convenient place to call __CSVRead to go to
> the next line.  (Is there a better place that I
> should
> be putting the __CSVRead(file, next) call?)
> 
> I'm happy that this solution did not require any
> modifications to jMeter (though I'll be extending
> the
> Tree View a bit to meet our reporting needs).
> 
> The only thing I'm less than thrilled about is that
> I
> have to tell the loop controller to stop looping by
> manually entering the number of lines in the CSV
> file.
>  It'd be nice if I could figure out a way to have
> the
> loop controller stop looping when the end of the
> file
> had been reached.  
> 
> Thanks, everyone, for all your help.
> 
> Dan Yuen
> 
> --- "BAZLEY, Sebastian"
> <Se...@london.sema.slb.com> wrote:
> > JMeter also has functions and variables, which can
> > be used to parameterise
> > just about anything, including Samplers and
> > Assertions.
> > 
> > If your test cases consist of lots of similar
> > samples and assertions, and
> > the only variation is in the parameters to same,
> > then you can create a
> > generic test plan, and feed it the required values
> > from files at run-time.
> > 
> > We have run tests with up to 1 million different
> > values. Most of the test
> > plans are relatively simple, with only a few
> > samplers. The variable data is
> > held in several external files which we read using
> > the _StringFromFile
> > function, often into a User Parameter form.
> > 
> > JMeter also has functions to get properties, and
> you
> > can set properties on
> > the command line. It is very easy to write a
> generic
> > test script that can be
> > run with any number of threads, and any number of
> > loops, and with any
> > desired throughput and/or wait times.
> > 
> > There is also a BeanShell sampler, which may be
> > useful - that can do
> > whatever java can do.
> > [I'll probably add a BeanShell Assertion element
> in
> > due course.]
> > 
> > Are you mainly performing functional, or
> performance
> > testing?
> > 
> 
> Mostly functional testing.
> 
> > S.
> > -----Original Message-----
> > From: mstover1@apache.org
> > [mailto:mstover1@apache.org]
> > Sent: 31 October 2003 01:51
> > To: JMeter Users List
> > Subject: Re: Using csv data as input
> > 
> > 
> > I see two good options for you:
> > 1.  There is a new LogParser Sampler (and now a
> > LogParser Controller soon to
> > be added) 
> > that reads access logs and creates HTTPSamplers on
> > the fly.  The LogParser
> > and Generator 
> > are interfaces you could implement to parse your
> CSV
> > files.  The downside
> > here is that it's not 
> > a great solution for load testing, since the
> parsing
> > is somewhat heavy.  It
> > also doesn't support 
> > making assertions on the fly.
> > 2. JMeter has routines to load .jmx files and
> > convert them into JMeter
> > TestElement classes.  
> > You could implement a new loading mechanism that
> > likewise reads your csv
> > files and creates 
> > TestElements.  To do this, you'd just have to make
> a
> > new action class (like 
> > org.apache.jmeter.gui.action.Load) that does this
> -
> > most of the code exists
> > and you can 
> > copy/extend it, but add your own file parsing. 
> > You'd then also have to add
> > a new menu option 
> > (ie Open CSV, or something).  The downside here is
> > that you'd be digging a
> > little deeper into 
> > the internals of JMeter's GUI system, which has a
> > somewhat steep learning
> > curve.  It could 
> > also result in very high memory usage if you have
> > large csv files that
> > represent many 
> > samplers and assertions.
> > 
> > -Mike
> > 
> > On 30 Oct 2003 at 16:54, Dan Yuen wrote:
> > 
> > > We are considering moving our application
> testing
> > over
> > > to jMeter and are looking at how we would need
> to
> > > modify jMeter to fit our company needs. 
> > Specifically,
> > > we have a test generation tool that produces a
> csv
> > > file which contains, among other things, inputs
> > for
> > > test cases (which I'm thinking would convert
> into
> > > Samplers) and expected outputs (which I'm
> thinking
> > > would get converted into Assertions for those
> > > Samplers).  
> > > 
> > > What would be the best way to convert the csv
> data
> > > into Samplers and Assertions?  Are there certain
> > > classes that can easily be extended so that I
> can
> > read
> > > a csv file and convert each line into a Sampler
> > with
> > > associated Assertions and add them to my Test
> > Plan? 
> > > Or would it be much easier and quicker to just
> > write a
> > > csv to jmx converter?  
> > > 
> > > It seems the latter would be quicker in the
> short
> > run
> > > but would require running the converter as an
> > > intermediate step before we run jMeter.  So,
> > before we
> > > make a decision on which road to take, I'm
> trying
> > to
> > > get my arms around what would be involved with
> 
=== message truncated ===


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org