Typically the following features are highly desirable:
1. Test/scenario skeleton generation. MAXQ does it
easily.
1: # imports
2: from com.bitmechanic.maxq import HttpTestCase
3: from junit.textui import TestRunner
4: from java.util import HashMap
5:
6: # defintition of test class
7: class MaxQTest(HttpTestCase):
8: def __init__(self):
9: HttpTestCase.__init__(self, "")
10:
11: def runTest(self):
12: self.get("http://www.google.com/";)
13: self.assertEquals(200,
self.getResponse().getStatusCode())
14:
15:
self.get("http://www.google.com/images/logo.gif";)
16: self.assertEquals(304,
self.getResponse().getStatusCode())
17:
18:
19: map = HashMap()
20: map.put("hl", "en")
21: map.put("q", "testing+tools")
22: self.get("http://www.google.com/search";,
map)
23: self.assertEquals(200,
self.getResponse().getStatusCode())
24:
25: ##########################################
26:
27: # Code to load and run the test
28: test = MaxQTest()
29: test.runTest()
2. adding assertions.
3. Instrumenting for performance measurements.
adding
begin = System.currentTimeMillis()
self.post(self.url + self.path, map)
interval1 = System.currentTimeMillis() - begin
is boring.
4. wrting loader which can create n threads and run m
times.
5. reporting.
Looks like if JMeter API will be published, 3,4,5 can
be done easily. And if HTTPProxy can generate scripts
it will be great.
Thanks
Ilia
--- Mike Stover <[EMAIL PROTECTED]> wrote:
> I would consider such an implementation as a new
> "protocol" for JMeter. Currently
> JMeter supports HTTP pretty well, also supports JDBC
> and FTP less thoroughly. New
> "protocols" have recently been added, such as SOAP
> and arbitrary Java objects.
>
> The value of being able to create Jython scripts
> that are then executed within the
> framework of JMeter is obvious - but it's not a
> replacement for the type of system I'm
> talking about. Not everyone who tests applications
> is a programmer. I'd like JMeter to
> be usable by such people. Furthermore, why would
> you want to write you're own regular
> expression routines and HTTP sampling routines if
> you didn't have to? If a Jython
> protocol were implemented, allowing people to write
> arbitrary Jython code to be
> "sampled", you'd have what you want, plus, you'd
> have access to some built-in JMeter
> values.
>
> -Mike
>
> On 10 Jul 2002 at 14:27, Ilia Iourovitski wrote:
>
> > Isn't it better to embed Jython into JMeter like
> MAXQ
> > does.
> > http://www.bitmechanic.com/projects/maxq/
> > It will let users write real scripts. After all
> JMeter
> > about measurements. All tools like Silk Performer
> has
> > it. And it is much easier to debug jython script
> than
> > long set of tests.
> >
> > Ilia
> >
> >
> > --- "Stover, Michael"
> <[EMAIL PROTECTED]>
> > wrote:
> > > Recently I've noticed increased interest in
> making
> > > JMeter react more
> > > dynamically during test runs. This seems only
> > > natural. The HTML Link
> > > Parser provides some support, but really only
> seems
> > > to wet the appetite for
> > > more powerful options.
> > >
> > > So, I'm starting on a more general solution and
> > > thought some of you might
> > > want to give some input.
> > >
> > > I would like to allow users to embed simple
> > > reference elements as values in
> > > config and sampler objects, and then have a
> separate
> > > place where the value
> > > of these referenced elements would be specified.
>
> > > Currently, people use a
> > > Default Config Object to set universal values
> such
> > > as DOMAIN and PORT. I
> > > think a reference replacement system might be
> more
> > > intuitive than the
> > > current overlay system. Rather than leaving the
> > > DOMAIN field blank and
> > > supplying a Default Config in the correct place
> in
> > > the tree, one would
> > > instead insert a reference - such as
> ${my_domain} -
> > > which would be replaced
> > > when the test is compiled. Elsewhere, a table
> of
> > > all reference +
> > > replacement values would allow the user to
> change
> > > all such values in one
> > > location.
> > >
> > > This has many advantages over the current
> situation
> > > - it's generic, meaning
> > > one can use this system for any protocol.
> > > Currently, there is an HTTP
> > > Defaults, and FTP Defaults, etc.
> > > It allows all such elements to have one
> centralized
> > > home which should be
> > > easier to manage.
> > >
> > > For such user-defined values, this is simple.
> I've
> > > taken the variable style
> > > from Ant - ${var-name} - because I like it.
> Much
> > > preferable to XML IMO. A
> > > bit more explicit than a Perl style as well.
> > > Thoughts on this format would
> > > be much appreciated. Anything simpler than what
> > > I've come up with that does
> > > the job.
> > >
> > > Certain built-in values would be equally simple:
> > > ${__threadNumber}
> > > ${__threadName}
> > > ${__timestamp}
> > > ${__counter(0,100,1)}
> > > ${__xmlFile(c:\jmeter\bin\users.xml,username)}
> > > ${__literal[[${ant-variable}]]}
> > >
> > > Well, some are not so simple, but I'm hoping you
> get
> > > the idea.
> > > ${__threadNumber} is replaced by the current
> > > thread's number. I'm using
> > > "__" to indicate a built-in value as opposed to
> a
> > > user-defined variable
> > > name.
> > >
> > > ${__counter(0,100,1)} - for those familiar with
> the
> > > HTTP Parameter Mask,
> > > this might look familiar. The first number
> gives
> > > the starting point, then
> > > the end point, and the last is the increment. I
> > > think it's another way of
> > > getting the same effect. By embedding this
> variable
> > > into an argument name
> > > or value, you can get a similar effect:
> > >
> > > NAME PARAMETER
> > > username user${__counter(0,100,1)}
> > >
> > > This would create arguments in the following
> manner:
> > > username=user0
> > > username=user1
> > > username=user2
> > > etc...
> > >
> > > Similarly, I see
> > > ${__xmlFile(c:\jmeter\bin\users.xml,username)}
> as a
> > > replacement for the User Parameter Modifier,
> though
> > > some complications have
> > > to be worked out.
> > >
> > > And ${__literal[[Anything at all]]} allows a
> user to
> > > use values that might
> > > otherwise conflict with this system. Although,
> that
> > > should be very rare,
> > > because variables not found in the table would
> be
> > > passed on as is.
> > >
> > > This is getting long, but I've implemented a
> more
> > > complex built-in variable
> > > that allows users to scrape values from
> responses
> > > using regular expressions.
> > > Right now, it takes the following form:
> > >
> > >
> >
>
${__responseVariable(REGULAR_EXPRESSION,prefix$1sometext$2suffix,[ALL|#|RAND
> > > |0.###],[between])}
> > >
> > > Take it slow. From the beginning, "__"
> indicates a
> > > built-in variable.
> > > "responseVariable" is the name used to find the
> > > correct Java class to
> > > execute. Then there are parentheses with
> arguments
> > > - just like the
> > > __counter(0,100,1) example above. There are 4
> > > possible arguments, but only
> > > the first 2 are required (thus the square
> brackets
> > > showing optional args).
> > >
> > > The first argument is a regular expression, Perl
> > > style. This regular
> > > expression will be applied to the response data
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
![http://www.google.com/images/logo.gif"](https://www.google.com/images/logo.gif"){kind=link}