jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dzmitry Kashlach <dzmitrykashl...@gmail.com>
Subject Re: Coding JMeter tests
Date Mon, 17 Nov 2014 08:02:06 GMT
Hi,
Sorry, I've noticed discussion only now :-)

Using jmeter-ruby for generating JMeter tests can be good idea
in case if it allow to convert Ruby script directly to JMeterTreeModel
object.

What I mean?

For now workflow is the following:
XML -> XStream parser -> JMeterTreeModel via .

If we add Jmeter-ruby over XML, I guess(but I can mistake) that we see this:
jmeter-ruby -> XML -> XStream parser -> JMeterTreeModel

So, additional conversion can be a source of bugs.

But, definitely, it's great idea to have scripting in JMeter, it will make
using "diff"  tools easier.
For instance, Gatling is using scripting on Scala.
May be, it would be good to move JMeter towards the same direction?
And leave GUI - mode as a plugin for QA engineers, who need it?



-------------------------------------------
"Ўчора" ужо было, "заўтра" яшчэ не прыйшло. У нас ёсць
толькі "сёньня".

tel: +375291142462
skype: dmitry.kashlach


On Sun, Nov 16, 2014 at 7:58 PM, Shmuel Krakower <shmulikk@gmail.com> wrote:

> Hi,
> I really glad to hear so many opinions on this.
> Summarizing the discussion so far, there are three pros for having jmeter
> in code (in oppose to XML/GUI), for developers:
> 1. It can allow developers stay in comfort zone (IDE). But may require them
> to 'script' in another language (i.e. jmeter-ruby).
> 2. It allows jmeter scripting to happen earlier, as developers may use that
> not only for performance testing, but also for UI / end user testing, by
> coding once, running twice.
> 3. It makes script comparison and review easier. Today it is hard to
> understand what was changed due to the XML format. Code comparison is
> easier to look at.
>
>
> QA engineers are less likely to open IDE for scripting, but as long as any
> ruby style jmeter script is easily converted to XML, it allows them to be
> able to review such scripts via the GUI, as done today, so it doesn't hurt
> them.
> On the other hand - QA automation engineers do script, as in selenium etc..
> So maybe this is also a pro as they may script jmeter tests and this will
> bring developers and QA / performance testers closer.
>
> From my side, I will give ruby-jmeter a try in my team in the near future
> and will use that if it works out for me.
> This sounds exactly like what I was looking for.
>
> Thank you all,
>
>
> Shmuel Krakower.
> www.Beatsoo.org - re-use your jmeter scripts for application performance
> monitoring from worldwide locations for free.
>
> On Sat, Nov 15, 2014 at 12:57 AM, Philippe Mouawad <
> philippe.mouawad@gmail.com> wrote:
>
> > Hello,
> > Very interesting discussion.
> > thanks @Flavio for the nice words on JMeter :-)
> >
> > My 2 cents:
> > - first your opinion on jmeter roadmap would be welcome, See
> > https://www.mail-archive.com/dev@jmeter.apache.org/msg03444.html
> > - to answer this request (if we decide it is worth doing it) we could
> > first  provide a public API (would be possible in shorter term) to create
> > and run the test as for now there is no "official" API to do it
> > - In the future a DSL (more work) could be a possible way. Inspired by
> > ruby-jmeter and developed with Groovy which seems well suited for DSLs .
> > Patches are welcome :-)
> >
> > Now regarding the discussion:
> > - As a tester, I am convinced that GUI is really useful and mandatory,
> > particularly when you are not the developer of the application under
> test,
> > without it, correlation is hard. Some may say JMeter GUI is not sexy,
> IMHO
> > it is not a serious argument but we take it into account and try to
> improve
> > GUI , 2.12 version makes an important progress with the enhancement of
> HTTP
> > Script Recorder and with UNDO/REDO Alpha feature but we still have bugs
> > that need to be fixed to complete the work on this feature.
> > - As a developer it is true that initially mastering the GUI  put me in
> > uncomfortable zone (as it is outside of my IDE), but learning it is
> really
> > worth it. Also take tools like firebug, developers use them, they are not
> > in their IDE but are highly used, so I am not sure about the IDE
> argument.
> > - With DevOps success, it is possible that load testing is introduced
> very
> > early in the development cycle and written by developers, in this cases
> > having a DSL is interesting for coders, mainly for source versioning, so
> it
> > is worth studying the feature.
> >
> > --
> > Regards.
> > Philippe M.
> > @philmdot
> >
> > On Fri, Nov 14, 2014 at 1:23 PM, Flavio Cysne <flaviocysne@gmail.com>
> > wrote:
> >
> > > @sebb, Thanks to clarify this.
> > >
> > > My mistake.
> > >
> > > That's why I need to know better JMeter's source code.
> > >
> > > Glad to know this.
> > >
> > > 2014-11-13 22:32 GMT-03:00 sebb <sebbaz@gmail.com>:
> > >
> > > > On 13 November 2014 12:54, Flavio Cysne <flaviocysne@gmail.com>
> wrote:
> > > > > My 2 cents.
> > > > >
> > > > > I really love JMeter and I'll try to get this passion aside from
my
> > > > opinion.
> > > > >
> > > > >
> > > > > 1. Developers are free to do whatever they can with JMeter.
> > > > >
> > > > > JMeter can test TCP, SOAP, JSF, .NET, common websites, Socket,
> > Database
> > > > > Queries, WebSocket (not from the core, but there is a plugin for
> > this)
> > > > and
> > > > > many more (and even MycroStrategy flash reports. I made a script
to
> > > test
> > > > it
> > > > > using WebDriver).
> > > > >
> > > > > 2. JMeter gives you the opportunity to evolve itself by your hands
> > > (make
> > > > a
> > > > > plugin)
> > > > >
> > > > > If there's a protocol you can't test because JMeter has no Sampler
> > for
> > > > it,
> > > > > do yours. It's not an excuse to be "unhappy" with JMeter. If
> there's
> > a
> > > > > Sampler but it is not complete enough, fork it, do your upgrades
> and
> > > > submit
> > > > > back to community.
> > > > >
> > > > > 3. Developers can do logic programming in JMeter test script.
> > > > >
> > > > > There are plenty of ways you can customize your script logic. The
> way
> > > you
> > > > > use Logic Controllers, and programmable Samplers like BeanShell
> > > Sampler,
> > > > OS
> > > > > Process Sampler or BSF Sampler, is what you need to make it work.
> > > > >
> > > > > Free your mind!!!
> > > > >
> > > > > I've been using JMeter for performance tests since 4 years ago, and
> > > > > capturing 2 scripts, in average, every week for different test
> > > scenarios.
> > > > > Some of those scripts had a complex logic to fulfill (test workflow
> > > > > requirements). Sometimes I had to write down the logic and make
> tests
> > > > using
> > > > > different JMeter components to know exactly what I had to use to
> > > achieve
> > > > > the test requirements.
> > > > >
> > > > > You have to understand how JMeter components interact to use them
> > > > properly.
> > > > >
> > > > > About this link
> > > > >
> > > >
> > >
> >
> http://blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui
> > > > ,
> > > > > I use JMeter Ant task and took some tests with JMeter Maven Plugin.
> > Ant
> > > > > task is more easily customized than Maven plugin. When I tested
> > JMeter
> > > > > Maven plugin it was brandy new and have less documentation than
> now.
> > > I'll
> > > > > take a look again to know If I hadn't used its full potential.
> > > > >
> > > > > I can't say that JMeter has no cons, all tools have theirs.
> > > > > What I can say about that is JMeter source code is a bit tricky,
> but
> > > I've
> > > > > not dedicated enough time to understand it.
> > > >
> > > > Regarding:
> > > >
> > > > > My opinion is that JMeter GUI classes and classes used during
> non-GUI
> > > > test
> > > > > execution should be taken apart so it could use less memory for
> > non-GUI
> > > > > tests.
> > > >
> > > > This is already the case.
> > > > The GUI is built from separate classes that are not loaded during
> > > > non-GUI test runs.
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> > > > For additional commands, e-mail: user-help@jmeter.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
> >
>

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