METHOD FOR MONITORING A GRAPHICAL USER INTERFACE ON A SECOND COMPUTER DISPLAY FROM A FIRST COMPUTER

Abstract

A high level interface between a remote computer and local computer operator permits the remote computer to be controlled via a sequence of interactions. The remote computer may be monitored for display information which is expected, and also controlled in the event the expected information either is or is not obtained. Command language extensions are provided which extend and complement a basic scripting language. Scripts with embedded command language extensions may be executed through a remote interface, permitting remote testing, operation and evaluation. The development of the scripts, including embedded command language extensions, may be prepared through execution of commands at the local computer on a depiction of the GUI received from the remote computer, and subsequently saved as a script.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 14/219,953 filed Mar. 19, 2014, entitled “Method for Monitoring a Graphical User Interface on a Second Computer Display from a First Computer,” which is a continuation of U.S. patent application Ser. No. 12/963,620, filed Dec. 8, 2010, entitled “Method for Monitoring a Graphical User Interface on a Second Computer Display from a First Computer,” which is a continuation of U.S. patent application Ser. No. 10/678,043, filed Oct. 1, 2003, entitled “Method for Monitoring a Graphical User Interface on a Second Computer Display from a First Computer,” now U.S. Pat. No. 7,870,504, issued on Jan. 11, 2011, all of which are incorporated herein in their entirety for all purposes.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention pertains generally to computer systems, and more particularly to methods and techniques for monitoring, testing and controlling the operation of one or more computers through communications links.

2. Description of the Related Art

With the early development of computers, all processing capability was located at a single computer system. These early machines were massive structures using many vacuum tubes, the result of which was the generation of an enormous amount of heat, and an associated sensitivity to environment. With these massive structures, all processing was performed centrally at this main computer, owing to the substantial expense required for isolation and environmental control. While remote communications with a computer system were sometimes used, the use was extremely infrequent and necessarily limited owing to the poor communications capability available at the time. These limitations of the need for environmental control and lack of adequate communications capability each persisted for several decades.

Progress in the semiconductor industry, initially with compact calculators beginning shortly after 1970 and followed by much more concentrated and capable chips suitable for computers less than a decade later, diminished and has ultimately virtually eliminated the need for extensive environmental control. Likewise, communications equipment, protocols and bandwidth compression have opened up the ability for substantial remote communications that were inconceivable only a few years ago.

For years, essentially from the days of first deployment of desktop computing, when a problem was encountered with a system, a computer user would be forced to resort to verbal telephone support with the hardware manufacturer. The waiting queues for these technical support personnel were notoriously long, with on-hold waits longer than an hour commonplace. When the technical support personnel were contacted, then the user would have to work verbally with the technical support person, and the support personnel would have to rely upon the computer users accurately describing the status and events, and performing operations requested by the support personnel. This arrangement was clearly less than optimum, requiring many times the effort that would have been required for the support personnel or a technician to directly diagnose and resolve the problem. Nevertheless, heretofore there has been little available for rapidly diagnosing the source of problems.

Unfortunately, many of the same issues and challenges face software vendors as those outlined above with regard to hardware manufacturers. When a particular program is prepared, the preparation work is usually performed upon a single type of computer having a particular combination of software installed thereon. All too frequently, the code will unintentionally rely upon components or features, such as may be found in the operating system, BIOS, system components or the like, which may vary from computer to computer. These variations may be based upon the release date of the particular computer, the software available at that time, upgrades provided by other vendors at the time of installation of their software, and other factors. At the time of deployment of early versions of the software, commonly referred to as alpha or beta versions, many of the incompatibility issues with diverse computers are discovered. Unfortunately, heretofore there has been no efficient way to diagnose the incompatibility, nor to quickly test the computer or isolate the source of the problem. Help databases have been prepared where persons may look for similar problems. Nevertheless, the amount of time involved in isolating and diagnosing a problem is still enormous and a source of much waste in the industry.

Even during the development of the software, substantial testing must be done. As is known in the art of programming, while a change in one part of the source code may not be expected to have an effect elsewhere, all too frequently this expectation is incorrect. As a result, even the most minor changes require substantial testing and validation to ensure that the changes do not disrupt the performance of a program at any other point. Presently, many software companies employ persons specifically in the role of testing. These persons will be assigned the chore of interacting with the computer as though they were a regular user, trying out each of the functions and determining whether any bugs may be identified. This approach also requires substantial operation by testing personnel, and is somewhat unreliable owing to the difficulty in determining whether the testers are, in fact, completing the testing properly and thoroughly. Nevertheless, this approach still provides cost saving over discovering a problem in the field after the software or hardware has been released more generally. Furthermore, the reputation of the company is improved by having fewer problems with the released software or hardware than competitors who utilize less thorough testing.

In the area of system administration, similar problems are also encountered. An IT professional will typically be called upon to implement a new program, upgrade or other such tasks throughout an entire network or system. In such instance, the administrator will frequently be required to visit each and every computer in order to perform the necessary tasks, and to verify the proper functioning thereof. This opportunity to access the computers has been made far more difficult with the advent of mobile systems and wireless communications, where many more of the computers connected through the network are not physically accessible at any given time.

In order to verify the performance of either software, hardware or a combination of the two, and regardless of whether the verification is being driven from the perspective of a manufacturer, developer, vendor, technical support, or internal maintenance within a single organization, this verification requires substantial interaction with the computer.

In an attempt to reduce the overhead associated with software debugging, a number of persons have developed methods for testing software by using a computer program. Many of these methods send information directly to the software or hardware, thereby bypassing the normal input channels and operations. Representative of the computer testing methods are U.S. Pat. No. 5,371,883 to Gross et al; U.S. Pat. No. 6,046,740 to LaRoche et al; U.S. Pat. No. 6,026,236 to Fortin et al; U.S. Pat. No. 5,022,028 to Edmonds et al; U.S. Pat. No. 5,249,270 to Stewart et al; U.S. Pat. Nos. 5,321,838 and 5,333,302 to Hensley et al; 5,335,342 to Pope et al; U.S. Pat. No. 5,594,892 to Bonne et al; U.S. Pat. No. 5,881,230 to Christensen et al; U.S. Pat. No. 5,926,638 to Inoue; U.S. Pat. No. 5,669,000 to Jessen et al; U.S. Pat. No. 6,119,247 to House et al; U.S. Pat. No. 6,195,765 to Kislanko et al; U.S. Pat. No. 6,249,882 to Testardi; U.S. Pat. No. 6,282,701 to Wygodny et al; and U.S. Pat. No. 6,353,897 to Nock et al; and 2002/0,099,978 to Kraffert, the contents of each which are incorporated herein for their teachings of the various methods and techniques associated with the control and operations associated with such systems. Nevertheless, no high level methods are introduced which readily permit the operator to perform the desired tests and operations on remote computers, particularly while interacting through the same or similar input devices and channels as would occur with standard human operations.

SUMMARY OF THE INVENTION

In a first manifestation, the invention is, in combination, a communications interface between a local computer and a remote system having a graphical user interface; a scripting language; and graphical user interface language extensions that enable the scripting language to control the remote system responsive to images appearing on the remote system graphical user interface.

In a second manifestation, the invention is a method for remotely testing the operation of a computer system. According to the method, a first element of the computer system graphical user interface is received. A user input action is then generated within the computer system responsive to the first element. The computer system graphical user interface is monitored for an expected second element within a predetermined time interval. A failure is signaled if the predetermined time interval elapses without detecting the expected second element.

In a third manifestation, the invention is a programmerator enabling a local system to remotely operate a computer system through local scripts and selectively respond to changes in graphical displays upon a graphical user interface of the remote computer system. A command capture interface displays a depiction of the remote system graphical user interface display and captures user input made therein. A command language set implements user input emulations representative of captured user input at the remote computer system and also implements image processing of the remote computer system graphical displays when processed by the local system. A scripting language has scripting commands that control a flow of execution of the local system in combination with command language set. An interface communicates between local system and remote computer system graphical user interface, responsive to the command and scripting languages.

OBJECTS OF THE INVENTION

Exemplary embodiments of the present invention solve inadequacies of the prior art by providing a high level interface between a computer and operator which will permit the computer to be controlled via a sequence of interactions. The computer may be monitored for display information which is expected, and also controlled in the event the expected information either is or is not obtained. The scripts may be executed through a remote interface, permitting remote testing, operation and evaluation.

A first object of the invention is to enable the execution of a plurality of user inputs directly through the computer system while responding to a video display. A second object of the invention is to enable the control of actions within the computer based upon the display. Another object of the present invention is to provide this capability using high level controls and commands that are intuitive and readily used. A further object of the invention is to enable this interaction and control to be instituted remotely through a communications interface through common Internet connection. Yet another object of the present invention is to enable both hardware and software developers to thoroughly test and evaluate the performance and operation of their developments and enhancements rapidly and with only minimal expense. An even further object of the invention is to permit a network or systems administrator to reliably, simply and quickly execute operations within an enterprise systems network, preferably without having to physically visit each of the computing devices within the network, and which would have been heretofore conducted with more time consuming, difficult and less reliable techniques.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, advantages, and novel features of the present invention can be understood and appreciated by reference to the following detailed description of the invention, taken in conjunction with the accompanying drawings, in which:

FIG. 1 illustrates a preferred graphical user interface designed in accord with the teachings of the present invention.

FIG. 2 illustrates a preferred functional block diagram for the execution of functions designed in accord with the teachings of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Manifested in the preferred embodiment, the present invention provides a computer user the ability to control any other computer connected through an interface, using the standard graphical user interface (GUI). As illustrated in FIG. 1, a user interface which takes the form of an interactive development environment (IDE) 100, will preferably include several functional windows 110, 120, 130 therein. More particularly, window 110 provides a command capture interface which most preferably provides a system-under-test (SUT) screen display 114 which provides a visual depiction of the display screen generated by the system for which the operation of the interactive development environment 100 is designed to control. Within that display there will be various graphical representations 116 that may take the form of icons as illustrated, or various buttons, message boxes, prompts or any other graphical image or control. The depiction may be an exact copy of the remote graphical user interface, a resized or scaled version, or may further include various image manipulations such as color conversions or other manipulations as deemed suitable and appropriate for a given application. A command tool bar 112 is provided which allows a user of interactive development environment 100 to select what type of command or action will most desirably be implemented at any given state within the system-under-test screen display 114. These commands will most desirably replicate the functions at the system-under-test 290 as though they were, in fact, executed directly upon that system. Preferably, such commands will include keyboard commands and mouse commands, though it will be understood that any form of user input may be emulated. Consequently, touch screen monitors, graphics pads or tablets, and any other type of primary or peripheral input device may be emulated as required and designed for. In the case of the keyboard commands, two commands may, for exemplary purposes only and not limited thereto, be implemented. The commands include a “TypeText” command and a “TypeCommand” command. These two commands permit any keyboard input available to be implemented, and yet provide a very understandable means to implement the same. In other words, where simple text must be entered, the “TypeText” command will be utilized. Where function and command keys are to be implemented, the “TypeCommand” function may be used. These commands are most preferably higher level language commands which will later be processed by a specific language extensions processor 255 described in greater detail herein below with regard to FIG. 2. Similarly, such mouse functions as “Click”, “DoubleClick”, “RightClick”, “MouseButtonDown”, “MoveTo”, “Drag”, and “MouseLocation( )” may be implemented. For the purposes of this disclosure, and as is commonplace in the computer arts, it will be understood that the use of parentheses denotes the implementation of a function that may include data or other variables that are being passed either from or to the function. Special commands such as “ClickAny”, the operation which will be described herein below, may also be implemented.

Operation of the present invention depends upon the graphical user interface. The myriad of possible functions and displays that may be produced as a result of an operation are extensive. For example, there are times where an operation may result in an introduction of one of a variety of controls. Where a single entity is anticipated, the image of the entity can be stored through the command capture interface window 110, and, when such image is later detected during execution of a script, an appropriate action can be selected, such as the “Click” command which would represent a mouse click upon a particular point in the screen. While many times this “Click” command may be executed directly upon the entity which newly appears upon the system-under-test screen 114, the direct action upon such an entity is not required. Instead the user of interactive development environment 100 has complete control over any of the user actions that may be relayed to the system-under-test 290, such as providing typed text, commands, movement of the mouse, and so forth. Consequently, the appearance of an object may stimulate any suitable action. Where such action would be to send a click on any active component that may appear on the screen, the “ClickAny” command will most preferably be provided, which enables the click to occur on any entity that may appear. Furthermore, in one contemplated embodiment, the activation of keystrokes or mouse clicks directly within the system-under-test screen 114 may be directly transferred as commands that are captured, or there may alternatively be a button to select which initiates and subsequently stops the recording of such within system-under-test screen 114 actions.

Since the present invention is designed to control graphical user interfaces, several commands are contemplated herein, but once again not considered to be solely limiting or restricted thereto. These image commands will most preferably include screen image searching commands and specific image information. Exemplary of the screen image searching commands are such commands as “WaitFor”, “WaitForAny”, “WaitForAll”, “RefreshScreen”, “ImageFound( )”, “AnyImageFound( )”, “ImageLocation( )”, “AnyImageLocation( )”, “EveryImageLocation( )”, and other similar commands. A variety of information will most preferably be obtained or obtainable with regard to specific images, through such commands as “ImageInfo( )”, “FoundImageNumber( )”, “FoundImageName( )”, “FoundImageLocation( )” “ImageHotSpot( )”, and “ImageSize( )”. Utilizing the above command set, it is possible to monitor a graphical user interface for any type or shape of image and then, responsive to the presence thereof, select a subsequent user action as though the user action were being performed directly upon the system-under-test 290 rather than from a source or controlling computer. In the event an unexpected event or entity appears upon the screen, the user, through the integrated development environment 100, has the opportunity to control the operation of the local and remote systems responsive thereto. For example, if a particular object is expected to appear upon the system-under-test screen 114 within a particular time interval, and the time expires prior to the object appearing, then it would be possible for a script entered within script window 120 to time out and cause an error message or warning message or the like to appear upon the local computer screen. The scripting window will most preferably provide access to functions and commands through, for exemplary purposes only, script tool bar 122 that are commonly associated with or available through any of the various scripting languages or more fundamental programming languages. Such functionality as decision structures, loops, timers, and the various other myriad of functions available therein as are well known will most preferably be incorporated herein, in accord with the particular language incorporated herewith or developed for operation herein. One such example is “SenseTalk”, though other suitable scripting languages are certainly contemplated herein, and will be dependent upon the preferred operating platform or cross-platform capability desired.

Most preferably, interactive development environment 100 will additionally include a window 130 which provides access to various organizational functions, which may, in the preferred embodiment, be implemented using the familiar index tab analogy. Among the available index tabs may, for exemplary purposes only, be functions such as the storage of various scripts 132, images 134, results from past script executions 136, scheduling of planned script executions 138, and the identification and or the location of helper script and image files 140, which may be local, on a network, or located anywhere on the Web.

While FIG. 1 provides a basic overview of the user view provided through the interactive development environment 100, FIG. 2 illustrates the functional interconnection of the interactive development environment 100 components with the various additional components that are not visible upon the screen to form the preferred programmerator system 200. More particularly, the presentation of the system-under-test screen 114 is achieved by a remote GUI interface 270. A command and image capture system 212 is responsible for the capture of appropriate commands from command tool bar 112 and image information such as icon 116. Consequently, when a user selects a particular command, such as a mouse click or the like, this command must be captured and incorporated into the appropriate scripting information. Likewise, the inclusion of an expected image or others of the herein above described image or user control commands must be incorporated. These commands, which are not native to prior art operating systems, programming or scripting languages, are passed through to the system data, scripts and images controller 235. Controller 235 is responsible for the appropriate redirection and incorporation of command, graphics and scripts between execution environment 245, script window 120, and command and image capture system 212. For example, when a command is received from command and capture system 212, this command and any associated language will preferably be inserted into scripting window 120. Likewise, the passing of images from the execution environment 245 will occur through controller 235. Script window 120, which would in operation contain an active script, may be processed directly through execution system 240 for a real-time run, or may be passed through organizational window 130 for storage and scheduling therein.

Ultimately, a given script will be executed through the execution system 240, which is configured to carry out the processes specified within a script. While somewhat simplistic in description, the execution system 240 and execution environment 245 are typically comprised by the local CPU, memory, OS, and the like. The command processor or CPU will effect or control much of the execution within system 240, but will be monitoring a diverse set of status indicators, potentially both locally and at the system-under-test 290, programming calls, and the like. These various items being monitored comprise in part the execution environment 245.

As the script is being processed, execution environment 245 will need to call the scripting language processor 250, which may be an interpreter, compiler or other suitable language processor. The scripting language has been extended in the preferred embodiment by various GUI commands and controls that are created through the command capture interface 110, such as the various mouse events and the like. Consequently, these commands must be processed not by the scripting language processor 250, but instead by a language extensions processor 255. As a result of the processing of the scripting language and the language extensions, an action may require to be initiated, which would be detected and triggered in the initiate action subsystem 260, which will relay the action back to execution environment 245. In the event this is an action intended for the system-under-test 290, such action will be relayed from execution environment 245 through remote GUI interface 270. The purpose of the remote GUI interface 270 is to implement an interface with the remote system-under-test 290, preferably relatively independently of the characteristics of communications channel 275 used and the data exchange rate associated therewith. This consists of providing client function to facilitate communication with the GUI server on the remote system-under-test 290, and to implement any needed out-of-band communication. Included are such operations as the client-server functions of retrieving images, sending keyboard and mouse commands, and initiating error recovery procedures as needed.

Communications channel 275 will in the preferred embodiment include a keyboard channel 272, mouse channel 274, and a transfer of screen updates from VNC server 280 back to the remote GUI interface 270. Communications channel 275 may be a high speed trunk line or cable, or may alternatively be a relatively slow-speed dial-up or RS-232 type connection. With proper selection of components, the preferred embodiment has much flexibility to operate through diverse communications channels having very different data transfer rates and signal to noise ratios.

To achieve broader application to more and more diverse systems-under-test 290, remote GUI interface 270 through a communications channel 275 communicates with remote computer virtual network computing server 280 or the like. As illustrated herein, the remote GUI interface 270 and VNC server 280 are most preferably VNC components which are readily available commercially and which operate as cross-platform components to directly interface with a remote system GUI. Nevertheless, other standard interfaces may be supported.

Images from the system-under-test 290 GUI will be relayed through VNC server 280 or the equivalent back to local system remote GUI interface 270, and from there routed to the GUI recognition subsystem 265. GUI recognition subsystem 265 dynamically scans the screen image of the remote system-under-test 290 for any bit-map images which the initiate action subsystem 260 is searching for. The goal of GUI recognition subsystem 265 is to locate images and signal the presence of such images to the initiate action subsystem 260 through an image detection signal, initiate recovery procedures such as moving the mouse cursor to locate images, or to report that the sought-after images are not available. GUI recognition subsystem 265 cooperates with the initiate action subsystem 260 and language extensions processor 255 output to determine whether a desired event or image has been created and if so, to execute the desired image identification actions requested within the language extensions received from language extension processor 255 through the execution environment 245.

Initiate action subsystem 260 initiates any action requested by the language extensions received from language extensions processor 255, which could be active commands to type text through the keyboard or to move the mouse in a number of ways. The commands may also in the preferred embodiment include passive commands to search the screen image on a continuing basis for a specific bit-map image, and, for exemplary purposes, terminating the search after a given period of time has elapsed.

While the preferred embodiment programmerator system 200 depends upon GUI image location, this may be practiced in one of several different ways. One approach is to directly map bits and to locate based upon this matching bit pattern. Said another way a black border with a blue interior and a yellow button bar may comprise the image of interest, which might, in this case, be a control or graphic. However, when some potential systems-under-test 290 are configured with a different color scheme, the same control may be comprised of a different color set and would, using this simpler approach, go undetected. Several approaches may be used to overcome this limitation. One such approach is to develop a custom color scheme at the local computer, in effect translating the remote system-under-test 290 display to the local color scheme. This may, for example, be achieved by access the system-under-test 290 and determining the color scheme being implemented within the operating system or the like to determine what color translations are required to restore color variations to a common baseline. Another approach is to map and convert the images based upon geometry into particular color sets. Yet another approach is to convert to black and white colors. Depending upon the design and intent, and the types of systems to be tested or controlled, one or more approaches may be provided or available within the operation of the programmerator system 200.

While the foregoing details what is felt to be the preferred embodiment of the invention, no material limitations to the scope of the claimed invention are intended. Further, features and design alternatives that would be obvious to one of ordinary skill in the art are considered to be incorporated herein. The scope of the invention is set forth and particularly described in the claims hereinbelow.

Claims

1. In combination,

a communications interface between a local computer and a remote system having a graphical user interface;

a scripting language; and

graphical user interface language extensions that enable said scripting language to control said remote system responsive to images appearing on said remote system graphical user interface.

2. The combination of claim 1 further comprising a display of said remote system screen at said local computer.

3. The combination of claim 2 further comprising a command capture interface for generating graphical user interface language extensions commands from actions performed upon said local computer display of said remote system screen.

4. The combination of claim 3 further comprising a means for transferring said graphical user interface language extensions commands to a script responsive to said actions performed upon said local computer display of said remote system screen.

5. The combination of claim 1 further comprising a graphical user interface recognition subsystem which detects image components appearing upon said remote system graphical user interface and produces an image detection signal responsive thereto.

6. The combination of claim 5 further comprising an initiate action subsystem which evokes a remote system action responsive to said image detection signal.

7. The combination of claim 1 wherein said communications interface further comprises a means for communicating keyboard actions to said remote system, a means for communicating mouse actions to said remote system, and a means for communicating screen updates from said remote system to said local computer.

8. A method for remotely testing the operation of a computer system, comprising the steps of:

receiving a first element of said computer system graphical user interface;

generating a user input action within said computer system responsive to said first element;

monitoring said computer system graphical user interface for an expected second element within a predetermined time interval; and

signaling a failure if said predetermined time interval elapses without detecting said expected second element.

9. The method of claim 8 wherein further comprising the steps of:

transferring said user input action to a stored script;

re-executing said steps of receiving, generating, monitoring and signaling subsequent to said storing step under control of said stored script.

10. The method of claim 8 wherein further comprising the steps of:

providing graphical user interface language extensions commands to a scripting language; and

passing said generated user input action through said graphical user interface language extensions from said scripting language processor to a language extensions processor.

11. The method of claim 8 further comprising the steps of:

generating a user input action within said computer system responsive to said second element;

monitoring said computer system graphical user interface for an expected third element within a predetermined time interval; and

signaling a failure if said predetermined time interval elapses without detecting said expected third element.

12. The method of claim 8 further comprising the steps of:

depicting said computer system graphical user interface upon a local display including said first element; and

receiving a local user input action within said local display;

wherein said generated user input action emulates said local user input action.

13. The method of claim 8 wherein further comprises comprising the steps of:

providing graphical user interface language extensions commands to a scripting language; and

depicting said computer system graphical user interface upon a local display including said first element;

receiving a local user input action within said local display;

transferring said user input action to a stored script;

passing said generated user input action through said graphical user interface language extensions from said scripting language processor to a language extensions processor wherein said generated user input action emulates said local user input action; and

re-executing said steps of receiving, generating, monitoring and signaling subsequent to said storing step under control of said stored script.

14. A programmerator enabling a local system to remotely operate a computer system through local scripts and selectively respond to changes in graphical displays upon a graphical user interface of said remote computer system, comprising:

a command capture interface that displays a depiction of said remote system graphical user interface display and captures user input made therein;

a command language set that when processed by said local system implements both of user input emulations representative of said captured user input at said remote computer system and image processing of said remote computer system graphical displays;

a scripting language having scripting commands that control a flow of execution of said local system in combination with said command language set; and

an interface for communicating between said local system and said remote computer system graphical user interface responsive to said command and scripting languages.

15. The programmerator of claim 14 further comprising:

a means for storing said scripting commands;

a means for inserting a command from said command language set into said storing means; and

a means for executing said inserted stored command.