On 11 Jul 2002 at 11:48, Jordi Salvat i Alabart wrote: > Hi. > > Some opinions and a proposal: > > - I'm with Ilia and Berin that the JMeter development team shouldn't use > their limited time to reinvent the wheel. > > - However I'm with Mike that the learning curve to use JMeter (or at > least to start using it) should be kept as low as possible. Actually, > when evaluating load-testing tools, I dismissed push-to-test's TestMaker > in favour of JMeter because TestMaker required me to learn Python. I've > been a programmer for many years and I've learned and used probably over > 50 different programming languages, so it's not that this scares me: > it's just that I'm too lazy. Should be even more of a barrier for > non-programmers. > > - Paul's proposal (Bean Scripting Framework) sounds like a good idea -- > at least it would provide everyone the opportunity to reuse his/hers > programming knowledge. IMO, it would be very sound to use this as a new > Protocol or a new Thread type -- in any case, not in a way that > *requires* using one of those languages to start using JMeter. > > - I disagree with the idea of adding full functional testing > capabilities to JMeter -- even though I agree that there's a need for a > functional testing tool out there. All load testing tools I know who > have attempted to cover both functional and performance testing have > failed in one of the two areas. Mercury covers both, but it's actually > by two separate tools for these two problems. Of course it would be > really great to have both in the same tool, but the risk of screwing up > the whole thing seems too high.
If ever what I do messes up stress testing - I hope people let me know. My intention is to add functional testing capabilities as needed without degrading the stress testing capabilities. Thus, I am willing to come up short in functional testing, but not in stress testing. > > Still, we need some scripting features to be able to test highly dynamic > sites. The main requirements for me are: > - Being able to compute some variable values programmatically, > possibly from the results of a previous sampling. > - Being able to use those variable values in a few specific places: > form field value, URL query-string parameters, and little more. Bingo - there are more possibilities, but this is a big chunk of what I'm aiming for, and you can see these are relatively simple things. I'm not convinced a whole scripting language needs to be imported to accomplish these things. > > This could be accomplished by having some Configuration element running > a script (maybe a BSF one?) to compute those variable values, then > having a variable replacement mechanism in those samplers who wish to > implement it -- or maybe some generic mechanism that can be used everywhere. > > Mike: does this approach what you're proposing? Yes, it sounds like what I'm doing. I'm creating some Variable and Function interfaces that can be implemented very easily to provide built-in variables and functions that can work on samplers and other test elements. The test elements won't need to be changed at all. Regarding re-inventing the wheel: As I said previously, it was a mistake to refer to what I'm thinking of as "scripting". It took me one day to build the complex built-in function I described in the first email. -Mike > > Salut, > > Jordi. > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
