| Automate Your Testing with BadBoy |
|
| Written by Brent Martin | |||||
| Tuesday, 25 December 2007 | |||||
|
A few months ago I had an opportunity to do performance testing, but I didn’t have a commercial performance testing tool available. Our users were way too busy to pound on the system until we got it tuned the way we liked, so I started looking for open source or cheap tools to help out. I ended up getting to know a product called BadBoy (http://www.badboy.com.au) very well. I haven’t written about BadBoy on this blog yet, but it certainly deserves some attention. In a sense, it reminds me of what you could once do with SQA Robot and PeopleTools 7.x. Essentially you can record a session, and play it back as a script. Badboy isn’t open source, but it is free if you don’t install it on more than 5 workstations in your organization, and it’s cheap for everybody. A 10 license pack is only $250 USD. There are several features that make it a very nice tool for PeopleSoft testing: 1) You can define variables that can later be used in a script.2) You can set variables based on a file input. 3) You can check for specific text on a page (using Regular Expressions) and take action depending on the Regex Match. 4) You can loop until a specific condition is met. I especially liked the Regular Expression matching features. I had one script that ran a query, and applied AR payments to items depending on the results of that query. BadBoy links to Internet Explorer’s API’s, and all of the recording is done through an Internet Explorer interface. That gives you several advantages: 1) You can record SSL sessions because BadBoy can see all of the requests and responses after they’ve been unencrypted at the client.2) All of the JavaScript executes and BadBoy can record responses to javascript requests like pop-up windows. 3) At playback, BadBoy can execute all of the JavaScript that a browser would run at playback time, and play back your pre-defined responses. BadBoy isn’t specifically a PeopleSoft Performance Testing tool, so you need to be aware of some specific quirks of PeopleSoft’s HTML processor. For example: 1) PeopleSoft adds an HTTP variable called ICStateNum on every form. ICStateNum gets incremented with every component. PeopleSoft checks the returned value of ICStateNum with what it originally sent to make sure the requests are received in the expected order. If they get out of order, you’ll get the “Click here to return to your most recent page” error we all know and love. This gets to be a problem if you want to combine scripts or rearrange the order of steps. Simply removing the ICStateNum variables from your script seems to be an effective way to work around this problem.2) PeopleSoft re-sends every variable on the page with every Post request. So if you want to make EMPLID use a variable, make sure you change every Post request in your script to use your variable. Changing just the first occurrence isn’t good enough. 3) Your script should manage sign-off’s appropriately so that stale sessions don’t clog up your application servers and bring everything to a halt. In my opinion, BadBoy is an interesting functional testing tool. If you want to record a series of test scripts to perform regression testing that’s a nice use of it. I don’t feel like it’s a particularly good performance testing tool. Some of the challenges I ran into with BadBoy when performance testing were: 1) If you run your script in “Raw thread” mode, it performs very well. Unfortunately you can’t use variables in “raw thread” mode. You have to use some of the other more processor hungry modes (like External MSHTML ) if you need to use variables. This limits the number of sessions that can run on a single CPU. I’ve never seen a performance test script that didn’t use variables to some extent, so this is a huge limiting factor.2) External MSHTML threads have another problem. Since they simulate Internet Explorer sessions, interpreting Javascript and the like, they are very processor-hungry. I was able to bring a 4-CPU system to its knees with (as I recall) around 25 sessions. 3) BadBoy stores response information as part of the test script, so BadBoy’s GUI interface performance grows slower the more the tests are executed. Fortunately this doesn't seem to impact the execution of test scripts. 4) I didn’t have any luck getting BadBoy to take action on pop-up windows if they had any “Explanation” text in them. To workaround this problem, I had to go to the message catalog and remove the explanation text. In theory, you can export BadBoy scripts to JMeter. But in practice I found that this only worked reliably for the most rudimentary test scripts. I always had more luck building a JMeter script by using the HTTP Proxy Server delivered with JMeter. Some of the more valuable BadBoy scripts I wrote included: 1) A test script to delete users. I like to delete users on-line since it hits so many tables, but I hate to delete more than a couple because it takes so long. It’s nice to kick off a badboy script that reads the users to delete from a file, then go to lunch and let it do its thing.2) A script to do some sanity checks on a new environment. It can run reports, check posting actions, and verify integration broker works after a new environment is created or refreshed.
|
|||||
| Last Updated ( Monday, 28 January 2008 ) | |||||
| < Prev | Next > |
|---|