115
`United States Patent
`5,870,539
`[11] Patent Number:
`[45] Date of Patent:
`Feb. 9, 1999
`Schaffer
`
`US005870539A
`
`[54] METHOD FOR GENERALIZED WINDOWS
`APPLICATION INSTALL TESTING FOR USE
`WITH AN AUTOMATED TEST TOOL
`
`Computer Design, vol. 31, No. 7, 1 July 1992, pp. 57-58,
`60,62,64, T. Williams: “Automation Improves Speed and
`Accuracy of Software Testing”I.
`
`[75]
`
`Inventor: Daniel H. Schaffer, Colorado Springs,
`Colo.
`
`[73] Assignee: Sun Microsystems, Inc., Palo Alto,
`Calif.
`
`[21] Appl. No.: 674,355
`
`[22]
`
`Filed:
`
`Jul. 1, 1996
`
`PSU] Tt, C08 nee ceeeccseseeeeeeeceesnneerecnnnnees G06F 15/60
`
`.. 395/183.14; 395/183.13
`[52] U.S. Cl.
`...
`oO
`Field of Search ...........0.0.0..0....... 395/183.14, 183.01,
`[58]
`395/183.11, 183.22, 183.21; 371/25.1
`
`[56]
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`4,991,176
`5,233,611
`5,394,347
`5,500,941
`5,513,315
`5,542,043
`5,596,714
`5,600,790
`5,630,049
`5,651,111
`5,652,835
`
`2/1991 Dahbura et al. oe 371/27
`8/1993 Triantafyllos et al.
`.. 395/183.22
`2/1995 Kita et ale ccccssesccssssseessssssseees 364/578
`3/1996 Gil we
`395/183.14
`4/1996 Tierney et al.
`395/183.13
`7/1996 Cohen et al.
`395/183.08
`1/1997 Connell et al.
`395/183.14
`2/1997 Barnstijn et al.
`395/183.14
`5/1997 Cardoza et al.
`395/183.01
`7/1997 McKeeman...
`.. 395/183.14
`7/1997 Miller oot eeceeeeeeeeeeee 395/183.14
`OTHER PUBLICATIONS
`
`
`
`
`...
`.
`..
`
`.
`
`Primary Examiner—Ly Hua
`Attorney, Agent, or Firm—Richard A. Bachand; William J.
`Kubida; Holland & Hart LLP
`
`[57]
`
`ABSTRACT
`
`A computer implemented method and computer system for
`testing a target software product is presented. The method
`includes constructing a finite state machine in which por-
`tions of the target product are ascribed to states of the state
`machine. ‘he state machine maycorrespond to a predeter-
`minedtest case for the target software product. A number of
`state functions are provided, each of the state functions
`performing at least one verification on the target software
`product. The state functions also may include transitioning
`from onestate to the next, for example, by a “next window”
`a “previous window”action if the target software program
`is a windowsbased program. The state functions may also
`verify that a current state in which the state machine exists
`is a correct state, may verify information that is supposed to
`have been written to a memory is written in fact to the
`memory, and may verify that the path to the information ts
`correct. Information is furnishedto the state machine for use
`
`by the target software product portions ascribed to states of
`the state machine. The information may include test case
`information from a test computer to the target software
`product as required bya test case being performed.
`
`6 Claims, 3 Drawing Sheets
`
`Boris Beizer: “Software Testing Techiniques —Second Edi-
`tion, Chapter 11: States, State Graphs, and Transition Test-
`ing” 1990, Van Nostrand Reinhold, New York, pp. 363-372,
`pp. 387-391.
`
`TEST CASE
`STATE MACHINE
`
`INSTALLATION
`
`INSTALLED
`PROGRAM
`
`PROGRAM
`
`24
`
`Google Exhibit 1129
`Google v. VirtaMove
`
`Google Exhibit 1129
`Google v. VirtaMove
`
`

`

`U.S. Patent
`
`Feb. 9, 1999
`
`Sheet 1 of 3
`
`5,870,539
`
`L O
`
`la
`
`Oooo«2;~S
`
`
`
`lyAYOWINley;|lI
`Ccrwwrens“1jI
`
` Add|e1Itt0/1a!1Reneceeeomeceeeeaeeeoeeeee—s
`
`SESa
`
`reseriererereter
`
`—_
`
`
`

`

`5,870,539
`
`INSTALLATION
`PROGRAM
`
`INSTALLED
`PROGRAM
`
`U.S. Patent
`
`Feb. 9, 1999
`
`Sheet 2 of 3
`
`Y
`------1t------ 4
`TEST CASE
`STATE MACHINE
`
`24
`
`

`

`U.S. Patent
`
`Feb. 9, 1999
`
`Sheet 3 of 3
`
`5,870,539
`
`START
`SETUP.EXE
`
`64
`
`62
`
`CHOOSE
`DESTINATION
`LOCATION
`
`SELECT
`PROGRAM
`FOLDER
`
`NO
`
`60
`y
`
`START
`[NSTALL.EXE
`
`
`DOES ist
`WINDOW EXIST
`2
`
`YES
`
`GET ANY DATA
`
`
`
`
`
`
`
`
`GET 1st ACTION
`
`FIG. 5
`
`
`
`ACTION
`VALID?
`
`YES
`
` ‘x:
`
`
`
`VERIFY INSTALL DCNE
`
`
`
`VERIFY NO MORE ACTIONS
`
`

`

`5,870,539
`
`1
`METHOD FOR GENERALIZED WINDOWS
`APPLICATION INSTALL TESTING FOR USE
`WITH AN AUTOMATEDTEST TOOL
`BACKGROUND OF THE INVENTION
`1. Field of the Invention
`
`This invention relates to improvements in computer
`systems, networks, and the like, and more particularly to
`improvements in methods and apparatuses for testing com-
`puter programs and processes.
`2. Relevant Background
`Producers of software products generally test their prod-
`ucts extensively to ensure proper operation of the products
`on severaldifferent various operating systems and computer
`models. As software products become more lengthy and
`complex, the software product tests also have become more
`lengthy and complex, requiring ever increasing amounts of
`time to perform. The development of routines to test the
`software products, therefore, have become of concern, espe-
`cially considering the market demands of producing
`adequately tested software in reasonable amounts of time.
`Typically,
`to develop a suitable test for a particular
`software product, a software test designer studies the prod-
`uct specifications. He then extracts a list of product features,
`and generates a number of “assertions” regarding the soft-
`ware product (herein the “target program” or “target
`product.”) Anassertionis, for example,a specificationofthe
`behavior of the target program, or part thereof, when it is
`operating properly. Thus, an assertion is a statement of how
`the target program is expected to operate under certain
`conditions, or other appropriate performanceor result ori-
`ented product expectation.
`For each assertion, the designer then develops a set of
`software “test cases.” The test cases exercise as many as
`possible of the code paths in the target product to prove the
`validity of the assertions. If each assertion is proven for a
`particular computer model and operating system, the soft-
`ware product is considered to be fully tested for that par-
`ticular system. Thus,
`for a particular software product,
`typically the target productis tested on various combinations
`of computer models and operating systems on which the
`product may be run.
`Typically, features of the target product are not totally
`independent. For example, most software products are con-
`structed using a number of subroutines, calls, branches,
`loops, and other program techniques. These techniques
`perform operations that are commonto multiple independent
`portions of the software, and which therefore are often
`repeatedly used by different parts of the program in which
`they are incorporated. Moreover, if the target program is
`changed, the tester must tediously change each test case to
`reflect the changes.
`In addition to target programs performing various par-
`ticular functions, sometimes the target programs serve to
`install still other programs onto a computer or computer
`system. A test of the target program, therefore, may require
`an analysis of the computer after the completion of the
`installation process. The analysis, for instance, may ensure
`that the files that should have been installed were installed,
`or that computer configuration steps have left the computer
`properly configured. In addition, often the target program
`has various optionsthat it performs along various pathways
`as a part of or in order to install the underlying program.
`Thus, it is often desirable for the test program to dynami-
`cally test the target program as it performs the various
`installation procedures of the underlying programs being
`installed.
`
`10
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`SUMMARY OF THE INVENTION
`
`Thus, according to a broad aspect of the invention, a
`computer implemented methodfortesting a target software
`product is presented. According to the method, which may
`be implemented on a programmeddigital computer, a finite
`state machine is constructed in which portions ofthe target
`productare ascribed to states of the state machine. The state
`machine may correspondto a predeterminedtest case for the
`target software product.
`A number of state functions are provided. Each of the
`state functions performsat least one verification on the target
`software product, and mayinclude meansfortransitioning
`from onestate to the next, for example, by a “next window,”
`a “previous window,” or another similar action if the target
`software program is a windows based program. ‘Ihe state
`functions may also verify that a current state in which the
`state machine exists is a correct state, may verify informa-
`tion that is supposed to have been written to a disk is written
`in fact to the disk, and may verify that
`the path to the
`information is correct.
`
`Information is furnished to the state machine for use by
`the target software product portions ascribed to states of the
`state machine. The information may include test case infor-
`mation from a test computer to the target software product
`as required bya test case being performed.
`According to yet another broad aspect of the invention, a
`computer implemented methodfor testing a target software
`product is presented. The method includescreating a finite
`state machine having a plurality of states, with each state
`representing a portion of the target software product. The
`target software product may be a windows-based program in
`which each portion of the target software product
`is a
`window.A verification test is performedin at least one of the
`states of the state machine on the target software product.
`Transition edges, which maybe “next window,” “previous
`window,” or other similar button of a windowbased target
`software product,are defined for the state machine with each
`of the transition edges causing the state machine to move to
`anext state. At least one test case is performed on the target
`software product by traversing from a start state to a finish
`state of the state machine. The test case may be performed
`by passing a stream of data containing a next action to a
`currentstate of the state machine to cause a transition of the
`state machine from each state to the next.
`
`According to yet another broad aspect of the invention, a
`computer implemented method for testing a target software
`product on a computer is presented in which a state machine
`is constructed having a plurality of states to represent the
`target software product. The target software product may be
`a windows based product. Each state has at least an entry
`command and an exit command, and may perform func-
`tional
`tests in at
`least some of the states according to
`predefined test cases. If the target software product is a
`windowsbased product, each state of the state machine may
`correspond to an associated window ofthe target software
`product. An evaluation is performed upon an exit from the
`state machine to determine whether a desiredtest case result
`
`has been achieved, and an indication is provided to a user
`whether the target software product passed the state and
`functional
`tests. In one embodiment,
`the target software
`product causes another computer software application to be
`installed. In this embodiment, the state and functional tests
`evaluate the another computer software application during
`the installation.
`
`According to yet another broad aspect of the invention, a
`computer system is prescnted having a state machine having
`
`

`

`5,870,539
`
`3
`a plurality of states, each state having a numberof functions
`associated therewith and having at least one means by which
`the state may be entered and exited. The state machine is
`operatively associated with a target computer product in
`which eachstate of the state machine corresponds with a set
`of steps of the target computer product. A number of
`functions are provided that exercise at least portions of the
`target computer product. A set of states of the state machine
`may correspondto a test case for testing the target computer
`product.
`A tester, which may be, for example, a programmed
`digital computer, is provided for interacting with the state
`machine. The tester includes means for moving among the
`various states of the state machine, meansfor exercising the
`functions performed within each state of the state machine,
`and means for performing a test after a movement through
`a complete predetermined set of the states.
`In one embodiment,
`the target computer product may
`include a main program and at least one subroutine. The
`main program mayrepresenta state of the state machine and
`the subroutine may represent another state of the state
`machine. In another embodiment, the target computer prod-
`uct maybe a windowsbased program, with eachstate of the
`state machine corresponding to a respective window asso-
`ciated with the target computer product. In yet another
`embodiment, the target computer product comprises a com-
`puter program for installing another computer program.
`In yet another broad aspect of the invention, a computer
`program product is presented having a computer useable
`medium and a computer readable code embodied on the
`computer useable medium for testing a target computer
`product. The computer readable code includes computer
`readable program code devices configured to cause a com-
`puter to construct a finite state machine with eachstate of the
`finite state machine corresponding to a respective set of
`program instructions of the target computer product, having
`at least one transition edge, and at least some of the states
`having an associated functional test for application to the
`target computer product. In addition, the computer readable
`code includes computer readable program code devices
`configured to cause a computer to effect transitions among
`the states of the state machine. The computer readable code
`also includes computer readable program code devices con-
`figured to cause a computer to execute the functional test
`when the state machine is in a state with which the func-
`
`tional test is associated. The computer readable program
`code devices is also configured to cause a computer to report
`to a user whether the target computer product passed the
`functionaltest.
`
`In one embodiment, the computer readable code addition-
`ally includes computer readable program code devices con-
`figured to cause a computer to pass data required by the
`target computer productin respective associatedstates of the
`state machine. In one embodiment, the computer readable
`code includes computer readable program code devices
`configured to cause a computer to verify a successful
`operation of the target computer product after all of the
`states of the state machine have beentraversed, or a finish
`state is reached.
`
`In a preferred embodiment, the target computer product is
`used to install another computer software product and fur-
`ther comprises computer readable program cade devices
`configured to causc a computcr to verify a successful
`installation of the installed computer software product after
`all of the states of the state machine have been traversed, or
`a finish state is reached.
`
`4
`The target computer product may be a windows based
`program in which the computer readable program code
`devices are configured to cause a computer to construct a
`finite state machine with each state of the finite state
`machine corresponding to a respective window associated
`with a set of program instructions of the target computer
`product.
`An installation algorithm according to the invention is
`provided which encodesall the installation pathways as one
`system and allowsall the pathways to be represented. Such
`algorithm is easily modified whenthe installation algorithm
`is changed.
`Oneof the advantages of the method of the invention is
`that by virtue of the representation of an application to be
`tested as a state machine in which individual states may be
`redundantly entered,the testing of the target program can be
`accomplished without redundant presentation of test code
`lines or routines, since the test code, as will be apparent, is
`prepared and run simultaneously with, or in parallel with,
`the target program.
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The invention is illustrated in the accompanying
`drawings, in which:
`FIG. 1 is a block diagram showing a gencralized cnvi-
`ronment in which the method and apparatus of the present
`invention maybe used.
`FIG. 2 is a conceptual diagram showing the general
`interrelationship of the state machine, installing computer
`program,
`installed computer program, and computer on
`which they are run and installed, in accordance with one
`preferred embodiment of the invention.
`FIG. 3 is a diagram illustrating a state machine represen-
`tation of a software application for testing the software
`application, in accordance with a preferred embodiment of
`the invention.
`
`10
`
`20
`
`25
`
`30
`
`35
`
`FIG. 4 is a state machine diagram generated for testing a
`software installation application in accordance with a pre-
`ferred embodiment of the invention.
`
`40
`
`FIG. 5 is a representation of a portion of a test program
`to test the software installation application for which the
`state machine has been generated, according to FIG. 4,
`illustrating state function tests for one state of the state
`machine and overall completion tests after the state diagram
`has been traversed.
`
`like reference
`In the various figures of the drawings,
`numerals are used to denote like or similarparts.
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`
`One environment in which the present invention may be
`used encompasses a general distributed computing system,
`general purpose computers, workstations, personal
`computers,or the like, connected by way of communication
`links of various types in a client-server arrangement,
`wherein programsand data, many in the form of objects, are
`made available by various members of the system for
`execution and access by other members of the system.
`Some of the clements of a general purpose workstation
`computer are shown in FIG. 1, wherein a processor 1 is
`shown, having an input/output (“I/O”) section 2, a central
`processing unit (“CPU”) 3, and a memoryscction 4. The I/O
`section 2 is connected to a keyboard 5, a display unit 6, a
`disk storage 9, a CD-ROM drive unit 7, and a network
`interface 11. The CD-ROMdrive unit 7 can read a CD-ROM
`
`45
`
`50
`
`55
`
`60
`
`65
`
`

`

`5,870,539
`
`5
`medium 8, which typically contains programs 10 and data,
`and which also may contain operating system components.
`The computer program products which containing mecha-
`misms to effectuate the apparatus and methods of the present
`invention may reside in the memorysection 4, on the disk
`storage unit 9, on the CD-ROM medium 8, or on the network
`interfaced by the network interface 11.
`This invention provides a method for representing an
`installation process and implementing an installation test
`algorithm that is easy to maintain and modify for use with
`an automated test tool. The following nomenclature is used
`in the description of test algorithm. “Verification step” is
`used to refer to an individual test that is performed at a
`particular stage in the algorithm being tested. “Test case” is
`used to describe a series of verification steps as the algorithm
`is traversed from a start to a finish point. “Test suite” is used
`to refer to the collection of test cases for a particular
`algorithm.
`As will be apparent, the invention is described in the
`context of a software installation program, and more
`particularly, to a programfor testing a program or process
`that
`installs another software program onto a computer.
`Moreover, in the embodimentillustrated and described, the
`software installation program is windowsbased. It should be
`noted, however, that although a windows based software
`installation program is described in detail, those skilled in
`the art will recognize that the invention may be used in
`conjunction with non-windows based programs, programs
`that operate as well within themselves, with separate
`databases, or in other will known modesof operation.
`According to the invention, a test suite may be applied to
`the software installation process via a finite state machine. A
`“state machine” as used in the context of this application is
`a representation of a machine or programmed digital com-
`puter that can be observed as having a numberofdiscrete
`“states” in each of which predefined functions are performed
`and to and from each of which movementis continuously
`defined. Although a state machine maybe represented by a
`hardware apparatus, preferably the state machine may be a
`programmed computer that exists in different states, an
`example of which is a computer that
`is programmed to
`operate with a “windows” based application having a plu-
`rality of discrete window displays among which a user may
`selectively “move” or traverse from one to another, with
`each window representing a machinestate.
`Typically, state machines are thought of in the context of
`digital circuitry and movement from onestate of the state
`machine to anotheris typically thought of being effected by
`the occurrence of an “edge”of a control pulse. In the context
`of the present invention, however,
`the “edges” are repre-
`sented by a selectable action taken by a user, for example,
`the actuation of a “push button” that selectively causes
`another windowor window application to be displayed or
`executed.
`
`10
`
`20
`
`30
`
`40
`
`45
`
`50
`
`55
`
`6
`program or product, the start state of the state machine is
`entered with the first window that appears when the install
`is initiated. The finish start is entered either upon a success-
`ful installation or an aborted installation attempt.
`In addition, a number of state functions are provided.
`Eachstate function is a function for each state for perform-
`ing oneor a series of actions whenthe state machineis in an
`associated state and to transition one state to the next,
`depending upon the particular action taken and data pro-
`cessed in the state. The required actions, information, and
`data are passed to the state machine in a stream of data. For
`example, the stream of data may specify a next action, or
`pass required information or data needed in a window.
`Although each installation may be differently configured,
`general settings for any particular installation may be stored
`in a data structure to which each state function has access.
`Another example of a state function may be to verify the
`install application (or application being tested) is currently
`in its expected state. If an unexpected state is reached, the
`installation test will fail and report an error. The state
`function sets any data relevant to the current window. The
`function verifies the next action from the data stream is a
`valid action then calls the next state function. When a final
`slale is reached, either as a successful or an aborted instal-
`lation or completion of the target program,
`the function
`verifies that the final state has been reached, then verifies
`that no more actions exist in the data stream. If actions exist
`in the data stream an error is logged and the test as failed.
`To design test cases, in particular for a software installa-
`tion program, the installation data structure is filled with
`specific information about the installation and a data stream
`is created to guide the process through the installation
`screens. A starting test case may be created to execute the
`install and call the initial screen, passing the data stream as
`a parameter. As each function is performed, it is removed
`from the data stream, and the next function is called, based
`upon the successive data stream item. When a function is an
`end state, control returnsto thefirst test case, which verifies
`that the data stream is empty. Any failures between theinitial
`function and the end state are reporting and the test stops
`reported an error. After the installation has finished,
`the
`program verifies that
`the installation was properly
`completed, based upon the data which the test case was
`provided.
`It will be appreciated that when changesto the installation
`model are implemented, only the finite state machine rep-
`resenting the install need be modified. Thus,
`instead of
`modifying each test case, only the one set of functions needs
`to be modified to represent the newfinite state machine. To
`code each pathway through the installation, only the data
`stream needs to be written, since the entire pathway is
`coding though the state functions. This approach makes
`coding the install pathways much easier and since all the
`pathways are coding by using the finite state machine
`approach, maintenance is mucheasier than the conventional
`method.
`
`The state machine is established with each possible win-
`A conceptual diagram showing the interrelationship of a
`dow that appears during the running of the installation
`state machine 20 performing test operations on an installa-
`program beingrepresented as a state, and each “push button”
`tion program 22 in its operation of installing an installed
`of the window, or each action that may be selectively
`initiated by a user to move to another window, being
`program 24 onto a computer 26 is shown in FIG. 2. In the
`
`represented by an cdge oratransition triggcring event in the embodimentillustrated in FIG. 2, an installation program 22
`state machine. Thus, generally, push buttons such as ‘Next’
`is the target for the test or tests being performed bythe state
`and ‘Back’ serve as edges that cause the state machine to
`machine 20. In the embodimentillustrated, the program 22
`transition to the next or to a previous state. Other means for
`is a software installation program, the purpose of whichis to
`moving among the various windows maybe used,as will be
`install another program, denoted the “installed program” 24.
`apparent to those skilled in the art. Therefore, in the context
`It should be noted that although the program 22 is an
`of testing a computer product that itsclf installs a computer
`installation program, the principles of the invention may be
`
`60
`
`65
`
`

`

`5,870,539
`
`types of
`
`8
`7
`individual states in the set of states 34 of the stale machine
`equally advantageously employed to other
`programs, as mentioned above.
`20, various transition triggers may be defined conveniently
`as the actuation of push buttons in the individual windows
`In the normal running of the program 22, the program
`may require various user inputs for operation. or example,
`that are generated during the operation of the installation
`in the case of an installation program of the type herein-
`program 22.
`described,
`the program may ask the user to identify the
`the various parts of the
`It should also be noted that
`various paths, disks, and so forth through which and onto
`drawing of FIG. 2 that include the state machine 20, data
`which the installed program 24 is to be located after instal-
`stream 40, installation program 22, installed program 24,the
`lation. In addition, the installation program 22 mayrequire
`display 28, and so forth may be operated in the same
`other types of command inputs from the user. For example,
`computer 26 concurrently. The installation program 22 may,
`the program 22 mayperiodically inquire the user to specify
`for example, be contained on a floppy disk or other appro-
`whether the user desires to continue an installation after a
`priate media for reading and operation in known manner by
`particular event has occurred or to abort the installation. In
`the computer 16.
`somecases,the installed program may have an configurable
`Moreparticularly, as shown in FIG. 3, a software appli-
`form which maybe specified by the user to be installed.
`cation is illustrated which has been generalized is repre-
`In order to receive the various inputs from the user, in a
`sented by a numberof states forming a state machine 50. In
`preferred embodiment, various windows maybe displayed.
`representing the software application as a state machine, the
`Windows based programs are well knownin the art and are
`various slates of the state machine may be defined to each
`not described in detail herein, other than to note that a
`represent discrete segments of the software application code.
`20
`particular window may provide “push buttons,” or other
`For example, a first state, state one, may beastart state. The
`window transitioning means, that can be selectively acti-
`next state, state 2, may be the main code portion of the
`vated by a user operated pointing device or which may
`program,and the last state may be an endstate, state 3. Of
`contain user input information boxes to enable the user to
`course, depending upon the code of the particular program
`specify information to the installation program 22, as noted
`being represented, other states may be defined as
`above. In addition, the displayed windowsprovide informa-
`appropriate, taking into consideration the particular types of
`tion to the user indicating information about the operation of
`tests desired to be run, the discreteness of individual code
`the installation program 22, such as the system requirements
`segments, and other similar considerations.
`for the installed program 24, a percentage of the installed
`In addition, other discrete portions of the application may
`program 24 that has been installed at any particular instan-
`be defined as states. For example, as shown, subroutine
`taneous moment, and so on. Thus,the installation program
`portions may be individually identified as states, as shown
`22 provides a display 28 in a sequence of windowson the
`by states 4 and 5. In addition, interrupt states, such as the
`computer system monitor 30.
`interrupt shown, may be represented as states of the state
`In order to test
`the installation program 22, a state
`machine, such as stale 6 shown. Otherdiscrete code portions
`machine 20 is defined having a numberorset of states 34
`similarly may be represented bystates.
`therein. The states 34 proceed from a start state 36 to an end
`In defining the various states of the state machine, the
`state 38 with each state in the set 34 representing a portion
`considerations may include the particular function per-
`of the installation program 22. In a preferred embodiment,in
`formed bythe individual code portion and whethera definite
`which the installation program 22 is a windows based
`entrance and exit are sufficiently defined within the code to
`program, each state in the set of states 34 may represent one
`enable a state to be properly defined. Thus, for example, in
`of the windowsthat is displayed to the user throughout the
`a typical programming language program, a subroutine is a
`consecutive sequencing of steps during the operation of the
`good candidate for defining a machine state, since a sub-
`installation program 22. State machine 20, in the embodi-
`routine has strict entry and exit protocols or rules and
`ment shown,is configured to monitor a particular test case
`generally performs a testable function in its operation.
`for the installation program 22. As an example of an
`Similarly, an interrupt may also be a good candidate for
`appropriate test case, the state machine 20 maystartat a start
`defining a machine state since it likewise has well defined
`state 36 in which the installation program 22 starts and
`entry and exit protocols and typically performs a function
`proceeds through a normal
`installation of the installed
`that can be tested as well.
`program 24 through completion at an end state 38. Another
`test case thal may be defined could be an abbreviated
`installation of the installed program 24. Othertest cases, of
`course, will be apparent to those skilled in the art.
`The operation of the installation program 22is essentially
`controlled by the state machine 20 which operates as a
`superintending control thereof. Since, in the preferred win-
`dows environment, the individualstates of the state machine
`20 each represent respective successive windows that are
`displayed as a result of the 35 operation of the installation
`program 22, with the windowsrequiring varioususer inputs,
`as described above, data 40 is provided to the state machine
`20 for delivery to the particular windows input sections of
`the respective windowsthat arc displayed during the opera-
`tion of the installation program 22. Examples of such data
`that may be provided, for example, may be the specification
`of the disk and path to which the install program 24is to be
`installed. The movement from one window to the next via
`the windows “push buttons,” other transitioning means, and
`so on. It can therefore be scen that in the definition of the
`
`Another class of programs that lend themselves well to
`being represented by a state machine are those programsthat
`are constructed in a windows based environment. Typically,
`such programs can be represented as a state machine by
`defining each window asa state of the state machine being
`defined. Moreover, typically, windows mayhave “buttons”
`that may be “pushed” to move from one window to another,
`thereby defining strict “edges” by which movement among
`the states of the state machine can be affected. It will be
`understood that the “pushing” of a button in the context of
`the present invention as performed by a superintending test
`program, below defined, rather than by a user using a mouse
`or other pointing device.
`With reference now to FIG. 4, a diagram sho