JP7294609B2 - Program, Method, and Device for Supporting Software Operation Scenario Generation - Google Patents

Description

Application of Article 30, Paragraph 2 of the Patent Act July 3, 2018 Microsoft Corporation's Visual Studio Marketplace website "https://marketplace.visualstudio.com/items?itemName=Codeer.TestAssistantP Opened to the public through ro July 2018 Released on Codeer, Inc.'s website "https://www.codeer.co.jp/" and "https://www.codeer.co.jp/Tools/TestAssistantPro" July 4, 2018 Published via GitHub, Inc. website "https://github.com/Codeer-Software/TestAssistantPro" and "https://github.com/Codeer-Software/TestAssistantPro.Samples" July 5 and 6, 2018 Released at ET & IoT Technology West 2018 September 28, 2018 Released at Developers Summit 2018 KANSAI November 10, 2018 Released at Wankuma Alliance Osaka Study Group #74 December 22, 2018 Meetup app Published on osaka@3 January 26, 2019 Published on BuriKaigi 2019 February 19, 2019 Hatena Blog website http://ishikawa-tatsuya.hatenablog.com/entry/2019/02/19/ 123109” February 21, 2019 Released at the 3rd Friendly Study Group March 8, 2019 For desktop applications. NET Core 3 compatible seminar March 10, 2019 Library for test automation "Friendly" Study Meeting at Tokyo vol1. Released on May 29th and 30th, 2019 at de:code 2019

TECHNICAL FIELD The present disclosure relates to generation of operation scenarios for software, and more particularly to technology for supporting generation of operation scenarios for graphical user interfaces.

Many applications are installed in devices such as PCs (Personal Computers), smart phones, and tablets. Applications installed on these devices are called native applications. These native applications typically include a GUI (Graphical User Interface). A GUI is a user interface that has an input form, buttons, etc., and can be operated visually and intuitively.

Furthermore, in recent years, web applications have been widely used due to the speeding up of networks and the development of cloud computing. In a web application, the server distributes the screen of the web application to the user's device. The user can use the functions of the web application by operating the distributed screen. Such web application screens are often visually displayed by a browser.

As described above, in recent years, many software often include a GUI. In the following description, native applications including GUIs and web applications are collectively referred to as "GUI applications". A programmer needs to test the developed GUI application and the internal operation of the application based on the operation of the GUI application.

There are roughly two types of automatic testing methods for GUI applications. An operation scenario refers to a series of processes that sequentially execute operation codes of multiple applications. In the following description, the operational code and operational scenarios used to test the application are referred to as "test code" and "test scenario", respectively. The method of creating a handwritten test scenario has the advantage of being able to create a highly readable test scenario, but on the other hand, it has the problem that the number of programmers who can create the test scenario is limited. The second method is to use GUI-operated capture and replay software. This method has the advantage of being less difficult to work than the method of preparing handwritten test code, but on the other hand, the test code generated by the capture replay software is less readable and less maintainable. I had a problem. Therefore, a more efficient GUI test method is required.

In addition, the efficiency of IT (Information Technology) operations is accelerating in recent years. For this reason, so-called RPA (Robotic Process Automation), which is the automation of tasks in which staff input and output data using GUI applications, is progressing. Also in RPA, there is a demand for means for efficiently creating operation scenarios for GUI applications.

Regarding a method of creating a GUI operation scenario, for example, Japanese Patent Application Laid-Open No. 2011-048714 (Patent Document 1) discloses that "a common format scenario added with a command for detecting the specified state of a graphical user interface is generated by a graphical user interface. changing to a command in a format corresponding to the interface and instructing; determining whether the state of the graphical user interface is the specified state; (see [Abstract]).

JP 2011-048714 A

According to the technique disclosed in Patent Document 1, it is not possible to efficiently generate an operation scenario with high readability and maintainability. Therefore, there is a need for techniques that efficiently generate highly readable and maintainable operational scenarios.

The present disclosure has been made in view of the background as described above, and an object in one aspect is to provide a technique for efficiently generating an operation scenario with high readability and maintainability.

According to one embodiment, a program for controlling a computer is provided. This program includes one or more controls in a computer, and includes a step of acquiring GUI (Graphical User Interface) information displayed on a monitor of the computer, and one or more control drivers that respectively operate each of the one or more controls. selecting a control to be captured from among the one or more controls based on the acquired GUI information and the one or more control drivers; and selecting the selected control captures the received operation; and generates an operation code corresponding to any one of the one or more control drivers based on the result of the capture.

In one aspect, each of the one or more control drivers is a class that operates each of the one or more controls externally. A GUI driver is a class that includes one or more control drivers as properties, and associates each of the one or more control drivers with information specifying each of the one or more controls included in the GUI information. Operational code includes any method or property of one or more control drivers.

In one aspect, the one or more control drivers includes a user-defined custom control driver.

In one aspect, the program further causes the computer to load an external program including one or more control drivers.

In one aspect, the program instructs the computer to call an operation code generation program corresponding to each of the one or more control drivers; and receiving an operation code generated by the code generation program.

In one aspect, the program further causes the computer to generate a confirmation code for confirming the output result of executing the operation code. The verification code includes any method or property of one or more control drivers.

According to another embodiment, a method of generating operation code for software is provided. The method includes the steps of acquiring information of a GUI displayed on a computer monitor, including one or more controls, and selecting a GUI driver including one or more control drivers respectively operating each of the one or more controls. A step of selecting a control to be captured from among one or more controls based on the step, the acquired GUI information, and one or more control drivers, and capturing the operation received by the selected control. and generating opcodes corresponding to any of the one or more control drivers based on the results of the capture.

According to another embodiment, an apparatus is provided for generating operation code for software. This device includes an input section that receives operations from a user, a display section that displays a GUI, a memory that stores one or more GUI drivers, and a control section. The control unit acquires GUI information including one or more controls displayed on the display unit, refers to the memory, and selects a GUI driver including one or more control drivers for operating each of the one or more controls. Then, based on the acquired GUI information and one or more control drivers, select a control to be captured from among one or more controls, and capture the operation received by the selected control from the input section. , based on the results of the capture, generate opcodes corresponding to any of the one or more control drivers.

According to the present technology, it is possible to efficiently generate a software operation scenario with high readability and maintainability.

The above and other objects, features, aspects and advantages of the present invention will become apparent from the following detailed description of the invention taken in conjunction with the accompanying drawings.

FIG. 4 is a diagram showing an example of an overview of test scenario generation by an automation support program according to an embodiment; FIG. 2 is a diagram illustrating an example of a hardware configuration of device 100; FIG. It is a figure which shows an example of a structure of the automation support program according to one embodiment. 4 is a diagram showing an example of a native application 400 running on a PC; FIG. 3 is a diagram showing a first example of a GUI driver 301; FIG. 6 is a diagram showing an example of a GUI 600 of a web application; FIG. FIG. 10 is a diagram showing a second example of the GUI driver 301; FIG. 10 is a diagram showing an example of an outline of the operation of the capture generator 303; FIG. It is a figure which shows an example of a test scenario. FIG. 10 is a diagram showing an example in which the generated test scenario 1001 is pasted on an editor or the like; 4 is a diagram showing an example of a communication processing procedure of the automation support program 300; FIG. 4 is a diagram showing an example of a test scenario generation processing procedure of the automation support program 300; FIG.

Hereinafter, embodiments of the technical concept according to the present disclosure will be described with reference to the drawings. In the following description, the same parts are given the same reference numerals. Their names and functions are also the same. Therefore, detailed description thereof will not be repeated.

In the following description, procedures for creating test codes and test scenarios for GUI applications by the automation support program according to this embodiment will be described. Operation codes and operation scenarios for RPA (for automating operations of GUI applications) can also be created in the same procedure, except that verification codes are unnecessary.

FIG. 1 is a diagram showing an example of an overview of test scenario generation by an automation support program according to this embodiment. The automation support program according to the present embodiment is for supporting testing of GUIs included in applications, and can generate test scenarios with excellent readability and maintainability with less man-hours than before.

The automation support program may operate alone or in cooperation with other software. As an example, the other software may be an editor for application development or an integrated development environment (hereinafter referred to as an IDE (Integrated Development Environment)). In one aspect, the automation support program may be provided as a web application. In the following description, an example in which the automation support program cooperates with the IDE to generate a test scenario for the application 102 will be described.

Device 100 executes an automation support program. In one aspect, device 100 may be a PC, workstation, tablet, smartphone, or the like. In other aspects, device 100 may be a device or the like that is virtually configured on a server or cloud.

The IDE 101 is development software having functions necessary for application development, such as an editor, debugger, and compiler. The IDE 101 can extend its functions by reading software or files called plug-ins or extensions. In this embodiment, the automation support program will be described as being linked with the IDE 101 as a plug-in, but the implementation method of the automation support program is not limited to this. In a certain aspect, the automation support program may be software started separately from the IDE 101, or the automation support program and the IDE 101 may be provided as one application.

Application 102 is a pre-developed application under test and includes a GUI. Application 102 is test-executed by device 100 . In one aspect, application 102 may be a standalone native application running on a PC or the like. In other aspects, application 102 may be a native application including a GUI running on a device such as a smart phone or tablet emulated on device 100 . In other aspects, application 102 may be a front portion of a web application that runs on software that displays HTML (Hyper Text Markup Language), such as a browser.

The GUI of the application 102 includes various components such as operable text boxes, buttons and pulldowns. In this embodiment, these parts are called controls. In one aspect, controls also include various components such as text boxes, buttons, and pull-downs rendered in HTML for web applications.

The application 102 is often expressed as a panel on which the above controls are pasted, and a component that serves as a frame to which these controls are pasted is sometimes called a window. These frame components can also be nested. The application 102 can be implemented by combining these controls with frame components such as windows. A web application may include a component corresponding to a frame such as a window configured by HTML tags.

The procedure for testing the application 102 is roughly divided into three steps: driver creation, capture, and test scenario execution. These three procedures are outlined below.

(Procedure 1 Create a driver)
Software that operates the application 102 is called a driver here. In one aspect, a driver may be a class defined in some programming language. More specifically, the driver includes a control driver corresponding to each control and a GUI driver (window driver) corresponding to each window or each GUI. Hereinafter, as an example, the driver will be described as being a class.

First, the user must provide or define a GUI driver that corresponds to the GUI of application 102 . The automation assistant program may provide semi-automatic generation or full auto-generation functionality for GUI driver creation.

Control drivers correspond to individual controls included in the GUI of application 102 . More specifically, the control driver can externally manipulate the controls of other applications. A control driver internally includes methods or properties for manipulating controls corresponding to the control driver. The automation support program can externally manipulate each control of the application 102 by calling the methods or properties of the control driver. As an example, a button control driver can manipulate buttons in other applications. Besides buttons, multiple control drivers can be defined that correspond to arbitrary controls such as text boxes, labels, checkboxes and radio buttons.

In one aspect, a plurality of control drivers corresponding to all or some of the controls that can be used by an application running on a specific OS may be defined as classes in advance. In another aspect, each of a plurality of control drivers corresponding to each of all or some of the controls that may be used in the web application may be pre-defined as a class.

A GUI driver may correspond to a separate GUI of the application under test. As an example, when the application 102 includes GUI(1), GUI(2) and GUI(3) as operation screens, GUI drivers corresponding to each of GUI(1), GUI(2) and GUI(3) are can be defined.

A GUI driver can include, as properties or methods, one or more control drivers corresponding to one or more controls included in the GUI corresponding to the GUI driver. A GUI driver may contain a control driver as a property of the class. As an example, it is assumed that GUI driver (A) is compatible with GUI (A). If GUI (A) includes controls (X), (Y), and (Z), GUI driver (A) creates control drivers (X) corresponding to controls (X), (Y), and (Z), respectively. , (Y), (Z) as properties. By including these control drivers (X) to (Z), the GUI driver (A) can operate various controls (X) to (Z) included in the GUI (A). Additionally, a GUI driver may contain other GUI drivers as properties or methods. In one aspect, suppose there is a GUI driver (N) that corresponds to a screen portion (N) of the GUI under test (M). In this case, a GUI driver (M) corresponding to GUI (M) may include GUI driver (N) as a property or method. That is, the GUI driver (M) corresponding to the entire screen can include the GUI driver (N) corresponding to part of the screen.

The GUI driver does not need to include control drivers corresponding to each of all the controls included in the corresponding GUI, and may include only control drivers corresponding to some controls included in the GUI. As an example, the GUI driver (A) may include the control drivers (X) to (Z) as properties, but may include only the control driver (X) which is a part thereof.

Furthermore, the GUI driver associates information for designating each control of the application 102 with each control driver. As an example, if the application 102 uses Microsoft (registered trademark) WPF (Windows Presentation Foundation) function, information about WPF can be used as information for designating each control. In the case of a web application, an ID (Identifier) or the like specified in an HTML tag can be used as information for specifying each control.

In a certain aspect, information for specifying each control may be passed as an argument to each control driver, but the method of association is not limited to this. Information for designating each control can be associated with each control driver by any method.

As described above, the GUI driver can hide the "information for designating each control" by associating the information for designating each control with each control driver. The test code described below includes methods or properties of the control driver included in the GUI driver. Therefore, even if the GUI specifications are changed, the user can use the test code simply by changing the description inside the GUI driver, and the test code has extremely high maintainability.

Furthermore, the control driver can hide the "processing that directly manipulates the control" as a method. The user can freely define the instance name, method name, etc. of the control driver. Therefore, the test code containing the control driver's methods or properties is extremely readable.

In some aspects, the control driver may be provided in a reusable form, included in a library or externally linked. A user may utilize these provided control drivers to define a GUI driver that corresponds to the GUI of application 102 . Additionally, users can define their own control drivers. You can define a control driver that contains your own defined methods for any control. A control driver can manipulate any control by including these user-defined custom control drivers.

In another aspect, the automation support program may automatically generate a GUI driver based on information for designating each control and a control driver prepared in advance.

The automation support program may use, for example, the library Friendly provided by Codeer, or Selenium to acquire information for designating each control. The automation support program may incorporate these pieces of software inside, or may cooperate with these pieces of software. The user may use the generated GUI driver as it is or edit it. Examples of specific GUIs, control drivers, and GUI drivers will be described later.

(Step 2 Capture)
The user then prepares a test scenario for testing the GUI of application 102 . The automation support program provides a capture function for creating test scenarios. Capturing here means acquiring the state of each control of the GUI under test. The state can include the occurrence of an event or a change in data related to each control (such as a value entered in an input form).

As mentioned above, test scenarios include test code. The test code defines the manipulation and validation code for controls contained in the GUI of application 102 . A test scenario can include any user-defined code in addition to the test code that defines the manipulation and validation code for these controls. As an example, assume that there is a test scenario (T1) in which test codes (A), (B), and (C) are executed in order. Test code (A) has a function of writing some character string in text box (A). Test code (B) has the function of writing an e-mail address in text box (B). The test code (C) has the function of pushing the send button (C). In this case, the test scenario (T1) sets the mail text and the destination address for the GUI of the application 102, and sends the mail.

The user can manually write the test scenario (T1) including these test codes (A) to (C), but manually creating the test scenario increases the programmer's man-hours. Therefore, the automation support program provides a function of capturing GUI operations of the application 102 and generating test code corresponding to the operations.

In one aspect, when the automation assistant program captures manipulation of the GUI of application 102, it may use Friendly or Selenium or the like to obtain information about the manipulated controls.

The automation assistant program generates test code based on the control driver based on the capture results. More specifically, it generates test code that calls methods or properties contained in the control driver's class. As an example, if a button included in the GUI of application 102 is pressed, the automation support program generates test code for pressing the button. This test code calls the "method for executing the button press operation" of the "control driver class corresponding to the button".

As described above, the test code generated by the automation support program includes the methods or properties of the control driver (class), so it has extremely high readability compared to the test code generated by conventional capture and replay software. Furthermore, since the GUI driver hides the information for designating each control, the test code has high maintainability. The automation assistant presents the user with a test scenario containing multiple test codes generated based on a series of captured results. A specific test code example will be described later.

(Step 3 Execution of test scenario)
The user then causes the device 100 to run the test scenario to check the operation of the application 102 . The device 100 can execute test scenarios generated by automation support programs as well as handwritten test scenarios.

In one aspect, the test scenarios generated by the automation support program may be executed by a programming editor, IDE, console application, or the like. In other aspects, an automated assistant program may execute the test scenario.

FIG. 2 is a diagram showing an example of the hardware configuration of the device 100. As shown in FIG. The hardware configuration of the device 100 and the functions of each configuration will be described with reference to FIG. Device 100 is, for example, a PC or workstation, as described above. A user uses device 100 to perform a test of application 102 .

The device 100 includes a control device 201 , a RAM (Random Access Memory) 202 , an input interface 203 , an output interface 204 , an external device interface 205 , a communication interface 206 and a storage device 207 .

A control device 201 controls the device 100 and executes an automation support program, an application 102, various programming tools, and the like. The control device 201 is composed of, for example, at least one integrated circuit. The integrated circuit is composed of, for example, at least one CPU (Central Processing Unit), at least one ASIC (Application Specific Integrated Circuit), at least one FPGA (Field-Programmable Gate Array), or a combination thereof.

The RAM 202 stores programs executed by the control device 201 and data referred to by the control device 201 . In some aspects, dynamic random access memory (DRAM) or static random access memory (SRAM) may be used as RAM 202 . The control device 201 reads the application 102, the automation support program, other programming tools, etc. from the RAM 202 and executes them.

Input interface 203 may be connected to any input device such as a keyboard, mouse or gamepad. In one aspect, a USB (Universal Serial Bus) terminal, a PS/2 terminal, a Bluetooth (registered trademark) module, or the like may be used as the input interface 203 . A user inputs a capture execution command or the like for the automation support program to the device 100 via the input interface 203 .

The output interface 204 can be connected to any output device such as a CRT display, a liquid crystal display, or an organic EL (electro-luminescence) display. In some aspects, a USB (Universal Serial Bus) terminal, a D-sub terminal, a DVI terminal, an HDMI (registered trademark) terminal, or the like may be used as the output interface 204 . The user confirms the operation of the application 102 by confirming the application 102 displayed on the liquid crystal display or the like, the execution result of the test scenario, and the like via the output interface.

The external device interface 205 can be connected to arbitrary external devices such as printers, scanners, and external HDDs (Hard Disk Drives). In one aspect, a USB (Universal Serial Bus) terminal or the like may be used as the external device interface 205 .

The communication interface 206 is connected to wired or wireless network equipment. In some aspects, a wired LAN (Local Area Network) port, a Wi-Fi (registered trademark) module, or the like may be used as communication interface 206 .

The storage device 207 is a non-volatile storage medium and can retain data even after the power of the device 100 is turned off. The storage device 207 stores programs executed by the control device 201 and data referred to by the control device 201 . In one aspect, HDDs and SSDs (Solid State Drives) may be used as the storage device 207 . GUI drivers, test scenarios, etc. generated by the automation support program can be stored in the storage device 207 .

FIG. 3 is a diagram showing an example of the configuration of automation support program 300 according to the present embodiment. The automation support program 300 includes a GUI driver 301 , a control driver 302 and a capture generator 303 .

The GUI driver 301 is a class corresponding to the individual GUI of the application to be tested, as described above. A GUI driver 301 is created for each GUI of an application to be tested. Therefore, GUI drivers 301 can be automatically or manually generated for the number of GUIs of the application to be tested. In one aspect, the automation support program 300 may load all or part of the GUI driver 301 as an external program.

Control drivers 302 are classes that correspond to individual controls that may be included in the GUI, as described above. Multiple control drivers 302 may be predefined, one for each of all controls used by an application or web application running on a particular OS. In one aspect, automation support program 300 may load control driver 302 as an external program. For example, the control driver 302 supports general-purpose components such as various controls, and is incorporated into a DLL (Dynamic Link Library) or the like and used as an external program, thereby improving user convenience.

Capture generator 303 is a program that generates test code and can be defined for each control. Each capture generator 303 corresponds to each control driver 302 respectively. As an example, button capture generator 303 corresponds to button control driver 302 . As another example, the textbox capture generator 303 corresponds to the textbox control driver 302 .

The user can also independently define the capture generator 303 as well as the control driver 302 . Automation assistant program 300 may use any user-defined control driver 302 and capture generator 303 .

The capture generator 303 generates test code corresponding to the operation when a control included in the GUI of the application under test is operated. In one aspect, automation assistant program 300 may send capture generator 303 to the application under test. In this case, when a control included in the GUI of the application under test is operated (when an event occurs or data associated with the control changes), the capture generator 303 is executed within the application under test. The capture generator 303 generates test code and transmits the test code to the automation support program 300 .

In other aspects, the automation assistant program 300 may utilize features of software such as Friendly or Selenium to constantly monitor changes in data related to event generation or control of the application under test. In this case, when a control included in the GUI of the application under test is operated (when an event occurs or data related to the control changes), the automation support program 300 causes the capture generator 303 to respond to the operation. Generate test code to

Next, details of the GUI of the application under test, the GUI driver 301 and the control driver 302 will be described with reference to FIGS. 4 to 7. FIG. Although native applications and web applications that run on PCs are exemplified in the following description, similar techniques can be applied to GUI applications that run on other devices such as tablets and smartphones.

FIG. 4 is a diagram showing an example of a native application 400 running on a PC. The native application 400 includes, as part of its controls, a name text box 401, a calendar 402, a number input box 403, an email text box 404, a language selection pull-down menu 405, and a gender selection radio button 406. , an entry button 407 and a cancel button 408 . Labels such as Name and Birthday of the native application 400 and menus at the top of the screen are also controls, but they are not related to the following description and will not be described in detail.

Text boxes 401 and 404 accept input of character strings. Calendar 402 accepts an operation to select a date. The number input box 403 accepts input of numerical values, and includes buttons for counting up and counting down numerical values. Pull-down menu 405 accepts a predetermined menu selection operation. Radio button 406 accepts an operation to select one of the options. The entry button 407 and the cancel button 408 accept pressing processing.

A user wants to create the native application 400 described above and perform a test using the controls from the text box 401 to the cancel button 408 . In that case, as an example, a class 501 of the GUI driver 301 shown in FIG. 5 is required.

FIG. 5 is a diagram showing a first example of the GUI driver 301. As shown in FIG. The source code shown in FIG. 5 shows part of the GUI driver 301 . In one aspect, the automation support program 300 may read and build the source files of the GUI driver 301 when using the GUI driver 301 . In another aspect, the automation support program 300 may load a pre-built GUI driver 301 binary file.

Class 501 defines GUI driver 301 . A class 501 may contain multiple control drivers 302 as control properties 502 . More specifically, the class 501 includes processing for creating an instance of each control driver 302 corresponding to each of the controls from the text box 401 to the cancel button 408 .

Further, the class 501 associates "information for designating each control" with "instance of each control driver 302". In the example of FIG. 5, information for designating each control is passed to each control driver 302 as an argument to associate them.

In the following description, the instance in the GUI driver 301 specified by the control driver 302 is called "control property" for distinction. For example, “Name” and “Birthday” are control properties 502 . A class assigned to the control property 502 is called a "control driver 302". For example, “WPFTextBox” and “WPFCalendar” are control drivers 302 .

In the example of FIG. 5, the control property 502 has the function of operating controls created using WPF, but the functions of each control driver 302 are not limited to this. In one aspect, each control driver 302 can be defined for each control of various platforms such as any OS, web, and the like.

The class 501 includes each control property 502 corresponding to each of the controls from the text box 401 to the cancel button 408, so that the controls (the text box 401 to the cancel button 408) of the native application 400 can be operated from the outside. .

Each control property 502 is created by the general-purpose control driver 302 defined for each control of various platforms such as any OS, web, etc., as described above. Therefore, the user only needs to add to the GUI driver 301 the process of creating the control property 502 (instance) of the control driver 302 corresponding to the control included in the native application 400 created by the user. For example, instances from Name to Cancel are all created from the control driver 302 prepared in advance.

When the automation support program 300 is actually executed, the device 100 refers to the class name (control driver 302) and argument (information for designating each control) at the time of instantiation generation of each control property 502. , each control property 502 can determine which control to operate. As an example, "Email" is a "WPFTextBox" class and manipulates text boxes. The argument (information for specifying each control) of "Email" is "~ByBinding("Mail.Value").Single()", and "Email" is the text box 404 of the email. know to operate. The information for specifying each control differs depending on the platform.

As described above, control driver 302 can be used as control property 502 to manipulate generic components within GUI driver 301 . In addition, the automation assistant program 300 is also capable of testing new controls created by the user. The automation support program 300 can use the user-defined control driver 302 to generate test code for any control corresponding to the user-defined control driver 302 . These newly created control drivers 302 can also be used by other users by being included in a DLL or the like and distributed. Thus, the automation support program 300 can use control drivers 302 corresponding to user-defined controls in addition to control drivers 302 corresponding to general-purpose controls.

A test code, which will be described later, calls methods or properties of each control property 502 defined in the GUI driver 301 . That is, in this embodiment, the definitions of the GUI driver 301 and the control properties 502 are separated from the test scenario including the test code. Separating the definition of the GUI driver 301 and the control property 502 from the test scenario increases the readability and maintainability of the test scenario.

Conventional capture programs that create test scenarios generate test code with low readability and low maintenance that includes both "information for specifying each control" and "processing that directly manipulates controls". Therefore, when the specification of the application is changed, all the test codes that have been generated so far cannot be used.

On the other hand, the automation support program 300 according to the present embodiment, even if the specifications of the native application 400 are changed, the definition of the control property 502 (class type, argument, etc. (information for specifying each control)) ), etc., the test scenario can be used.

FIG. 6 is a diagram showing an example of a GUI 600 of a web application. Since web applications are executed by browsers and the like, they are often used as applications distributed to various devices. The automation support program 300 can test the GUI of such a web application as well as the GUI of a native application.

The web application 600 includes, as part of the controls, a title text box 601, a broadcast start date text box 602, a genre text box 603, a price text box 604, and a save button 605. FIG.

A user creates the GUI 600 of the above web application and wants to test using the controls from the text box 601 to the save button 605 . In that case, as an example, a class 701 of the GUI driver 301 shown in FIG. 7 is required.

FIG. 7 is a diagram showing a second example of the GUI driver 301. As shown in FIG. The source code shown in FIG. 7 shows part of the GUI driver 301 . In one aspect, the automation support program 300 may read and build the source files of the GUI driver 301 when using the GUI driver 301 . In another aspect, the automation support program 300 may load a pre-built GUI driver 301 binary file.

Class 701 defines GUI driver 301 . A class 701 may contain multiple control drivers 302 as control properties 702 . More specifically, class 501 includes processing for creating instances of control driver 302 corresponding to each of the controls from text box 601 to save button 605 .

Comparing FIG. 5 and FIG. 7 reveals that the descriptions of the control property 502 and the control property 702 are different. The control property 502 passes information about WPF to the control driver 302 that operates the WPF controls. Control properties 702, on the other hand, pass information about the web application to the control driver 302, which manipulates the web application's controls. That is, the automation support program 300 supports various platforms simply by changing the control driver 302 used in the GUI driver 301 and the information passed to the control driver 302 (information for specifying each control). be able to.

Next, test scenario generation processing will be described with reference to FIGS. 8 to 10. FIG. In the following description, the native application 400 in FIG. 4 will be used as an example, but the automation support program 300 can also create test scenarios for testing the web application 600 and GUI applications of other platforms using similar procedures.

FIG. 8 illustrates an example of an outline of the operation of the capture generator 303. FIG. In procedure 801 , the automation support program 300 sends the capture generator 303 to the application 102 . At this time, the capture generator 303 corresponding to each control property 502 is sent to the application 102 . Capture generator 303 runs inside application 102 .

In one aspect, automation assistant program 300 may send each capture generator 303 corresponding to each of control properties 502 to application 102 when using class 501 as GUI driver 301 .

In other aspects, capture generator 303 may be associated with multiple control properties 502 defined by the same control driver 302 . For example, if all of the control properties (A) to (C) corresponding to the controls (A) to (C) are of the "WPFTextBox" class, the capture generator 303 (X) corresponding to the "WPFTextBox" class is the control It may be associated with properties (A) to (C). In that case, automation assistant program 300 may send capture generator 303(X) to application 102 to capture the manipulation of controls (A)-(C).

In step 802, each transmitted capture generator 303 detects changes in data associated with events or controls occurring in the application 102 and generates corresponding test code. For example, the capture generator 303(Y) that monitors the text box 401 detects the occurrence of an operation event for the text box 401 and generates test code corresponding to the operation event. The test code will be the same processing as the actual operation. As an example, when “tanaka” is entered in the text box 401 , the capture generator 303 (Y) generates test code for entering “tanaka” in the text box 401 . The automation support program 300 acquires the test code generated by each capture generator 303 and integrates them into one to create a test scenario 803 .

In one aspect, instead of sending the capture generator 303 to the application 102, the automation support program 300 uses a function such as Friendly to monitor the operation of each control of the application 102 (occurrence of an event or change in data related to the control). You can just do it. The automation support program 300 may cause the capture generator 303 to generate test code when detecting the operation of each control.

FIG. 9 is a diagram showing an example of a test scenario. The test scenario includes generated test code 901 and verification code 902 . The test code 901 is generated by the capture generator 303 and the test code 901 executes test operations on the application 102 .

The verification code 902 verifies output results to each control when the test code 901 is executed. The capture generator 303 can generate the verification code 902 based on the output result when generating the test code. The verification code 902 can raise an exception when an output result different from the original is obtained. The verification code 902 includes methods or properties of the control driver 302, similar to the test code 901. FIG.

Each test code 901 and verification code 902 both call methods or properties of control properties 502 included in the class 501 of the GUI driver 301 . Therefore, it is highly readable and easy to edit, like handwritten code. Furthermore, since the class 501 of the GUI driver 301 and the test scenario are separated, even if the information for specifying each control in the control property 502 is changed, the automation support program 300 can execute the test scenario without any problem. is.

FIG. 10 is a diagram showing an example of a generated test scenario 1001. As shown in FIG. The user can execute the generated test scenario 1001 if there is software such as an IDE that has a build function.

FIG. 11 is a diagram showing an example of a communication processing procedure of the automation support program 300. As shown in FIG. Communication processing between the automation support program 300 and the application 102 under test will be described with reference to FIG. In some aspects, application 102 may be a native application or a front part of a web application. In another aspect, the control device 201 may load the automation support program 300 into the RAM 202 and execute the process of FIG. 11 .

Processing is mainly divided into processing 1150 and processing 1160 . Processing 1150 is processing for generating the GUI driver 301, and processing 1160 is processing for creating a test scenario. In step S1110, the automation support program 300 cooperates with Friendly, Selenium, or the like to obtain information on the application 102 for designating each control.

In one aspect, the automation assistant program 300 may obtain information indicative of the application under test 102 upon startup. The information indicating the application 102 under test may be arbitrary information such as a process ID or a URL (Uniform Resource Locator). In another aspect, the automation support program 300 may launch the application under test 102, or may launch a browser and cause the browser to display the GUI of the web application.

In step S1120, the automation support program 300 receives information for designating each control from the application 102. FIG. The information for designating each control can include information about the type of each control and information uniquely identifying each control. The automation support program 300 can automatically generate the GUI driver 301 based on the information for designating each control. A user can edit the automatically generated GUI driver 301 .

In step S1130, the automation support program 300 sends the capture generator 303 corresponding to the monitored control to the application 102. FIG. In step S1140, the automation support program 300 receives test code from the capture generator 303 operating within the application 102. FIG.

FIG. 12 is a diagram showing an example of a test scenario generation processing procedure of the automation support program 300. As shown in FIG. Internal processing of the automation support program 300 will be described with reference to FIG. In one aspect, the control device 201 may load the automation support program 300 into the RAM 202 and execute the process of FIG. 12 .

In step S1210, the automation support program 300 creates the GUI driver 301. FIG. This step corresponds to process 1150 . The automation support program 300 obtains information about the application under test 102 and determines the controls that the application 102 contains. The automation support program 300 uses the control driver 302 corresponding to the determined control to generate control properties.

In step S1220, the automation support program 300 accepts editing processing of the GUI driver 301 from the user. In some aspects, a user may edit GUI driver 301, such as with another editor or IDE. In other aspects, the user may manually define GUI drivers 301 .

In step S<b>1230 , the automation support program 300 acquires information on the application 102 displayed on the device 100 . In one aspect, the automation assistance program 300 may accept input of information indicative of the application 102 from the user at startup or during execution. Information indicating the application 102 is, for example, a process ID or a URL. In other aspects, automation support program 300 may launch application 102 based on a path on a file, a URL, or the like.

In step S<b>1240 , the automation support program 300 selects the GUI driver 301 to be used from the GUI drivers 301 created in advance based on the information of the application 102 .

In step S<b>1250 , the automation support program 300 identifies controls to be captured based on the control properties of the GUI driver 301 . More specifically, the automation support program 300 is a capture target based on the type of the control driver 302 that generates the control property (instance) and information for specifying each control passed to the control property. Identify controls.

In step S1260, the automation support program 300 sends the capture generator 303 corresponding to the control property specified in step S1250 to the application 102, and monitors the operations received by the application 102. FIG. The capture generator 303 generates test code based on the operation of the application 102 and transmits the test code to the automation support program 300 .

In step S1270, the automation support program 300 receives the test code and includes the test code in the test scenario. In step S1280, the automation support program 300 generates a verification code for verifying the output result of the test code and adds it to the test scenario.

As described above, in this embodiment, the GUI driver 301 and the control driver 302 are defined independently of the test scenario. By including the control driver 302 as a control property, the GUI driver 301 hides information for designating each control and processing for directly operating the control. In addition, the automation assistant program 300 generates test code that calls methods or properties of the control driver 302 when capturing the operations of the application under test. Through this processing, the automation support program 300 can create a test scenario including test code with high readability and maintainability. Furthermore, the automation support program 300 can generate a scenario for RPA by removing the verification code addition process from the test scenario creation procedure described above.

It should be considered that the embodiments disclosed this time are illustrative in all respects and not restrictive. The scope of the present invention is indicated by the scope of the claims rather than the above description, and is intended to include all modifications within the meaning and scope equivalent to the scope of the claims.

10, 100 device, 101 IDE, 102 application, 201 control device, 202 RAM, 203 input interface, 204 output interface, 205 external device interface, 206 communication interface, 207 storage device, 300 automation support program, 301 GUI driver, 302 control Driver, 303 Capture Generator, 400 Native Application, 401, 404, 601, 602, 603, 604 Text Box, 402 Calendar, 403 Number Input Box, 405 Pull-down Menu, 406 Radio Button, 407 Entry Button, 408 Cancel Button, 501, 701 class, 502, 702 control property, 600 web application, 605 save button, 803, 1001 test scenario, 901 test code, 902 verification code.

Claims (7)

A program for controlling a computer, said program causing said computer to:
Acquiring information on a GUI (Graphical User Interface) including one or more controls and displayed on the monitor of the computer;
selecting a GUI driver comprising one or more control drivers respectively operating each of said one or more controls;
selecting a control to be captured from among the one or more controls based on the acquired GUI information and the one or more control drivers;
capturing operations received by the selected control;
calling an operation code generation program corresponding to each of the one or more control drivers;
generating opcodes corresponding to any of the one or more control drivers based on the results of the capture;
and receiving an operation code generated by the operation code generation program from the operation code generation program when an event of the GUI occurs or data related to the control changes. each of the one or more control drivers is a class that operates each of the one or more controls from the outside;
The GUI driver is
A class that includes the one or more control drivers as methods or properties,
Information specifying each of the one or more controls included in the GUI information is associated with each of the one or more control drivers,
2. The program of claim 1, wherein the operational code includes any method or property of the one or more control drivers. 3. The program product of claim 1 or 2, wherein the one or more control drivers comprises a user-defined custom control driver. Said program, on said computer,
4. The program according to any one of claims 1 to 3, further causing the step of loading an external program containing said one or more control drivers. Said program, on said computer,
Further executing a step of generating a confirmation code for confirming an output result when the operation code is executed;
A program according to any preceding claim, wherein said verification code comprises any method or property of said one or more control drivers. A method of generating operation code for software, comprising:
obtaining information in a GUI that includes one or more controls and is displayed on a computer monitor;
selecting a GUI driver comprising one or more control drivers respectively operating each of said one or more controls;
selecting a control to be captured from among the one or more controls based on the obtained GUI information and the one or more control drivers;
capturing operations received by the selected control;
calling an operation code generation program corresponding to each of the one or more control drivers;
generating opcodes corresponding to any of the one or more control drivers based on the results of the capture;
receiving from the opcode generator an opcode that the opcode generator generates when an event occurs in the GUI or when data associated with the control changes. an input unit that receives an operation from a user;
a display unit for displaying a GUI;
a memory storing one or more GUI drivers;
and a control unit,
The control unit
obtaining information of the GUI including one or more controls displayed on the display;
selecting the GUI driver including one or more control drivers that refer to the memory and operate each of the one or more controls, respectively;
selecting a control to be captured from among the one or more controls based on the acquired GUI information and the one or more control drivers;
capturing an operation received by the selected control from the input unit;
calling an operation code generation program corresponding to each of the one or more control drivers;
generating opcodes corresponding to any of the one or more control drivers based on the results of the capture;
An apparatus for receiving, from the operation code generation program, an operation code generated by the operation code generation program when an event occurs in the GUI or when data associated with the control changes.

Images