JP2013149178A - Test code automatic generation program using debugger function - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a program for recording an operation performed by a user and automatically generating a test code for reproducing the operation in a GUI (Graphical User Interface) application subject to a test and being independent of means such as relaying and capturing an event message represented by an X Window system and Windows (registered trade mark).SOLUTION: The test code automatic generation program comprises: a recorder 20 for obtaining and storing information from a debugger library 30 that a processing system of a GUI application 100 provides to the GUI application 100 subject to a test; an information storage unit 40 for storing the information; and a test code output unit 50 for outputting a test code source file 200 from the information storage unit 40.

Description

  The present invention relates to a test support system for a GUI (Graphical User Interface) application, and more particularly to automatic generation of a test code used for test automation.

  In recent years, a development form in which, when a program is created, a test code for the program is created at the same time has become common. The reason is that when the program code is modified, if there is a test code, the regression test can be executed immediately and the development efficiency is high. For example, in Java (registered trademark), there is a test framework called JUnit, and if a test code according to this framework is created, a unit test can be easily performed.

  However, test code creation itself requires a lot of labor for the developer, such as the test code needs to be modified if the program interface (function arguments, etc.) of the target program changes. It has become a difficult task. Therefore, various methods for automatically generating the test code itself have been proposed.

  For example, in Patent Document 1, a GUI application to be tested is modified to supplement an X window system event message, stored in a file as event information, and a GUI is automatically executed from the saved event information. How to operate is introduced.

  Patent Document 2 introduces a conventional method of supplementing an event message in the X window system using a special extended function of the X server as a supplement method of the event message. The literature introduces a method for supplementing an event message in a GUI application and reproducing the GUI application by creating a message exchange means.

  Patent Document 3 introduces a method of recording an operation of a GUI application in Windows (registered trademark) by reading an event message generated inside the OS of Windows (registered trademark) and saving it in a script file for GUI. Has been.

JP-A-7-84765 Japanese Patent No. 3271682 Japanese Patent No. 4295775

  In the above method, in either case of the X window system or Windows (registered trademark), before the GUI application processes the event message, the event message is supplemented and the event information is recorded. In a GUI system that does not have an event message (or that it is difficult to supplement the event message), a similar method cannot be adopted, and it is difficult to automatically generate a test code.

  The present invention proposes a method for automatically generating a test code by recording the content of a user operating a GUI application even in a GUI system without an event message.

The present invention is premised on the following conditions in the GUI application to be tested.
(A) A GUI application is implemented using a specific GUI framework (or GUI library) with respect to the GUI.
(B) The GUI application and the framework (a) can be debugged by a symbolic debugger.
(C) The debugger provided in (b) has a debugger library that can be operated from an external program.
(D) There is a test framework for test programs that can reproduce user actions.
(E) The data items required in the GUI framework for automatically generating the test code are clarified.

  The test code automatic generation program according to the present invention is achieved by creating a program including the following recorder, information storage unit, and test code output unit.

The recorder uses the debugger library of the processing system of the GUI application to be tested, starts the GUI application, and after starting, stops execution at the location required for test code generation (hereinafter referred to as break). Is a module that automatically performs the following operations while the GUI application is operating.
(A) Break of test target program by set break point (B) Acquisition of data necessary for generating test code, saving to information storage unit (C) Resumption of GUI application

  The information storage unit is a module that temporarily holds the content recorded by the recorder and is used when generating a test code.

  The test code output unit is a module that generates a test code based on data accumulated in the information storage unit.

  By using the present invention, even in a GUI system without an event message, it is possible to record the content of the user operating the GUI application and automatically generate a test code.

  In addition, by using the present invention, the user operation when the GUI application is operated is recorded without changing the GUI application and the GUI framework used by the GUI application, and the same operation as the user operation is performed from the recorded contents. Test code to perform can be automatically generated.

  Furthermore, by using the present invention, it is possible to create a test code automatic generation program that depends on the GUI framework but does not depend on the GUI application.

It is a block diagram showing an example of embodiment of this invention. The solid line between modules represents the relationship between modules, and the arrow line represents the flow of data. The same notation is used for the other configuration diagrams. It is a flowchart showing operation | movement of the test code automatic generation program in FIG. Arrow lines represent the flow of processing. It is a block diagram showing an example of embodiment of a test code automatic generation program at the time of using Java (trademark) for a GUI application, a test code source file, and a test code automatic generation program. 3 shows a screen configuration, which is a specific example of the GUI application in FIG. It is a specific example of the GUI framework in FIG. It is a specific example of a breakpoint setting table in FIG. It is a specific example of the mounting part of the GUI application specific part in FIG. 5 is an example of an operation performed by a user during recording in the GUI application of FIG. 5 is a specific example of a trace information table recorded by the recorder with respect to FIG. It is an example of the test code conversion table in FIG. FIG. 3 shows an example of the output test code.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 relates to an embodiment of an automatic test code generation program according to the present invention, and is a diagram showing the internal / external configuration thereof. This program is realized by using hardware resources in a computer system. Is.

  As shown in FIG. 1, the test code automatic generation program 10 includes a recorder 20 that records the operation of the GUI application 100 to be tested, an information storage unit 40 that holds information acquired by the recorder 20, and an information storage unit. The test code output unit 50 outputs the test code source file 200 from 40. The recorder 20 is connected to the debugger library 30 in order to use the debugger library 30 provided by the processing system of the GUI application 100. The GUI application 100 is internally divided into a GUI framework 110 and a unique part 120 of the GUI application. The test code source file 200 represents a test code source file that is output after the test code automatic generation program 10 records an operation by the user of the GUI application 100 and operates in the same manner as the user operation.

  FIG. 2 is a flowchart showing a processing procedure from when the test code automatic generation program 10 starts up the GUI application 100 to when the test code source file 200 is output. The processing procedure of the test code automatic generation program 10 will be described below based on the flowchart of FIG.

  First, in step ST1-1, the recorder 20 starts the GUI application 100 in a paused state, and in step ST1-2, a debugger library is placed at a location where information necessary for test code generation can be extracted from the GUI framework 110. Use 30 to set a breakpoint. Thereafter, in step ST1-3, the GUI application 100 is restarted. Thereafter, the user can operate the GUI application 100, and the user operation can be recorded.

  Subsequently, the flowchart is a loop process until the GUI application ends or the recording is stopped by the user. Step ST1-4 is a process for determining whether the GUI application 100 is activated. If it is activated, the process is continued, and if completed, the process proceeds to step ST1-9. Step ST1-5 is a process for determining whether or not recording stop is requested by the user in the test code automatic generation program 10, and if the stop is not requested, the process is continued. Proceed to ST1-9.

  Subsequently, step ST1-6 is a process of waiting until the GUI application 100 is broken at a breakpoint. In step ST1-6, if the GUI application 100 is broken by a breakpoint, the process proceeds to the next process. In step ST1-7, information necessary for test code generation is acquired from the GUI framework using the debugger library 30 in the state when the break occurs, and stored in the information storage unit 40. In step ST1-8, the GUI application 100 is restarted using the debugger library 30.

  Finally, if the GUI application 100 is terminated or a stop request is made by the user, the process proceeds to step ST1-9. In step ST1-9, the test code output unit 50 outputs the test code source file 200 to the storage, memory or database of the computer system based on the information stored in the information storage unit 40.

  FIG. 3 shows an example of the test code automatic generation program 10 by Java (registered trademark) in the GUI application 103 using Java (registered trademark). Here, the output test code source file 201 is also described in Java (registered trademark). Hereinafter, an embodiment in which Java (registered trademark) is used for a GUI application, a test code, and a test precode automatic generation program will be described with reference to FIG.

  The debugger library 30 in FIG. 1 is replaced with a JDI (Java (registered trademark) Debug Interface) 31 in FIG. The JDI 31 uses a JDWP (Java (registered trademark) Debug Wire Protocol) 32 to connect to a Java (registered trademark) VM (Virtual Machine) 101 running the GUI application 103. The information storage unit 40 includes a breakpoint setting table 60, a trace information table 70, and a test code conversion table 80 as an embodiment.

  Operations of the recorder 20 and the test code output unit 50 in FIG. 3 are as follows. When the GUI application 100 is activated, the recorder 20 sets a breakpoint using the JDI 31 at the head of a method (corresponding to a C ++ member function) of the GUI framework 110 described in the breakpoint setting table 60. The breakpoint setting table 60 is a table describing locations where information necessary for test code generation can be extracted, and it is assumed that data is prepared in advance before starting the recording operation. When the recorder 20 breaks during the recording operation, the recorder 20 acquires information necessary for test code generation using the JDI 31 and records it in the trace information table 70. When the recording operation of the recorder 20 ends, the test code output unit 50 operates. The test code output unit 50 outputs the test code source file 201 while converting the record of the trace information table 70 into the test code using the test code conversion table 80. The test code conversion table 80 is a conversion table for replacing with the method on the test code when converting the information in the trace information table 70 to the test code, and data is prepared in advance before starting the test code output operation. Assuming that

  With the configuration as shown in FIG. 3, the test code automatic generation program of the present invention can be implemented in an environment using Java (registered trademark).

  Next, with respect to the embodiment of FIG. 3, the operation from the recording of the user operation to the output of the test code source file in the GUI application will be described using the specific examples of FIGS. It is assumed that the GUI framework, GUI application, and test code are described in Java (registered trademark). This specific example will be described below.

  FIG. 4 is an example of the GUI application in FIG. The GUI application 500 of FIG. 4 has a menu 502, a menu 503, and a menu 504 having captions “MENU1”, “MENU2”, and “MENU3” as GUI components, and a button 501 having a caption “BUTTON”. Have. The GUI application 500 has a width × height of 180 × 180 except for the menu portion, and the button 501 is arranged at the coordinates (120, 80) of the window portion. The button 501 has a width × height of 60 × 20.

  FIG. 5 is an implementation example of the GUI framework of the GUI application in FIG. The GUI framework 510 includes a Button class that represents a GUI component button, a MenuItem class that represents a GUI component menu, and a Window class that represents a screen. The underlined portion in the GUI framework 510 represents a place where a breakpoint is set, which is set by the recorder 20 at the start of the recording operation.

  The Button class has a constructor Button () and a method onClicked () that operates when the button is clicked. The constructor Button () is an id representing a resource ID, posX representing the position of the upper left X coordinate of the button, posY representing the position of the upper left Y coordinate of the button, a character string caption displayed on the button, and a window representing the window in which the button is arranged. Is stored in the Button class field (corresponding to the C ++ member variable), and then the GUI component is displayed. When the onClicked () method is called, it further calls an onButtonClicked () method of the Window class. That is, when a button is clicked, an onButtonClicked () method of the Window class is called, and an operation specific to the GUI application can be implemented by overriding the onButtonClicked () method of the Window class.

  Similarly to the Button class, the MenuItem class also has a constructor MenuItem () and a method onSelected () that operates when a menu is selected. When the onSelected () method is called, it further calls the onMenuItemSelected () method of the Window class. That is, when the menu is selected, the onMenuItemSelected () method of the Window class is called, and the GUI application specific operation can be implemented by overriding the onMenuItemSelected () method of the Window class.

  The Window class represents a basic screen of the GUI application, and it is assumed that the GUI application is created by being derived from the Window class. In the Windows class, create () method that is called when the application starts (screen creation), onCreated () method that is called from create (), onDeviceTouched () method that is called when a user clicks a part other than the GUI part of the screen, and is called when the button is clicked It has an onButtonClicked () method, an onMenuItemSelected () method called at the time of menu selection, and an onTouched () method called from the onDeviceTouched () method. The onCreate () method, onButtonClicked () method, onMenuItemSelected () method, and onTouched method () can be overridden by a derived class of the Windows class that is an implementation on the GUI application side, so that unique operations of the GUI application can be implemented. It has become. The onTouched () method receives the X and Y coordinates of the coordinates clicked by the x and y arguments.

  560 in FIG. 6 is an example of the break point setting table 60 that is used when the recorder 20 sets break points in the GUI framework 510. After activating the GUI application 500, the recorder 20 refers to the breakpoint setting table 560 and sets breakpoints at the underlined locations of the GUI framework 510.

  Reference numeral 520 in FIG. 7 is an implementation example of the unique part of the GUI application 500 of the GUI application 500 using the GUI framework 510. A SampleApplication class 520 is a main class of the GUI application 500. The SampleApplication class has a Button class button, a MenuItem class menuItem1, menuItem2, menuItem3 as a field, and represents a button 501, a menu 502, a menu 503, and a menu 504 of the GUI application 500, respectively. In order to generate a GUI component, an onCreated () method of the Window class is overridden, and a GUI component button and menu are generated therein. Also, the onButtonClicked () method is overridden to implement the action when the button is clicked, the onMenuItemSelected () method is overridden to implement the action when the menu is selected, and the onTouched ( ) Overriding method.

  Reference numeral 530 in FIG. 8 is a table that summarizes the contents of operating the GUI application 500 when the user executes the test code automatic generation program in the GUI application 500 (hereinafter referred to as an operation table). The operation table 530 includes, as items, “No.” representing the row number in the operation table, “Time” representing the time when the operation was performed, and “User” in the GUI application 500 representing the operation performed by the user in the GUI application 500. Has the operation ". The format in the time is No. Taking “1” as an example, “2011-10-24T20: 27: 31.100” represents “October 24, 2011, 20:27:31, 100 milliseconds”. This indicates that the GUI application 500, which is the first operation, is “started at 20:27:31 seconds and 100 milliseconds on October 24, 2011”. No. From 2 onwards, the contents that the user has done in the same manner are described.

  Reference numeral 540 in FIG. 9 is an example of a trace information table recorded by the recorder 20 when the user performs an operation in the operation table 530. The trace information table 540 includes, as items, “time” indicating the time when the break occurs, “application type” for distinguishing the application, and “window type” indicating the type of window operated by the user immediately before the break. , “Class name” that represents the class of the control component that the user was operating immediately before the break, “method” that represents the method at the time of the break, “argument” that represents the argument of the method at the time of the break, Has a “field” that represents a class field. The item “application type” is an item provided to distinguish GUI applications when recording operations of a plurality of GUI applications. The item “window type” is an item provided for distinguishing when a plurality of windows, dialogs, and the like are displayed.

  Next, the contents recorded in the trace information table 540 in FIG. 9 will be described. No. in the operation table 530. 1, when the GUI application 500 is started, the recorder 20 can detect that the SampleApplication class that is the actual state of the GUI application 500 is started at the time “2011-10-24T20: 27: 31.100”. The recorder 20 records the time, application type, class name, and method name in the trace information table at this timing. Here, since the application type is “SampleApplication”, the GUI application 500 has one window, the window type is recorded as “Main”, the class name is recorded as “SampleApplication”, and the method name is recorded as “create”. Next, No. in the operation table 530 is set. When the button is clicked as shown in FIG. 2, since a breakpoint is set in the Button class's onClicked () method, the Button class's onCricked () is set at time “2011-10-24T20: 27: 32.400”. ) The method breaks and detects that the button is clicked at this timing. Similar to the onCreated () method, the recorder 20 records in the trace information table. At this time, since the break was caused by the onClicked () method of the Button class, “Button” as the class name and “onClicked” as the method name are recorded in the trace information table. In order to distinguish when there are a plurality of buttons, the resource ID value is obtained from the field id of the button object of the Button class, which is an argument of the onClicked () method, during the break, and the data “id = 1001 "is recorded in the item" field ". No. in the operation table 530. No. 3 is also No. Record in the trace information table as in 2. No. in the operation table 530. For 4, what is needed for the reproduction in the test code is the coordinates on the screen, so at break time, the value of the argument of the onDeviceTouched () method of the Window class is acquired, and the clicked coordinates are (30, 30) and record “x = 30, y = 30” in the item “argument” of the trace information table. Thereafter, similarly, the method that has been broken by the user's operation and the acquired information are recorded in the trace information.

  550 in FIG. 11 is an output example of the test code output by the test code output unit 50 using the test code conversion table in FIG. 10 based on the contents of the trace information table 540 recorded in FIG.

  In the test code 550 of FIG. 11, it is assumed that there is a test framework that can reproduce the operation of the GUI application, and the 550 TestFramework class corresponds to this. The testSampleApplication () method of the TestProgram class is a method called at the start of the test. The doWindowCreate () method, the sleep () method, the doButtonClick () method, the doMenuSelect () method, and the doWindowTouch () method are test frame class test methods that operate the GUI component. "Open the window of the specified window class", "Wait for the specified time (milliseconds)", "Click the button of the specified resource ID", "The menu of the specified resource ID This process imitates the user's operation of “select” and “click specified coordinates on the screen”.

  FIG. 10 is a specific example of the test code conversion table. The test code conversion table 570 includes, as items, a “class name to be converted” representing a class name to be converted by the GUI framework 110, a “method name to be converted” representing a method name to be converted of the corresponding class, a test It has “class name after conversion” that represents the class name on the test framework to be replaced with code, and “method name after conversion” that represents the method name on the test framework to be replaced with test code.

  A method for outputting the test code in FIG. 11 will be specifically described.

  Since the code other than the code in the testSampleCreate () method can be generated from the template, the detailed generation method other than the code in the testSampleCreate () method is omitted.

  Next, a method for generating code in the testSampleCreate () method will be described. Since it can be seen from the first line of the trace information table 540 that the sample application class window has been opened, the test code output unit 50 outputs “doWindowCreate (SampleApplication.class);” using the test code conversion table 570. However, at this time, when the test code conversion table 570 is used for conversion, the first line of the trace information table 540 is converted to the test code based on the fact that the “SampleApplication class is a derived class of the Window class and is also a Windows class”. Conversion is performed in association with the third row of the table 570. Subsequently, from the time difference between the records in the first row and the second row of the trace information table 540, it can be seen that the button is clicked after waiting for 1300 milliseconds after the GUI application is started. Outputs “sleep (1300);”. Further, since it can be seen from the record in the second row that “click button of resource ID = 1001”, the test code output unit outputs “doButtonClick (1001);” using the test code conversion table 570. In the same manner, the class information, method name, argument, contents recorded in the trace information table 540 and the contents recorded in the field and the test code conversion table 570 can be used to know how long to wait and which process to perform. A test code can be output as indicated at 550 in FIG.

  From the above, the present invention can record an operation performed by a user and output a test code that can reproduce the operation.

10. Test code automatic generation program 11. Java (registered trademark) VM (Virtual Machine) for operating the test code automatic generation program
20 ... Recorder 30 ... Debugger library 31 ... JDI (Java (registered trademark) Debug Interface)
32 ... JDWP (Java (registered trademark) Debug Wire Protocol)
40 ... Information storage unit 50 ... Test code output unit 60 ... Break point setting table 70 ... Trace information table 80 ... Test code conversion table 100 ... GUI (Graphical User Interface) application 101 ... Java (registered trademark) for operating the GUI application VM
110 ... GUI framework 120 ... GUI application specific part 200 ... Test code source file 201 ... Test code source file 500 by Java (registered trademark) ... Example of GUI application 501 ... Button 502 with caption "BUTTON" ... "MENU1 Menu 503 with caption "...... Menu 504 with caption" MENU2 "... Menu with caption" MENU3 "510 ... Implementation example of GUI framework 520 ... Implementation example of specific part of GUI application 530 ... User in GUI application Example of operation performed 540 ... Trace information table recording example 550 ... Test code source file output example 560 ... Breakpoint setting table Examples of Le example 570 ... test code conversion table

Claims (2)

  In a test code automatic generation program for recording an operated procedure and values for single and plural GUI applications to be tested, information is acquired from a debugger library provided by the processing system of the GUI application and stored. An automatic test code generation program, comprising: a recorder; an information storage unit that holds the information; and a test code output unit that outputs a test code source file from the information storage unit.   2. The test code automatic generation program according to claim 1, wherein the single and plural GUI applications operate on a computer different from the test code automatic generation program.