Re: Automated GUI testing

Hi Ide,

I did a program like this but it wasn't for testing, it was to
completely hide an expensive hard to use licensed program and present
to the users a simple cut down interface. Amazingly, this project
succeeded. It succeeded because of few key reasons.

1. Keyboard accelerators are your friends.
2. Command buttons are your enemy, especially those that can change
meaning with context.
3. Text boxes are your friends.
4. Bitmaps are your enemy.
5. Menus are your friend only if each menu item has a keyboard
accelerator associated with it.
6. Variable menus are your enemy.
7. Focus (or the loss of it) is your enemy.

Having this ideas in mind you can succeed if you control the program
to be tested and you can limit your remote control to keyboard
accelerators and setting text properties in dialogs etc. Thoughtful
naming can make your job of locating the proper window and control
easier.

In my case, the program to be manipulated was used by an operator in a
call center. The interface was considered too complicated for our
users to master. I never exected it to work at all, but somehow it
worked marvelously well.

So here's how I attacked the problem. I coded one step at a time. I
heavily used the SPY++ to see what messages were flowing in normal
operation of the program. Then I wrote code to find those windows,
give them focus, and send them the same messages. I was able to avoid
having to simulate mouse movement (thank god).

I used alot of FindWindow followed by PostMessage of WM_COMMAND.
For dialogs I used FindWindow with enumchildwindows wherein I would
read the window class name compare for "Button", then look at the
caption, strip the ampersands, compare the caption for "OK" or "Yes"
or "Cancel". Send that windows WM_SETFOCUS, WM_LBUTTONDOWN,
WM_LBUTTONUP. For text boxes on dialogs I would send the same three
messages follow by EM_SETSEL 0, and WM_KEYDOWN messages for each
character I wanted to load into the control on the (invisible) dialog.

I also had to use GetMenu to observe status information which was
thankfully visible as checkmarks on menu items.

Incredibly, this program worked even though the underlying program
went through several versions. It was used on on 50 workstations at
once.

So, if you control that target program then you can make your job much
easier by making everything visible in these ways which are fairly
straightforward. Avoid menus that add/change delete items all the
time. Use accelerators on everything you can. Always supply check
marks on menu items for things that you want to observe. Always use
simple text controls and unambiguous command buttons where you know
you will need to feed text into the target program.

I was lucky in my project because I only had to interact with perhaps
20 of these points in the target program. I wish you similar good
luck in your project,

Hope this helps,

- Kurt

On 30 Jun 2005 22:03:15 -0700, idesilva@xxxxxxxxxxxxxx wrote:

>Hi,
>
>I'm in the process of developing a GUI testing tool. The tool should
>provilde the ability to define a GUI test case using a 'script' and
>then 'simulate' the necessary key/mouse inputs and 'recognize' actual
>outputs on the screen using OCR or similar techniques.
>
>The platform I use is MFC with VC 6.0 or 7.0 (unmanaged).
>
>My approach is to use two levels of scripts:
>1) Window Definitions Scripts
>2) Business Scripts
>
>What I want now is to come up with a scheme to 'define' the layout of a
>window. This definition must be 'tied' to the actual app windows, to
>enable input simulation and output recognition.
>
>Say, I want to test a Login Screen. Then I want to define the screen
>as:
>
>//----------------------------------------------------------------
><Window Name="LoginScreen">
> <Component Title="UserID" Type="Lable" X=100 Y=20>
> <Component Title="Password" Type="Lable" X=100 Y=50>
> ...
> <Component Title="OK" Type="Button" X=400 Y=100>
> <Component Title="Cancel" Type="Button" X=400 Y=130>
>
> <Action Name="OK" Target="OK" ID="IDC_OK" Command="WM_CLICK">
></Window>
>//----------------------------------------------------------------
>
>
>Then to write the business script as:
>
>
>//----------------------------------------------------------------
>LoginScreen scr; // define a LoginScreen object
>
>scr.UserID = "test"
>scr.Password = "123"
>
>scr.OK() // Perform the 'Action' defined above
>//----------------------------------------------------------------
>
>
>If I define 'actions' as in:
>
><Action Title="OK" Target="OK" ID="IDC_OK" Command="WM_CLICK">
>
>I should be able to send commands to a 'different' app from my test
>tool.
>
>Can this be done? How can one application query the window components
>of another app and send commands to it?
>
>I would appreciate any insights (or references) into how MS Windows
>uses resource IDs, control IDs and window IDs etc. to tie up a UI.
>Please share your experiences and comment on the feasibility of the
>approach I'm going to take.
>
>To sum up, my main question is how can one 'define' the layout of a
>window so that a robot app can read and control it?
>
>Many thanks in advance,
>Ishan.

.