Some image-based application (or software) automation systems typically include a record phase and a playback phase. During the record phase, an image-based application automation system records actions for an application that will be automated during a playback phase. For example, an image-based application automation system detects input events at a graphical user interface and captures an image of the graphical user interface in response to each input event. Often, the image-based application automation system then defines an automation action for each input event that specifies the image for that input event, and automation actions defined during the record phase are stored within a script file.
During the playback phase, the image-based application automation system performs the actions recorded during the record phase. For example, the image-based application automation system can identify the automation actions in the script file and replay the input events specified in the automation actions. That is, for each automation action, the image-based application automation system identifies a portion of a graphical user interface of the application that matches the image specified in that automation action and performs the input event at that portion of the application.
Image-based application (or software) automation systems can suffer from failures when such systems are unable to match an image related to an input event with a portion of a graphical user interface. For example, an input event can be relative to (or performed at) a graphical user interface element that has multiple states (e.g., visual appearances). As a specific example, the input event can be relative to a button control that has a first visual appearance when a cursor (e.g., a mouse pointer) does not hover over the button control, and a second visual appearance when the cursor hovers over the button control. Accordingly, an image of the button control that is captured in response to an input event such as a mouse button down input event at the button control will include the button control in the second visual appearance (or state) because the mouse pointer hovers over the button control when a mouse button down input event is performed at the button control.
However, during a replay phase, the mouse pointer may not be hovering over the button control when the image-based application automation system attempts to replay an automation action including the mouse button down input event (e.g., replay the mouse button down input even specified at the automation action) at the button control. As a result, the button control is in the first visual appearance, but the image for the mouse button down input event includes the button control in the second visual appearance. Thus, the image-based application automation system will likely fail to match the image with the button control, and the replay phase will fail for this automation action.
Some image-based application automation systems provide a mechanism that allows a user such as a test engineer to provide an image to an image-based application automation system as a substitute for an image generated (or captured) by the image-based application automation system. For example, after the failure described above, the user can manually generate an image that includes the button control in the first visual appearance, and provide that image to the image-based application automation system as a replacement for the image generated by the image-based application automation system.
Such a process, however, can be time-consuming for the user. For example, a user may be required to manipulate the application to display the button control in the first visual appearance, generate a screenshot image of the application, and then edit (e.g., crop or resize) the screenshot image to produce an image to replace the image generated by the image-based application automation system.
Implementations discussed herein associate multiple images with an input event. For example, multiple images including a graphical user interface element at which an input event is performed during a record phase of an image-based application automation system are captured at different times, and are identified (or referenced) by an automation action for that input event. Additionally, implementations discussed herein allow a user to specify which of the multiple images should be used to identify the portion of a graphical user interface (e.g., the graphical user interface element) at which the input event should be performed. Accordingly, for example, a user can select image from a group of images generated by an image-based application automation system and associated with an input event as the target for the input event rather than provide a user-generated image.
Such inputs events are often performed relative to a graphical user interface (GUI) or elements of a graphical user interface (GUI elements). For example, a user can interact with a GUI element (e.g., using a mouse or touch-sensitive device click on the GUI element) to generate an input event relative to that GUI element. As another example, a GUI element can have or be the input focus of a GUI (e.g., in response to previous user selection of that GUI element), and input events that occur or are detected while that GUI has the input focus are relative to that GUI element. Accordingly, input events can be referred to as being relative to, occurring at, or performed at portions of a GUI or at GUI elements.
A GUI is a user interface that allows a user to interact with a system (e.g., a computing device) using graphical representations of objects rather than textual commands. For example, a user can move a cursor to a graphical representation of a button and press and release the graphical representation of the button using a mouse or touch-sensitive device.
Such graphical representations are referred to herein as graphical user interface elements (or GUI elements). A GUI element is a portion of a GUI at which a user can provide input to the GUI. For example, a GUI element can be a control such as, a pushbutton or button, a radio button, a check box, a text field or box, a dropdown list, a spinner (or spin control), a slider, an icon, a tree control, a scroll bar, a hyperlink, or some other control. As another example, a GUI element can be a GUI container that can include other GUI elements such as a window, a view, a dialog box, a frame, a tab, a menu, or some other container.
Often, a coordinate system such as a Cartesian coordinate system is associated with a GUI. For example, the upper-left corner of the GUI can be designated as the origin and described using the tuple (0, 0). Each point (often corresponding to each pixel of a display such as a computer monitor at which the GUI is output) of the GUI can then be described using as coordinates relative to the origin. For example, for a GUI displayed at a computer monitor with a resolution of 1,920 by 1,080 pixels, the point in the upper-left corner of the GUI is described as (0, 0), the point in the lower-left corner of the GUI is described as (0, 1,080), the point in the upper-right corner of the GUI is described as (1,920, 0), and the point in the lower-right corner of the GUI is described as (1,920, 1,080). Accordingly, input events can include a description of the location (or locations) at the GUI an input event occurred. For example, an input event for movement of a cursor can specify one set of coordinates indicating where the movement began (e.g., the position of the cursor before the movement) and another set of coordinates indicating where the movement ended.
The image-based application automation system implementing process 100 can detect input events at block 110 using a variety of methodologies. For example, an image-based application automation system can register with an operating system (e.g., using an application programming interface (API) of the operating system) to receive a notification or signal such as a system signal, a function call, or method invocation that includes a description of an input event (e.g., an identifier of a type of class of the input event, a description of the input event such as which button was pressed at a keyboard, and/or a location of the input event). As another example, an image-based application automation system can communicate with one or more device drivers to receive notifications or signals when peripheral devices (e.g., a mouse, a touch- or proximity-sensitive device such as a trackpad, a physical keyboard, or a virtual keyboard such as an on-screen keyboard) provide signals or notifications to a computing device to indicate that an input event has occurred at those peripheral devices. As yet another example, an image-based application automation system can instrument an operating system (e.g., hook input event handling routines of the operating system or provide a device driver) to intercept notifications or signals that are related to input events and are generated by the operating system or device drivers.
After the input event is detected at block 110, multiple images are associated with the input event at block 120. In other words, the image-based application automation system implementing process 100 defines or establishes a relationship between the input event and two or more images. For example, a description of the input event and identifier of each image (e.g., universal resource identifier (URI), filesystem path, or filename) to be associated with the input event can be stored at an automation action. An automation action represents an input event to be replayed during a replay phase. As examples, an automation action can be represented or stored as a portion of a script file, an Extensible Markup Language (XML) element or group of XML elements, or a data structure at an image-based application automation system.
As used herein, the term “image” means a representation of some subject (e.g., a GUI, a portion of a GUI, or a GUI element) that is based on the visual appearance of the subject. Moreover, a copy or transform (e.g., altered color space, size, aspect, or ratio) of an image of a subject is also an image of the subject.
In some implementations, the images associated with the input event are generated chronologically at various times during a record phase or are based on such images. For example, the image-based application automation system implementing process 100 can generate images of a GUI (e.g., perform a screen capture or a screenshot relative to the GUI) at an interval such as every other second or every 200 milliseconds. Alternatively, for example, the image-based application automation system implementing process 100 can generate images of a GUI in response to input events such as movement input events.
In some implementations, each image generated during a record phase is cached or archived by the image-based application automation system. In some implementations, an image-based application automation system implementing process 100 includes a fixed-length queue in which the most recently generated images are stored. Furthermore, in some implementations, the image-based application automation system implementing process 100 also generates an image of the GUI in response to the input event detected at block 110. Moreover, the image-based application automation system implementing process 100 can continue to generate images of the GUI after an input event is detected.
The number of images associated with an input event can vary according to various implementations based on, for example, a type or class of an input event, a user-defined or -configurable parameter, a predefined parameter, or other criteria. Additionally, the images associated with an input event include the portion of a GUI or GUI element at which the input event was performed. For example, as discussed above, the images associated with the input event can include a portion of a GUI or GUI element in different states. Moreover, the images associated with an input event can be centered at the location at which the input event occurred. More specifically, for example, an image-based application automation system can identify the location of the input event at the GUI based on location information included in a description of that input event or a previous input event.
The image-based application automation system can then generate a group of images to be associated with the input event. For example, the image-based application automation system can identify a portion of the GUI or a GUI element that surrounds the location. As a specific example, using edge detection or other image processing analysis methodologies, the image-based application automation system can identify a GUI element that includes or surrounds the location. As another example, the image-based application automation system can identify a portion of the GUI by defining a rectangle, ellipse, polygon, or other shape including or centered at the location. The image-based application automation system can then generate a group of images including the portion of the GUI or GUI element by, for example: accessing two images that were captured before the input event, an image captured in response to the input event, and an image captured after the input event; generating copies of those images; and cropping the image copies about the identified portion of the GUI or GUI element (e.g., based on the coordinate system of the GUI scaled as appropriate for each image). The cropped images can then be associated with the input event as discussed above, and/or stored at a data store.
As discussed above, the image copies can be cropped to have various dimensions or shapes according to various implementations. Moreover, the image copies can be cropped about a location (or point) other than the location of the input event. In other words, the cropped image copies can be centered at a location of the GUI other than the location of the input event. In such implementations, the image-based application automation system replays the input event during a replay phase at a location appropriately offset from the center of such images such that the input event is replayed at the same location as the location at which the input event occurred during the record phase. As used herein, a second location is the same as a first location if the second location is identical to the first location or is sufficiently similar or close to the first location that an input event at the second location has the same effect at a GUI or GUI element as that input event at the first location.
Process 100 illustrated in
Button 215 has various states including the first state illustrated in
As discussed above, because the state (or visual representation) of GUI elements of an application with respect to which automation actions will be replayed (or the input events specified in those automation actions are specified) can change during execution of that application, image-based application automation systems can fail to identify a portion of the application (output using a GUI) at which an automation action should be replayed because the image specified in that automation action includes that portion of the application in one state, but that portion of the application is currently (i.e., when the automation action should be replayed) in a different state.
An image-based application automation system implemented according to implementations discussed herein can generate multiple images of a GUI (or portions thereof) during a record phase. For example, such an image-based application automation system can generate a group of images of window 210 that includes at least one image of button 215 in the first state and at least one image of button 215 in the second state by periodically capturing screenshots of the application including window 210 or by capturing screenshots in response to input events such as movement input events. Moreover, the image-based application automation system can detect an input event when a mouse down event occurs at button 215 (e.g., when cursor 220 hovers at button 215), and can generate an image that includes button 215 in the third state in response to that input event.
Additionally, in response to the input event, the image-based application automation system can crop images (e.g., each image or a subset of the images such as every other image or every nth image) from those images about the location of the input event. For example, a notification from an operating system of a computing device hosting the application can provide a notification to the image-based application automation system that includes coordinates of the input event. The image-based application automation system can then crop images to generate a second group of images of the GUI element to which the input event was relative, and can associate the second group of images with the input event (e.g., at an automation action).
Event detection module 410 detects or determines when input events occur at an application including a GUI, and provides a notification (e.g., a signal or a message) related to the input event to association module 430. In some implementations, event detection module 410 also provides notifications related to input events to image generation module 420. As discussed above, event detection module 410 can, for example, register with or instrument an operating system at which an application is hosted to receive notifications of input events.
Image generation module 420 generates images of a GUI. For example, image generation module 420 can capture screenshots of a GUI at some interval and/or can receive notifications related to input events from event detection module 410 and generate images in response to such notifications. In some implementations, image generation module 420 can generate images in response to stimulus or signals from other modules.
In some implementations, image generation module 420 stores images in a queue to maintain a record of the most recent images generated at image generation module 420. For example, image generation module 420 can store the seven most recently generated images at a queue. When a new image is generated, the oldest of the seven images is discarded from the queue (e.g., overwritten in a memory, removed from a memory, or memory for that image is deallocated) and the new image is added to the queue. In other implementations, image generation module 420 stores images at image repository 440. Image repository 440 can be a data store such as a database or memory allocated to store images. In some implementations, image repository 440 is or operates as a fixed-length queue (e.g., similar to the queue discussed above in relation to image generation module 420). In other implementations, image repository 440 is a data store at which all images generated by image generation module 420 during a record phase are stored.
In some implementations, images generated by image generation module 420 are temporarily stored (e.g., cached) at image generation module 420, and stored for the duration of a record phase (or longer) at image repository 440. Thus, for example, images can be stored at a fixed-length queue of image generation module 420, and stored at image repository prior to being discarded from image generation module 420.
Association module 430 receives a notification related to an input event from event detection module 410, and associates a group of images generated at image generation module 420 with the input event. For example, association module 430 can access a group of the most recently generated images at image generation module 420 and/or image repository 440, and include identifiers (e.g., URIs) of those images within an automation action generated at association module 430 for that input event (e.g., an automation action that includes a description of that input event).
In some implementations, association module 430 generates images based on images accessed at image generation module 420 and/or image repository 440, and associates the images generated at association module 430 with the input event. For example, association module 430 can generate copies of images accessed at image generation module 420 and/or image repository 440, crop those copies of images to generate reduced-size images that include (e.g., are centered about or surround) the location of the input event relative to a GUI, and associate the reduced-size images with the input event. Accordingly, each image associated with the input event can include a portion of a GUI with the GUI element at which the input event occurred rather than the entire GUI.
Display interface 520 is a combination of hardware and software that outputs data to a display such as a computer monitor, a notebook computer display, or tablet display. For example, display interface 520 can include a graphics card or graphics processor coupled to processor 510 and related software driver hosted at that graphics card, graphics processor, and/or processor. In some implementations, such as computing device can be a notebook computer, tablet, all-in-one desktop computer, or other computing device with an integrated display. In such implementations, display interface 520 can include a display.
Memory 530 is a processor-readable medium that stores instructions, codes, data, or other information. As used herein, a processor-readable medium is any medium that stores instructions, codes, data, or other information non-transitorily and is directly or indirectly accessible to a processor. Said differently, a processor-readable medium is a non-transitory medium at which a processor can access instructions, codes, data, or other information. For example, memory 530 can be a volatile random access memory (RAM), a persistent data store such as a hard disk drive or a solid-state drive, a compact disc (CD), a digital video disc (DVD), a Secure Digital™ (SD) card, a MultiMediaCard (MMC) card, a CompactFlash™ (CF) card, or a combination thereof or other memories. Said differently, memory 530 can represented multiple processor-readable media. In some implementations, memory 530 can be integrated with processor 510, separate from processor 510, or external to computing device 510.
Memory 530 includes instructions or codes that when executed at processor 510 implement operating system 531, event detection module 410, image generation module 420, association module 430, and application 535. In other words, operating system 531, an image-based application automation system including event detection module 410, image generation module 420 and association module 430, and application 535 are hosted at computing device 500.
In the example illustrated in
In some implementations, computing device 500 can be a virtualized computing device. For example, computing device 500 can be hosted as a virtual machine at a computing server. Moreover, in some implementations, computing device 500 can be a virtualized computing appliance, and operating system 531 is a minimal or just-enough operating system to support (e.g., provide services such as a communications protocol stack and access to components of computing device 500 such as display interface 520) event detection module 410, image generation module 420, association module 430, and application 535.
Event detection module 410, image generation module 420, and association module 430 can be accessed or installed at computing device 500 from a variety of memories or processor-readable media. For example, computing device 500 can access event detection module 410, image generation module 420, and association module 430 at a remote processor-readable medium via a communications interface such as a network interface card (NIC, not shown). As a specific example, computing device 500 can be a thin client that accesses operating system 531, event detection module 410, image generation module 420, association module 430, and application 535 during a boot sequence.
As another example, computing device 500 can include (not illustrated in
In some implementations, event detection module 410, image generation module 420, and association module 430 can be accessed at or installed from multiple sources, locations, or resources. For example, some components of event detection module 410, image generation module 420, and association module 430 can be installed via a communications link, and other components of event detection module 410, image generation module 420, and association module 430 can be installed from a DVD.
In other implementations, event detection module 410, image generation module 420, and association module 430 can be distributed across multiple computing devices. That is, some components of event detection module 410, image generation module 420, and association module 430 can be hosted at one computing device and other components of event detection module 410, image generation module 420, and association module 430 can be hosted at another computing device. As a specific example, event detection module 410, image generation module 420, and association module 430 can be hosted within a cluster of computing devices where each of event detection module 410, image generation module 420, and association module 430 is hosted at multiple computing devices, and no single computing device hosts each of event detection module 410, image generation module 420, and association module 430.
The target can be designated using a variety of methodologies. For example, an image generated in response to the input event can be designated as the target for the input event by listing an identifier of that image first in a list of images associated with the input event at an automation action for that input event. In other implementations, an automation action can include a field at which an identifier of the image that is the target for the input event can be included. As yet another example, a target flag or attribute can be set for the image that is the target for the input event, and a target flag or attribute can be reset for each other image associated with the input event.
Additionally, the image designated as the target for the input event can be selected based on a variety of methodologies. For example, an image generated after the input event can be designated as the target. As another example, the image generated in response to the input event can be designated as the target. As yet another example, an image generated a predetermined number of seconds or milliseconds before or after the input event can be designated as the target.
At block 640, a selection interface is output to a user. The selection interface allows to user indicate that an image different from the image currently designated as the target should be designated as the target for the input event (e.g., in an automation action for the input event).
If the user provides input (e.g., a keystroke, a mouse click, or a tap at a touch-sensitive input device) that indicates that the target should not be changed (e.g., that the image currently designated as the target should be the target), process 600 completes. In some implementations, process 600 also defines an automation action for the input event. More specifically, for example, the user can click on an “Accept” or “OK” button at the selection interface, and an image-based application automation system implementing process 600 can define an automation action for the input event which specifies the input event, the images associated with the input event, and the target.
If the user provides input that indicates the target should be changed, process 600 proceeds to 660 at which the image-based application automation system implementing process 600 selects an image based on the user input and designates that image as the target. For example,
Selection interface 700 can be displayed by an image-based application automation system in response to selection of an automation action by a user. For example, the image-based application automation system can display a list of automation actions at another interface (not shown), and the user can select (e.g., click on using a mouse) a representation of an automation action to cause the image-based application automation system to output selection interface 700.
As illustrated in
To designate image 310 as the target for this automation action, the user navigates cursor 740 to image 310 and clicks on image 310. In response, selection interface updates as illustrated in
Referring again to
Process 600 as illustrated in
Moreover, in some implementations, the image-based application automation system implementing process 600 does not output the selection interface as part of process 600. Said differently, for example, blocks 610, 620, 630, and 640 are part of a first process (or sub-process), and blocks 640, 650, and 660 are part of a second process (or sub-process). As a specific example, blocks 610, 620, 630, and 640 are executed as discussed above during a record phase of an image-based application automation system, and the image-based application automation system executes blocks 640, 650, and 660 in response to user input in parallel of asynchronously with respect to blocks 610, 620, 630, and 640. In other words, the image-based application automation system executes blocks 640, 650, and 660 when a user indicates (e.g., clicks a button using a mouse) that the user would like to designate an image as the target for an input event.
While certain implementations have been shown and described above, various changes in form and details may be made. For example, some features that have been described in relation to one implementation and/or process can be related to other implementations. In other words, processes, features, components, and/or properties described in relation to one implementation can be useful in other implementations. As another example, functionalities discussed above in relation to specific modules or elements can be included at different modules, engines, or elements in other implementations. Furthermore, it should be understood that the systems, apparatus, and methods described herein can include various combinations and/or sub-combinations of the components and/or features of the different implementations described. Thus, features described with reference to one or more implementations can be combined with other implementations described herein.
As used herein, the term “module” refers to a combination of hardware (e.g., a processor such as an integrated circuit or other circuitry) and software (e.g., machine- or processor-executable instructions, commands, or code such as firmware, programming, or object code). A combination of hardware and software includes hardware only (i.e., a hardware element with no software elements), software hosted at hardware (e.g., software that is stored at a memory and executed or interpreted at a processor), or at hardware and software hosted at hardware.
Additionally, as used herein, the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise. Thus, for example, the term “module” is intended to mean one or more modules or a combination of modules. Moreover, the term “provide” as used herein includes push mechanism (e.g., sending an interface description to a scanner via a communications path or channel), pull mechanisms (e.g., delivering an interface description to a scanner in response to a request from the scanner), and store mechanisms (e.g., storing an interface description at a data store or service at which a scanner can access the interface description). Furthermore, as used herein, the term “based on” includes based at least in part on. Thus, a feature that is described as based on some cause, can be based only on the cause, or based on that cause and on one or more other causes.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/US2012/022741 | 1/26/2012 | WO | 00 | 7/22/2014 |