Stress Testing The WinFrame Server
Using LoadRunner & WinRunner

(Page 2)

Enough Talk, What's the Secret?

The key is really simple. All that you will have to do is to cycle through all of the WinFrame session windows, one at a time, from the first to the last, and performing the action on the current window. For your action, use the context sensitive win_ commands, since they're performed relative to the window. This means that the WinFrame session window's location is irrelevant as long as it is completely visible on the display. Here is the pseudocode:

  for each WinFrame window {
    set the focus to the window
    perform action on the window
  }
  repeat the above loop with different actions.

and a code snippet:

  for (i = 0; i < windows_count; i++) {
    win_activate (windows[i]);
    # Perform action here, e.g.:
    win_mouse_click (windows[i], 100, 150);
  }

Now, if you'll notice, I'm using the win_activate() function as opposed to the set_window() function. There are 2 reasons for this:

1. This will make sure that the intended window is brought to the foreground. If you're going to be opening 10 sessions of WinFrame, at a default (and realistic) window size of 640 x 480 pixels, some of the windows are going to overlap. The WinRunner technical note suggests that you set the WinFrame window's size to a smaller size so that each window will not overlap the others, but this is not a good design because: your application under WinFrame might not show properly at the smaller display size, and you are limited by your display area.
   There are two options to allow more windows to share the real estate: either by minimizing/restoring the windows (minimized when not in use, restore when it's going to receive some action) or letting the windows overlap over each other. Minimizing and maximizing seems cleaner on the display, but it has a fairly large delay penalty (about 1 second to minimize and another 1 second to restore). One of the fear of overlapping windows is when the window that should be acted on is at the bottom of the pile.
   Fortunately, by using the win_activate() command, WinRunner will actually brings the specified window to the foreground.
2. At the same time, the win_activate() function also sets the focus to the window. Two hits with one command!!

That said, you should have a fairly good foundation about implementing a WinRunner script that controls multiple WinFrame sessions.

Optimizing the Action Between WinFrame Sessions

Beyond getting faster hardware, there are several areas where you can try to optimize the actions performed on the WinFrame sessions. Why is this important? Because in stress testing you want to synchronize all of the actions between the different users to simulate a peak load. The slower the actions are performed between the different WinFrame sessions, the less synchronized the load will be. The faster you can get WinRunner to perform its actions between all of the WinFrame session windows, the better it is. Also, it looks very cool when the computer's flipping between 15 windows in a matter of 5 seconds!!

GUI Interaction

As a rule, mouse action takes longer to perform than keystrokes. So, if you're concerned with trying to simulate simultaneous actions between the windows, try to see if there is a keystroke equivalent that will do the task. For example:

• Pressing the Return key ("<kReturn>") will usually click on the default button (e.g. the OK button).
• If the button that you want to press is not the default, you can try to set the focus to it by tabbing between the objects ("<kTab>" and "<kS_Tab>") and then pressing the space bar or return key.
• When selecting menu items, you can use the keyboard shortcuts (the Alt key equivalent, e.g.: "<kAlt_L-f>o" to open a file when the menu item is "File;Open").
• Most objects also have mnemonic keyboard shortcuts that you can take advantage of. They're also accessed by using the Alt key combined with the mnemonic key.

All right. Now you have the GUI interaction part optimized. How about the waiting for the action to complete?

GUI "Check"

I only have one answer for this, use text recognition as opposed to bitmap recognition. Remember that our goal here is to load the WinFrame server, not check the functionality of the application. Text recognition can take as little as 0.5 (half) a second per window, while bitmap recognition (with a timeout value of 0, and all the option settings set to 0, in a compiled module) takes at least twice as long. To perform the text recognition, all you have to do is get the text from the specified area, and then compare it with the text that you're expecting. Usually, when the session is in a wait state (hourglass cursor), the WinFrame window will be blank. So this is a very good check to use. Here's the code snippet to do this:

  # wait_str is the text to wait for
  # win_names_racount is the number of windows
  # res_ra[] is an array that stores the text check result for each of the window
  # max_wait is the wait limit
  count = 0;
  start_time = get_time();
  do {
    for (i = 0; i < win_names_racount; i++) {
      if (res_ra[i] != E_OK) {
        win_activate (win_names_ra[i]);
        res_ra[i] = ((win_get_text (win_names_ra[i], tmp, x1, y1, x2, y2) == E_OK)
            ? ((tmp == wait_str) ? E_OK : E_GENERAL_ERROR) : E_GENERAL_ERROR );
        if (res_ra[i] == E_OK) {
          count++;
        }
      }
    }
  } while (((get_time () - start_time) < max_wait) &&
    (count < win_names_racount));

The above code will go through all of the windows, and check if the text has appeared in the window. If the text appears, then the window will be skipped in the next iteration. This helps minimize the amount of checks that is done, and reduce unnecessary duplicate checks.

If you absolutely have to use bitmap checks, try to minimize the size of the bitmap area as possible so as to minimize the process's time.

Optimizing the Script

Finally, don't forget that optimizing your script will mean faster execution also. Create custom functions for regularly used actions, save them as a compiled module, and load the module as a system module.

Tech Page @