WO2007118271A1

WO2007118271A1 - A method and system and product for conditioning software

Info

Publication number: WO2007118271A1
Application number: PCT/AU2007/000481
Authority: WO
Inventors: Emil Isaac; Raffi Sekzenian
Original assignee: Todaycom Pty Ltd
Priority date: 2006-04-13
Filing date: 2007-04-10
Publication date: 2007-10-25

Abstract

A method of testing and modifying software by forming blocks of code and adding a unique identifier to each block, and associating first data with at least one of the blocks. A corresponding image is associated with at least one of the blocks. The conditioned software can be used in association with an Automated Functional Testing Tool or Automated Performance Testing Tool to test software applications. Modifications to the automated test scripts are required only when a new behavior of an object on the GUI is introduced.

Description

A METHOD AND SYSTEM AND PRODUCT FOR CONDITIONING SOFTWARE

Field of the Invention

[001] This invention relates to means for conditioning software and to means for using the conditioned software.

[002] The invention can be used in methods and arrangements for testing computer programs having a graphical user interface (GUI). An embodiment of the invention can be used with Automated Functional Testing Tools (AFTTs) in the field of automated software testing.

Background of the invention

[003] Computer programs can control large and complex systems which are governed by complex business rules. Furthermore, most modern computer programs interact with the user via a GUI or web interfaces. The GUI includes elements referred to as "objects" such as windows, menus, scroll bars, icons, dialog boxes, list boxes, check boxes, radio buttons, etc. Web interfaces include web browsing as well as web services. Consequently computer programs are lengthy and complex and hence prone to programming defects or bugs. Debugging of a program having a GUI is even more complex than one without because, in addition to the instructions for the program to carry out computing tasks, the program also includes instructions for managing the GUI and its objects.

[004] The value that testing brings to the software development lifecycle is to isolate anomalies in the observed behavior of newly created or modified computer program to those specified by the functional requirement specifications, before the program is productionised where an economic loss would be experienced. These anomalies (also termed defects or bugs) arise when the specified requirements are not clearly communicated resulting in an incorrect implementation; or clearly specified requirements are incorrectly implemented; or the fixing of one anomaly in a new release of the program inadvertently introduces new anomalies in the computer program; or the introduction of a new functionality or business rule introduces defects in previously working functionality or business rule; or a combination of these scenarios.

[005] Typically formal software testing effort is driven by the user requirements as documented in functional requirement specifications. The requirements are implemented in software that is then put through testing. The requirements implemented in software are collectively termed the application under test (AUT).

[006] Typically manual software testing is undertaken by composing step-by-step instructions including the test data and corresponding expected test results. This set of test steps is called a test case, which seeks to verify a specific user requirement(s) in the AUT. The test case would exercise a specific function or series of functions. An entire suite or a subset thereof of test cases would be created to test all the business requirements against a version of the AUT. During test execution, whenever an observed result matches the expected results of a test case step, that test step would be deemed a pass; and deemed a fail whenever there is a mismatch. Investigation of failed test step is made to isolate the failure which could be a programming defect which is then fixed and a subsequent version of the AUT is released for retest. This process of test-isolate defect-Fix-retest is repeated until all the test cases are executed and all the test steps pass, thus verifying that the AUT meets the stated specifications. Testing may involve many repeated cycles until all agreed defects are fixed. Isolation of programming defects by testing and retesting bug- fixes using an entirely manual testing effort is costly and time consuming.

[007] Commercially available automated functional testing tools (AFTTs) came on the market in the early 1990s to speed up the de-bugging of GUI applications by having the retesting executed automatically by the AFTT. Rational Robot^®, Rational Functional Tester^®, Mercury WinRunner^® and open-source tools such as Marathon^®, PesterCat^®, Selenium^®, Wet^® and TestSmith^® are some of the off-the-shelf AFTTs. The principle of operation of these tools is the same. Using an AFTT, a user manually executes a test case once against a baseline version of the AUT. The AFTT records user keystrokes and automatically generates a computer program, known as a test script, which may be replayed by the AFTT to automatically reproduce the same keystrokes against the AUT in order to execute the same test case steps. During the recording of the test script, multiple processes of AUT are exercised by the user by entering test data in certain GUI object and then capturing verification points of the GUI objects and their properties in the response. The object properties include type of object, the dimension, colour, index number, etc. The generated script and the verification point are stored in the AFTT database.

[008] To verify that a new version of the AUT has not regressed and still works as in the prior baseline version, the same AFTT generated scripts (including the hard coded data entered by the user) can be replayed automatically by the AFTT and hence execute the retest against the AUT without user involvement. During replay, the recorded GUI objects properties and verification points are automatically recaptured by the AFTT and compared to the baseline captured properties and verification points. Differences are identified and logged as defects for the user to view when the script stops and identify if the logged defect is a programming defect. Thus AFTT can speed up the testing effort by automatically replaying a single recording of a test case as many times as required at a fraction of the time taken by a manual execution and with greater accuracy.

[009] AFTTs then evolved from simple record and playback to be able to run scripts from within scripts and sequence multiple test scripts that can also replay different test data (dynamically retrieved from a spreadsheet) rather than the hard coded in the scripts. The differing test data causes a different script to be executed thus exercising a correspondingly different business process during the same test. This is known as data-driven testing.

[010] A major limitation of all AFTTs is that their scripts can only be manually updated when the AUT changes its GUI content or business flow (in keeping with changing business requirements). The first step of manually updating scripts requires the user to identify all the scripts that require the updating. The second step is the manual update of the script, which may involve partial re-recording and can take longer than wholly re-recording the script against the changed AUT. Hence, due to this maintenance overhead, it becomes unviable to invest in automated testing and AFTTs in those environments because automated testing takes longer than manual testing. As a result AFTT utilization has been confined to regression testing where the AUT has little or no changes between tested releases.

[Oi l] Attempts to address AFTT limitations in the prior art gave rise to several embodiment of data frameworks being devised that separate the GUI objects being acted on in the script, along with the navigational test data, from the AFTT scripts and centralize and manage that information in a separate spreadsheets or database. The frameworks comprise of several internal spreadsheet layers of control and function call between the layers that then dynamically pass the navigational and test data to the AFTT to execute during replay in the context of the script. When the AUT GUI object properties change, the changes are updated in one spreadsheet belonging to the framework which effectively passes the change to all impacted scripts during test execution, thus repairing the automated test scripts.

[012] An inherent drawback of the said data framework is the steep learning curve in understanding the framework structure, the need for technical programming skills to maintain the framework structure which forces non-intuitive steps in the testing workflow. Consequently data frameworks have had limited adoption in the automated functional testing user community.

[013] When an object is not recognized by an AFTT, the object properties are not able to be captured in the test script due to various reasons, the most being the AUT programmers failed to assign the object its unique properties. The AFTT defaults to a "generic" recognition of the object in the generated test script. The generic recognition of an object means the AFTT relies entirely on the coordinates of the object in order to locate and execute an action against it. This method of automation is the least robust because if the generically recognized object were to move from its original position in the AUT, the replay of the AFTT would not recognize the movement and will attempt to perform an action in the same coordinate location, even though the object is no longer located there. The AFTT would fail to perform the intended actions and the script would be rendered effectively useless. During replay the AFTT will fail to recognize the object if there are more than one "generic" object on the screen as identifying properties are missing to enable the AFTT to make a distinction. [014] Test cases are documented in either a spreadsheet or document table or in dedicated tool which are then stored and managed separately from the generated automated test scripts. Whenever the AUT changes, the test cases need to be updated manually in order to incorporate the AUT changes, before proceeding to re-record the impacted test cases. The overhead of maintaining the test cases separately from the automated test scripts is time inefficient and hence costly. As a result the maintenance of the test case is often ignored, thus losing standard traceability to what are the latest test steps, except what is captured in the automated test scripts, which is hard to decipher quickly.

[015] Any reference herein to known prior art does not, unless the contrary indication appears, constitutes an admission that such prior art is commonly known by those skilled in the art to which the invention relates, at the priority date of this application.

SUMMARY OF THE INVENTION

[016] It is therefore an obj ective of the invention to provide a means of conditioning software to improve its facility for use in maintaining software. The invention also provides a system and method for maintaining software.

[017] Software conditioned by the invention can be used to address one or more of the previously mentioned limitations to provide a software maintenance system tool whose one of its embodiment is that it integrates into available AFTTs for use in updating and maintaining AFTT scripts in keeping with GUI object changes, web services, web browsing and even business flow changes in the AUT.

[018] It is desirable to provide a Software Maintenance Tool that does not rely on spreadsheet or text based apparatus.

[019] It is desirable to provide a Software Maintenance Tool where the maintenance is primarily GUI image based apparatus, with text based support available for advanced users. [020] It is desirable to provide a Software Maintenance Tool that is automated except for simple GUI-based confirmation involvement from the user.

[021] It is desirable to provide a Software Maintenance Tool where the learning curve involves simple visual interrogation of images and mouse clicks to operate.

[022] It is desirable to provide a Software Maintenance Tool that is AFTT vendor independent and hence AFTT script syntax independent.

[023] It is desirable to provide a Software Maintenance Tool which manages all AFTT automated test scripts in a given test repository, and which becomes more valuable as the number of scripts increases in that repository.

[024] It is desirable to provide a Software Maintenance Tool that reduces the investment in manpower to implement, maintain and enhance automated testing software.

[025] It is desirable to provide a Software Maintenance Tool where modifications to the automated test scripts are required only when a new behavior of an object on the GUI is introduced.

[026] It is desirable to provide a Software Maintenance Tool where the Software Maintenance Tool also enhances the testing productivity and script quality by recycling code between archived and current scripts within the same repository or across many repositories.

[027] It is desirable to provide a Software Maintenance Tool where non-technical (non- programming skill) users can carry out the script maintenance.

[028] It is desirable to provide a Software Maintenance Tool where the workflow steps are intuitive and the system is largely self-maintaining once the initial administrative activities are carried out. [029] It is desirable to provide a Software Maintenance Tool where any AFTT script, even those requiring major changes to the GUI/Web Interface as well as changes to the business flow, can be carried out with positive certainty and faster than re-recording the scripts.

[030] It is desirable to provide a Software Maintenance Tool where the graphical images of each block also doubles to overcome AFTTs limitation of software object recognition.

[031] It is desirable to provide a Software Maintenance Tool where the test case maintenance is incorporated into the automated test script maintenance activity.

[032] A method of modifying software including initial code, the method including the steps of: grouping the software into blocks; and referencing each block with a unique reference.

[033] The method can include the step of associating first data with at least one of the block.

[034] The method can include associating a corresponding first image with at least one of the blocks.

[035] The method can include associating two or more images with one or more corresponding blocks.

[036] The step of referencing can include association of a keyword with each block.

[037] The keyword can identify an object.

[038] The keyword can be contained in a comment.

[039] The step of referencing can include a command associated with the first image. [040] The initial code of each of one or more blocks can define a corresponding context image.

[041] The initial code can be generated by an automated functional testing tool (AFTT) in response to user inputs.

[042] The user inputs can be input as instructions in an application under test (AUT).

[043] The context can be a context in the AUT.

[044] The method can include the step of: associating instances of the same object in the same context.

[045] The method can include the step of storing the referenced blocks and their associated data.

[046] The invention also provides a method of testing and/or modifying software, including the steps of: modifying initial code as described above; running a modified code on the application under test; capturing second data resulting from the running of the modified code; identifying differences between the first and second data.

[047] Preferably, the data is image data.

[048] The method can include comparing first image and/or instruction information with second image and/or instruction information.

[049] The invention can compare data, whether or not it is image data, and instructions, and the use of the term "data" is not intended to exclude "instruction" unless, the distinction is expressly made or is required by necessary implication. [050] The method can include the steps of: comparing the changed images with their associated images; and selectively editing the code associated with the or each data change.

[051] The method can include the steps of: generating a unique software identifier; generating associated data attributes of the unique software; generating an image and forming an association with the unique software; generating a logical link to other instances of similarly behaving unique software; identifying modifications to the unique software; identifying other instances of the unique software that require the same modification; and applying the modification to the located instances of the unique software.

[052] The Identifying singular or plurality of unique software to be used for developing software (find code which may be imported into the script currently under development so as to speed up the time and effort required in developing new scripts - IMPORT function); and applying identified unique software to software in development (copying code from the found script to the script currently under development); identification of a plurality of instances of a specific sequence of unique software; identifying many sequences of common blocks which are candidates for moving into library functions; and extracting associated data and associated image of unique software (extracting comments and images of script to MS Word document or other text/image viewing/editing 3rd party software).

[053] The unique software can be a computer program instruction logically grouped with a plurality of other computer program instruction in a procedure known as a script.

[054] The script can be an automated test script generated by an Automated Functional Testing Tool (AFTT). [055] The said computer program instruction can execute an action or verification on the Application Under Test (AUT).

[056] The method of generating a unique software identifier can include the step of tagging the software with a unique identifier.

[057] The unique identifier can be inserted in the script containing the computer program instruction in close proximity to the associated computer program instruction.

[058] The associated data attributes of the unique software can include: The name of the AUT component upon which the software interacts with; and Software which defines the context in which the AUT component resides.

[059] The name of the AUT component can be inserted in the script in close proximity to the software code to which it is associated.

[060] The name of the AUT component can be the label of the component as identified in the AUT.

[061] The said method of identifying the AUT component label can be based on what is visually observed in the AUT.

[062] The said name of the AUT component can be defined by the user.

[063] The unique software identifier and associated data attributes, as well as the software itself, can be grouped together in a uniform order in the script, forming a unit known as a block.

[064] The image can be a picture taken of the AUT containing the image of the AUT component upon which the software acts. [065] The said picture can be captured immediately before or immediately after the software is executed against the AUT component.

[066] The picture capture can be invoked by software in the script situated immediately before or after the software that executes the action upon the AUT component.

[067] The said association of the said picture to the software., can be by way of the unique identifier, thereby logically associating the said picture to the uniquely identified block.

[068] The said image can be in the form of a motion picture showing the motion of the execution of the software acting upon the AUT component.

[069] The motion picture can be invoked to start and stop recording by software in the script situated immediately before and after the software that executes the action upon the AUT component.

[070] The said association of the said motion picture to the software can be by way of the unique identifier, thereby logically associating the said motion picture to the uniquely identified block.

[071] The method can include the step of highlighting the AUT component upon which the software acts, contained within the boundaries of the said picture.

[072] The said logical link to other instances of similarly behaving unique software can be established by the steps of: searching for identical or similar software; and interrogating the search results; and creating the logical link.

[073] The said searching can be conducted by forming search criteria composed of the software syntax and associated data attributes of the unique software. [074] The said interrogating can be by means of comparing a combination of the highlighted image and the data attributes of the unique software to the matched unique software, with the aim of locating another unique software that acts on the same AUT component.

[075] The logical linking in the event of a matched comparison can include the steps of: Highlighting the AUT component upon which the software acts, contained within the boundaries of the said picture;

Associating the unique software to the logical entity of the matched unique software, thereby forming a logical link to all other instances of unique software linked to the same logical entity.

[076] The said logical linking in the event that there is no match can include the steps of: Highlighting the AUT component upon which the software acts, contained within the boundaries of the said picture; Creating a new logical entity and linking it to the unique software.

[077] The said identifying modifications can be achieved by comparing the previous version of the unique software to the current version of the same unique software.

[078] The said previous version of the unique software can be previously stored in and retrieved from an archive.

[079] The previous and current versions of an AFTT script can be presented concurrently.

[080] The software in the scripts can be displayed in Text Mode comprising of either unblocked AFTT code or block formatted code.

[081] The script can be displayed in Image Mode wherein a script is represented by a plurality of miniature images where each image is associated with the corresponding unique software contained in the script, thus forming film strip representation of the script. [082] The miniature image associated with the unique software in focus is distinguished from surrounding miniature images, and is positioned midway down the film strip.

[083] The said Image Mode displays an enlarged image associated with the unique software currently in focus in the script.

[084] The said modification can include identifying the change in content of a block by comparing the previous (archived) version of the block to the current version of the same block.

[085] The said modification can include the steps of:

Identifying a change in position of a unique software by comparing its relative position to other unique software positions in the previous (archived) version to the current version of the script; and

Identifying added unique software that do not exist in the previous (archived) version of the script, but exists in the current version of the script; and

Identifying deleted unique software that exist in the previous (archived) version of the script, but do not exist in the current version of the script.

[086] Highlighting of content can change within a block; changes in position of a unique software; addition of unique software; and deletion of unique software are respectively represented by different colours that are consistent in both Test and Image Modes.

[087] The said identifying other instances of the unique software that require the same modification, can include the steps of: specifying a search criteria; and searching for matches of the search criteria; and returning results; and displaying and highlighting the matched unique software.

[088] The said specifying a search criteria can include a combination of one or more of the following elements: logical entity of the unique software; and data attributes of the unique software or part thereof; and unblocked AFTT code or part thereof; and unique software code or part thereof.

[089]- The said displaying and highlighting can be in either Text or Image Mode, where the unique software or its associated image respectively which meet the search criteria are highlighted in the script.

[090] The said applying the modification can include the steps of: copying and pasting unique software or other software from the current version of the current script to the current version of the matched script as viewed in either Text or Image Mode; and deleting and modifying code in the current version of the matched script, as viewed in either Text or Image Mode.

[091] Copying and pasting unique software can include: the associated data attributes of the unique software; and the associated image of the unique software.

[092] Applying identified unique software to software in development, can include the steps of: copying and pasting unique software or other software from the matched script to the current script under development as viewed in either Text or Image Mode; and deleting and modifying code in the current version of the matched script, as viewed in either

Text or Image Mode.

[093] Copying and pasting unique software, can include: the associated data attributes of the unique software; and the associated image of the unique software.

[094] The Identification of a plurality of instances of a specific sequence of unique software, can include the steps of: specifying the criteria of the minimum number of unique software that are required in a sequence to constitute a match; and specifying the criteria of the minimum number of occurrences of that sequence that are required to be to constitute a match; and searching for matches of the search criteria; and returning results; and displaying a summary of all the matched sequences, and the number of occurrences of each matched sequence; and for every matched sequence, displaying and highlighting the unique software that constitutes the sequence, at eveiy location of that sequence.

[095] Displaying and highlighting can be in either Text or Image Mode, where the unique software or its associated image respectively which meet the search criteria are highlighted in the script.

[096] The unique software extracted with its associated data and associated image are a plurality of unique software occurring in a script, whereby the extraction is in the corresponding order in which the unique software occur in the script.

[097] The invention thus provides the ability to locate sequence of code that is repeatedly used within the scripts, and to move that code out of the scripts and place it in a library function which is called on by the scripts. This reduces code volume and improves execution efficiency etc The invention finds the sequence of code based on a simple user criteria.

[098] The invention also provides a system for conditioning software including: a software edit tool adapted to group the software into blocks, and to add a reference to each block.

[099] The edit tool can be adapted to associate data with at least one of the blocks.

[0100] The system can include: first processing means adapted to run the edit tool, second processing means adapted to run an AFTT in conjunction with an AUT to generate the software.

[0101] The first and second processing means can be incorporated in a single computer.

[0102] The system can include first storage means adapted to store the software.

[0103] The system can include second storage means adapted to store the conditioned software from the edit tool.

[0104] The system can include a display means adapted to display corresponding blocks derived from different versions of the software.

[0105] The display can display the corresponding blocks on a single screen display.

[0106] The display can display images associated with corresponding blocks.

[0107] The invention also provides a software maintenance or editing tool adapted for use in grouping software into blocks and referencing the software blocks.

BRIEF DESCRIPTION OF THE DRAWINGS

[0108] FIGURE 1 is a block diagram showing an exemplary hardware environment for practicing the present invention;

[0109] FIGURE 2 is a diagram showing illustrative embodiment of the floating menu bar;

[0110] FIGURE 3 is a flow chart presenting an overview of the process steps used to practice one embodiment of the present invention; [0111] FIGURE 4 is a diagram showing an exemplary format that is enforced by the Software Maintenance Tool on each action block in AFTT test scripts;

[0112] FIGURE 5 is a block diagram showing an exemplary formatting process of the Software Maintenance Tool and the user involvement in the process;

[0113] FIGURE 6 is a block diagram showing an exemplary formatting process of the Software Maintenance Tool on each action block of an AFTT script;

[0114] FIGURE 7 is a diagram showing a sample native Rational Robot^® AFTT script and pointing out the plurality of script action commands on the AUT objects.

[0115] FIGURE 8 shows a diagram of the sample native Rational Robot^® AFTT script after it has been formatted by the Software Maintenance Tool.

[0116] FIGURE 9 shows an illustrative AUT image being captured by the Software Editing Tool.

[0117] FIGURE 10 is an exemplary embodiment of the basic unit of the Software Editing Tool GUI screen shown in image mode.

[0118] FIGURE 11 is an exemplary embodiment of the basic unit of the Software Editing Tool GUI screen shown in text mode.

[0119] FIGURE 12 is an exemplary embodiment of the ARCHIVE function user interface.

[0120] FIGURE 13 is an exemplary embodiment of the FORMAT function user interface. [0121] FIGURE 14 is an exemplary embodiment of the ERROR function user interface.

[0122] FIGURE 15 is an exemplary embodiment of the DEFINE function user interface.

[0123] FIGURE 16 is an exemplary embodiment of the BUILD function user interface, shown in import mode.

[0124] FIGURE 17 is an exemplary embodiment of the BUILD function user interface, shown in export mode moving blocks within a script.

[0125] FIGURE 18 is an exemplary embodiment of the BUILD function user interface, shown in export mode moving blocks between different scripts.

[0126] FIGURE 19 is an exemplary embodiment of the BUILD function user interface, shown in export mode identifying a sequence of blocks between different scripts.

[0127] Figure 20 is a conceptual illustration of a system according to an embodiment of the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENT

[0128] In the following description, reference is made to the accompanying drawings which form a part hereof, and which is shown, by way of illustration, several embodiments of the present invention. It is understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention.

[0129] Li accordance with the foregoing objectives which will be discussed in detail below, the methods and system according to an embodiment of the invention include an automated test script generated by an automated functional testing tool (AFTT) which generates an automated test script (or which includes a utility that generates an automated test script). As used herein when it is stated that AFTT generates an automated test script it is understood that the automated functional testing tool may provide a separate utility which generates the automated test script.

[0130] According to an embodiment of the invention, the scripts are formatted into a series of consistently structured units using formatting rules specific to each AFTT. The units are called blocks. An action block acts upon a GUI object in the AUT in some way. A verification block verifies whether the object properties captured during script run time match the baseline properties of the same object.

[0131] The formatted script is replayed by the AFTT to capture images of each of the blocks as well as its GUI context. The script blocks are then number-tagged and logically linked with their corresponding images and to compose an image-by-image film strip equivalence of the AFTT script in consultation with the user.

[0132] In an embodiment of the invention, facilitation of script maintenance uses the formatted scripts and their film strip equivalent. During maintenance the Software Maintenance Tool automatically identifies, compares, searches, retrieves, manipulates and displays matching images and their associated text blocks from its database to aid the user in confirming what needs to change and where to apply the change within the same or other scripts. The graphical mode allows the user to scroll up or down the script, in a similar manner to that of image frames in a video film strip, to empower the user to decide with absolute and positive certainty.

[0133] The Software Maintenance Tool's business logic that govern its graphical user interface and the database is composed of plurality of software functions that perform discrete operations written in a computer language that is independent of the computer language the AFTT is written in.

[0134] According to an embodiment of the Software Maintenance Tool, the AFTT is Rational Robot . The Software Maintenance Tool's relational database is preferably MySQL database. [0135] In one embodiment, the Software Maintenance Tool is a two-tier architecture system, comprising of a graphical user interface (GUI) front-end and a relational database back-end. The Software Maintenance Tool's business logic rules drive the interaction between the two tiers and also between the user and GUI tier. The Software Maintenance Tool's business rules are based on a series of intuitive workflow steps that the user is trained to follow (the learning curve). The Software Maintenance Tool's functional specification will now be described.

[0136] FIGURE 1 illustrates an exemplary computer system 100 that could be used to implement the present invention. The computer 102 comprises a processor 104 and a memory, such as random access memory 106. The computer 102 is operatively coupled to a display 120, which presents images such as windows containing objects to the user on a graphical user interface 121. The computer 102 may be coupled to other devices, such as a mouse device 122, a keyboard 124, etc. Of course, those skilled in the art will recognize that any combination of the above components, or any number of different components, peripherals, and other devices, may be used with the computer 102.

[0137] Generally, the computer 102 operates under control of an operating system (OS) 110 stored in the memory 106, and interfaces with the user to accept inputs and commands and to present results through a GUI module 121. Although the GUI module 121 is depicted as a separate module, the instructions performing the GUI functions can be resident or distributed in the operating system 110, the application program 114, or implemented with special purpose memory and processors. The computer 102 also implements a compiler 112 which allows an application program 114 written in a programming language such as Java, Visual Basic or other language to be translated into processor 104 readable codes. After completion, the application 114 accesses and manipulates data stored in the memory 106 of the computer 102 using the relationships and logic that was generated using the compiler 112.

[0138] Further, the operating system 110 and the application programs 114 are comprised of instructions which, when read and executed by the computer 102, cause the computer 102 to perform the steps necessary to implement and/or use the present invention. Application programs 114 and/or operating instructions may also be tangibly embodied in memory 106.

[0139] In one embodiment, the AFTT application program 116 and the Software Maintenance Tool application program 118 reside in the computer 102 application programs 114. In this embodiment the AFTT application program 116 instructs the computer 102 with the AFTT program steps. The Software Maintenance Tool application program 118 instructs the computer 102 with the Software Maintenance Tool program steps. The Software Maintenance Tool application program 118 is made up of subprograms that are invoked by the user through the GUI 121 to carry out specific functions described below. In this embodiment, both the AFTT application program 116 is separate and independent of the Software Maintenance Tool application program 118.

[0140] hi the one embodiment, the computer system 100 is in communication with the server hosting the AUT 126. The server 126 could be located locally or remotely from the computer system 100.

[0141] In one embodiment, the computer system 100 is in communication with the AFTT data base tier 128 and the Software Maintenance Tool data base tier 132 whereby both databases could be hosted locally on or remotely from the computer system 100 and from each other. The AFTT data base 128 stores the AFTT generated automated test scripts 130. The Software Maintenance Tool database 132 stores the Software Maintenance Tool formatted test scripts 134 and the corresponding graphical images that make up the film strip 136.

[0142] hi the one embodiment, the Software Maintenance Tool database 132 reads from and writes to AFTT database via 138.

[0143] FIGURE 2 is a diagram of an example of the floating menu bar used to practice one embodiment of the present invention. The floating menu bar 200 is displayed on the GUI screen 121 when the Software Maintenance Tool application program 118 is started up in the exemplary hosting computer system 100. The floating menu bar 200 is the central point of user interaction with the Software Maintenance Tool and floats above open applications in the GUI 121. The exemplary list box 202 enables the user to point the Software Maintenance Tool at the chosen AFTT script repository stored in the AFTT data base 128. The exemplary list box 204 displays all the AFTT automated test scripts 134. Colour coding is used to indicate the maintenance state of each of the listed AFTT scripts 134. The exemplary DEFINE push button 206 invokes the DEFINE function in the Software Maintenance Tool application 118 and displays the corresponding DEFINE screen 1500 on the GUI 121. The exemplary BUILD push button 208 invokes the BUILD function in the Software Maintenance Tool application 118 and displays the BUILD screen 1600 on the GUI 121. The exemplary ARCHIVE push button 210 invokes the ARCHIVE function in the Software Maintenance Tool application 118 and displays the ARCHIVE screen 1200 on the GUI 121. Business rules residing in the application program 118 determine when these buttons are enabled and their corresponding screen can hence be displayed. An embodiment of the business rules is described below.

[0144] FIGURE 3 is a flow chart presenting an overview of the process steps used to practice one embodiment of the present invention. The method comprising the steps of STEP 1 to STEP 7 that are described below with relevant screen embodiment being described when appropriate in the process.

[0145] STEP 1 : Start the Software Maintenance Tool and point at script repository 302. The process begins by the user starting up the Software Maintenance Tool application as in one embodiment 118 resulting in one embodiment of the floating menu bar 200 being displayed in the GUI 121. From field 202, the user points the Software Maintenance Tool at the chosen AFTT Data Base 128. Current Script field 204 and DEFINE button 206, BUILD button 208 and ARCHIVE button 210 are inactive and grayed out till after successful completion of STEP ^■ 2.

[0146] Typically the user would also start the AFTT application program 116 at this time in the process so its user interface is available in GUI 121 to be used in subsequent process steps. AFTT application program is not required by the user until a formatting error is found in STEP

2. [0147] STEP 2: Resolve non-compliant AFTT script errors 304. In one embodiment of the invention, the Software Maintenance Tool scans the entire AFTT script repository 130 and makes available to the user in field 204 the script names that are non-compliant to the Software Maintenance Tool's block format standard 400 and formatting rules 500. The AFTT script names are colour coded 600 to enable the user to graphically determine which AFTT script has formatting errors.

[0148] FIGURE 4 is an embodiment of the Software Maintenance Tool action block format for Rational Robot^® AFTT. The Software Maintenance Tool checks the format of each action block in all AFTT scripts is in keeping with 400. The action block format structure has first line 402 containing the unique reference tag created by the Software Maintenance Tool. The second line 404 contains the user comment which is typically entered by the user before executing the action during recording session of the script via the AFTT, or otherwise post the recording. This line also contains a keyword that summarises the action undertaken by the block. The third line 406 is the AFTT generated screen context line that navigates and orientates the AFTT through the AUT from one screen to the next during playback of the script. The fourth line 408 is the AFTT generated command line that contains the program action instruction that is being enacted on the AUT object within the AUT screen. The fifth line 410 is a blank line to separate the action block from successive instruction lines, verification or action blocks to help with user readability.

[0149] FIGURE 5 is a block diagram of an exemplary script clean up routine that the Software Maintenance Tool undertakes on every AFTT script 130 that it detects has changed save time stamp. The clean up routine parses through the script and removes excess set context lines 502, then removes excess blank line 504 and arranges the script into discrete action and verification block 506 in keeping with the exemplary action block format of 400.

[0150] FIGURE 6 is a block diagram of an exemplary block formatting function that the Software Maintenance Tool undertakes on every script that it detects has changed save time stamp. The formatting function checks the block's unique reference tag line 602 if it has been deleted or edited. If deleted, then deleted the tag from the AFTT script and the Software Maintenance Tool 604, else if edited then delete the tag from the database 606 so a new unique tag can be created for the block. The formatting script then checks if an entire block is deleted or edited 608 and accordingly updates the database in 610 or 612. Lastly the function checks for missing START APPLICATION line 614 and inserts it in 616 else the routine moves on to the next consecutive block in the script

[0151] The user selects a non-compliant script from the floating menu bar from at the current script field 204 which invokes the error handling function and the ERROR screen 1300 is displayed in GUI 121. The selected script name in displayed current script field 204 is shown in a colour in keeping with a colour code. The ERROR screen 1300 contains the AFTT non- complaint script code with the first non-compliant block centered in the screen and highlighted as per a colour code. The user then resolves the selected script errors within the AFTT application and saves the script. Once the Software Maintenance Tool detects a change in save date in the AFTT data base 128 for the current script, it then rescans and redisplays any outstanding formatting errors. Once all errors are resolved, the Software Maintenance Tool automatically exits into Step 3, at which time the script name in current script field 204 changes colour in keeping with a colour code, DEFINE button 206 and BUILD button 208 become enabled for the current script.

[0152] FIGURE 13 is an embodiment of the ERROR screen. The screen is a downward extension embodiment to the floating menu bar 200. Source Script field 1302 lists all AFTT scripts in the current repository containing errors, with the selected script shown in the field. Errors Tab 1304 is used for invoking the DEFINE screen is changed to display "ERRORS". This only occurs when there are AFTT scripts in the current repository that violate a rule that stops Formatting from occurring. Text pane 1308 show the errors in the AFTT Source Script highlighted. Error Description pane 1310 provides a description of the error in the Source Script. Error Instance column 1312 shows the number of instances of the error type that occurs in the Source Script.

[0153] STEP 3: Format and store script 306. A copy of the saved current selected script, free of errors, is automatically retrieved from the AFTT data base 128 via communication connection 138 and stored in Software Maintenance Tool data base embodiment 132. The Software Maintenance Tool automatically parses through the current script and allocates a unique tag reference number to all untagged action block(s) and then inserts the AFTT specific image-capturing function call at the start of that/those block(s) in keeping with block format 400. The formatted script is then saved in the Software Maintenance Tool's database 132 and is available for user access from the Software Maintenance Tool script repository 134.

[0154] FIGURE 14 is an embodiment of the FORMAT state in 1400 is the floating menu bar 200 with the DEFINE button 206, used for invoking the DEFINE screen, is changed to display FORMAT button 1402. This only occurs when the script that requires formatting (converting non-blocked AFTT code to block format) is locked by the AFTT. Once script is unlocked by the user, the format automatically takes place and the FORMAT button 1402 changes to DEFINE button 206 again.

[0155] FIGURE 7 is a sample native Rational Robot^® AFTT generated script 700 as captured against a sample AUT. Although a script is a physical file that contains software, it is possible for software to be contained in other forms, such as within a database. Each of the lines 702, 704, 706 of software is executed by the AFTT resulting in a predictable interaction with the target object contained in the interface of the AUT.

[0156] FIGURE 8 shows the same sample script 700 after it has been formatted by the Software Maintenance Tool. In one embodiment of the formatting step, the three action commands in lines 702, 704 and 706 are formatted into blocks 802-808, 810-16 and 818-824 respectively. Each of the blocks are preceded by a function call 802, 810 and 818 respectively that captures a picture of the AUT momentarily before the action commands are executed in 808, 816 and 824 respectively. This same line also contains the unique reference tags 826, 828, 830 for each block respectively. The second line of each block is a comment line 804, 812 and 820 respectively containing the name of the AUT component being interacts with, which also serve as the keywords shown in square brackets. The third line 806, 814, 822 of each block respectively is code in the native language of the AFTT that defines the context in which the AUT component 808, 816 and 824 respectively is interacted with. [0157] In the embodiment, lines 802, 810 and 818 execute a function call which in turn captures an image of the AUT component within the AUT screen context, assigns a unique reference number to the image 826, 828 and 830 respectively which links the image specifically to that instance of code. In this embodiment, the unique reference is a unique integer that is passed to the function as a parameter. As a consequence, if that software structure changes its relative location to other structured code, the link between the code and its image still holds because the code is part of the comment, which is a part of the software structure and remains so as long as the structure exist.

[0158] Each comment line 804, 812 and 820 contain the name of the AUT component upon which the software line 808, 816 and 824 respectively interacts. A comment is a passive software in the AFTT that does not perform any action against the AUT, that serves to summarise the block action to the user, thus is the test case step. The name of the AUT component 826, 828 and 830 is contained within brackets and usually consists of one or more words. These keywords words are usually visually located either on the component, or next to a component on the interface of the AUT. On the occasions where a name for a component does not exist or is ambiguous because it is identical to the name of another component under the same context, the user may define a unique name for that component which becomes standard name adopted by all structured software lines that interact with the same component.

[0159] Lines 806, 812 and 822 are examples of lines of software, usually generated by the AFTT, which defines the context in which the component in the AUT exists. The context is typically defined by the AFTT with the name of the window caption in the AUT which contains the AUT component upon which is meant to execute. Thus the context lines provide orientation for the command lines and navigational guidance for the AFTT during test execution. Without a correctly defined context, the command lines 808, 816 and 824 will execute but will fail in interacting with the component in the way it is designed to do. With this in mind, the preferred embodiment of the Software Maintenance Tool is to enforce the user to include the correct context line before each command line in a software structure to ensure the command line executes as intended. This ensures that each software structure is self-contained and contains all the necessary software lines for it to execute.

[0160] Lines 808, 816 and 824 are software that interact with AUT components contained in the AUT screens. The AUT component is usually a GUI component, such as a radio-button, push button, textbox or list-box. The name of the component usually visually printed on the component itself, such as in the case of a button, or next to the component, as is the case with radio-buttons. Names may sometimes not even be visible on first glance, but may appear momentarily as tool-tips when the user moves the mouse-cursor over the component. The name of the AUT component as it appears to the user is required by the preferred embodiment to exist in between the brackets on the comment line of 804, 812 and 820

[0161] STEP 4: Rerun script to capture images 308. Using the AFTT, the user replays Software Maintenance Tool formatted AFTT script as in STEP 3 and stored in 134. During replay the actual image of each invoked AUT object and its AUT screen context in the AUT 126 is automatically captured by the AFTT for each action block. During script replay, the Software Maintenance Tool automatically buffers the captured images in its data base 132 and on replay completion automatically associates each action block image with its corresponding action block reference tag. The action block images are then stored in the Software Maintenance Tool's database 132 and are available for user access from the Software Maintenance Tool image repository 136.

[0162] FIGURE 9 is an exemplary image of an AUT screen 900 that is captured by the software line 810 and linked to the software structure identified by the reference tag "838" which also exists on line 810. The "Yes" annotation 902 whose dimensions and location on the AUT image identify the component of the AUT upon which the software line 816 interacts with. In the preferred embodiment, the shape of the image is a square or rectangle, and the dimensions and location of the annotation are determined by the user and superimpose over the image by the user after the image is captured.

[0163] The user can repeat STEPS 2 and 3 for any or all other scripts and proceed to DEFINE STEP 4 when all scripts have been formatted and have action block images captured. Alternatively, the user can proceed to DEFINE STEP 4 for the one script that had been formatted and had action block images captured, and leave other scripts unformatted. That Software Maintenance Tool allows either user choice or a combination of those choices.

[0164] STEP 5 : DEFINE action blocks 310. The floating menu bar 200 colour codes in the current script field drop down list 204 which script has undefined action blocks, as per a user defined colour code. From the drop down list 204, the user selects one script name then presses the DEFINE button 206 which causes the DEFINE screen 1500 to be displayed in the GUI 121 wherein the current script program instructions is displayed in the text tab 1510 wherein the first undefined action block of the script is centered and highlighted. The DEFINE screen is used by the user to define all action blocks. Matching objects that have the same object or closest properties are automatically retrieved from 132 and displayed in text tab 1510 or image tab 1506 of the script. Both text and image modes are available to help the user visually interrogate and select a matching instance for the object (ie whether the object has already been defined in another block and this is another instance) or instruct the Software Maintenance Tool to create a new object. New object definition is created by the user mouse-pointing at and highlighting the object represented by the block in the captured image 1514. The Software Maintenance Tool updates the database 132 with the selection and then proceeds to the next undefined block and seeks the user decision as before. Search capability 1518 is also available in the event the user wants to make manual search. When all undefined blocks have been completed in the script, the DEFINE screen 1500 is automatically replaced with the BUILD screen 1600 for the current script.

[0165] FIGURE 10 is an embodiment of the basic Image GUI screen used by the Software Maintenance Tool as shown in 1000. Text Tab 1004 displays AFTT script information of the current script to be described in FIGURE 11. Image Tab (selected) 1002 displays the actual image information associated with the current block. This information is formatted into blocks. Image 1006 is a blowup of the image associated with the current block. Highlighted Block Image 1008 displays the AUT component being acted on in the current block. Filmstrip 1010 displays vertically arranged thumbnails of the images of the blocks immediately prior and following the current block. Object Box 1012 is a thumbnail version of the Image 1006 upon which the AFTT action command of the current block is destined to interact with. Block The thumbnail images 1010 each have a border. The colour of the border indicates the status of the block associated with the bordered thumbnail. Black colour represents the "current block" as in 1012. Orange bordered thumbnail 1014 represent a "moved" block. Red bordered thumbnail image 1016 represents a "deleted block". Green bordered thumbnail image 1018 represents an "added" (new) block. Violet bordered thumbnail image 1020 represents a "matched" block, resulting from a search conducted on a specific combination of logical object/ AFTT programming code.

[0166] FIGURE 11 is an embodiment of the basic Text GUI screen used by the Software Maintenance Tool as shown in 1100. Image Tab displays actual image information associated to the current block as described in FIGURE 10 above. Text Tab 1104 displays the AFTT script information of the current script. This information is formatted by the Software Maintenance Tool into blocks whose borders are status colour highlighted. The border status colour code is as per FIGURE 11 described above. The colour of the block border represents the status of the block. The current text block 1106 is associated with its image thumbnail 1108. The two text blocks 1110 and 1112 preceding the current text block have their associated thumbnail images 114 and 1116 displayed in the film strip. Similarly the two text boxes following the current text block have their associated thumbnail images displayed in the film strip below the current thumbnail image respectively.

[0167] FIGURE 15 is an embodiment of the DEFINE screen 1500. Source Scripts 1502 displays all AFTT scripts in current repository. When selected, Undefined Blocks Filter 1504 display only AFTT scripts with undefined blocks in 1502. When selected, Blocks Without Images Filter 1508 display only AFTT scripts with defined blocks without images in 1502. Source Script Name 1501 lists scripts containing blocks needing to be Defined. Matched Script shows the logical object potentially the same as that the logical object of block in the process of being Defined in the Source Script. Ghost Object Box 1514 is a duplicate Object Box from that Object shown in the current Matched Script Block. The ghost box could potentially be highlighting the same logical object as that in the process of being defined in the Source Script. If the correct logical object has been found, but the Ghost Object Box is not positioned exactly on the object in the image, it can be moved over the top of it manually in the Source Script Block Image. If no matching logical object is found, the user creates the first instance of the logical object of the block being defined by creating a new Object Box over the top of the object in the Source Script Block Image. Matched Script Object Box 1516 is the Object Box (previously Defined) representing the matched block in the Matched Script. Search Criteria Parameters 1518 containing Keyword, Context and Command of the block in the Source Script currently being Defined upon which the search takes place. The Blocks most closely matching the search criteria located among all the AFTT scripts in the current repository and displayed in the Search Results list 1524. The logical object representing the block in the Source Script currently being Defined is potentially located topmost in the Search Results list 1528. Script Block Issues List 1520 displays a list of the number of undefined blocks, and the number of defined blocks without images currently existing the Source Script. Filter By Text In Comment 1522, when selected, the Search Results are filtered by those matched blocks containing the text (entered by the user in the textbox) in the comment line sub-component of the Block. Existing Instances (selected) / Deleted Instances Tabs 1525 displays EXISTING matched Blocks in the Search Results list. However, if there are Blocks that match but have been deleted from the Source Script during recent changes, then these Blocks are specified under the Deleted Instances tab. Search/Refresh Buttons 1526 invokes a search to be conducted on the Search Criteria displayed. Since the user may manually change the defaulted Search Criteria (if the correct logical object is not found), the Refresh button refreshes the contents of the Search Criteria to reflect the initial default values. Matching Objects / Command Line Linked to Object / Instances lists 1528 displays the most closely matched logical objects (based on the search criteria). The Command Line Linked to Object list displays all the different types of AFTT command lines associated with the selected Matching Object, and the Instance List displays all the Block instances that are matched to AFTT command line selected from the Command Line Linked to Object list. Display Original Image and Object Filter 1530 displays the original image and object box defined for the Matched Script block. This allows the user to see how the block may have originally been defined, as there is a chance that the object box does not sit exactly over the top of the latest image captured for the block. Summary View Button / Summary View Pane 1532 is a summary View Button which invokes the Summary View Pane 1533. This pane displays the thumbnail view of every image of every Block of every logical object found in the Matching Objects list. Undefine / Start Definition / Accept Definition / Quit Definition Buttons 1534: Undefine button removes the association of the . current Source Script Block to its logical object (if this association is incorrect); Start Definitions button finds all undefined blocks from top to bottom of the Source Script, and stops at each occurrence to allow the user to Define it; Accept Definition associates the current Source Script Block to the logical object found in the current Matched Script Block. It also accepts the Object Box defining the object in the image displayed in the Source Script. Search and Refresh buttons 1526 invoke the search based on the search criteria and Refresh resets the search citeria to default. Display Only Comments Filter 1536 displays the script comment lines only and available when the DEFINE screen is on text mode. Export Script Button 1538 outputs the comments and associated image of each step of a script to an external file.

[0168] STEPS 2 to 5 above are administration steps that a user undertakes for all the automated test scripts in the repository. These steps are typically undertaken using the baseline or first release version of the AUT. These administrative steps transform each script from being complex and unwieldy text based software program instructions that are hard for users to read, orient themselves in, edit and hence maintain, into user-friendly formatted scripts that the user can maintain via the Software Maintenance Tool BUILD screen in the next step.

[0169] In the subsequent weeks or months a later version of the AUT is released with GUI objects that may be modified, deleted, or added. Business process flow maybe change the flow of a test script steps or introduce new steps. Testing is called on to verify that the newly released version of the AUT has not regressed and still works as specified by sequentially replaying the suite of automated test scripts. These AUT changes will break the automated test scripts and cause them to fail.

[0170] The Software Maintenance Tool user may know what the GUI changes are by communicating with the. AUT developers and hence may obtain a pre-release list of some or all changes to the GUI object properties; and in the BUILD step below incorporate the changes proactively and have the automated test scripts maintained in readiness for testing the AUT when in is released.

[0171] Alternatively the Software Maintenance Tool user may not know what the GUI changes are and will have to wait for the automated test script failed action blocks to fail before responding and maintaining the scripts. The first script to fail due to one or many of the said reasons of changes in the AUT, the user may stop the replay or wait for the run error log if the script can run past the failure and rerecord the failed step.

[0172] Either way, a failed action block in a particular script can be applied to all instances of that action block across all scripts in the repository (in the export mode) using the Software Maintenance Tool in the next step. The import mode will also be explained.

[0173] STEP 6: BUILD the script (Import or Export) 312. When a script has successfully exited DEFINE step, it is available to be built or fixed. If not automatically invoked from the DEFINE step, the BUILD screen 1600 can be invoked from the drop down list 204, where the user selects one script name then presses the BUILD button 208 which causes the BUILD screen 1600 to be displayed in the GUI 121. This step allows the user to export matching action block(s) or other AFTT code from the current source script into other script(s). Also allows the user to import matched action block(s) or other AFTT code from other scripts into the current script. On completion of this last step of the Software Maintenance Tool the script maintenance is over and the script is ready to be replayed (as part of the AFTT test suite) against the modified AUT to identify functional defects in the AUT.

[0174] FIGURE 16 is an embodiment of the BUILD screen 1600 shown in import mode. Source Script Name 1602 displays list of source scripts. The AFTT script the user is currently working on into which code from another AFTT script is to be imported is displayed in this field. Build Tab (selected) 1604 when invoked, displays the functionality used for Import/Export of code. Block Border in Source Script 1606 highlights the block/s on the AFTT script chosen in the Inter-Block Search Criteria list upon which to conduct the search. Matched Script Name 1608 shows the match of the Liter-Block Search Criteria. Block Border in Source Script 1610 highlights the matching block/s in the AFTT script based on the Inter-Block Search Criteria list. Inter-Block Issues Tab 1612 contains the Inter-Block Search Criteria controls. Search Results List 1614 displays the matched Script Names, as well as the number of matches in each of those scripts. Inter-Block Search Criteria List 1616 displays the user defined search criteria, which may be purely logical object/s, purely AFTT programming code, or a mixture of both. Anywhere / Contiguous Within Script controls 1618 determine if the Inter- Block Search Criteria List values are expected to be found contiguously in a script to be considered a "matched", or if other blocks can be between the search criteria blocks but it would still be considered a "match". The latter is a much looser search criteria and would find more matches. Comparator View button 1620 changes the look of the Build Screen so that the most recently archived version of the Source Script and the current version of the Source Script are displayed side-by-side on the top half of the screen, with Block differences highlighted, the jnost recently archived version of the Matched Script and the current version of the Matched Script are displayed side-by-side on the bottom half of the screen, with Block differences highlighted. This button invokes the Export Mode of the Build Screen, which is used to export code from Source script to Matched script. Save Modified Scripts button 1622 is redundant in import mode of the Build Screen. Searchbutton 1624 invokes the search of the Inter-Block Search Criteria. Copy User Selection button 1626 copies the code manually selected by the user in the Matched Script into the Software Maintenance Tool's buffer in readiness to be pasted in the script in the AFTT itself (rather than pasted in a script in the Software Maintenance Tool).

[0175] FIGURE 17 is an embodiment of the BUILD screen shown in Export Mode 1700. Source Scripts List 1702 displays all AFTT scripts in current repository. Build Tab (selected) 1704, when invoked, displays the functionality used for Import/Export of code. Source Script Archived Version 1706 is the script name chosen from Source Script list. This is the most recently archived version of the source script. It is to be compared to the current version of the script to ascertain changes, and then to apply the same changes to the Matched scripts. Source Script Current Version 1708 is the script name chosen from Source Script list. This is the script modified by the user in the AFTT. It is to be compared to its most recent archived version to ascertain changes, and then to apply the same changes to the Matched scripts. Inter-Block Issues Tab 1710 contains the Inter-Block Search Criteria controls. Search Results List 1712 displays the matched Script Names, as well as the number of matches in each of those scripts. Display only Comments Filter 1714 displays only the comment sub-section of every Block in the AFTT scripts, whilst still retaining the colour coding of the status of every Block. This presents a summarised view of the scripts, which is the test case that was initially used to record the AFTT script. Inter-Block Search Criteria List 1716 displays the user defined search criteria, which may be purely logical object/s, purely AFTT programming code, or a mixture. Block Filters 1618, when selected, displays blocks that are of a particular status. Selecting Display Added Blocks displays only the new Blocks in the current version of the Source Script. Selecting Display Deleted Blocks displays only the deleted Blocks from the most recently archived version of the Source Script. Selecting Display Moved Blocks displays the Blocks that have been moved from on area of the script to another in the current and most recently archived version of the Source Script. Comparator View button 1720 changes the look of the Build Screen so that the most recently archived version of the Source Script and the current version of the Source Script are displayed side-by-side on the top half of the screen, with Block differences highlighted, the most recently archived version of the Matched Script and the current version of the Matched Script are displayed side-by-side on the bottom half of the screen, with Block differences highlighted. This button invokes the Export Mode of the Build Screen, which is used to export code from Source script tσ Matched script. Anywhere / Contiguous Within Script controls 1722 determine if the Inter-Block Search Criteria List values are expected to be found contiguously in a script to be considered "matched", or if other blocks can be between the search criteria blocks but it would still be considered a "match". The latter is a much looser search criteria and would find more matches. Save Modified Script 1724 saves the Matched Script located in the bottom right hand side of the Build Screen. This is the Matched script upon which code would have been exported from the Source Script, or other forms of edits made to it. Matched (Destination) Script Archived Version 1726 is the most recently archived version of the matched (destination) script. Refresh Destination button 1728 refreshes the matched (destination) script to the state it was originally in, discarding any user exported code or other changes. Matched (Destination) Script Current Version 1730 is the most current version of the matched (destination) script. Search button 1732 invokes the search of the Inter-Block Search Criteria. Editing Controls 1734 are used to make edits to the matched (Destination) script. [0176] FIGIRE 18 is an embodiment of the BUILD screen shown in export mode with intra- block changes. Source Scripts list 1802 displays all APTT scripts in the current repository. Build Tab (selected), 1804, when invoked, displays the functionality used for Import/Export of code. Source Script Archived Version 1806 shows the script name chosen from Source Script list. This is the most recently archived version of the source script. It is to be compared to the current version of the script to ascertain changes, and then to apply the same changes to the Matched scripts. Source Script Current Version 1808 shows the script name chosen from Source Script list. This is the script modified by the user in the AFTT. It is to be compared to its most recent archived version to ascertain changes, and then to apply the same changes to the Matched scripts. Intra-Block Issues tab 1810 contains the Intra-Block Search Criteria controls. Search Results List 1812 displays the matched Script Names, as well as the number of matches in each of those scripts. Intra-Block Modification List 1814, depending on the tab chosen, will display either the context, command line or keyword changes for a particular logical object. Display Only Comments filter 1816 displays the test case equivalent of the test script when the BUILD screen is on text mode. Comparator View button 1818 changes the look of the Build Screen so that the most recently archived version of the Source Script and the current version of the Source Script are displayed side-by-side on the top half of the screen, with Block differences highlighted, the most recently archived version of the Matched Script and the current version of the Matched Script are displayed side-by-side on the bottom half of the screen, with Block differences highlighted. This button invokes the Export Mode of the Build Screen, which is used to export code from Source script to Matched script. In the case of Intra- Block mode, the text mode of scripts are displayed by default as intra-block changes, by their nature, can only be highlighted as text, not as an image. Search / Replace Criteria filters 1820 provide filtering of the search on blocks based on a particular combination of intra-block changes or non-changes. User has opportunity to change the context or command line from one of the existing values to another in an effort to unify the intra-block values of all instances associated to a particular logical object. Save Modified Script 1822 saves the Matched Script located in the bottom right hand side of the Build Screen. This is the Matched script upon which intra-block changes would have been exported from the Source Script. Matched (Destination) Script Archived Version 1824 is the most recently archived version of the matched (destination) script. Matched (Destination) Script Current Version 1826 is the most current version of the matched (destination) script. Editing Controls 1828 are used to make edits to the matched (Destination) script. Search button 1830 invokes the search of the Intra- Block Search Criteria.

[0177] FIGURE 19 is an embodiment of the BUILD screen shown in export mode with contiguous block sequences. Search Results List 1902 displays the matched Script Names, as well as the number of matches in each of those scripts. Contiguous Block Sequences tab 1904 contains controls that display information regarding sequences of blocks containing identical logical objects that occur many times over in the current repository. These sequences are potential candidates for functionalisation. Comparator View button 1906 changes the look of the Build Screen so that the most recently archived version of the Source Script and the current version of the Source Script are displayed side-by-side on the top half of the screen, with Block differences highlighted, the most recently archived version of the Matched Script and the current version of the Matched Script are displayed side-by-side on the bottom half of the screen, with Block differences highlighted. This button invokes the Export Mode of the Build Screen, which is used to export code from Source script to Matched script. Save Modified Script 1908 saves the Matched Script located in the bottom right hand side of the Build Screen. This is the Matched script upon which code would have been exported from the Source Script, or other forms of edits made to it. Logical Object Command Line Differences list 1910, for the selected sequence, if the logical objects have more than one command line associated with it, it displays the different command lines and detail the number of instances of each of the command lines. The user can view each of these instances to investigate whether or not the command lines can be unified in the hope of functionalizing the sequence. Inter-Block Search Criteria List 1921 displays the search criteria which is the sequence of logical objects in each of the contiguous sequences. Anywhere / Contiguous Within Script controls 1914 determine if the Inter-Block Search Criteria list values are expected to be found contiguously in a script to be considered a "matched", or if other blocks can be between the search criteria blocks but it would still be considered a "match". The latter is a much looser search criteria and would find more matches. This is set to Contiguous Within Script when in the Contiguous Block Sequences mode. Contiguous Sequence List 1916 displays the sequences of 5 or more contiguous blocks that exist over 10 times in the scripts in the current repository. [0178] STEP 7: The ARCHIVE step 314. This script archiving step is left to the user to carry out at any time, but would normally be so after the BUILD step. On pressing the ARCHIVE button 210, the floating menu bar is expanded to the right to display additional informational list boxes as in the embodiment 1200. The DEFINE button 206 and BUILD button 208 are displayed and the Current Script list 204 is updated with colour coding of the scripts needing archiving. The user selects the script to archive and when ready presses the ARCHIVE button 210 to commit the selection. The Software Maintenance Tool updates the database with the selection and floating menu is resumed to normal size as in 200.

[0179] FIGURE 12 is an embodiment of the ARCHIVE screen 1200. Unarchived Scripts list 1201 displays the un-archived AFTT scripts. ARCHIVE button 210 archives the selected scripts from the unarchived list 1210. Source Script Archived list 1204 displays the lists of archived scripts of the Source Script selected. Delete Selected Archives button 1208 deletes the selected scripts archives from 3. Archives to Delete 1212 displays the number of archives NOT to delete from ALL scripts.

[0180] Figure 20 is a block diagram illustrating an embodiment of the inventive concept.

[0181] 2002 is a first application under test AUT 1.1. A second version of the AUT is shown as AUT 1.2. An AFTT 2004 is used by user 2008 to produce the test script 2006. The test script is stored in memory 2012. The user 2008 then uses the edit tool 2010 to condition the script by tagging and associating with corresponding images. The conditioned script is stored in memory 2014. The user 2008 can use the conditioned script to form further associations with other scripts (not shown).

[0182] When a new version of the AUT is produced (AUT 1.2), the user 2008 uses the AFTT to run the script 2006 and the stored images from the initial conditioned script are displayed in window 20018 on display 2016. At the same time, the images generated by the new version are displayed in window 2020. [0183] The Software Maintenance Tool application program 118 can be incorporated to be part of AFTT application program 116 such that there is only one application program loaded into computer 100. Likewise the Software Maintenance Tool Data Base 132 can be incorporated to be part of the AFTT Data Base 128 such that the Software Maintenance Tool formatted test scripts 134 and the corresponding graphical images that make up the film strip 136 are all stored in the AFTT Data Base 128 such that computer 100 is communicating to one database.

[0184] This alternative embodiment removes the need for communication link 138.

[0185] This alternative embodiment simplifies the process depicted in FIGURE 3 whereby step 302 is removed as the software maintenance tool was started when the AFTT was started, Steps 304, 306 and 308 are simplified by having script errors and formatting errors resolved, the script formatted and stored in the AFTT Data Base 128, and images captured respectively during the AFTT script recording session when the AFTT automated test scripts 130 are being generated. Other subsequent steps would remain unchanged.

[0186] The alternative embodiment of the Software Maintenance Tool that incorporates it as part of the AFTT simplifies the DEFINE step since the AFTT knows the screen coordinates upon which the software line 816 acts. During the execution of the line 816 code in the AFTT, the coordinates of the mouse-click or cursor are noted by the AFTT and used to position a generic identifying shape over the captured image. This saves the user the work of manually defining an object by highlighting an Object Box over the top of the object in the Source Script Block Image on the image of the AUT 1514. Instead the Software Maintenance Tool locates and highlight the object and the user confirms the correct object is highlighted.

[0187] The Software Maintenance Tool can be implemented with an Automated Performance Testing Tools (APTT) in a similar manner to that described above for AFTT. This Software Maintenance Tool is directly applicable to APTT but the embodiment workflow is customised to the APTT and the associated recording protocol such HTTP, Tuxedo, and Oracle. The- process depicted in 300 is applicable in a similar embodiment for APTT as for an AFTT. [0188] The Software Maintenance Tool can be implemented in "n" tier distributed mode and web enabled, architecture server, instead of a standalone workstation as in Figure 1, whereby multiple users can access and operate the Software Maintenance Tool at the same time (concurrent users).

[0189] Where ever it is used, the word "comprising" is to be understood in its "open" sense, that is, in the sense of "including", and thus not limited to its "closed" sense, that is the sense of "consisting only of. A corresponding meaning is to be attributed to the corresponding words "comprise", "comprised" and "comprises" where they appear. .

[0190] Those skilled in the art will recognise many modifications may be made to this configuration without departing from the scope of the present invention. For example, those skilled in the art will recognise that any combination of the above components, or any number of different components, peripherals, and other devices, may be used with the present invention.

[0191] It will be understood that the invention disclosed and defined herein extends to all alternative combinations of two or more of the individual features mentioned or evident from the text which could be implemented by a person familiar with the technology. All of these different combinations constitute various alternative aspects of the invention.

[0192] While particular embodiments of this invention have been described, it will be evident to those skilled in the art that the present invention may be embodied in other specific forms without departing from the essential characteristics thereof. The present embodiments and examples are therefore to be considered in all respects as illustrative and not restrictive, and all modifications which would be obvious to those skilled in the art are therefore intended to be embraced therein.

Claims

1. A method of modifying software including initial code, the method including the steps of: grouping the software into blocks; and referencing each block with a unique reference.

2. A method as claimed in claim 1, including associating data with at least one of the blocks.

3. A method as claimed in claim 1 or claim 2, including associating at least one corresponding first image with at least one of the blocks.

4. A method as claimed in any one of the preceding claims, wherein the step of referencing includes association of a keyword with each block.

5. A method as claimed in claim 4, wherein the keyword identifies an object.

6. A method as claimed in claim 4 or claim 5 wherein the keyword is contained in a comment.

7. A method as claimed in any one of the preceding claims, wherein the step of referencing includes a command associated with the first image.

8. A method as claimed in any one of the preceding claims, wherein the initial code of each of one or more blocks defines a corresponding context.

9. A method as claimed in any one of the preceding claims, wherein the initial code is generated by an automated functional testing tool (AFTT) in response to user inputs.

10. A method as claimed in claim 9, wherein the user inputs are input as instructions in an application under test (AUT).

11. A method as claimed in claim 10, wherein the context is a context in the AUT.

12. A method as claimed in any one of the preceding claims, including the step of: associating instances of the same object in the same context.

13. A method as claimed in any one of the preceding claims including the step of storing the referenced blocks and their associated first images.

14. A method of editing software, including the steps of: modifying initial code in accordance with the method of claim 2 or any one of claims 2 to 13 as appended to claim 2; running an modified code on the application under test; capturing second images resulting from the running of the modified code; identifying differences between the first and second images.

15. A method as claimed in claim 14, including comparing the changes images with their associated images; and selectively editing the code associated with the images associated with the or each changed image.

16. A method of conditioning software, the method comprising the steps of: generating a unique software identifier; generating associated data attributes of the unique software; and generating an image and forming an association with the unique software; and generating a logical link to other instances of similarly behaving unique software; and identifying modifications to the unique software; and identifying other instances of the unique software that require the same modification; and applying the modification to the located instances of the unique software; and identifying singular or plurality of unique software to be used for developing software; and applying identified unique software to software in development; and identification of a plurality of instances of a specific sequence of unique software; and extracting associated data and associated image of unique software.

17. The method of claim 16, wherein the said unique software is a computer program instruction logically grouped with a plurality of other computer program instruction in a procedure known as a script.

18. The method of claim 17, wherein the said script is an automated test script generated by an AFTT.

19. The method of claim 17, wherein the said computer program instruction executes an. action or verification on the AUT.

20. The method of claim 16, wherein the method of generating a unique software identifier includes the step of tagging the software with a unique identifier.

21. The method of claim 20, wherein the unique identifier is inserted in the script containing the computer program instruction in close proximity to the associated computer program instruction.

22. The method of claim 16, wherein the said associated data attributes of the unique software includes: the name of the AUT component upon which the software interacts with; and software which defines the context in which the AUT component resides.

23. The method of claim 22, wherein the said name of the AUT component is inserted in the script in close proximity to the software code to which it is associated.

24. The method of claim 22, wherein the said name of the AUT component is the label of the component as identified in the AUT.

.25. The method of claim 24, wherein the said method of identifying the AUT component label is based on what is visually observed in the AUT.

26. The method of claim 22, wherein the said name of the. AUT component is defined by the user.

26. The method of claim 16, wherein the unique software identifier and associated data attributes, as well as the software itself, are grouped together in a uniform order in the script, forming a unit known as a block.

28. The method of claim 16, wherein the said image is a picture taken of the AUT containing the image of the AUT component upon which the software acts as well as the AUT context in which the AUT component resides.

29. The method of claim 28, wherein the said picture is captured immediately before or immediately after the software is executed against the AUT component.

30. The method of claim 28, wherein the said picture capture is invoked by software in the script situated immediately before or after the software that executes the action upon the AUT component.

31. The method of claim 16, wherein the said association of the said picture in claim 26 to the software, is by way of the unique identifier, thereby logically associating the said picture to the uniquely identified block.

321. The method of claim 16, wherein the said image is in the form of a motion picture showing the motion of the execution of the software acting upon the AUT component.

33. The method of claim 32, wherein the motion picture is invoked to start and stop recording by software in the script situated immediately before and after the software that executes the action upon the AUT component.

34. The method of claim 16, wherein the said association of the said motion picture in claim 33 to the software, is by way of the unique, thereby logically associating the said motion picture to the uniquely identified block.

35. The method of claim 28, further comprising the step of highlighting the AUT component upon which the software acts, contained within the boundaries of the said picture.

36. The method of claim 16, wherein the said logical link to other instances of similarly behaving unique software comprising the steps of: searching for identical or similar software; and interrogating the search results; and creating the logical link.

37. The method of claim 36, whereby the said searching is by forming search criteria composed of the software syntax and associated data attributes of the unique software;

38. The method of claim 36, wherein the said interrogating is by means of comparing a combination of the highlighted image and the data attributes of the unique software to the matched unique software, with the aim of locating another unique software that acts on the same AUT component;

39. The method of claim 36, whereby the said logical linking in the event of a matched comparison comprising the steps of: highlighting the AUT component upon which the software acts, contained within the boundaries of the said picture; and associating the unique software to the logical entity of the matched unique software, thereby forming a logical link to all other instances of unique software linked to the same logical entity.

40. The method of claim 36, whereby the said logical linking in the event that there is no match comprising the steps of:

Highlighting the AUT component upon which the software acts, contained within the boundaries of the said picture; and

Creating a new logical entity and linking it to the unique software.

41. The method of claim 16, wherein the said identifying modifications is achieved by comparing the previous version of the unique software to the current version of the same unique software.

42. The method of claim 41 , wherein the said previous version of the unique software is previously stored in and retrieved from an archive.

43. The method of claim 41, wherein the previous and current versions of an AFTT script are presented concurrently.

44. The method of claim 43, wherein the software in the scripts are displayed in Text Mode comprising of either unblocked AFTT code or block formatted code as in claim 26.

45. The method of claim 43, wherein the script is displayed in Image Mode comprising of a script being represented by a plurality of miniature images where each image is associated with the corresponding unique software contained in the script, thus forming film strip representation of the script.

46. The method of claim 45, wherein the miniature image associated with the unique software in focus is distinguished from surrounding miniature images, and is positioned midway down the film strip.

47. The method of claim 45, wherein the said Image Mode also displays an enlarged image associated with the unique software currently in focus in the script.

48. The method of claim 41, wherein the said modification comprises of identifying the change in content of a block by comparing the previous (archived) version of the block to the current version of the same block.

49. The method of claim 41, wherein the said modification comprising the steps of: identifying a change in position of a unique software by comparing its relative position to other unique software positions in the previous (archived) version to the current version of the script; and identifying added unique software that do not exist in the previous (archived) version of the script, but exists in the current version of the script; and identifying deleted unique software that exist in the previous (archived) version of the script, but do not exist in the current version of the script.

50. The method of claims 44 or 45, wherein highlighting of content changes within a block; changes in position of a unique software; addition of unique software; and deletion of unique software are respectively represented by different colours that are consistent in both the Test and Image Modes.

51. The method of claim 16, wherein the said identifying other instances of the unique software that require the same modification, comprising the steps of: specifying a search criteria; and searching for matches of the search criteria; and returning results; and displaying and highlighting the matched unique software.

52. The method of claim 51 , wherein the said specifying a search criteria is comprised of a combination of one or more of the following elements: logical entity of the unique software; and data attributes of the unique software or part thereof; and unblocked AFTT code or part thereof; and unique software code or part thereof.

53. The method of claim 51 , wherein the said displaying and highlighting can be in either Text or Image Mode, where the unique software or its associated image respectively which meet the search criteria are highlighted in the script.

54. The method of claim 16, wherein the said applying the modification, comprising the steps of: copying and pasting unique software or other software from the current version of the current script to the current version of the matched script as viewed in either Text or Image Mode; and deleting and modifying code in the current version of the matched script, as viewed in either Text or Image Mode.

55. The method of claim 54, wherein copying and pasting unique software includes: the associated data attributes of the unique software; and ^• the associated image of the unique software.

56. The method of claim 16, wherein the said Applying identified unique software to ^• software in development, comprising the steps of: copying and pasting unique software or other software from the matched script to the current script under development as viewed in either Text or Image Mode; and deleting and modifying code in the current version of the matched script, as viewed in either Text or Image Mode.

57. The method of claim 56, wherein copying and pasting unique software, comprising of: the associated data attributes of the unique software; and the associated image of the unique software.

58. The method of claim 16, wherein the said Identification of a plurality of instances of a specific sequence of unique software, comprising the steps of: specifying the criteria of the minimum number of unique software that are required in a sequence to constitute a match; and specifying the criteria of the minimum number of occurrences of that sequence that are required to be to constitute a match; and searching for matches of the search criteria; and returning results; and displaying a summary of all the matched sequences, and the number of occurrences of each matched sequence; and for every matched sequence, displaying and highlighting the unique software that constitutes the sequence, at every location of that sequence.

59. The method of claim 58 , wherein the said displaying and highlighting can be in either Text or Image Mode, where the unique software or its associated image respectively which meet the search criteria are highlighted in the script.

60. The method of Claim 16, wherein the said unique software extracted with its associated data and associated image are a plurality of unique software occurring in a script, whereby the extraction is in the corresponding order in which the unique software occur in the script.

61. A system for conditioning software including: a software maintenance tool adapted to group the software into blocks, and to add a reference to each block.

62. A system as claimed in claim 61 , wherein the maintenance tool is adapted to associate data with at least one of the blocks.

63. A system as claimed in claim 61 or claim 62, including first processing means adapted to run the edit tool, second processing means adapted to run an AFTT in conjunction with an AUT to generate the ^•software.

64. A system as claimed in any one of claims 61 to 63, wherein the first and second processing means are incorporated in a single computer.

65. A system as claimed in any one of claims 61 to 64, including first storage means adapted to store the software.

66. A system as claimed in any one of claims 61 to 65, including second storage means adapted to store the conditioned software from the maintenance tool.

67. A system as claimed in any one of claims 61 to 66, including a display means adapted to display corresponding blocks derived from different versions of the software.

68. A system as claimed in any one of claims 61 to 66, including a display means adapted to display corresponding blocks derived from one or more other software scripts.

69. A system as claimed in claim 67, wherein the display displays the corresponding blocks on a single screen display.

70. A system as claimed in claim 67 or claim 68, wherein the display displays images associated with corresponding blocks.

71. A software maintenance tool adapted for use in the method of any one of claims 1 to 60.

72. A software editing tool adapted for use in the method of any one of claims 1 to 60.

73. A method of conditioning software substantially as herein described with reference to the accompanying drawings.

74. A method of testing and/or editing software substantially as herein described with reference to the accompanying drawings.

75. A system for conditioning software substantially as herein described with reference to the accompanying drawings.

76. A system for testing and/or editing software substantially as herein described with reference to the accompanying drawings.

77. A software maintenance or editing tool substantially as herein described with reference to the accompanying drawings.