JP4859821B2 - Application program test program - Google Patents

Description

  The present invention relates to a test program for an application program, and more particularly to a test program for an application program for testing a screen of the application program.

  Conventionally, for example, when testing a screen of an application program (application) that performs communication, a test tool has been used. For example, the test tool first executes a test case to record events (user input operations, screen changes, data transmission / reception, etc.), and records events that occur (playback) in subsequent tests. It is determined whether or not the event matches.

  For example, the test tool has tested the screen by recording and playing back a specific value on the screen and communication between the client and the server. In addition, the test tool performs a screen test by recording and reproducing an event and a screen of an operating system (OS) such as Windows (registered trademark) and a browser.

  FIG. 1 is a schematic diagram showing a conventional method for testing an application screen. In the method of FIG. 1, at the time of recording, the verification target is manually designated from the contents of the communication message or the screen update received by the browser from the server due to the event from the user. At the time of reproduction, the application screen is tested by comparing the verification target designated in advance in the communication message received from the server or the contents of the screen update received from the server by the event from the user.

  In the method of FIG. 1 in which the contents of the communication message or the screen update (text field value, etc.) are to be verified, there is no problem even if the fine layout changes. However, in the method of FIG. 1, the verification target must be manually specified from the communication message received by the browser from the server or the contents of the screen update due to the event from the user. In some cases, the method of FIG. 1 cannot verify changes in style such as color and character decoration.

  In Patent Documents 1 and 2, for the purpose of automating test work, a technique is described in which the occurrence of an event is detected and automatically recorded, instead of the user manually specifying a verification target. The methods disclosed in Patent Documents 1 and 2 compare screen bitmaps. The methods of Patent Documents 1 and 2 are examples in which a screen test is performed by recording and playing back an event or screen of an OS or browser such as Windows (registered trademark).

FIG. 2 is a schematic diagram showing a conventional method for testing an application screen by comparing bitmaps. The technique of FIG. 2 can be realized by using, for example, a Windows (registered trademark) native test tool.
JP-A-5-81082 JP 2000-235455 A

  However, the conventional method of testing application screens by comparing bitmaps has the problem that verification fails because the screen size, screen display position, browser type and settings, etc. are different. It was. For example, in FIG. 2, since the screen size and the display contents of the status bar and tool bar are different between recording and playback, the verification fails.

  SUMMARY An advantage of some aspects of the invention is that it provides an application program test program that can accurately test a screen of an application program without manually specifying a verification target.

  In order to solve the above-described problems, the present invention provides a recording device that cumulatively records user events and screen events generated in an application program when a computer on which the application program is installed executes a test case for the application program. A recording control unit that reads the user events and screen events accumulated and recorded in the recording device, and sequentially executes the user events in the application program to be tested; A screen event that occurs between the execution of a user event and the execution of the next user event, and a screen that occurs between the execution of the one user event read from the recording device and the execution of the next user event Comparing the vent, characterized in that the non-matching the screen event is an application program test program to function as an error output control means for outputting as an error.

  In addition, what applied the component, expression, or arbitrary combination of the component of this invention to a method, an apparatus, a system, a computer program, a recording medium, a data structure, etc. is also effective as an aspect of this invention.

  According to the present invention, it is possible to provide a test program for an application program that can accurately test the screen of the application program without manually specifying a verification target.

  Next, the best mode for carrying out the present invention will be described based on the following embodiments with reference to the drawings. First, in order to facilitate understanding of the present invention, a conventional method for testing a browser screen as an example of an application program (application) will be described.

  FIG. 3 is a schematic diagram showing a conventional mechanism (during recording) for testing a browser screen. In FIG. 3, the event detection unit 3 included in the browser plug-in 2 detects an event (key input, mouse operation, etc.) that has occurred in the browser 1. The event detection unit 3 records the detected events other than the screen event in the event store 4. Further, the event detection unit 3 records the display content of the screen based on the screen event among the detected events in the screen store 5. For example, an HTML file representing the display content of the screen is recorded in the screen store 5.

  FIG. 4 is a schematic diagram showing a conventional mechanism (during reproduction) for testing a browser screen. In FIG. 4, the Java (registered trademark) Script library 10 includes a comparison unit 11, an event execution unit 12, and an event reading unit 13. The event reading unit 13 reads an event from the event store 4 and sends it to the event execution unit 12. The event execution unit 12 executes an event (key input, mouse operation, etc.) in the browser 1.

  After the screen change based on the screen event, the comparison unit 11 compares the display content of the screen recorded in the screen store 5 with the display content of the screen by the browser 1, and the display content of the screen recorded in the screen store 5. If there is a difference between the display content of the screen by the browser 1, it is determined that there is an error. If there is an error, the comparison unit 11 causes the error output unit 14 to output an error.

  FIG. 5 is a schematic diagram showing the method of the present invention for testing a browser screen. In the method of FIG. 5, during recording, the test recording mechanism 22 detects and records an event (such as a key input) from the user 21 in steps S1 to S2. In steps S <b> 3 to S <b> 5, the browser 1 receives the contents of the screen update from the server 23 by an event from the user 21. The test recording mechanism 22 records the contents of the screen update received by the browser 1. Note that the processing in steps S1 to S5 is repeated every time there is an event from the user 21.

  At the time of reproduction, the browser 1 receives the contents of the screen update from the server 23 by an event from the test recording mechanism 22 in steps S11 to S14. The test recording mechanism 22 detects the content of the screen update received by the browser 1 and tests the screen of the browser 1 by comparing it with the content of the screen update recorded at the time of recording. Note that the processing in steps S11 to S14 is repeated every time there is an event from the test recording mechanism 22.

  In the method of FIG. 5, a screen change can be detected in response to an event such as a user input operation, a screen change, and data transmission / reception that occurs in the browser 1, and a test recording process or a reproduction process can be performed. .

  The test reproduction according to the present invention is triggered by an event such as a user input operation, a screen change, and data transmission / reception, so that it is not necessary to have a timing in real time unlike a Windows (registered trademark) native test tool. Therefore, in the present invention, it is possible to execute a test on the browser 1 screen at high speed.

  Further, in the present invention, when the screen changes are accumulated and recorded as a history, the difference between the screen changes is recorded, so that it is possible to detect a difference between the screens during test recording and playback. Therefore, unlike the Windows (registered trademark) native test tool, the present invention can be accurately tested even if the screen size changes between recording and playback.

  Further, in the present invention, even if the screen change is structurally different between reproduction and recording, it can be accurately tested by finding out whether the same screen change exists elsewhere. Furthermore, in the present invention, by abstracting events such as user input operations, screen changes, and data transmission / reception that have occurred in the browser 1 on a command-by-command basis, differences in the types of the browser 1 can be absorbed. Even if the type of browser 1 is different between playback and playback, it can be tested accurately.

  FIG. 6 is a schematic diagram showing an example of the mechanism (during recording) of the present invention for testing the browser screen. In FIG. 6, the browser plug-in 2 includes an event detection unit 3 and a command recording unit 31.

  The event detection unit 3 detects events (key input, mouse operation, communication reception, screen change, etc.) that have occurred in the browser 1. The event detection unit 3 sends the detected event to the command recording unit 31. The command recording unit 31 abstracts the received event by converting it into a command to be described later. Note that the command recording unit 31 abstracts the display content of the screen based on the screen event by converting it into a command. The command recording unit 31 records the converted command in the command store 32.

  FIG. 7 is a schematic diagram showing an example of the mechanism (during reproduction) of the present invention for testing a browser screen. In FIG. 7, the Java (registered trademark) Script library 10 includes an event execution unit 12, an event analysis, screen change confirmation unit 41, and a command reading unit 42.

  The command reading unit 42 reads a command from the command store 32 and sends it to the event analysis / screen change confirmation unit 41. The event analysis / screen change confirmation unit 41 sends the received command to the event execution unit 12. The event execution unit 12 converts the received command into an event as will be described later. Of the converted events, the event execution unit 12 executes user events such as key input and mouse operation on the browser 1.

  The event analysis / screen change confirmation unit 41 receives from the browser 1 a screen change screen event that has occurred in the browser 1. The event analysis and screen change confirmation unit 41 performs screen changes necessary from the execution of one user event to the execution of the next user event based on the screen change screen event generated in the browser 1 received from the browser 1. It is confirmed as described later whether or not.

  Further, the event analysis / screen change confirmation unit 41 uses the error temporary storage store 43 to determine whether the content of the screen update generated in the browser 1 is the same as the content of the screen update recorded in the command store 32 at the time of recording. To make sure. If there is a difference between the content of the screen update generated in the browser 1 and the content of the screen update recorded in the command store 32 at the time of recording, the event analysis and screen change confirmation unit 41 will determine whether the difference is a problem as described later. Check with.

  If the difference is a problem, the event analysis / screen change confirmation unit 41 causes the error output unit 14 to output an error. If the difference is not a problem, the event analysis / screen change confirmation unit 41 does not cause the error output unit 14 to output an error.

  FIG. 8 is a schematic diagram showing an example of another mechanism (during recording and reproduction) for testing the browser screen. The mechanism of FIG. 8 differs from the mechanism shown in FIGS. 3 and 4 in the processing of the comparison unit 11. The mechanism of FIG. 8 records the display content of the entire screen in the screen store 5 at the time of recording, similarly to the conventional mechanism shown in FIG.

  8 compares the display content of the entire screen recorded in the screen store 5 with the display content of the entire screen by the browser 1 during playback, similar to the conventional mechanism shown in FIG. Thus, the same mechanism as that of the present invention shown in FIGS. 6 and 7 can be realized. In the case of the mechanism of FIG. 8, if there is “the same screen change even if the location is different” in the comparison unit 11, it is determined that there is no error.

  FIG. 9 is a schematic diagram of an example of an event execution unit that can convert a command into an event. The event execution unit 12 that can convert a command into an event is the event execution unit 12 included in FIG.

  The event execution unit 12 of FIG. 9 includes a command reception unit 51, an execution browser determination unit 52, an event execution unit 53 for browser A, and an event execution unit 54 for browser B. As shown in FIG. 6, the command recording unit 31 abstracts the event received from the event detection unit 3 by converting it into a command described later, and records the command in the command store 32.

  The command reception unit 51 of the event execution unit 12 sends the command received from the event analysis / screen change confirmation unit 41 to the execution browser determination unit 52. Since the event details (property name, etc.) vary depending on the type of the browser 1, the execution browser determination unit 52 determines the type of the browser 1 that executes the event. In FIG. 9, it is assumed that the execution browser determination unit 52 determines browser A or browser B as the type of browser 1.

  If it is determined that the type of the browser 1 that executes the event is browser A, the execution browser determination unit 52 sends the command received from the command reception unit 51 to the event execution unit 53 for browser A. The event execution unit 53 for the browser A converts the received command into an event of the browser A and sends the event to the browser 1 in order to embody the received command.

  If it is determined that the type of the browser 1 that executes the event is browser B, the execution browser determination unit 52 sends the command received from the command reception unit 51 to the event execution unit 54 for browser B. The browser B event execution unit 54 converts the received command into a browser B event and sends the event to the browser 1 in order to embody the received command.

  FIG. 10 is an image diagram showing problems of a conventional method for testing the screen of an application. The image diagram of FIG. 10 shows an example in which the content of the screen update that occurred in the browser is different from the content of the screen update that was recorded in the event store at the time of recording. For example, in the case of a Windows (registered trademark) native test tool which is a conventional method, an error occurs unless the position and value are completely the same.

  FIG. 11 is an image diagram showing problems of a conventional method for testing an application screen. The image diagram of FIG. 11 shows an example in which the content of the screen update generated in the browser is different from the content of the screen update recorded in the event store at the time of recording. For example, if the communication message or screen update content (text field value, etc.), which is a conventional method, is to be verified (inspected), specify the inspection target manually from the communication message or screen update content. I had to leave.

  FIG. 12 is an image diagram showing the method of the present invention for testing an application screen. The image diagram of FIG. 12 shows an example in which the content of the screen update generated in the browser is different from the content of the screen update recorded in the command store at the time of recording. The technique of the present invention automatically determines that there is no problem if there are different screen updates (changes) and the same change is in another part of the screen. In the method of the present invention, if there is a different change, an error is temporarily output, but it is determined that there is no problem when the entire consistency is achieved, and the error is erased. Of course, the determination that there is no problem automatically made can be invalidated by the user.

  Note that, when there is a different change, whether or not the same change is in another part of the screen is determined as follows, for example. FIG. 13 is a schematic diagram showing an example of a method for determining whether or not the same change is in another part of the screen when there are different changes. When the platform is a browser, it is possible to know whether or not the change is finally the same by accumulating the “changed portion (expression in Xpath)” and the “DOM subtree”. In the case of other platforms (for example, Windows (registered trademark) Form), the same effect can be obtained by accumulating, for example, “changed part (x, y coordinates)” and “changed contents (change of property)”. It is done.

  In the method of the present invention, detection of different changes in the screen (error detection) and comparison of whether the same change is in another part of the screen (error comparison) are performed as follows. FIG. 14 is a schematic diagram showing the mechanism of error detection and error comparison. In the method of the present invention, “DOM change 1” and “DOM change 2”, which are screen events, are accumulated and recorded during recording. “DOM change 1” and “DOM change 2”, which are screen events during reproduction, are different in order and position from “DOM change 1” and “DOM change 2”, which are screen events during recording.

  Errors during playback are detected by different screen changes. In the example of FIG. 14, “DOM change 2” and “DOM change 1” that are screen events during playback are detected as errors, but “DOM change 1” and “DOM change” that are cumulatively recorded screen events during recording. By comparing with “2”, it is determined that the error is not a problem. If the change value such as the value of the text field is different, an error is issued as it is. In the method of the present invention, it is also possible to reproduce the screen at the time of recording and indicate which portion is different by combining the history of screen changes (change history) that have been accumulated and recorded.

  FIG. 15 is an image diagram showing an example of error determination based on error detection and error comparison according to the present invention. In the example 1, the screen events “DOM change 1” and “DOM change 2” are cumulatively recorded at the time of recording. At the time of reproduction, the error detection is detected as an error because the order and position of “DOM change 2” and “DOM change 1” of the screen events are different from those at the time of recording. In the error comparison, a cumulative comparison is made with the screen events “DOM change 1” and “DOM change 2” that are cumulatively recorded at the time of recording, and since only the position is different, it is determined that the error is not a problem.

  In the example 2, the screen events “DOM change 1”, “DOM change 3”, and “DOM change 2” are cumulatively recorded at the time of recording. At the time of reproduction, an error is detected as an error because the position of “DOM change 1” in the screen event, the presence / absence of “DOM change 3”, and the order and position of “DOM change 2” are different from those at the time of recording. In error comparison, “DOM change 1”, “DOM change 3”, and “DOM change 2” of the screen events that are cumulatively recorded at the time of recording are cumulatively compared. "DOM change 3" which does not exist at the time of reproduction is determined as an error.

  The technique of the present invention is realized by executing various programs according to the present invention on a computer device having a hardware configuration as shown in FIG. FIG. 16 is a configuration diagram of an example of a computer device. The computer device includes an input device 61, an output device 62, a drive device 63, an auxiliary storage device 64, a main storage device 65, an arithmetic processing device 66, and an interface device 67 that are mutually connected by a bus B.

  The input device 61 is composed of a keyboard, a mouse, etc., and is used for inputting various signals. The output device 62 is composed of a display device or the like, and is used for displaying various windows and data. The interface device 67 includes a modem, a LAN card, and the like, and is used for connecting to a network.

  The application program test program according to the present invention is at least a part of various programs for controlling the computer apparatus. The application program test is provided by distributing the recording medium 68 or downloading it from the network.

  The recording medium 68 is a recording medium that records information optically, electrically, or magnetically, such as a CD-ROM, flexible disk, or magneto-optical disk, or a semiconductor that electrically records information, such as a ROM or flash memory. Various types of recording media such as a memory can be used.

  When the recording medium 68 storing the application program test program is set in the drive device 63, the application program test program is installed in the auxiliary storage device 64 from the recording medium 68 via the drive device 63. The application program test program downloaded from the network is installed in the auxiliary storage device 64 via the interface device 67.

  The computer device stores a test program of the installed application program and stores necessary files, data, and the like. The main storage device 65 reads the application program test program from the auxiliary storage device 64 and stores it at the time of activation. The arithmetic processing unit 66 implements various processes as will be described later in accordance with the application program test program stored in the main storage device 65. The application program test program corresponds to the browser plug-in 2 and the Java (registered trademark) Script library 10.

(Flow chart showing processing at the time of recording)
FIG. 17 is a flowchart showing an example of processing during recording. Note that the flowchart on the left side of FIG. 17 represents processing of the event detection unit 3. The flowchart on the right side of FIG. 17 represents the processing of the command recording unit 31.

  Proceeding to step S51, the event detection unit 3 repeats the process of step S51 until it detects that an event has occurred in the browser 1. When detecting that an event has occurred in the browser 1, the event detection unit 3 proceeds to step S52, sends the detected event to the command recording unit 31, and then returns to step S51.

  Upon receiving an event from the event detection unit 3, the command recording unit 31 proceeds to step S53, and determines whether or not the type of the received event is “user event”. The event type is determined using the event type correspondence table shown in FIG. FIG. 18 is a configuration diagram of an example of the event type correspondence table.

  In the event type correspondence table of FIG. 18, an event and an event type are associated with each browser. By using the event type correspondence table of FIG. 18, the command recording unit 31 can determine the type of the event by specifying the browser and the event. If the received event type is “user event”, the command recording unit 31 proceeds to step S54 and converts the received event into a command.

  Note that conversion from an event to a command is performed using a command conversion correspondence table shown in FIG. FIG. 19 is a configuration diagram of an example of a command conversion correspondence table. In the command conversion correspondence table in FIG. 19, an event, a command name, an event attribute, and a command attribute are associated with each browser.

  If the received event type is not the “user event”, the command recording unit 31 proceeds to step S55, and determines whether the received event type is the “screen event” from the event type correspondence table. If the received event type is “screen event”, the command recording unit 31 proceeds to step S56, and converts the received event into a command using the command conversion correspondence table.

  If the received event type is not “screen event”, the command recording unit 31 proceeds to step S57 and determines whether the received event type is “communication event” from the event type correspondence table. If the type of the received event is “communication event”, the command recording unit 31 proceeds to step S58 and converts the received event into a command using the command conversion correspondence table.

  If the received event type is not “screen event”, the command recording unit 31 proceeds to step S59, and converts a unique event that is neither a user event, a screen event nor a communication event into a command using the command conversion correspondence table. Then, the command recording unit 31 proceeds to step S60 following steps S54, S56, S58 and S59, and records the converted command in the command store 32 as shown in FIG.

  FIG. 20 is a configuration diagram of an example of a command store. The command store 32 of FIG. 20 records the received event type, converted command, position, type, attribute, and attribute value in association with each other.

(Flow chart showing processing during playback)
FIG. 21 is a flowchart illustrating an example of processing performed by the command reading unit during reproduction. In the flowchart of FIG. 21, the process proceeds to step S71, and the command reading unit 42 determines whether or not the event store not shown in FIG. 7 is empty. If the event store is empty, the command reading unit 42 proceeds to step S72 and reads one command from the command store 32.

  In step S73, the command reading unit 42 determines whether there is a command in the command store 32. If there is a command in the command store 32, the command reading unit 42 proceeds to step S74, and sends the command read in step S72 to the event analysis and screen change confirmation unit 41. If the event store is not empty in step S71, the command reading unit 42 repeats the process of step S71 until the event store is empty. If there is no command in the command store 32, the command reading unit 42 proceeds to step S75, outputs the error remaining in the error temporary storage store 43, and then ends the process of the flowchart shown in FIG.

  FIG. 22 is a flowchart illustrating an example of processing performed by the event analysis, screen change confirmation unit, and event execution unit during playback. When the command is received from the command reading unit 42, the event analysis and screen change confirmation unit 41 proceeds to step S81, and determines whether or not the type of the received command is “screen event”.

  If the type of the received command is “screen event”, the event analysis and screen change confirmation unit 41 proceeds to step S82 and performs a comparison detailed process described later. If the received command type is not “screen event”, the event analysis and screen change confirmation unit 41 proceeds to step S83, and determines whether or not the received command type is “user event”.

  If the received command type is “user event”, the event analysis and screen change confirmation unit 41 proceeds to step S84 and determines whether the event store is empty. If the event store is not empty, the event analysis and screen change confirmation unit 41 proceeds to step S85 and reads the event from the event store. In step S86, the event analysis / screen change confirmation unit 41 registers the event read in step S85 in the error temporary storage store 43.

  If the event store is empty, the event analysis / screen change confirmation unit 41 sends the command read in step S72 to the event execution unit 12. The event execution unit 12 proceeds to step S87, and converts the command read from the command store 32 in step S72 into an event unique to each browser. For the conversion from the command to the event, for example, a command conversion correspondence table shown in FIG. 19 is used.

  Subsequent to steps S86 and S87 or if the type of command received in step S83 is not “user event”, the process proceeds to step S88, and the event execution unit 12 causes the browser 1 to execute the event. The event analysis and screen change confirmation unit 41 ends the process of the flowchart shown in FIG. 22 after the process of step S82. The event execution unit 12 ends the process of the flowchart shown in FIG. 22 after the process of step S88.

  FIG. 23 is a flowchart showing an example of event analysis during playback and processing of the screen change confirmation unit. The event analysis and screen change confirmation unit 41 repeats the process of step S91 until a screen change screen event that has occurred in the browser 1 is received from the browser 1.

  When receiving a screen change screen event generated in the browser 1 from the browser 1, the event analysis and screen change confirmation unit 41 proceeds to step S92, and converts the event into a command using, for example, the command conversion correspondence table shown in FIG. Proceeding to step S93, the event analysis and screen change confirmation unit 41 performs comparison detail processing described later, and then returns to step S91.

  FIG. 24 is a schematic diagram showing each store used during reproduction and its relationship. FIG. 24 shows the relationship between the command store 32, the event store, and the error temporary storage store 43.

  First, the comparison target in the command store 32 and the event store is selected in the order of event occurrence. In the example of FIG. 24, the screen event recorded in the event store is different from the screen event recorded in the command store 32 in the order of occurrence and position, and thus is recorded in the error temporary storage store 43.

  However, since the screen event recorded in the event store is different from the screen event recorded in the command store 32 only in the order of occurrence and position, the event analysis and screen change confirmation unit 41 has no problem with the error. The screen event shown in FIG. 24 recorded in the error temporary storage store 43 is canceled.

  FIG. 25 is a flowchart illustrating an example of the detailed comparison process in step S82. The event analysis / screen change confirmation unit 41 starts the process of the flowchart shown in FIG. 25 when the type of the command received from the command reading unit 42 is “screen event”.

  In step S101, the event analysis / screen change confirmation unit 41 reads the first event from the event store. In step S102, the event analysis / screen change confirmation unit 41 compares the command received from the command reading unit 42 with the event read in step S101, and determines whether the command, type, attribute, and attribute value are the same. .

  If the command received from the command reading unit 42 and the event read in step S101 do not have the same command, type, attribute, and attribute value, the event analysis and screen change confirmation unit 41 proceeds to step S103 and temporarily stores an error. It is determined whether the event read in step S101 exists in the store 43. If the event read in step S101 does not exist in the error temporary storage store 43, the event analysis / screen change confirmation unit 41 proceeds to step S104, and stores the event read in step S101 in the error temporary storage store 43. If the event read in step S101 exists in the error temporary storage store 43, the event analysis / screen change confirmation unit 41 does not perform the process of step S104.

  The processes in steps S101 to S104 are repeated until the next event disappears from the event store. When the next event disappears from the event store, the event analysis and screen change confirmation unit 41 proceeds to step S105, saves the command received from the command reading unit 42 in the error temporary storage store 43, and then the flowchart of FIG. End the process.

  If the command received from the command reading unit 42 and the event read in step S101 have the same command, type, attribute, and attribute value, the event analysis and screen change confirmation unit 41 proceeds to step S106, and the error temporarily It is determined whether the event read in step S101 exists in the storage store 43. If the event read in step S101 does not exist in the error temporary storage store 43, the event analysis / screen change confirmation unit 41 ends the process of the flowchart shown in FIG.

  If the event read in step S101 exists in the error temporary storage store 43, the event analysis / screen change confirmation unit 41 proceeds to step S107, and deletes the event read in step S101 from the error temporary storage store 43. Further, the event analysis / screen change confirmation unit 41 proceeds to step S108, deletes the event read in step S101 from the event store, and then ends the process of the flowchart shown in FIG.

  FIG. 26 is a flowchart illustrating an example of the detailed comparison process in step S93. When the event analysis / screen change confirmation unit 41 receives a screen change screen event that has occurred in the browser 1 from the browser 1, it reads the first event from the error temporary storage store 43.

  In step S112, the event analysis / screen change confirmation unit 41 compares the command received from the command reading unit 42 with the event read from the error temporary storage store 43 in step S111, and the command, type, attribute, and attribute value are determined. Determine if they are the same. If the command received from the command reading unit 42 and the event read from the error temporary storage store 43 in step S111 do not have the same command, type, attribute, and attribute value, the event analysis and screen change confirmation unit 41 performs step S111. Then, the next event is read from the error temporary storage store 43 and the processing is continued.

  When there is no next event from the error temporary storage store 43, the event analysis / screen change confirmation unit 41 proceeds to step S113, and stores the command received from the command reading unit 42 in the error temporary storage store 43. In step S114, the event analysis / screen change confirmation unit 41 stores the command received from the command reading unit 42 in the event store, and then ends the process of the flowchart illustrated in FIG.

  If the command received from the command reading unit 42 and the event read from the error temporary storage store 43 in step S111 have the same command, type, attribute, and attribute value, the event analysis and screen change confirmation unit 41 Proceeding to step S115, the event read at step S111 is deleted from the error temporary storage store 43, and then the processing of the flowchart shown in FIG.

  The error output unit 14 outputs an error remaining in the error temporary storage store 43 on an error screen as shown in FIG. 27, for example. FIG. 27 is an image diagram of an example of an error screen.

The present invention may have the following configurations as described below.
(Appendix 1)
A computer with an application program installed
Recording control means for accumulating and recording in a recording device user events and screen events that occur in the application program when a test case is executed for the application program;
Execution means for reading the user events and screen events accumulated and recorded in the recording device and sequentially executing the user events in the application program to be tested;
A screen event that occurs between the execution of one user event and the execution of the next user event in the application program to be tested, and the next user after the execution of the first user event read from the recording device A test program for an application program for comparing screen events that have occurred before an event is executed and causing the screen events that do not match to function as error output control means for outputting as an error.
(Appendix 2)
The recording control means detects a user event and a screen event generated in the application program when a test case is executed for the application program;
Recording means for abstracting the user event and screen event detected by the event detection means and cumulatively recording them in the recording device;
The execution means reads out the abstracted user event and screen event accumulated and recorded in the recording device;
Determining means for determining the application program to be tested;
Appendix 1 characterized by having an event execution unit that materializes the abstracted user event according to the application program determined by the determination unit and executes the user event by the application program to be tested Application program test program described.
(Appendix 3)
The error output control means includes a screen event that occurs from the execution of one user event in the application program to be tested to the execution of the next user event, and the one user event read from the recording device. The screen event generated from execution to the next user event is compared without considering the generation order, and the screen event that does not match is output as an error. Application program test program.
(Appendix 4)
The application program test according to appendix 1, wherein the screen event accumulated and recorded in the recording device by the recording control means is a difference in screen change and is information acquired by DOM (Document Object Model). program.
(Appendix 5)
The additional event according to claim 4, wherein the screen event accumulated and recorded in the recording device by the recording control means is information represented by a changed portion expressed in Xpath and a DOM subtree. Application program test program.

  The present invention is not limited to the specifically disclosed embodiments, and various modifications and changes can be made without departing from the scope of the claims.

It is the schematic diagram showing the conventional method of testing the screen of an application. It is the schematic diagram showing the conventional method of testing the screen of an application by bitmap comparison. It is the schematic diagram showing the conventional mechanism (at the time of recording) which tests the screen of a browser. It is the schematic diagram showing the conventional mechanism (at the time of reproduction | regeneration) which tests the screen of a browser. It is the schematic diagram showing the method of this invention which tests the screen of a browser. It is a schematic diagram of an example showing the mechanism (at the time of recording) of this invention which tests the screen of a browser. It is a schematic diagram of an example showing the mechanism (at the time of reproduction | regeneration) of this invention which tests the screen of a browser. It is a schematic diagram of an example showing the other mechanism (at the time of recording, at the time of reproduction | regeneration) of this invention which tests the screen of a browser. It is a schematic diagram of an example of the event execution part which can convert a command into an event. It is an image figure showing the problem of the conventional method of testing the screen of an application. It is an image figure showing the problem of the conventional method of testing the screen of an application. It is an image figure showing the method of this invention which tests the screen of an application. It is a schematic diagram showing an example of a method for determining whether or not the same change is in another part of the screen when there are different changes. It is a schematic diagram showing the mechanism of error detection and error comparison. It is an image figure showing an example showing error judgment by error detection and error comparison of the present invention. It is a block diagram of an example of a computer apparatus. It is a flowchart of an example showing the process at the time of recording. It is a block diagram of an example of an event type correspondence table. It is a block diagram of an example of a command conversion correspondence table. It is a block diagram of an example of a command store. It is a flowchart of an example showing the process of the command reading part at the time of reproduction | regeneration. It is a flowchart of an example showing the process of the event analysis at the time of reproduction | regeneration, a screen change confirmation part, and an event execution part. It is a flowchart of an example showing the process of the event analysis at the time of reproduction | regeneration, and a screen change confirmation part. It is a schematic diagram which shows each store used at the time of reproduction | regeneration, and its relationship. It is a flowchart of an example showing the comparison detailed process of step S82. It is a flowchart of an example showing the comparison detailed process of step S93. It is an image figure of an example of an error screen.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Browser 2 Browser plug-in 3 Event detection part 4 Event store 5 Screen store 10 Java (trademark) Script library 11 Comparison part 12 Event execution part 13 Event reading part 14 Error output part 21 User 22 Test recording mechanism 23 Server 31 Command recording Unit 32 Command store 41 Event analysis and screen change confirmation unit 42 Command reading unit 43 Error temporary storage store 51 Command receiving unit 52 Executing browser determination unit 53 Event execution unit for browser A 54 Event execution unit for browser B 61 Input device 62 Output device 63 Drive device 64 Auxiliary storage device 65 Main storage device 66 Arithmetic processing device 67 Interface device 68 Recording medium B bus

Claims (5)

A computer with an application program installed
Recording control means for accumulating and recording in a recording device user events and screen events that occur in the application program when a test case is executed for the application program;
Execution means for reading the user events and screen events accumulated and recorded in the recording device and sequentially executing the user events in the application program to be tested;
A screen event that occurs between the execution of one user event and the execution of the next user event in the application program to be tested, and the next user after the execution of the first user event read from the recording device A test program for an application program for comparing screen events that have occurred before an event is executed and causing the screen events that do not match to function as error output control means for outputting as an error. The recording control means detects a user event and a screen event generated in the application program when a test case is executed for the application program;
Recording means for abstracting the user event and screen event detected by the event detection means and cumulatively recording them in the recording device;
The execution means reads out the abstracted user event and screen event accumulated and recorded in the recording device;
Determining means for determining the application program to be tested;
An event execution unit that materializes the abstracted user event in accordance with the application program determined by the determination unit and executes the user event by the application program to be tested. 1. A test program for the application program according to 1.   The error output control means includes a screen event that occurs from the execution of one user event in the application program to be tested to the execution of the next user event, and the one user event read from the recording device. 2. The screen event generated between execution and execution of the next user event is compared without considering the generation order, and the screen event that does not match is output as an error. Application program test program described.   2. The application program according to claim 1, wherein the screen event accumulated and recorded in the recording device by the recording control means is a difference in screen change and is information acquired by DOM (Document Object Model). Test program.   5. The screen event accumulated and recorded in the recording device by the recording control means is information represented by a changed location expressed in Xpath and a DOM subtree. Application program test program.

Images