jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordi Salvat i Alabart <jsalv...@atg.com>
Subject Re: JMeter for funtional testing
Date Fri, 13 Feb 2004 15:20:57 GMT
My personal position would be to move towards allowing functional 
testing, but still keep performance testing a priority. That is: never 
make a change that improves functional testing ability if it degrades 
performance testing ability. The opposite could happen, although I guess 
we would always go great lengths to try to make both requirements 
compatible.

The rationale for this is:
- JMeter is a performance testing tool -- or at least that's its charter.
- Performance testing requires functional testing features: you need to 
see that function is not degraded under load.

-- 
Salut,

Jordi.

Michael R. Wolfe wrote:
> I have a fairly broad question.  We are using Jmeter for performance and
> stress testing and have been successful with it.  Most of our Jmeter
> scripts are fairly hardcoded, although there are a few places we've
> driven test data from CSV files.
> 
> But I've been stymied when creating more complex scripts to do
> functional and regression testing.  You can do some crude things using
> CSVFiles and loops (and the IF controller will be a big help), but in
> general making reusable, data-driven scripts is very cumbersome and
> involves lots of hacks.   We are using Jmeter to test a web-driven
> application with reports, config interfaces, etc., and not a relatively
> static website.
> 
> So, my question is:
> 
> 1 - Is there an equivalent tool to Jmeter to do functional testing
> (other than HTTPUnit, which is too low-level)
> 2 - Do folks see Jmeter evolving in this direction?  It would require
> adding more controllers (the IF controller is a good start), reusable
> subroutines, some variable operations, more options to read from CSV
> files (and XML files!), and other gizmos that the commercial tools have.
> A little would go a long way here, and I might start to add things on my
> own, but I didn't know if anyone had an overall vision of Jmeter going
> this direction.  
> 
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message