Are there any tips on automating an installation of an application using SilkTest?

Are there any tips on automating an installation of an application using SilkTest?

Structuring the Automation

The techniques used in automating the software installation may also be applied to any application that proceeds through a sequence of forms in completing a core task. The important things to think about in terms of the install program are that there are multiple configuration screens, and that each of these screens allows the user to cancel the installation at that point.

To automate the sequence of screens, the best approach is to declare each screen and then write a standard set of methods, modified to fit each screen. Some methods may be written at the class level whereas others need to be rewritten for each screen.

In a standard install, the following methods are useful for each input screen:

  • Invoke - This method is used to open the specified screen, having progressed through all preceding screens. The previous screens are either passed through with default data, or the data for the Invoke must incorporate all data needed to reach the specified screen. Here is a sample Invoke method:

    VOID Invoke ()
         if !InstallShield.Exists ()
             InstallShield.Invoke ()
         SQ_WaitForWindow (InstallShield,120)

  • Configure - Used to modify configuration parameters on the specified screen. Here is an example of a Configure method:

    VOID Configure (SETUP_TYPE stSetup)

  • Cancel - Cancels the installation at the specified screen. Also confirms the cancel request when asked and completes the cancellation. Here is a sample Cancel method:

    VOID Cancel ()
         Cancel.Click ()
         ExitSetup.Yes.Click ()

  • Resume - Issues a cancellation request. When asked for confirmation, responds in the negative and completes the installation. Here is a sample Resume method:

    VOID Resume ()
         Cancel.Click ()
         ExitSetup.No.Click ()

  • Finish - After configuration or resuming from cancel, used to kick off completion of the installation. Data for subsequent screens is either defaulted or passed from this method. Here is a sample Finish method:

    VOID Finish ()
         if (RebootDialog.Exists())

The majority of testcases for an install involve an isolated event such as modifying one default parameter. These testcases can be automated using the previous methods. For instance, one testcase might modify the installation directory, but take all other defaults. The testcase would perform the following steps using the above methods:

  • Invoke the directory modification window
  • Configure the window with the desired data
  • Complete the installation from the same screen
  • Perform verification of successful installation as described later in this article

Using the methods described earlier, it is possible to put together all kinds of combinations that cover a broad range of testcases. The follow section gives suggestions for handling a reboot situation during installation (or at any time).

Automating a Reboot

Installation programs typically involve rebooting the machine upon which the installation is being performed. There are other situations, as well, where rebooting is desirable during automation. SilkTest is well suited to handling these situations.

SilkTest must be used in its host-target mode when a reboot is to be part of the automation. In this mode, the SilkTest client runs on one machine and the Agent runs on another.

The Agent needs to run on the machine where the installation is occurring. The following steps are used to automate the installation reboot, or any reboot:

  • Initiate reboot - The installation program will do this when the last screen is accepted. If rebooting in other situations, the reboot needs to be undertaken in a slightly delayed fashion to allow time for the disconnect, so or the Task Manager cannot be used for the reboot.

  • Disconnect from the Agent - SilkTest must be disconnected from the remote Agent before the reboot occurs.

  • Wait for reboot - Commands using the Agent should not be executed during the reboot. The simplest approach is to perform a Sleep. Make sure the Sleep is long enough to allow the remote machine to complete the reboot.

  • Reconnect to the remote Agent - In order to complete this step, the remote machine must be able to complete booting up in an unattended fashion. This includes logging into the network if needed. Utility programs such as TweakUI are useful for this. In addition, the SilkTest Agent must come up on its own, prior to reconnecting. Put the Agent in the Startup folder to make this happen.

The following function, may be used to perform the above steps:

// function:  SQ_WaitDuringReboot (iTimeToWait, sMachine)
// parameter: iTimeToWait: The amount of time to wait for the reboot to happen. INTEGER
// parameter: sMachine: The name of the machine to connect to after the reboot. STRING.
// notes:     Disconnects, waits the specified amount of time, then reconnects.

VOID SQ_WaitDuringReboot (INTEGER iTimeToWait, STRING sMachine)
     // Disconnect from any connected agent
     // Wait the specified amount of time
     Sleep (iTimeToWait)
     // Reconnect to the specified machine
     Connect (sMachine)
     // Close message box if we get one
     if MessBox.Exists ()
          MessBox.SetActive ()
          MessBox.Close ()



Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Top Contributors
Version history
Revision #:
1 of 1
Last update:
‎2013-02-15 19:24
Updated by:
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.