We are not testing PeopleSoft here, but we do use Apache in front of our Tomcat
servers...
The way we avoid having to reconfigure all of our JMeter tests for every update
is simply to build our tests as a set of 'Test Fragments'. So we include the
test fragments in other tests.
That way, if our 'login' process changes, we don't have to update all of our
tests that require logins - we just fix the 'login' test fragment - then all of
our test cases automatically inherit that fix. We even have test fragements that
are made up of other test fragments. For example, if one of our users wanted to
change their email address - they would 'login', 'go to "My Accounts" page', and
'change email address'. So we have multiple layers of test fragments for this
this fragment:
Login - stand-alone test fragment
Go to My Accounts - includes:
"Login" test fragment
goes to My Accounts URL
Change Email Address - includes:
Go to My Accounts test fragment
Goes to Change Email tab in My Accounts pages
POSTs update to email address
We have several functions in our "My Accounts" pages, so each of them start with
the "Go to My Accounts" test fragment, and then perform another function.
Our "Test My Accounts" test case then combines all of the "My Accounts" test
fragments into a single unified test case, and we can run that as a single test.
But if any part of the "My Accounts" system changes - we can fix _only_ that
part, and the rest of the overall "My Accounts" test case remains unmodified for
the next test cycle.
I will point out - we only use JMeter to test performance and load/stress
conditions - not to perform 'functional' tests. And we use a different tool
(Selenium) to test for functional 'regression'. So perhaps you were using it
differently than we are.
I'm not sure about how much changes in your releases, but we find this keeps our
JMeter 'fixing' to a minimum, and we can roll out new releases with only minor
fixes to our JMeter scripts. We have (on occasion) needed to perform
mass-updates to our JMeter scripts (when we updated JMeter versions), but those
are rare, and they usually are easily handled with direct edits to the 'jmx'
files - once we identify the specific changes needed to make everything work
right. Those fixes haven't ever taken more than a few hours of time - basically
just going through each 'jmx' file and altering the XML to match the updated
spec. for the new version of JMeter we're using (or the new controller/config
we're using in place of the old one).
--
Robin D. Wilson
Sr. Director of Web Development
KingsIsle Entertainment, Inc.
http://www.kingsisle.com
-----Original Message-----
From: Natalie Maines [mailto:natalie.mai...@duke.edu]
Sent: Tuesday, January 07, 2014 2:48 PM
To: JMeter Users List; Tony Anecito; JMeter
Subject: RE: Peoplesoft load testing...
Duke used Jmeter for load testing two years ago. We are on PeopleSoft Campus
Solutions 9.0.
JMeter worked well for our testing with the exception - whenever anything
changed (ie - tools version, apache updates, shibboleth updates), we'd have to
re-tool our scripts (which is not necessarily easy, since we had many parameter
related scenarios).
You probably don't have shibboleth or apache in front of your PeopleSoft
application, which would make the maintenance of jmeter scripts much easier, but
PTools upgrades were an issue.
When the jmeter scripts worked, they worked very well, but we were spending a
lot of time re-generating our load testing scripts.
We are currently contracting with Oracle's OATS product for our load testing.
Regards,
Natalie Maines
Senior IT Analyst
Duke University
natalie.mai...@duke.edu
-----Original Message-----
From: Tony Anecito [mailto:adanec...@yahoo.com]
Sent: Tuesday, January 07, 2014 2:59 PM
To: JMeter
Subject: Peoplesoft load testing...
Hi All,
Has anyone use JMeter for peoplesoft 9.2 load testing?
Thanks,
-Tony
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
For additional commands, e-mail: user-h...@jmeter.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
For additional commands, e-mail: user-h...@jmeter.apache.org
