Patent ID: 12210886

DETAILED DESCRIPTION

Testing automation can be used to test web applications and other programs. Irrespective of the technologies used to build a web application, the web application will emit an HTML form with a Document Object Model (DOM) structure. Since web applications are exposed in an HTML form and elements are visible, it is comparatively easy to read the elements and map them in test automation tools.

By contrast, in Desktop applications, such as Windows™ desktop or Java Swing™ applications, the parameters of user interface (UI) controls may be encoded (or formatted) using an encoding (or formatting) scheme that is specific to the technology used to create the user interface components (e.g., Oracle Forms, Java Swing, Windows Presentation Foundation (WPF), etc.). This makes the automation of UI test cases more difficult. Although there are available UI automation tools for desktop applications, these tools tend to provide UI test automation for one type of technology for creating UI controls, and they are not compatible with multiple technologies.

Some desktop UI test automation tools that are available on the market adopt a record-and-replay approach to the testing of UI controls. Such tools record user inputs that are made to the UI of an application and then replay the inputs. The user inputs are recorded by scraping the user interface of the application and capturing the attributes of UI controls that are part of the interface. However, in general, the recording of user inputs yields a large and complex body of information, which is difficult to use by software engineers. Most of the time, a software engineer will need only a small portion of the information that is recorded, and sifting through the entire body of information to locate the needed portion could be very time-consuming and difficult.

The present disclosure proposes a technique that captures only the properties of “required UI controls”, while omitting the capturing of unnecessary information, thus simplifying the whole testing automation process for desktop applications. In another aspect, the proposed technique is compatible with multiple technologies for the creation of user interfaces.

FIG.1is a diagram of an example of a computing device100, according to aspects of the disclosure. As illustrated, computing device100may include a processor110, a memory130, and communications interface(s)140. The processor110may include one or more of a general-purpose processor, a digital signal the processor (DSP), an application-specific integrated circuit (ASIC), a special-purpose processor, a field-programmable gate array (FPGA), and/or any other suitable type of processing circuitry. The memory130may include any suitable type of volatile or non-volatile memory, such as an electrically-erasable programmable read-only memory (EEPROM), dynamic random-access memory (DRAM), and/or any other suitable type of memory. The communications interface(s)140may include one or more of a radio transceiver, a modem, and/or any other suitable type of communications interface.

The processor110may be configured to execute an operating system112. The operating system112may include the Windows™ operating system, Linux, and/or any other suitable type of operating system. Inside the operating system112, the processor110may execute an application114and an integrated development environment (IDE)116. Application114may include a graphical user interface (GUI)113. The IDE116may be used to code, debug, and/or test the application114. The IDE116may include Visual Studio™, NetBeans™, and/or any other suitable type of IDE. According to the present example, the IDE116includes a text editor118and a UI control handle generator120(hereinafter “generator120”). The operation of the generator120is discussed further below with respect toFIGS.2-8. Although not shown inFIG.1, the IDE116may include an object browser, a debugger, and/or any other component that is commonly found in IDE tools.

The memory130may be configured to store a control script132, a repository class134, and a test class136. The control script132may identify properties of one or more UI controls of application114. The control script132is discussed further below with respect toFIGS.4-5. The repository class134may include a different respective handle for each (or at least some) of the UI controls whose properties are identified in the control script132. An example of repository class134is discussed further below with respect toFIG.6. The test class136may include one or more test cases that use handles for different UI controls in the user interface113, which are provided by the repository class134. An example of the test class136is discussed further below with respect toFIG.7.

FIG.2is a diagram illustrating aspects of the operation of the generator120, according to one possible implementation. As illustrated, the UI control handle generator120may include a control capture manager202(hereinafter “manager202”), a data adapter module204, a control script manager206(hereinafter “manager206”), and a test manager208(hereinafter “manager208”).

Manager202is responsible for capturing properties (e.g., Name, ID, etc.) of UI controls in user interface113of application114. In operation, the user may launch the application114. Next, the user may activate the generator120. Next, the manager202may detect a user input201that selects one of the UI controls in the user interface113. The user input201may include placing the mouse cursor over the UI control and pressing the lefthand button of the mouse. Next, manager202may identify which UI control of the user interface113has been selected. Next, manager202may retrieve the values of one or more properties203of the selected UI control. And finally, the manager202may provide the retrieved property values203to the data adapter module204. Manager202may be implemented in the same or similar manner as the interface of CodedUI™, which also includes a selection tool that displays the properties of a UI control in response to the user clicking on the UI control.

The data adapter module204may translate the property values203to produce translated property values205. The data adapter module204may provide the translated property values205to the manager206. As noted above, property values203may be formatted (and/or encrypted) in accordance with a format that is specific to the technology used to create the user interface113(e.g., Oracle Forms, Java Swing, WPF, etc.). The translated property values205may be formatted (and/or encrypted) in accordance with a format that is compatible with manager206(hereinafter “a uniform format”). In some respects, the data adapter module204may include a plurality of adapters, wherein each adapter is associated with a different technology for creating user interfaces. Each of the adapters may be configured to translate, into the uniform format, values that are formatted in accordance with the format of the adapter's respective technology.

In operation, the data adapter module204may receive the property values203. Next, the data adapter module204may identify a technology whose format the property values203are formatted in accordance with. Next, the data adapter module204may select one of the plurality of adapters that are associated with the technology whose format the property values203are formatted in accordance with. Next, the data adapter module204may use the selected adapter to translate into a uniform format the property values203and produce the property values205as a result. And finally, the data adapter module204may provide the translated values205to the manager206.

The manager206may be configured to receive the property values205. Next, manager206may generate a UI control definition based on the received property values205. Next, manager206may insert the UI control definition into the control script132. And finally, manager206may provide the control script132to manager208. In some implementations, the manager206may create (e.g., “initialize”) the control script132before inserting the UI control definition into the control script132.

Manager208may be configured to retrieve the UI control definition for the selected UI control from the control script132. Next, the manager208may generate a handle based on the control definition. The generated handle may include a function that returns an object referencing the selected UI control. Next, the manager208may insert the generated handle into the repository class134. And finally, the manager208may make the repository class134available for use by other components of the IDE116, such as the text editor118.

In text editor118, the user may type a test class including one or more test cases. At least one of the test cases may use the handle generated by the manager208to push test data onto the selected UI control.

In the present example, each of manager202, data adapter module204, manager206, and manager208is implemented in software. However, alternative implementations are possible in which any of manager202, data adapter module204, manager206, and manager208is implemented in hardware or as a combination of software and hardware. Although in the example ofFIG.2only one UI control of the user interface113is selected with manager202, it will be understood that in some instances more than one UI control may be selected. In such instances, the manager206may create a respective UI control definition for each of the selected UI controls, and insert it into the control script132. Moreover, based on the UI control definitions, the manager208may create a respective handle for each of the selected UI controls and insert it into the repository class134. In some implementations, the manager206may create (e.g., “initialize”) the control script132before inserting any UI control definitions into the control script132. In some implementations, the manager208may create (e.g., “initialize”) the repository class134before inserting any handles into the repository class134.

FIG.3is a diagram of an example of the user interface113, according to aspects of the disclosure. As illustrated, the user interface113may include a window301and UI controls302-316. UI control302may include a text box; UI control304may include a text box; UI control306may include a text box; UI control308may include a text box; UI control310may include a text box; UI control312may include a text box; UI control314may include a text box; and UI control316may include a button. According to the present example, UI controls302-316are instantiated within the memory space of window301. Under the nomenclature of the present disclosure, two UI controls are related if one of the controllers is instantiated within the memory space of the other. Under this nomenclature, each of the UI controls302-316is an “unrelated” UI control to any other one of UI controls302-316, and each of the UI controls302-316is a “related UI control” to window301. Although the UI controls that are shown inFIG.3include only textboxes and a button, it will be understood that the concepts and ideas presented throughout the disclosure can be applied to any type of UI control, such as a button, a checkbox, a combo box, a label, a list, and/or a scrollbar.

FIG.4is a diagram of an example of the control script132, according to one implementation. As illustrated, the control script132may include a plurality of UI control definitions402that correspond to different respective UI controls in the user interface113of the application114. In addition, the control script132may include a definition404corresponding to the window301and a definition406that corresponds to the application114. Each of the UI control definitions402may identify a different respective one of the UI controls302-316in the user interface113. Each of the UI control definitions402may identify the values of one or more properties of the definition's respective UI control. Definition404may identify the values of one or more properties of window301. Definition406may identify the values of one or more properties of application114. In some respects, the control script132may include all (or at least some) of the information that is necessary for a testing function to target UI controls whose definitions are present in the control script132. Examples of specific testing functions are discussed further below with respect toFIG.7.

FIG.5is a partial view of an example of the control script132, according to one implementation. As illustrated, the control script132may include UI control definitions510-530.

UI control definition510may correspond to UI control302. UI control definition510may include portions512and514. Portion512may include an identifier that is assigned to the UI control302(or the definition510) by the generator120. Optionally, the assigned identifier may exist within the naming space of the control script132, but not within the naming space of the user interface113(or application114). The assigned identifier may be used by the repository class134for the purpose of referencing the data that is included in portion514. Portion514may identify the values of one or more properties of the UI control302. For each of the identified properties, portion514may contain an indication of the type of the property and an indication of the value of the property. As illustrated, portion514may identify the name of the UI control302by which the UI control is referred to within the namespace of application114(or user interface113). In addition, portion514may identify the technology name and type of the UI control302.

UI control definition520may correspond to UI control304. UI control definition520may include portions522and524. Portion522may include an identifier that is assigned to the UI control304(or the definition520) by the generator120. Optionally, the assigned identifier may exist within the naming space of the control script132, but not within the naming space of the user interface113(or application114). The assigned identifier may be used by the repository class134for the purpose of referencing the data that is included in portion524. Portion524may identify the values of one or more properties of the UI control304. For each of the identified properties, portion524may contain an indication of the type of the property and an indication of the value of the property. As illustrated, portion524may identify the name of the UI control304by which the UI control is referred to within the namespace of application114(or user interface113). In addition, portion524may identify the technology name and type of the UI control304.

UI control definition530may correspond to UI control312. UI control definition530may include portions532and534. Portion532may include an identifier that is assigned to the UI control312(or the definition530) by the generator120. Optionally, the assigned identifier may exist within the naming space of the control script132, but not within the naming space of the user interface113(or application114). The assigned identifier may be used by the repository class134for the purpose of referencing the data that is included in portion534. Portion534may identify the values of one or more properties of the UI control312. For each of the identified properties, portion534may contain an indication of the type of the property and an indication of the value of the property. As illustrated, portion534may identify the name of the UI control312by which the UI control is referred to within the namespace of application114(or user interface113). In addition, portion534may identify the technology name and type of the UI control312.

In the example ofFIG.5, the properties whose values are identified in each of definitions510-530include Name, TechnologyName, and Control type. However, alternative implementations are possible in which the values of any of those properties are omitted from one or more of definitions510-530. Additionally or alternatively, in some implementations, the values of other properties may be inserted in any of definitions510-530, such as ControlType, Name, FriendlyName, ID, TechnologyName, and Class for example.

FIG.6is a diagram of repository class134, according to aspects of the disclosure. According to the present example, the repository class134is generated by the generator120based on the control script132. As illustrated, the repository class134may include handles610-630.

Handle610may be generated, by generator120, based on UI control definition510. Handle610may be an accessor function that returns a WinEdit object (or another object) that references UI control302, and which is generated based on the property values of UI control302that are listed in the UI control definition510. As illustrated, handle610references the property values for UI control302by the ID512, which is generated by generator120, and which is assigned (or mapped) to UI control definition510in the control script132. In other words, in some implementations, the repository class134may import the namespace of the control script132, which allows the handle610(as well as other handles) to reference the property values for a control by an identifier for the control that is unique, and/or which is assigned to the control by the generator120when the control script132is generated.

Handle620may be generated, by generator120, based on UI control definition520. Handle620may be an accessor function that returns a WinEdit object (or another object) that references UI control304, and which is generated based on the property values of UI control304that are listed in the UI control definition520. As illustrated, handle620references the property values for UI control304by the ID522, which is generated by generator120, and which is assigned (or mapped) to UI control definition520in the control script132.

Handle630may be generated, by generator120, based on UI control definition530. Handle630may be an accessor function that returns a WinEdit object (or another object) that references UI control312, and which is generated based on the property values of UI control312that are listed in the UI control definition530. As illustrated, handle630references the property values for UI control312by the ID532, which is generated by generator120, and which is assigned (or mapped) to UI control definition530in the control script132.

As used throughout the disclosure, the term “handle” shall refer to a function or other code that, at least in part, returns an object for handling a UI control. Although the term “handle” could conceivably refer to the object that is being returned, under the nomenclature of the present disclosure, the term “handle” refers to code that, at least in part, provides access to the object, and which can be invoked in test cases to gain access to the object.

In addition, the repository class134may include a line601where the parent window identification starts. Although not shown, in some implementations, the repository class134may include a line importing the namespace of the control script132.

FIG.7is a diagram of the test class136, according to one implementation. As illustrated, test class136includes a test case702. The test case702may include lines710-730.

Line710is a call to a test function SendKeys which pushes test string “Oscar” on the UI control302. The test function takes as a parameter a reference to the UI control302, which is obtained by calling handle610, as well as the string “Oscar”. Executing the SendKeys function causes the UI control302to behave as if a user has manually typed the string “Oscar” in the UI control302.

Line720is a call to the test function SendKeys which pushes the test string “1 Elm St.” on the UI control304. The test function takes as a parameter a reference to the UI control304, which is obtained by calling handle620, as well as the string “1 Elm St.”. Executing the SendKeys function causes the UI control304to behave as if a user has manually typed the string “1 Elm St.” in the UI control304.

Line730is a call to the test function SendKeys which pushes test number “401.001.0001” on the UI control312. The test function takes as a parameter a reference to the UI control312, which is obtained by calling handle630, as well as the number “401.001.0001”. Executing the SendKeys function causes the UI control312to behave as if a user has manually typed the string “401.001.0001” in the UI control312.

According to the example ofFIG.7, the test function in each of lines710-730is a function that emulates the typing of text into a textbox. However, alternative implementations are possible in which the test case702includes calls to other types of test functions, such as a test function that emulates the checking of a checkbox, a function that emulates the pressing of a button, a function that emulates the hovering of a mouse cursor over a particular location, and/or any other test function. In the example ofFIG.7, the test functions used by the test case702include test functions that are provided by the CommonMethods class of CodedUI™, alternative implementations are possible in which any suitable type of test function API is used.

FIG.8is a flowchart of an example of a process800, according to aspects of the disclosure.

At step802, the computing device100executes the application114and displays the user interface113of the application114.

At step804, the computing device100detects user input for activating the generator120. The user input may include opening a menu of plugins that are available for the IDE116and selecting, from the menu, a menu item that corresponds to the generator120. In response to the user input for activating the generator120, the computing device100executes the generator120.

At step806, the computing device100detects user input selecting one or more UI controls that are part of the user interface113. In some implementations, the user may select a control in the user interface113by activating a selection tool that is part of the user interface of generator120and clicking on the UI control that the user wishes to select. In some implementations, the user may select multiple UI controls of the user interface113by clicking on the UI controls.

At step808, the generator120retrieves the respective properties of the selected UI controls. Specifically, for each of the selected UI controls, the generator120may receive data that identifies the value and/or type of one or more properties of the UI control. In some implementations, the generator120may use a data adapter to convert the data set from a technology-specific format to a uniform format. The data adapter may be part of a data adapter module, such as the data adapter module204, which is discussed above with respect toFIG.2.

At step810, the generator120generates a control script based on the respective properties of the UI controls, which are retrieved at step808. The generated control script may be the same or similar to the control script132, which is discussed above with respect toFIG.5. The generated control script may include a different respective UI control definition for each of the UI controls selected at step806. Any of the UI control definitions may be the same or similar to one or more of UI control definitions510-530, which are discussed above with respect toFIG.5. Generating the control script may include: (i) instantiating a script file, (ii) generating a plurality of UI control definitions, and (iii) including each of the generated UI control definitions into the script file. The script file may include a JSON file, a markup language file, a text file, and/or any other suitable type of file. Generating any of the UI control definitions may include: (i) identifying one of the UI controls (selected at step806), (ii) instantiating a new UI control definition for the identified UI control, (iii) assigning an identifier to the identified UI control (or instantiated control definition), (iv) inserting the assigned identifier in a first portion of the instantiated UI control definition, (v) obtaining property values of the identified UI control, which are retrieved at step808, and (vi) inserting the obtained property values into a second portion the instantiated UI control definition. The first portion of each instantiated UI control definition may have the same or similar format and/or content to any of portions512,522, and532, which are discussed above with respect toFIG.5. The second portion of each instantiated UI control definition may have the same or similar format and content to any of portions514,524, and534, which are discussed above with respect toFIG.5.

At step812, the generator120generates a repository class based on the control script (generated at step810). The generated repository class may be the same or similar to repository class134, which is discussed above with respect toFIG.6. The generated repository class may include a plurality of handles. Each of the handles may correspond to a different one of the UI controls (selected at step806). Each of the handles may be configured to return an object referencing the handle's corresponding UI control, which can be used by a test function to push a particular input on the corresponding UI control. Each of the handles may be generated based on the UI control definition (for the handle's corresponding UI control), which is provided in the control script (generated at step812).

At step814, the computing device100outputs an indication that the repository class has been generated, and is available for use in various test cases.

In some implementations, the repository class (generated at step812) may include only handles for UI controls that are selected at step806. For instance, if the user selects UI controls302and304, the repository class would include handles for UI controls302and304. On the other hand, if the user does not select UI controls306and308, handles for UI controls306and308may be absent from the repository class. Additionally or alternatively, in some implementations, the repository class may include handles for UI controls that are related to the selected UI controls, but which are not selected (such as a handle for the window301). Additionally or alternatively, in some implementations, the repository class may not include handles for UI controls that are unrelated to the selected UI controls, and which are themselves not selected. As noted above, limiting the repository class to including only the handles for selected UI controls (and possibly UI controls that are related to the selected UI controls) is advantageous because it simplifies the structure of the repository class, thus increasing the efficiency at which the repository class can be used by software engineers to test the application114.

In some implementations, the control script (generated at step810) may include only UI control definitions for UI controls that are selected at step806. For instance, if the user selects UI controls302and304, the control script would include handles for UI controls302and304. On the other hand, if the user does not select UI controls306and308, definitions for UI controls306and308may be absent from the control script. Additionally or alternatively, in some implementations, the control script may include also include definitions for UI controls that are related to the selected UI controls, but which are not selected. Additionally or alternatively, in some implementations, the control script may not include handles for UI controls that are unrelated to the selected UI controls, and which are themselves not selected.

FIGS.1-8are provided as an example only. At least some of the steps discussed with respect toFIGS.1-8can be performed in a different order, in parallel, or altogether omitted. Although in the example ofFIGS.1-8the generator120is an IDE plugin, alternative implementations are possible in which the generator120is implemented as a standalone application. Although in the example ofFIG.1-8user interface components are selected by clicking on the UI controls (e.g., see step806ofFIG.8), alternative implementations are possible in which they are selected by any other input action (e.g., typing the names of UI controls that are desired to be selected, etc.). The term “UI control definition” may refer to any object, number, string, alphanumerical string, or another entity or set of entities, that identifies the values of one or more properties of a UI control. The terms “control script” or “control file” may refer to any file that includes a control definition.

For example, and without limitation, the phrase “generating a control file including one or more UI control definitions” may refer to at least one of: (i) instantiating a new file and inserting one or more newly-generated UI control definitions in the new file, or (ii) inserting one or more newly-generated UI control definitions into a pre-existing file. The pre-existing file may be empty or it may include other UI control definitions and/or other content.

For example, and without limitation, the phrase “generating a repository class including one or more handles” may refer to at least one of: (i) instantiating a new class and inserting one or more newly-generated handles into the new class, or (ii) inserting one or more newly-generated handles into a pre-existing class. The pre-existing class may be empty or it may include other handles and/or other content.

The term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form.

To the extent directional terms are used in the specification and claims (e.g., upper, lower, parallel, perpendicular, etc.), these terms are merely intended to assist in describing and claiming the invention and are not intended to limit the claims in any way. Such terms do not require exactness (e.g., exact perpendicularity or exact parallelism, etc.), but instead it is intended that normal tolerances and ranges apply. Similarly, unless explicitly stated otherwise, each numerical value and range should be interpreted as being approximate as if the word “about”, “substantially” or “approximately” preceded the value of the value or range.

Moreover, the terms “system,” “component,” “module,” “interface,”, “model” or the like are generally intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a controller and the controller can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.

Although the subject matter described herein may be described in the context of illustrative implementations to process one or more computing application features/operations for a computing application having user-interactive components the subject matter is not limited to these particular embodiments. Rather, the techniques described herein can be applied to any suitable type of user-interactive component execution management methods, systems, platforms, and/or apparatus.

While the exemplary embodiments have been described with respect to processes of circuits, including possible implementation as a single integrated circuit, a multi-chip module, a single card, or a multi-card circuit pack, the described embodiments are not so limited. As would be apparent to one skilled in the art, various functions of circuit elements may also be implemented as processing blocks in a software program. Such software may be employed in, for example, a digital signal processor, micro-controller, or general-purpose computer.

Some embodiments might be implemented in the form of methods and apparatuses for practicing those methods. Described embodiments might also be implemented in the form of program code embodied in tangible media, such as magnetic recording media, optical recording media, solid-state memory, floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the claimed invention. Described embodiments might also be implemented in the form of program code, for example, whether stored in a storage medium, loaded into and/or executed by a machine, or transmitted over some transmission medium or carrier, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the claimed invention. When implemented on a general-purpose processor, the program code segments combine with the processor to provide a unique device that operates analogously to specific logic circuits. Described embodiments might also be implemented in the form of a bitstream or other sequence of signal values electrically or optically transmitted through a medium, stored magnetic-field variations in a magnetic recording medium, etc., generated using a method and/or an apparatus of the claimed invention.

It should be understood that the steps of the exemplary methods set forth herein are not necessarily required to be performed in the order described, and the order of the steps of such methods should be understood to be merely exemplary. Likewise, additional steps may be included in such methods, and certain steps may be omitted or combined, in methods consistent with various embodiments.

Also, for purposes of this description, the terms “couple,” “coupling,” “coupled,” “connect,” “connecting,” or “connected” refer to any manner known in the art or later developed in which energy is allowed to be transferred between two or more elements, and the interposition of one or more additional elements is contemplated, although not required. Conversely, the terms “directly coupled,” “directly connected,” etc., imply the absence of such additional elements.

As used herein in reference to an element and a standard, the term “compatible” means that the element communicates with other elements in a manner wholly or partially specified by the standard, and would be recognized by other elements as sufficiently capable of communicating with the other elements in the manner specified by the standard. The compatible element does not need to operate internally in a manner specified by the standard.

It will be further understood that various changes in the details, materials, and arrangements of the parts which have been described and illustrated in order to explain the nature of the claimed invention might be made by those skilled in the art without departing from the scope of the following claims.