| || |
sqarobot.jar Corrupting Java Objects?
User Sean P. Kane (firstname.lastname@example.org) posted:
I'm having a very odd, but completely repeatable issue with certain GUI
elements in my Java (SUN JDK 1.3.1_01) application losing functionality or
simply disappearing. The application runs fine during manual tests, but
certain widjets start to exhibit odd functionality after progressing so far
through a suite of test scrtipts. This problem seems to evolve the longer
Robot is accessing the application.
1) certain buttons no longer launching an event when pressed (or so it
2) A combobox no longer being navigatable using the first letter of an entry
in that box (i.e. hitting "b" to automatically scrool down to the first
thing that starts with "b")
3) And a vanishing scrollbar. This scrool bar only appears when the java
tree is to long to fit in the assigned area, but once robot has run awhile
it never appears, no matter what.
Has anyone seen any issues like this themselves, and do you have any
thoughts on solutions?
Re: sqarobot.jar Corrupting Java Objects?
User Schoen, Torsten 3865 PPE-QA1 (Torsten.Schoen@de.heidelberg.com.nospam) posted:
Oh boy, that sure sounds familiar. Actually I had similar things happen to
me in our AUT as well, and here are the findings in regard to some of the
problems you face:
With the sqarobot.jar the amount of memory used by the UI increases a bit,
and sometimes that makes a difference by itself. Also as all objects require
some extra bytes with the additional methods robot utilizes, so if your
application has memory leaks that shows earlier than in manual testing. With
Java applications the amount of memory used is configurable on the command
line of java.exe, and it helps to increase the min and max values to
overcome those problems. Of course you also want the memory leaks to be
fixed. Memory leaks are most often introduced with calls to C++ code, not
with the native JDK classes (anymore, that is).
Another thing to be aware of is the frequency the garbage collector is
called. In an automation environment java and robot compete for cpu time,
and if Java doesn't get enough of that you might soon run into the described
problems because the gc doesn't get called often enough. This problem is
worsened by the rapid execution of the scripts by robot. I have played with
the delay between commands option of robot and found values between 200ms to
500ms to reduce the number of faults. At certain points a delayfor might be
needed as well. As test equipment we used some brand new server systems, 2x
PIII-933, 512MB - 1GB RAM and fast SCSI drives. That made Java testing
possible in regards to performance and stability.
In 1 script I had to use a combination of mouse actions and keyboard strokes
to make the navigation work, neither mouse nor keyboard by themselves would
do for a stable script. Never found out why, though. And another script kept
blowing up after 10-12 repetitions, of which we needed about 400. To restart
the aut after every 8 repetitions was a workaround, but nasty. We had our
developers write a DLL with which we can interface the server directly
without the UI to get a better coverage of the servercode and reduced the
amount of UI testing dramatically.
Hope that helps a little, and you can work around the rest ;-)
Heidelberger Druckmaschinen AG