Software Testing With Virtual User

A cost-effective proving ground for software

By Jeremy Vineyard

Introduction

It is continually frustrating to have new applications crash soon after being installed. Such products give the impression that insufficient work was done before shipping to ensure their quality.

In software companies today, it is standard procedure to test a product to ensure its quality and reliablity before shipping. Quality Assurance (QA) is a common name for such testing. QA is becoming increasingly important as applications take on ever-increasing size and complexity. There can be many thousands of variations in the ways a user might interact with a software product, and a QA tester must check these to verify that everything works correctly. So QA testers need the tools to get their job done effectively.

There are numerous ways to improve the software testing process, but one of the most effective has been the automated testing tool, whereby QA testers can set up specific tests and suites of tests to be run by the computer. This frees them from many hours of drudgery, thus saving both time and money by allowing them to refocus their energies on tasks that need more human interaction, spreading the range of the testing eventually completed. This also leads to more reliability in the software.

You don’t have to have a dedicated QA department to be able to test your products. Even if you are a small developer, it is a good idea always to verify the quality of your products before they are shipped, and automated tools can help. One of the most popular automated testing tools for the Mac is Virtual User.

What is Virtual User?

Virtual User (VU) is an automated testing tool that allows a computer to emulate a human user, performing actions such as clicking the mouse and typing keys. This computer acts as a host, and controls other computers just as a person would. One or more target computers act as agents receiving instructions from the host.

Figure 1. Virtual User

The VU environment consists of an application that compiles and run scripts. VU scripts must be edited separately in a text editor, such as MPW or BBEdit.

VU links computers together over an AppleTalk network. The minimum setup for a VU testing system is the VU software package and two computers (one host and one target).

VU is developed by Apple Computer, Inc., and is available for under $100 through most Macintosh developer catalogs. [It comes for free if you’re already subscribing to the ETO CD. Apple lists the price as $150 on their Web site, at http://dev.info.apple.com/TPC/VU.Datasheet.html, but says $79 in the printed APDA catalogue. Go figure. - man]

Limitations Of Virtual User

There are many things that an automated tool cannot do, and it is important to realize these limitations before planning your automated test suites. An automated tool cannot tell when something “looks right” on the screen. VU can’t tell you when an icon or window is pretty or ugly or misaligned.

VU is fairly unintelligent. You can tell it to “Move window ‘My Window’ to (x,y)”, but you can’t tell it to “Open icon for hard drive in Finder.” Also, if the target machine crashes, VU doesn’t know about it and will keep trying to run the script. The script can be paused and the machine restarted to allow the script to resume. Proper debugging techniques are essential for determining the events that led up to the crash. Some of these techniques will be explained later in the article.

Advantages of Virtual User

VU is most effective at highly repetitive tests that may have many variations. One example might be to select every control in every dialog in the application, making sure that each click produces the appropriate dialog, action, etc. This would be a very tedious task for a human to accomplish, but the computer doesn’t care about tediousness, making it the ideal tester for the project.

Another use of VU is to write a test that can be run after every internal build of a product (development, alpha, beta, final candidate) to verify that nothing was broken by the code changes made to the previous version. VU can also be used to set up automatic bug verification, by acting out the steps necessary to reproduce a bug. With this capability, the automatic bug verification can be run on every new release of a product to ensure that the bug is fixed and that it doesn’t sneak back into the code.

Understanding Virtual User Scripts

Each automated script has an entry point specified by the script statement in VU:

script TestControlsAndWindows()
begin
    # Do automated tests here.
end;

From then on, the VU script is much like the actions of a person. You tell it to click on windows or buttons, move the mouse, type keys, and more. Here is an example of a script that will test some menu items:

script TestMenuItems()
begin
    # Select the menu item “Show Script Window” from the “Windows” menu.
 select [menuItem title:"Show Script Window" 
 menu:[menu title:"Windows"]];

    # Wait 10 seconds for the window to appear.
 wait(10);

    # Verify that the “Script Window” window appears.
 if match [window ordinality:1 title:"Script Window"]
 println("The window 'Script Window' 
 opened correctly.");
 else
 println("ERROR! The window 'Script Window'
  did not open.");
end;

In addition to scripts, VU supports functions that act as extensions to the script. These are called tasks. A task is a procedure with a list of parameters and an optional return value.

task DoTheRightThing(var1 := "default value", var2)
begin
    # Do the right thing here.
 
    # Return a value (optional).
 return "result";
end;

VU collects information about the target computer’s environment using (as we have already seen) the match statement. The match statement looks for a specific environment element, using descriptor traits such as the element’s title or ordinality.

VU can “see” any menu or window and any control that is implemented with the Control Manager and stored in the window’s list of controls. However, because the List Manager doesn’t provide a standard API for accessing the contents of a list, VU cannot see a list or the items inside it. VU can also see dialog items such as user items, static text, edit text, icons, and pictures.

# Find the menu called “Testing”.
theMenu := match [menu title:"Testing"];

# Find the frontmost window.
theWindow := match [window ordinality:1];

The collect statement is similar to match in that it collects all the elements of a certain type into a list.

# Keep a list of all the open windows.
windowList := collect [window];

VU then interacts with the environment, using such keywords as select, drag, close, type, and click. VU accesses common Macintosh objects such as windows, buttons, scroll bars, and menus.

# Select the menu item.
select [menuItem title:"Show Clipboard" 
 menu:[menu title:"Edit"]];

# Move the window.
drag [window title:"Clipboard"] relative:{30, 30};

# Type characters into the window.
type keystrokes:{"This is some text"};

# Select a button.
select [button title:"OK"];

# Close the window.
close [window ordinality:1 title:"Clipboard"]!;

Tip: If possible, implement your application windows as modeless dialogs. VU recognizes the user item element in a dialog, allowing user items to indicate to VU where non-standard user interface elements are located.

Debugging Virtual User Scripts

VU provides a log file feature, by which information from within the script can be written out, providing the scripter with information about the current run-time state of the script. One of the most effective ways to debug an automated script is to log with the println statement anywhere anything important happens or changes. (The {} syntax substitutes the actual values of the variables for the variable names in the string.)

task MyTask(var1, var2, var3)
begin
 println("MyTask({var1}, {var2}, {var3})");

 println("Starting batch processing.");
 StartBatchProcessing();
end;

Tip: Because there is no type checking in VU, it is a good idea to log the parameters that are input into every task to make sure that the correct values were passed.

Extending Virtual User with Libraries

One of the most useful features of VU is the ability to split commonly used tasks into reusable files called libraries. To use all of the tasks in a library, the Libraries statement is used as shown:

# This statement makes all the tasks in the file called “Special Tools.vulib” 
# accessible to this script.
Libraries "Special Tools.vulib";

Libraries are commonly used to group tasks with common actions into smaller and more manageable files, such as Finder Tools.vulib, My App Tools.vulib, etc.

Tip: Because large projects may have dozens of library files, it is a good idea to establish a naming convention for both the names of the library files and the names of the tasks within the files. One might, for instance, append “Tools.vulib” to the name of every library file, and use a unique two-letter prefix for every task in the library.

# This task is in the library “Finder Tools.vulib”.
task FT_EjectDisk()
begin
    # Eject the disk with a command-key combination.
 pressKey keystrokes:{commandKey};
 type keystrokes:{'E'};
 releaseKey keystrokes:{commandKey};
end;

Extending Virtual User with Globals

Another useful feature of VU is support for global variables. To declare a global variable, simply place the global keyword before the variable name when you define it.

# Once this variable is defined, it can be accessed from anywhere.
global gMyGlobal := 1000;

To access a previously defined global variable, again attach the global keyword before using the variable.

Here is an example of how using global variables can save considerable time and effort. This script:

task MA_DoThis(appVersion := '1.0', var1, var2, var3)
begin
end;

task MA_DoThat(appVersion := '1.0', var1, var2)
begin
end;

script MyScript()
begin
 MA_DoThis('1.0', 10, 20, 30);
 MA_DoThat('1.0', "test", "do");
end;

can be simplified to this:

task MA_DoThis(var1, var2, var3)
begin
    # Now the variable ‘gAppVersion’ is using the global value.
 global gAppVersion;
end;

task MA_DoThat(var1, var2)
begin
    # Now the variable ‘gAppVersion’ is using the global value.
 global gAppVersion;
end;

script MyScript()
begin
 global gAppVersion := '1.0';

 MA_DoThis(10, 20, 30);
 MA_DoThat("test", "do");
end;

The advantages may seem small in this simple example, but once you start writing scripts with hundreds or even thousands of separate tasks being called, it can be difficult to pass variables several levels deep through the chain. Using globals allows variables to be accessed from anywhere within the script.

Tip: For applications whose user interface is changing rapidly, insteading of searching all of your scripts and libraries every time the text for a menu item, window, or button is changed, use a global variable that is declared at the beginning of every script, to hold the current state of the interface item.

# This task must be called before the globals can be used.
task MA_DeclareGlobals()
begin
 global toolsMenu := [menu title:"Tools"];

    # If the name of the paint tool menu item ever changes, we have only to
    # change it in one place, and all other scripts will be using the correct
    # value. This keeps us from having to replace the string everywhere it
    # occurs in all of the scripts.
 global paintToolMenuItem := 
 [menuItem title:"Painter" menu:toolsMenu];
end;

task MA_SwitchToPaintTool()
begin
 select global paintToolMenuItem;
end;

Extending Virtual User with External Tools

If you find that you have reached the limitations of the VU language, it is possible to write an external tool for VU. An external tool is an application that communicates with VU by sending and receiving Apple events. Because the external tool can be written in a more powerful language such as C/C++ or Pascal, the VU language can be extended. Templates and examples for creating external tools come with VU, eliminating much of the work.

Additional Features of Virtual User

VU has many of the features of a modern programming language, including if-else statements, for/while loops, list- and string-processing operators, and more.

VU has a built-in regular expression matching system that allows you to write scripts that match environment elements based on regular expressions, rather than simple strings. This is useful for multiple interface elements that may have similar names, but are not exactly the same. “Untitled-1”, “Untitled-2”, etc., can be represented by the regular expression “/Untitled- /”.

When running against multiple target machines, agents can communicate with each other by sending and receiving messages. This allows synchronization of events for software that can be run on multiple systems at the same time. This is useful for network software products that must be installed on more than one machine to communicate with one another.

The best place to learn about the features of VU is to look in the VU Language Reference manual. It is well written, and thoroughly describes the capabilities of the VU language.

Summary

Automated testing tools will never be able to entirely replace human testers in QA, nor should they. Most of what QA does is about discerning how a user might interact with a product, and a computer cannot always predict these actions or define a good way to test them. However, used properly, automated tools can greatly increase the productivity of QA, saving labor costs, increasing consistency, and shortening time to market. In today’s highly competitive environment, automated tools can provide you with the edge you need to succeed.

[There is a great deal of VU-related material on the Tool Chest editions of Apple’s Developer CD. For instance, in the May CD, which was the current Tool Chest CD as this issue went to press, the Testing & Debugging folder inside the Subject Index folder held aliases to various folders containing VU material, including a tutorial and a host of tools that extend VU’s abilities in valuable ways (note, in particular, Ivy, which allows VU to “capture and compare screen images”). - man]