"Let\'s face it..."
... says the test engineer. "There are many controls our developers create WinRunner is not able to detect or to handle."
Our developers ask: "What is it you need from our windows and controls to make WinRunner happy?"
And that is my question: Is there any reference or contribution describing the requirements on a GUI element so WinRunner can deal with it?
Thanks for answering...
Re: "Let\'s face it..."
"What is it you need from our windows and controls to make WinRunner happy?"
You need a method of unique recognition.
1) WinRunner User Guide
2) The TSL Online Help and examples
3) Addins to accommodate certain controls
4) The information in the archives of this forum
5) Mercury support
You also need to read the FAQ and posting guidelines as your topic gives no guidance.
Re: "Let\'s face it..."
Besides being able to uniquly identify the controls, you have to be able to work with them.
One generalization is that controls created from scratch are usually not recognized. Just for the sake of argument, suppose you're working in a windows environment. Suppose your developers like to re-invent the wheel, so they create their own edit box. All the functionality for drawing and text editing is developed from scratch. The object looks and acts like a regular Windows edit, but it's not. Since the WinRunner programmers have never seen such an animal, the code for dealing with it cannot be present. The end result: WinRunner recognizes that there's an object of some sort but doesn't know what kind. It records obj_mouse_click and obj_type. The solution in this case would be to write your own custom replay function - something like my_edit_set.
Another common problem occurrs when the developers take a standard object, but then add a few bells and whistles. Suppose the need exists for an edit box that plays Bethoven's ninth symphony when both mouse buttons are clicked. In object-oriented terminoligy, the developers would create a sub-class of the standard Windows edit object, then add functionality for handling the double mouse click event. When such a derived class is created, WinRunner often doesn't recognize the unerlying control (class object). The solution in this case is to map the class to class edit (set_class_map). In other words, WinRunner doesn't know what it is, but you do. Since the standard edit functionality is still present in the object , set_class_map will work (assuming it's a windows object - java will need something else). You will of course still need a custom replay function for dealing with the bells and whistles - something like edit_play_ninth_symphony.
I hope this helps - Good Luck.