JP5200719B2 - Web application inspection program, test execution device, and test execution method - Google Patents

Description

  The present invention relates to a Web application inspection program, a test execution device, and a test execution method for inspecting a Web application installed on a Web server when a client accesses the Web server.

  Conventionally, as a test of a web application, a method of confirming whether the web application operates correctly by repeatedly performing operations on the web browser is generally employed.

  In this case, since bugs may occur due to combinations of multiple operations and combinations of multiple input data, in order to grasp the points that need to be corrected, only some operations or data inputs are performed, and other parts For, it was necessary to perform the same operation as the previous time. Therefore, since it is necessary to record all operation procedures and input data in each test, the work in the recursive test is complicated.

  As a support apparatus in such a recursive test, when verifying a test result, a technique for determining whether or not the stored HTML (HyperText Markup Language) file and the content of the HTML file received from the Web server match. Is disclosed (for example, see Patent Document 1 below).

JP 2005-266554 A

  However, in the above-described prior art, since one job is usually composed of a plurality of programs, even if it is possible to detect the occurrence of a data abnormality, where the abnormality occurred. There was a problem that could not be grasped.

  An object of the present invention is to provide a technique capable of shortening the time required to find a bug occurrence location on a program when a bug is detected in order to solve the above-described problems caused by the prior art.

  In order to solve the above-described problems and achieve the object, in the disclosed technique, a web server in which a web application including a series of programs is installed is a series of screen transitions included in the test case of the web application. A request for requesting a Web screen of a screen transition specification selected from the specifications is received from a client, and a program for calling the Web screen of the program group is executed based on the received request, and the Web screen is executed. The output value related to the screen item to be displayed on the screen, the output value related to the program and the attribute thereof are output, the output value related to the program output and the attribute thereof are stored in the storage area as session information, and the output related to the output screen item is output. Regarding the Web screen in which the value is embedded Generating a response, inserting the session information stored in the storage area into the generated response related to the Web screen, and transmitting the response related to the Web screen into which the session information is inserted to the client To do.

  In addition, a Web application inspection apparatus that can access the Web server receives test specification data in which the series of screen transition specifications are described, and transmits the request to the Web server. An output value related to the screen item and the session information are extracted from the acquired response related to the Web screen, and the output value related to the extracted screen item and the session information are extracted from the Web screen. It is necessary to write the test specification data received in the receiving step in association with

  According to the present disclosure technique, it is possible to shorten the time for finding a bug occurrence location on a program when a bug is detected.

(Outline of the disclosed technology)
The outline of the disclosed technique will be described below with reference to the accompanying drawings. If there is an error in the execution result of the regression test of the Web application installed on the Web server, whether or not the error occurred in the execution result due to a bug in the program that called the screen that finally displays the execution result I don't know if there was an error in the execution result due to a bug in the program. Here, a bad year display program will be described as an example of a Web application.

  FIG. 1 is a screen process transition diagram showing transitions of screens and processes of a bad year display program. FIG. 2 is an explanatory diagram showing the source code of the bad year display program 100. The bad year display program 100 is a Web application that calculates and displays the bad year of the person from the date of birth of the Japanese calendar input by the user.

  In FIG. 1, a user operates a Web browser to input a URL (Uniform Resource Locator), and transmits an HTTP (Hypertext Transfer Protocol) request to the Web server. The Web server generates a birth date input screen 101 that is an initial screen and transmits it as a response to the client. Thereby, the client's Web browser transits to the birth date input screen 101.

  The user inputs the date of birth of the Japanese calendar by selecting or keying in the era name, year, month, and day on the date of birth input screen 101, and presses the submit button. Thereby, the HTTP request including the date of birth of the Japanese calendar is transmitted to the Web server. A Japanese calendar → Western calendar conversion program 102 is executed on the Web server to generate a gender input screen 103. The gender input screen 103 is transmitted as a response to the client and displayed on the Web browser.

  On the gender input screen 103, information input on the date of birth input screen 101 is displayed as a screen item for confirmation, and an input form such as a radio button for inputting gender is arranged. The user selects or inputs a gender on the gender input screen 103 and presses a submit button. In the Web server, a bad year calculation program 104 is executed to generate a bad year display screen 105 on which the bad year information which is the final calculation result is displayed. The bad year display screen 105 is transmitted to the client as a response and displayed on the Web browser.

  In such a troubled year display program 100, even if a test is passed to the sex input screen 103 on the screen output and a failure is detected on the troubled year display screen 105, it is determined that the bug exists in the previous troubled year calculation program 104. I can't. Normally, it is generally considered that there is a bug in the troubled year calculation program 104 that is the process immediately before the screen where the failure is detected, but in reality there may be a bug lurking in the Japanese calendar → Western calendar conversion program 102, It is difficult to identify where the bug is.

  Referring to the source code 200 of FIG. 2, the underlined line is an instruction that may affect the birthday variable, and is a line that may be a bug. In the disclosed technique, the position where the bug is hidden is specified with high accuracy, thereby improving the reliability of the Web application test.

<Embodiment 1>
First, the first embodiment of the disclosed technology will be described. In the first embodiment, a screen output due to a bug is specified as a bug position. First, a schematic configuration of the Web application inspection system will be described.

(Schematic configuration of Web application inspection system)
FIG. 3 is an explanatory diagram of a schematic configuration of the Web application inspection system according to the first embodiment. In the Web application inspection system 300, a Web server 301 and a client 302 are connected to each other via a network 303 such as the Internet. Note that the Web server 301 and the client 302 may be configured as a single machine.

  The Web server 301 is a computer device in which a Web application to be inspected is installed. The Web server 301 executes a Web application test.

  The client 302 is a computer device used by the Web application inspector, and corresponds to the Web application inspection device in the first embodiment. The client 302 creates test specification data. The created test specification data is stored in a test specification DB (Database) 310. In this creation, the client 302 accesses the Web server 301 to transmit a request for requesting a Web screen of an arbitrary screen transition specification to the Web server 301 and receive a response from the Web server 301. Then, the response can be analyzed and displayed on the display.

(Hardware configuration of computer device)
FIG. 4 is a block diagram of a hardware configuration of the computer apparatus according to the first embodiment. 4, the computer apparatus includes a CPU (Central Processing Unit) 401, a ROM (Read-Only Memory) 402, a RAM (Random Access Memory) 403, a magnetic disk drive 404, a magnetic disk 405, and an optical disk drive 406. An optical disk 407, a display 408, an interface (I / F) 409, a keyboard 410, a mouse 411, a scanner 412, and a printer 413. Each component is connected by a bus 400.

  Here, the CPU 401 controls the entire computer apparatus. The ROM 402 stores programs such as a boot program. The RAM 403 is used as a work area for the CPU 401. The magnetic disk drive 404 controls the reading / writing of the data with respect to the magnetic disk 405 according to control of CPU401. The magnetic disk 405 stores data written under the control of the magnetic disk drive 404.

  The optical disk drive 406 controls reading / writing of data with respect to the optical disk 407 according to the control of the CPU 401. The optical disk 407 stores data written under the control of the optical disk drive 406, or causes the computer to read data stored on the optical disk 407.

  The display 408 displays data such as a document, an image, and function information as well as a cursor, an icon, or a tool box. As the display 408, for example, a CRT, a TFT liquid crystal display, a plasma display, or the like can be adopted.

  An interface (hereinafter abbreviated as “I / F”) 409 is connected to a network 303 such as a LAN (Local Area Network), a WAN (Wide Area Network), and the Internet through a communication line. Connected to other devices. The I / F 409 controls an internal interface with the network 303 and controls input / output of data from an external device. For example, a modem or a LAN adapter may be employed as the I / F 409.

  The keyboard 410 includes keys for inputting characters, numbers, various instructions, and the like, and inputs data. Moreover, a touch panel type input pad or a numeric keypad may be used. The mouse 411 moves the cursor, selects a range, moves the window, changes the size, and the like. A trackball or a joystick may be used as long as they have the same function as a pointing device.

  The scanner 412 optically reads an image and takes in the image data into the computer apparatus. The scanner 412 may have an OCR (Optical Character Reader) function. The printer 413 prints image data and document data. As the printer 413, for example, a laser printer or an ink jet printer can be adopted.

(Data structure of test specification data)
Next, the data structure of the test specification data will be described. When testing a Web application, it is first necessary to create test specification data. In such a method for automatically generating test specification data, the tester once extracts the input information and the output information while executing the Web application, and writes it to the test specification data. Since the test specification data is created while executing the test once, this test is called “initial test”.

  FIG. 5 is an explanatory diagram showing the data structure of the test specification data for the initial test. In FIG. 5, since the test specification data D1 before the start of creation is shown, the expected value information is blank. The test specification data D1 is electronic data in which a series of screen transition specifications included in a test case of a Web application installed in the Web server 301 is described. Specifically, for example, a spreadsheet in a table format is used. Created by a macro file.

  The test specification data D1 includes a series of screen transition specifications and expected value information for each test case TCi (i = 1, 2,..., N) to be inspected for the Web application to be inspected. Described. In FIG. 5, two (n = 2) test cases TC1 and TC2 are shown as an example. The screen transition specification may be entered manually, or a part or all of the screen transition specification may be mechanically extracted from design document information such as a screen transition diagram.

  The screen transition specification is specified by the screen name and the operation procedure description. The screen name is a name that identifies the screen file of the Web screen displayed on the client 302. For example, in the case of complying with JSP (Java Server Pages) and Java language specifications prescribed by Sun Microsystems, Inc., the JSP file name Is described as follows. In the case of the above-mentioned bad year display program 100, the date of birth input screen 101, the sex input screen 103, and the bad year display screen 105 are displayed.

  FIG. 6 is an explanatory diagram illustrating a screen example of the date of birth input screen 101. FIG. 7 is an explanatory diagram showing a screen example of the gender input screen 103. FIG. 8 is an explanatory diagram showing a screen example of the bad year display screen 105.

  Further, the operation procedure description represents the user's operation procedure when the associated Web screen, that is, the Web screen specified by the screen name of the left adjacent cell is displayed. If input information is given to the Web screen as described in this operation procedure, the Web screen with the screen name of the cell on the lower left is displayed.

  For example, if the birth date input screen 101 shown in FIG. 6 is displayed in the test case TC1, “Heisei” is selected from the year pull-down shown in FIG. When “13”, “10”, and “25” are entered and the submit button (the button “Go to gender input screen 103” in FIG. 6) is clicked, the screen changes to the gender input screen 103 shown in FIG. To do.

  On the other hand, the expected value information is described based on a response from the Web server 301 in which the Web application is installed during creation. When all blank cells in the expected value information are described for a test case TCi, the test specification data D1 related to the test case TCi is completed.

  FIG. 9 is an explanatory diagram showing the test specification data D1 after the initial test. The expected value information of the specification data D1 shown in FIG. 9 is a normal value. In FIG. 5 and FIG. 9, the meta information in the expected value information is information including a tag class and its attributes. A tag class is a class to which a tag of a Web application belongs.

  The attribute is detailed information of the tag class, and includes an attribute name (name) and an attribute value (property) of the tag belonging to the tag class. The number of calls is the number of appearances of meta information. The expected value is a value expected as an output value when a tag specified by meta information including a tag class, an attribute name, and an attribute value is executed. Hereinafter, this expected value is referred to as “screen item expected value”.

  In the expected value information, the session information is information acquired by a session information acquisition engine described later. The session information attribute is information indicating an attribute in the session. The expected value of session information is an output value expected during a session. This expected value is hereinafter referred to as “session expected value”.

(Detailed internal configuration of each computer device)
Next, a detailed internal configuration of each computer apparatus will be described. FIG. 10 is a block diagram showing a detailed internal configuration of each computer apparatus. First, a detailed internal configuration of the Web server 301 will be described.

  The Web server 301 includes an AP (Application) server 1011, a preprocessor 1012, a compiler 1013, a Web application 1014, a meta information insertion engine 1017, and a session information acquisition engine 1018.

  The AP server 1011 is a program serving as an execution environment for the Web application 1014, and includes a preprocessor 1012 and a compiler 1013. Specifically, middleware that can execute a program described in Java language and compiled by a compiler 1013 such as Apache Tomcat is applied as the AP server 1011.

  Here, when conforming to the JSP and Java language specifications defined by Sun Microsystems, Inc., a JSP expansion engine can be applied as the preprocessor 1012, and a Java compiler can be applied as the compiler 1013. The JSP expansion engine 1012 interprets a template description language such as JSP and translates it into a Java language and a Java class file.

  In addition, a Web application 1014 to be inspected is mounted on the AP server 1011 and includes a business logic 1015 and a template file 1016. The Web application 1014 is a program group described in a language such as Java or JSP. Which business logic 1015 and template file 1016 are called in response to an HTTP request from the Web browser of the client 302 by a framework such as MVC (Model View Controller) that can separate design and processing logic. Is determined. However, distribution to the business logic 1015 and the template file 1016 is possible without using the above-described framework.

  The business logic 1015 is a logical description of the Web application 1014 that executes an operation process such as a business transaction. For example, “When a customer puts an item in a shopping cart, it is determined to check inventory. “When you press the send button, the card company is authenticated. "Is a logical description that determines how each business flows. The bad year display program 100 shown in FIGS. 1 and 2 corresponds to the business logic 1015.

  The business logic 1015 describes processing logic such as performing a search according to the input search condition and authenticating a member. These business logics 1015 include a logical description for accessing an external database to refer to information and performing database operations such as adding, updating, and deleting data in the database.

  The template file 1016 is a file that defines the screen design and the display position of output items. In the case of using Java, a JSP file can be applied as the template file 1016.

  The bad year display program 100 shown in FIG. 1 will be described as an example. The design of the birth date input screen 101, the sex input screen 103, and the bad year display screen 105 on the Web browser 1021 is developed as a template file 1016 in the JSP language. The Further, the Japanese calendar → Western calendar conversion program 102 and the troubled year calculation program 104 are developed as a business logic 1015 in the Java language. Then, the result compiled by the compiler is executed while being saved as a Java class file.

  The user can access the screen by first inputting the URL of the template file 1016 corresponding to the date of birth input screen 101. The birth date input screen 101 describes a transition destination URL when the submit button is pressed, and this transition destination URL is defined in the AP server 1011 (or the above-described framework) to call the Japanese calendar → Western calendar conversion program 102. Yes.

  When the processing is completed, the Japanese calendar → Western calendar conversion program 102 designates a template file 1016 corresponding to the gender input screen 103 which is the next screen. As a result, the AP server 1011 transmits the HTML of the gender input screen 103 to the Web browser 1021. Calling the troubled year calculation program 104 from the gender input screen 103 and displaying the troubled year display screen 105 as a result are executed by the same procedure.

  As described above, in recent Web application development, a technique for separating the design function and the business logic function is becoming common. Therefore, the output item processed in the business logic 1015 is displayed at the position specified by the custom tag in the JSP file 1016.

  Further, the meta information insertion engine 1017 specifies meta information including a tag class, an attribute value of the name attribute, and an attribute value of the property attribute from the Java source fragment. And it inserts as a comment sentence of an output item. Specifically, the Java class file output by the JSP development engine 1012 is converted into a Java class file having a different behavior by injecting an aspect.

  The session information acquisition engine 1018 acquires only the necessary session information (memory structure) held by the Web server 301 for each screen. Specifically, for example, it is described as a program in a format that can be called from the AP server 1011, and a filtering process for accessing and changing HTML text information output by the Web application 1014 can be added. Yes.

  More specifically, for example, it is a Java language program developed by means such as a filter in the Java Servlet specification, and has been compiled as a Java class file. Although a method using a filter has been presented here, the same can be realized by using a general technique such as an aspect-oriented language, a DI (Dependency Injection) container, or a framework.

  Next, a detailed internal configuration of the client 302 will be described. The client 302 has a Web browser 1021 and an execution navigator 1022.

  The Web browser 1021 generates and transmits an HTTP request to the Web application 1014 of the Web server 301, or receives a response in HTML format from the Web server 301, and an analysis for analyzing the received response HTML. This is a program having a function and a drawing function for drawing the analysis result on a display.

  The execution navigator 1022 is a program installed to acquire an operation procedure description to be executed next and pass it to the Web browser 1021 or write information extracted from the response HTML into the test specification data.

  Specifically, the execution navigator 1022 acquires the response HTML via the web browser 1021. The response HTML is acquired by using an API (Application Program Interface) provided by the Web browser 1021, a method using output information such as a log or cache of the Web browser 1021, and a network from the Web server 301 to the client 302. Various methods such as a method of inserting a proxy server on the route are conceivable. Here, a method of notifying the acquired response HTML on the execution navigator 1022 using a plug-in deployed on the Web browser 1021 is used.

  The execution navigator 1022 analyzes the comment part in the response HTML. There are two types of comments: meta information HTML comments and session HTML comments. The meta information HTML comment is decomposed into meta information (a tag class name of a screen item, an attribute of a screen item) and a screen item expected value. On the other hand, the session HTML comment is decomposed into session information attributes and session expected values. In this decomposition, the character strings before and after “=” in the HTML comment beginning with “sessionInfo” are assigned to the session attribute and the session expected value, respectively.

  When the test case TCi is composed of a plurality of screen transitions, the screen item expected value and the session expected value are acquired for each screen. Normally, when testing the Web application 1014, it is common to perform test cases of several hundred to several thousand items, depending on the scale of the Web application 1014. In this way, a series of operations of the Web application 1014 are stored as one test case in the test specification DB 310, and a sufficient number of test cases are stored to ensure the quality of the Web application 1014.

  The execution navigator 1022 sequentially acquires test cases from the test specification DB 310, and digests them while automatically executing the Web application 1014. Further, the execution navigator 1022 changes the screen according to the operation procedure description from the URL of the initial screen in the test case. Each time the screen transitions, the execution navigator 1022 determines whether the content of the screen item existing in the screen matches the expected value.

  Even during this automatic execution, the meta information insertion engine 1017 is woven into the Web application 1014, and the latest execution result can be acquired. The execution navigator 1022 performs automatic determination by comparing the expected value of the screen item with the latest execution result. When the test case TCi is composed of a plurality of screen transitions, the test is performed by repeating the above procedure until all the procedures in each test case TCi are completed.

  An overall outline when the test is performed in the system configuration as shown in FIG. 10 will be described. When testing the Web application 1014, it is necessary to first create test specification data D1. In such a method of automatically generating the test specification data D1, the tester once executes the Web application 1014, extracts the input information and the output information using the meta information insertion engine 1017, and performs the test. This is written in the specification data D1. Since the test specification data D1 is created while the test is manually executed once at first, this test is referred to as “initial test”.

  In the first embodiment, in addition to the input / output information described above, the memory state is also stored in the test specification data D1, so that the difference from the first test in the second and subsequent tests is different in the entire Web application 1014. Identify where it occurred and locate the bug.

  In a state where the test specification data D1 is created in the initial test, the input to the Web application 1014 and the expected execution result (expected value) are written in the test specification data D1 as input / output information. Automated tests are performed based on the information. This automatic test method is disclosed in Japanese Patent Application No. 2006-294502. The second and subsequent tests that are automatically performed in a state where the test specification data D1 is created are referred to as “regression tests” in the present embodiment. In the first embodiment, the execution navigator 1022 compares the expected value with the result of the regression test, and identifies the place where the comparison result has changed as the bug position.

  Hereinafter, description will be made using the troubled year display program 100 of FIG. In the bad year display program 100, the bad year calculation program 104 calculates the bad year based on both the date of birth of the Japanese calendar entered by the user on the birth date input screen 101 and the gender entered on the gender input screen 103. In this example, it is assumed that the troubled year calculation program 104 can access only the contents entered on the gender input screen 103. As a method for the troubled year calculation program 104 to access information input from the date of birth input screen 101, there is a method using a session object.

  The session object is secured on the memory of the Web server 301 in order to manage the state in the Web session (access that is continuously performed on the same Web server 301 by the same client 302 and the same Web browser 1021). Is an area. Used to temporarily store past input information and intermediate calculation results for the same user. Since this session object is in a memory state, it cannot be referenced from outside unless a debugger is used.

  FIG. 11 is an explanatory diagram showing a session object. The session object 1100 can be accessed through the AP server 1011 from the Japanese calendar → Western calendar conversion program 102 and the bad year calculation program 104. FIG. 11 will be described in accordance with the screen process transition of the bad year display program 100 shown in FIG.

  When the Japanese calendar → Western calendar conversion program 102 receives “date of birth of the Japanese calendar = October 25, 2001” as the input information 1101 from the date of birth input screen 101, the date of birth of the calendar is displayed as the output information 1102. = October 25, 2001 "is passed to the session object 1100. The session object 1100 stores “date of birth” on the left side of “=” in the output information 1102 as an attribute, and “October 25, 2001” on the right side of “=” as a character string expression.

  Upon receiving “gender = male” as input information 1103 from the gender input screen 103, the troubled year calculation program 104 accesses the session object 1100, and the attributes and character string representations stored in the session object 1100 are “A.D. “Birth date = October 25, 2001” is read out as input information 1104. The bad year calculation program 104 calculates the bad year based on the input information 1103 and 1104. Then, “bad year = 2025, 2042, 2061” is embedded in the bad year display screen 105 as output information 1105 and output to the client 302.

  The session information acquisition engine 1018 acquires session information immediately after the processing (Japanese calendar-to-year conversion program 102 or troubled year calculation program 104) and at the timing immediately before the screen transition (A or B in FIG. 11). At this timing, all attribute information in the session object 1100 is acquired from the session information. The session information acquired in this way is embedded as a comment sentence in HTML generated as the next screen. Accordingly, the comment text is not displayed in the Web browser 1021, but is subject to analysis by the Web browser 1021.

(Sequence of Web server 301)
FIG. 12 is a sequence diagram showing a sequence of the Web server 301. First, the client 302 transmits an HTTP request including the URL of the Web server 301. In the Web server 301, the AP server 1011 receives the HTTP request and executes a request analysis process (step S1201). Then, the AP server 1011 executes business logic execution processing (step S1202). The business logic execution process (step S1202) executes the business logic 1015 and writes the session information to the session object 1100.

  Thereafter, output item expansion processing by the JSP expansion engine (step S1203), aspect injection processing by the meta information insertion engine 1017 (step S1204), and response generation processing by the AP server 1011 (step S1205) are executed. Then, the session information acquisition process (step S1206) by the session information acquisition engine 1018 is executed, and the session information is embedded in the response HTML generated by the response generation process (step S1205). The detailed processing procedure of the session information acquisition process (step S1206) will be described later. The AP server 1011 executes response transmission processing (step S1207) for transmitting the response HTML in which the session information is embedded to the client 302.

  Here, the request analysis process (step S1201), the business logic execution process (step S1202), the output item expansion process (step S1203), the aspect injection process (step S1204), and the response generation process (step S1205) will be described with reference to FIGS. This will be specifically described with reference to FIG.

  FIG. 13 and FIG. 14 are explanatory diagrams showing the contents of Web application execution processing by the Web server 301. First, in the request analysis process (step S1201), the AP server 1011 analyzes the content (request line, message header, entity body) of the received HTTP request and calls the business logic 1015 to be inspected. As shown in FIG. 13A, the business logic 1015 analyzes the content of the HTTP request and calculates items to be output to the screen. For example, when the business logic 1015 is the above-described Japanese calendar → West calendar conversion program 102, the date of birth of the Japanese calendar is converted to the date of birth of the Western calendar. In the case of the bad year calculation program 104, the bad year is calculated.

  Next, in the output item expansion processing (step S1203) by the JSP expansion engine 1012 of the Web server 301, the JSP expansion engine 1012 displays the display position of the output item 1310 in the JSP file 1016 as shown in FIG. To decide. For example, when the business logic 1015 is the above-described Japanese calendar → West calendar conversion program 102, the conversion result as an output item is not displayed on the gender input screen 103, so there is no need to determine the display position. On the other hand, in the case of the troubled year calculation program 104, the position of the output item 1310 is determined.

  Then, as shown in FIG. 13B, the JSP file 1016 is converted into source code in which the output position of the output item is designated. By converting into the source code, the custom tag 1301 of the JSP file 1016 is converted into the Java source fragment 1303.

  The Java source fragment 1303 is code that calls the doStartTag () method and the doEndTag () method of the class corresponding to the custom tag 1301. Then, as shown in FIG. 13C, the compiler generates a screen class file 1304 by compiling the converted source code into a binary file.

  Next, in the aspect injection process (step S1104) by the meta information insertion engine 1017 of the Web server 301, by inserting meta information into the screen class file 1304, as shown in FIG. A file 1315 is obtained.

  Next, in the response generation process (step S1205) by the AP server 1011 of the Web server 301, the AP server 1011 generates the response HTML 1320 with meta information by executing the Java class file with aspect 1315. As shown in FIG. 13E, HTML comments 1321 and 1322 are added to the response HTML 1320 with meta information. For example, in the case where the business logic 1015 is the above-described Japanese calendar → Western calendar conversion program 102, the conversion result as the output item is not displayed on the gender input screen 103, and therefore the meta information is not inserted. On the other hand, in the case of the bad year calculation program 104, meta information is inserted.

  FIG. 14 shows how the response HTML 1320 with meta information is generated by replacing the operation with the Java class file 1315 with aspect. When the meta information insertion engine 1017 is configured by an aspect-oriented programming language such as AspectJ, the meta information insertion engine 1017 and the AP server 1011 send a response HTML 1320 with meta information in the following procedures (1) to (5). Generate.

(1) The class name of the class to which the setPageContext () method of the Java source fragment 1303 belongs is acquired. In this example, “org.apache.struts.taglib.bean.WriteTag” described in the 145th line of the Java source fragment 1303 shown in FIG. 13B and FIG. Acquired as a tag class.

(2) The tag class and the setXXX () method on the Java source fragment 1303 are extracted as an attribute list. In this example, “AddForm” described in the 148th line of the Java source fragment 1303 shown in FIGS. 13B and 14A is described in the 149th line as the attribute value of the name attribute. “Result” is extracted as the attribute value of the property attribute.

(3) Immediately before the doStartTag () method is called, an HTML comment in which meta information is commented out as HTML is output. As a result, as shown in FIG. 14B, “<!-TestStart class =“ WriteTag ”name =“ AddForm ”property =“ result ”—> is displayed.

(4) The doStartTag () method and the doEndTag () method are executed, and the Web application 1014 is executed as usual. As a result, as shown in FIG. 14C, the output value “5” is displayed as the output item 1310 of the execution result.

(5) An HTML comment is output immediately after doEndTag () ends. Accordingly, as shown in FIG. 14B, “<!-TestEnd->” is displayed.

  FIG. 15 is an explanatory diagram showing the execution result of the Web application 1014 according to the above (1) to (5). As shown in FIG. 15, in the response HTML 1320 with meta information, HTML comments 1321 and 1322 indicating meta information are arranged and output before and after the output position of the output value “5” as an output item. Become.

  Next, the session information acquisition process (step S1206) will be described. The session information acquisition process (step S1206) is a process performed by the session information acquisition engine 1018. The session information acquisition engine 1018 is called by the AP server 1011 when the AP server 1011 generates a response HTML. Then, the session information is acquired using the session object 1100 described above, and the session information is embedded in the response HTML generated by the response generation process (step S1205). Hereinafter, the response HTML in which the session information is embedded is referred to as “response HTML with session information”.

  FIG. 16 is a flowchart showing a detailed processing procedure of the session information acquisition process (step S1206). In FIG. 16, first, it waits for a request object to be detected (step S1601: No), and when a request object is detected (step S1601: Yes), a session object 1100 is acquired (step S1602). Then, it is determined whether there is an unselected attribute (step S1603).

  If there is an unselected attribute (step S1603: Yes), an unselected attribute is selected (step S1604), and a character string expression of the selected attribute is extracted (step S1605). Then, the selected attribute and its character string expression are embedded as a session HTML comment as a comment sentence at the end of the generated response HTML (step S1606).

  In the Java Servlet specification, it is specified that the attribute name is a character string representation. However, since the attribute value is an arbitrary Java object excluding the primitive type, the attribute value is converted into a character string representation and formatted into an HTML comment format. . The session information acquisition engine 1018 converts this character string expression into a session HTML comment character string (HTML comment format surrounded by “<!-” And “->”).

  For example, if the attribute value of the attribute “date of birth in the Christian era” is “October 25, 2001”, the session HTML comment character string is “<!-SessionInfo Date of birth in the Western calendar =“ October 25, 2001 ” Day "->". When a plurality of attributes are extracted, a plurality of session HTML comment character strings are listed.

  FIG. 17 is an explanatory diagram showing an example of a response HTML with session information. FIG. 17 shows a response HTML 1700 with session information regarding the gender input screen 103. Thereafter, in FIG. 16, the process returns to step S1603. If there is no unselected attribute in step S1603 (step S1603: No), the session information acquisition process (step S1206) is terminated.

(Test specification creation process at the time of the first test by the client 302)
FIG. 18 is a flowchart showing a test specification creation processing procedure at the time of the initial test by the client 302. In FIG. 18, first, test specification data D1 for the initial test shown in FIG. 7 is read (step S1801). Then, the index i of the test case TCi is set to i = 1 (step S1802), and it is determined whether i> n is satisfied (step S1803). If i> n is not satisfied (step S1803: NO), an expected value information writing process for the test case TCi is executed (step S1804). Thereafter, i is incremented (step S1805), and the process returns to step S1803.

  Thereafter, when i> n (step S1803: Yes), the test specification data D1 is displayed by the Web browser 1021 (step S1806). The test specification data D1 displayed at this time is as shown in FIG. Thereby, expected value information can be confirmed visually.

  Then, it is determined whether or not a test case has been added (step S1807). When there is an addition (step S1807: Yes), it is determined whether i> m is satisfied (step S1808). m is the total number of test cases after addition.

  If i> m is not satisfied (step S1808: NO), expected value information writing processing for the test case TCi is executed (step S1809). Thereafter, i is incremented (step S1810), and the process returns to step S1808.

  Thereafter, when i> m (step S1808: Yes), the test specification data D1 is displayed by the Web browser 1021 (step S1811). Thereby, the expected value information for the additional portion can be confirmed visually. Then, the process returns to step S1807.

  If no test case is added in step S1807 (step S1807: NO), an output process to the test specification DB 310 is executed for the test specification data D1 (step S1812). As a result, the series of processes is completed.

(Expectation value information writing process of test case TCi)
Next, a specific processing procedure of the expected value information writing process of the test case TCi shown in steps S1804 and S1809 will be described. FIG. 19 is a flowchart illustrating a specific processing procedure of expected value information writing processing of the test case TCi.

  In FIG. 19, first, an HTTP request for an initial screen is transmitted to the Web server 301 (step S1901). Taking the test case TC1 of the test specification data D1 shown in FIG. 5 as an example, the birth date input screen 101 is an initial screen, and thus an HTTP request for the birth date input screen 101 is transmitted to the Web server 301.

  After transmitting an HTTP request to the Web server 301, a response HTML corresponding to the HTTP request is received (step S1902). Since session information (session HTML comment character string) is not embedded on the date of birth input screen 101, meta information and session information are not embedded in the received HTML response.

  On the other hand, the gender input screen 103 receives a response HTML with session information in which session information is embedded. On the bad year display screen 105, a response HTML with session information in which meta information and session information are embedded is received. Here, these are collectively referred to as “reception response HTML”.

  Then, the reception response HTML is displayed by the Web browser 1021 (step S1903). In the reception response HTML, embedded meta information and session information are not displayed when displayed by the Web browser 1021, but are subject to analysis.

  Thereafter, the Web browser 1021 analyzes the reception response HTML and executes expected value information extraction processing (step S1904). When there is no meta information or session information, the expected value information extraction process (step S1904) is not executed, but when there is meta information or session information, the expected value information extraction process (step S1904) is executed. Details of the expected value information extraction process (step S1904) will be described later.

  Then, the extracted expected value information is written into a blank cell of the test case TCi (step S1905). Thereafter, in the test case TCi, it is determined whether there is a transition destination screen that transitions from the current Web screen (step S1906).

  When there is a transition destination screen (step S1906: Yes), it waits for input information as described in the operation procedure description on the current Web screen to be received (step S1907: No). Taking the test case TC1 of the test specification data D1 shown in FIG. 5 as an example, the operation procedure description on the date of birth input screen 101 is entered as “select gender“ male ”and click“ bad year display ”” Wait for input information to be accepted.

  When the input information is accepted (step S1907: Yes), the HTTP request for the transition destination screen, that is, the HTTP request including the input information is transmitted to the web server 301 (step S1908). Thereafter, the process returns to step S1902. On the other hand, in step S1906, when there is no transition destination screen (step S1906: No), the process proceeds to step S1805 (S1810). As a result, the expected value information write processing procedure for a series of test cases TCi is completed.

(Expected value information extraction process)
FIG. 20 is a flowchart showing a detailed processing procedure of expected value information extraction processing (step S1904). In FIG. 20, first, a screen item expected value is extracted from a position surrounded by a testStart tag and a testEnd tag (step S2001). If there is no testStart tag and testEnd tag, no extraction is performed. Next, a list of sessionInfo tags is acquired (step S2002).

  Then, it is determined whether or not there is an unprocessed sessionInfo tag (step S2003). If there is an unprocessed sessionInfo tag (step S2003: Yes), the contents of the unprocessed sessionInfo tag are acquired (step S2004). For example, in the response HTML1700 with session information shown in FIG. 17, “<!-SessionInfo date of birth =“ October 25th, 2001 ”->” of “<! The date of birth = “October 25, 2001” is acquired.

  Then, in the acquired content, the description before “=” is identified as the attribute name, and the description after is identified as the attribute value (step S2005), and the process returns to step S2003. In the previous example, “date of birth in the Christian era” is the attribute name, and “October 25, 2001” is the attribute value. If there is no unprocessed SessionInfo tag in step S2003 (step S2003: No), the process proceeds to step S1905. Thus, in step S1905, the screen item expected value and the session information are associated with each other and written in the test specification data D1.

(Test specification creation process during regression test by client 302)
Next, a test specification creation process at the time of a regression test by the client 302 will be described. The test specification data is created by the Web browser 1021 and the execution navigator 1022. The client 302 reads test specification data for the regression test.

  FIG. 21 is an explanatory diagram showing test specification data for a regression test. The difference from the test specification data D1 for the initial test shown in FIG. 5 is that “expected value information” is “actual value information”, “screen item expected value” is “screen item actual value”, and “session expectation”. The “value” is changed to the “session performance value”. In the test specification data D2 for the regression test, the cell of the actual value information is blank before the regression test.

  FIG. 22 is an explanatory diagram showing the test specification data D2 after automatic creation during the regression test. There is a cell in which performance value information is embedded by a regression test. Next, a test specification creation process procedure by the client 302 will be described.

  FIG. 23 is a flowchart showing a test specification creation processing procedure at the time of a regression test by the client 302. In FIG. 23, first, the test specification data D2 for the regression test shown in FIG. 21 is read (step S2301).

  Then, the index i of the test case TCi is set to i = 1 (step S2302), and it is determined whether i> n is satisfied (step S2303). If i> n is not satisfied (step S2303: NO), the actual value information writing process of the test case TCi is executed (step S2304). Thereafter, i is incremented (step S2305), and the process returns to step S2303.

  Thereafter, when i> n (step S2303: Yes), the test specification data D2 is displayed by the Web browser 1021 (step S2306). The test specification data D2 displayed at this time is as shown in FIG. Thereby, performance value information can be confirmed visually. Thereafter, an output process to the test specification DB 310 is executed for the test specification data D2 (step S2307). As a result, the series of processes is completed.

(Test value TCi result value information writing process)
Next, a specific processing procedure of the actual value information writing process of the test case TCi shown in step S2304 will be described. FIG. 24 is a flowchart showing a specific processing procedure of the actual value information writing process of the test case TCi.

  In FIG. 24, first, an HTTP request for an initial screen is transmitted to the Web server 301 (step S2401). Taking the test case TC1 of the test specification data D2 shown in FIG. 21 as an example, the birth date input screen 101 is an initial screen, and thus an HTTP request for the birth date input screen 101 is transmitted to the Web server 301.

  After transmitting an HTTP request to the Web server 301, a response HTML corresponding to the HTTP request is received (step S2402). Since session information (session HTML comment character string) is not embedded on the date of birth input screen 101, meta information and session information are not embedded in the received HTML response.

  On the other hand, the gender input screen 103 receives a response HTML with session information in which session information is embedded. On the bad year display screen 105, a response HTML with session information in which meta information and session information are embedded is received. Here, these are collectively referred to as “reception response HTML”.

  Then, the reception response HTML is displayed by the Web browser 1021 (step S2403). In the received response HTML, the embedded meta information and session information are not displayed when displayed by the Web browser 1021, but are subject to analysis.

  Thereafter, the received response HTML is analyzed by the Web browser 1021, and the performance value information extraction process is executed (step S2404). When there is no meta information or session information, the actual value information extraction process (step S2404) is not executed, but when there is meta information or session information, the actual value information extraction process (step S2404) is executed. Details of the performance value information extraction process (step S2404) will be described later.

  Then, the extracted actual value information is written in a blank cell of the test case TCi (step S2405). Thereafter, in the test case TCi, it is determined whether there is a transition destination screen that transitions from the current Web screen (step S2406).

  When there is a transition destination screen (step S2406: Yes), it waits for input information as described in the operation procedure description on the current Web screen to be received (step S2407: No). Taking the test case TC1 of the test specification data D2 shown in FIG. 21 as an example, the operation procedure description on the date of birth input screen 101 is input according to “select gender“ male ”, click“ bad year display ”” Wait for input information to be accepted.

  When the input information is accepted (step S2407: Yes), an HTTP request for the transition destination screen, that is, an HTTP request including this input information is transmitted to the Web server 301 (step S2408). Thereafter, the process returns to step S2402. On the other hand, if there is no transition destination screen in step S2406 (step S2406: No), the process proceeds to step S2305. Thereby, the result value information writing process procedure of a series of test cases TCi is completed.

(Actual value information extraction processing)
FIG. 25 is a flowchart showing a detailed processing procedure of the actual value information extraction processing (step S2404). In FIG. 25, first, the screen item actual value is extracted from the position surrounded by the testStart tag and the testEnd tag (step S2501). If there is no testStart tag and testEnd tag, no extraction is performed. Next, a list of sessionInfo tags is acquired (step S2502).

  Then, it is determined whether there is an unprocessed sessionInfo tag (step S2503). If there is an unprocessed sessionInfo tag (step S2503: Yes), the contents of the unprocessed sessionInfo tag are acquired (step S2504). For example, in the response HTML1700 with session information shown in FIG. 17, “<!-SessionInfo date of birth =“ October 25th, 2001 ”->” of “<! The date of birth = “October 25, 2001” is acquired.

  In the acquired contents, the description before “=” is identified as the attribute name, and the description after is identified as the attribute value (step S2505), and the process returns to step S2503. In the previous example, “date of birth in the Christian era” is the attribute name, and “October 25, 2001” is the attribute value. In step S2503, when there is no unprocessed sessionInfo tag (step S2503: No), the process proceeds to step S2405. Thus, in step S2405, the screen item actual value and the session information are associated and written to the test specification data D2.

(Bug location processing)
Next, the bug position specifying process by the client 302 will be described. The execution navigator 1022 performs the bug location specifying process. The bug location specifying process is performed by comparing the test specification data D1 for the initial test that has been subjected to the initial test (FIG. 9) with the test specification data D2 for the regression test that has been subjected to the regression test (FIG. 22).

  FIG. 26 is an explanatory diagram showing the test specification data D2 for the regression test after comparison with the test specification data D1 for the initial test. The actual value information of the test specification data D2 in FIG. 26 is the same as that in FIG. A difference from FIG. 22 is that cells having different values from the test specification data D1 are shaded.

  For example, in the gender input screen 103 of the test case TC1, the expected session value in FIG. 9 is “October 25, 2001”, whereas the actual session value in FIG. 26 is “October 25, 2000”. . Further, in the bad year display screen 105 of the test case TC1, the screen item expected value in FIG. 9 is “2025, 2042, 2061”, whereas the screen item actual value in FIG. 26 is “2024, 2041”. , 2060 ". Further, the expected session value in FIG. 9 is “October 25, 2001”, whereas the actual session value in FIG. 26 is “October 25, 2000”.

  As shown in FIG. 26, in the test case TC1, the screen item actual value “2024, 2041, 2060” displayed on the bad year display screen 105 by the Web browser 1021 is the screen item expected value of FIG. Since it is different from “2025, 2042, 2061”, it is considered that there is a bug in the bad year calculation program 104 that has output the bad year display screen 105. However, looking at the session result value, it can be seen that the session result value of the gender input screen 103 which is the transition source screen of the bad year display screen 105 is different from the expected session value.

  Therefore, in this case, it should be determined that there is a bug in the Japanese calendar → Western calendar conversion program 102 that outputs the gender input screen 103. In the first embodiment, since the bug position in the source code of the Web application 1014 is not specified, the bug position in this case is the gender input screen 103.

  FIG. 27 is a flowchart showing the bug position identification processing procedure (part 1). In FIG. 27, first, both test specification data D1 and D2 are read (step S2701). Next, an initial screen is selected (step S2702). Then, it is determined whether or not the expected value for the selection screen is in the specification data D1 (step S2703). Here, if at least one of the screen item expected value and the session expected value is written in the cell of the test specification data D1, it is determined that there is an expected value.

  When there is no expected value (step S2703: No), the process proceeds to step S2709. On the other hand, when there is an expected value (step S2703: Yes), the actual value corresponding to the existing expected value is specified from the specification data D2 (step S2704). Then, it is determined whether the screen item expected value matches the screen item actual value (step S2705). If there is no expected screen item value and no actual screen item value, the process proceeds to step S2707. If they do not match (step S2705: NO), the screen item actual value of the test specification data D2 is highlighted (step S2706), and the process proceeds to step S2707. On the other hand, if they match (step S2705: YES), the process proceeds to step S2707.

  In step S2707, it is determined whether or not the expected session value matches the actual session value (step S2707). If there is no expected session value or actual session value, the process proceeds to step S2709. If they do not match (step S2707: NO), the session result value of the test specification data D2 is highlighted (step S2708), and the process proceeds to step S2709. On the other hand, if they match (step S2707: YES), the process proceeds to step S2709.

  In step S2709, it is determined whether there is a transition destination screen (step S2709). If there is a transition destination screen (step S2709: YES), the transition destination screen is selected (step S2710), and the process returns to step S2703. On the other hand, when there is no transition destination screen (step S2709: No), a series of processing is terminated. As a result, test specification data D2 as shown in FIG. 26 is obtained, so it is possible to visually recognize which screen is the bug position. In this example, the test specification data D2 is highlighted, but the test specification data D1 may be highlighted.

  FIG. 28 is a flowchart (first half) showing the bug position specifying process procedure (part 2), and FIG. 29 is a flowchart (second half) showing the bug position specifying process procedure (part 2). In the bug position specifying processing procedure (part 1) shown in FIG. 27, the bug position is specified by highlighting the cell of the test specification data D2 having a value different from that of the test specification data D1 and visually recognizing the user. However, the bug position specifying processing procedure (part 2) is an example of automatically specifying the bug position. This bug position specifying process procedure (part 2) is executed for each test case TCi.

  In FIG. 28, first, both test specification data D1 and D2 are read (step S2801). Next, an initial screen is selected (step S2802). Then, it is determined whether or not the expected value for the selection screen is in the specification data D1 (step S2803). Here, if at least one of the screen item expected value and the session expected value is written in the cell of the test specification data D1, it is determined that there is an expected value.

  If there is no expected value (step S2803: NO), the process proceeds to step S2809. On the other hand, when there is an expected value (step S2803: Yes), the actual value corresponding to the existing expected value is specified from the specification data D2 (step S2804). Then, it is determined whether or not the screen item expected value matches the screen item actual value (step S2805).

  If there is no expected screen item value and no actual screen item value, the process proceeds to step S2807. If they do not match (step S2805: No), the screen item mismatch flag is turned ON (step S2806), and the process proceeds to step S2807. On the other hand, if they match (step S2805: YES), the process proceeds to step S2807.

  In step S2807, it is determined whether the session expected value matches the session performance value (step S2807). If there is no expected session value and actual session value, the process proceeds to step S2809. If they do not match (step S2807: NO), the session mismatch flag is turned ON (step S2808), and the process proceeds to step S2809. On the other hand, if they match (step S2807: YES), the process proceeds to step S2809.

  In step S2809, it is determined whether there is a transition destination screen (step S2809). If there is a transition destination screen (step S2809: Yes), the transition destination screen is selected (step S2810), and the process returns to step S2803. On the other hand, when there is no transition destination screen (step S2809: No), the process proceeds to step S2901 in FIG.

  In FIG. 29, it is determined whether or not there is a screen whose screen item mismatch flag and session mismatch flag are both ON (step S2901). If there is no screen in which both flags are ON (step S2901: No), it is determined that there is no bug (step S2902), and the process proceeds to step S2907.

  On the other hand, if there is a screen in which both flags are ON (step S2901: YES), at least an incorrect value will be displayed. Therefore, the screen on which the session mismatch flag is first turned on is identified (step S2903). Then, it is determined whether or not the specified screen is the same screen as the screen in which both flags are turned on in step S2901 (step S2904).

  If they are not the same screen (step S2904: No), the screen with both flags ON is determined as the bug display screen, the screen specified in step S2903 is determined as the bug position (step S2905), and the process proceeds to step S2907.

  On the other hand, if the screen is the same as both flags ON (step S2904: YES), the screen with both flags ON is determined as the bug position (step S2906), and the process proceeds to step S2907. In step S2907, various determination results are output (step S2907). As a result, the series of processes is completed.

  In the test specification data D2 of FIG. 22, in the test case TC1, the screen item actual value and the session actual value of the bad year display screen 105 are the screen item expected value and the session expected value of the bad year display screen 105 of the test specification data D1. Different. Therefore, the troubled year display screen 105 becomes the “both flag ON screen” in step S2901. Further, the session result value on the gender input screen 103 is different from the expected session value of the test specification data D1.

  Therefore, the gender input screen 103 becomes the “specified screen” in step S2903. Accordingly, in this case, the troubled year display screen 105 becomes a bug display screen and the gender input screen 103 is determined as a bug position in step S2905. As a result, the tester can determine that there is a bug in the Japanese calendar to Western calendar conversion program 102 that calls the gender input screen 103.

  If the session result value on the gender input screen 103 matches the expected session value of the test specification data D1, the troubled year display screen 105 becomes the “specified screen” in step S2903. Thus, in this case, the troubled year display screen 105 is determined as the bug position in step S2905. Thereby, the tester can determine that there is a bug in the bad year calculation program 104 that calls the bad year display screen 105.

  As described above, in the first embodiment, by comparing the test specification data D1 and D2, it is possible to automatically specify the Web screen obtained by the bug from the Web screens output from the Web application 1014. Therefore, it is possible to reduce the time for bug detection, and it is possible to reduce the overall time required for bug correction. As a result, the development cycle can be shortened and the work period for software development in general can be reduced.

<Embodiment 2>
Next, a second embodiment will be described. In the first embodiment, the screen output by the bug is specified as the bug position by comparing the test specification data D1 and D2. That is, when the same input operation is performed in the initial test and the regression test, if there is a difference in the session information, it is determined that a bug has occurred in the processing.

  In the session information to be compared, information such as an ID number such as a date and a reception number / reservation number may be held. Since such information is information that may change every time, the test specification data D1 and the test specification data D2 may have different values. For this reason, in the second embodiment, as the basic information for bug detection, it is possible for the tester to specify what is necessary and what is not necessary, thereby improving the accuracy of specifying the bug position at the time of bug detection. Plan. Note that the description of the same configuration and the same process as in the first embodiment is omitted.

  FIG. 30 is an explanatory diagram showing a program for recording information in the session object 1100. In the first embodiment, for the sake of simplicity, a method for storing single information (one object having an attribute name “date of birth of the year”) for the session object 1100 is shown. On the other hand, when more information is recorded in the session object 1100, it is often preferred to record the information as a JavaBean rather than recording each information one by one.

  FIG. 31 is an explanatory diagram of an example (part 1) of JavaBean source code. In FIG. 31, two pieces of information (“birthday of the Christian era” and “access date”) are stored in one JavaBean, and the JavaBean holding the plurality of pieces of information is the session object 1100 in the fourth line of FIG. Stored in

  In JavaBean, each element stored in JavaBean is called a property, and a method for reading and writing information with respect to the property is called an accessor. In particular, a method for acquiring information from JavaBean is called a getter, and a method for writing information to JavaBean is called a setter.

  In the example of FIG. 31, the same content should always be obtained for the property “birthday of the Christian era” if the information input on the date of birth input screen 101 is the same. In other words, when a bug is detected, if the birthday information differs between the initial test and the regression test, it can be determined that the bug location is specified.

  On the other hand, the access time stores the system time of the Web server 301 at the moment when the Japanese calendar → Western calendar conversion program 102 is executed. For this reason, different times are always stored in the initial test and the regression test. It is necessary to remove the expected session value of the session information regarding the access date from the expected session value stored in the test specification data D1.

  FIG. 32 is an explanatory diagram of an example of JavaBean source code (part 2). When developing a JavaBean, the developer of the Web application 1014 adds an annotation “@Ignore” before a property that is not to be recorded as an expected value, such as an access date. In the example of FIG. 32, the “@Ignore” annotation is added immediately before the declaration of the “access date” property in JavaBean.

  The information “Ignore” is interpreted according to the metadata specification of Java, and can be left in the Java class file 1315 with an aspect after compilation. Furthermore, when the Web application 1014 is executed, the session information acquisition engine 1018 determines whether or not the “@Ignore” annotation is added to each property. It is also possible to extract session information that has not been added.

(Session information acquisition process)
FIG. 33 and FIG. 34 are flowcharts showing a session information acquisition processing procedure by the session information acquisition engine 1018 according to the second embodiment. The same processes as those in FIG. 16 are denoted by the same step numbers, and the description thereof is omitted.

  First, in FIG. 33, after selecting an unselected attribute in step S1604 (step S1604), it is determined whether or not the selected attribute is JavaBean (step S3300). As a judgment standard, if there is at least one method starting with “get” in the attribute object, it is determined that the JavaBean is used. Otherwise, the JavaBean is not used. If it is not JavaBean (step S3300: No), the character string representation of the selection attribute is extracted (step S1605). On the other hand, if it is JavaBean (step S3300: Yes), the process proceeds to step S3401 in FIG.

  In step S3401, it is determined whether there is an unselected property (step S3401). If there is an unselected property (step S3401: YES), an unselected property is selected (step S3402). Then, it is determined whether or not “@Ignore” annotation is added to the selected property (step S3403). If the “@Ignore” annotation is added (step S3403: YES), the selected property is ignored and the process returns to step S3401.

  On the other hand, if the “@Ignore” annotation is not added (step S3403: NO), the character string representation (property value) of the selected property is extracted because it is an acquisition target (step S3404).

  Since the property itself is often defined as a private scope that cannot be accessed from the outside in the program, the property value is obtained by calling the getter method corresponding to the property name. Since the getter method has “get” or “Is” added in front of the property name, it can be easily specified. For example, when the property name is “Birthday of the Christian era”, the getter method name is “Birthday of the Christian era”.

  Thereafter, the attribute name, property name, and property value of the session information are embedded as an HTML comment at the end of the response HTML (step S3405). “.” (Period) is specified as a delimiter (character for separating information and information) between the attribute name and property name of the session information. In this example, “birthday”, “birthday of the Christian era”, and “October 25, 2001” can be acquired as the attribute name, property name, and property value of the session information, respectively. The column is “<!-SessionInfo birth date. Birth date in the Christian era =“ October 25, 2001 ”->”.

  This operation is repeated for the number of attributes in the session object 1100. When the processing for all the attributes is completed, all the attributes have been output, and the processing ends. In this way, information to be recorded in the session object 1100 is JavaBean, and information used as expected values and information not used are managed separately in the information, so that only information necessary for inspection is expected values. Can be recorded as

  Therefore, it is possible to improve the accuracy regarding the bug position specification. Further, since unnecessary information can be easily deleted, the readability and maintainability of the test specification data D1 and D2 are improved, and the amount of resources used such as memory and hard disk is reduced.

  In the second embodiment, a method for annotating a JavaBean property (also referred to as a field) definition statement has been proposed. However, even if an annotation is added to a getter method, the session expected value (or session result value) is also captured. It is possible to determine whether or not. In addition, annotations are given to properties to be ignored as expected values. Conversely, properties to be imported as session expected values (or session actual values) may be annotated, and annotations with different names for properties to be ignored and properties to be imported. May be added. Moreover, you may enable it to designate the annotation with respect to the whole JavaBean class.

  In addition, when using a Java virtual machine that does not correspond to JSR (Java Specification Request) -175 metadata, it is possible to specify whether or not to capture as an expected value by adding a keyword such as transient.

<Embodiment 3>
Next, a third embodiment will be described. In the first and second embodiments, it is possible to specify the bug position in units of screens, but it is not possible to diagnose at a finer level (class unit, method unit, line number unit, etc.).

  For example, when the gender input screen 103 is specified as a bug position, it can be specified on the program that there is a bug in the Japanese calendar → West calendar conversion program 102. For example, any class or method in the Japanese calendar → West calendar conversion program 102 can be specified. It is not possible to specify the place. In particular, when the Japanese calendar to Western calendar conversion program 102 depends on other libraries, the part of the bug position that is manually relied upon becomes large.

  In the third embodiment, when writing in the session information is detected, the class name and method name of the program that performed the writing are also acquired and output to the Web browser 1021 as a response HTML, so that the screen level is more detailed. Identify the bug location. In addition, description is abbreviate | omitted about the same structure as Embodiment 1, 2, and the same process.

  FIG. 35 and FIG. 36 are sequence diagrams when the Web application 1014 is executed. In this sequence diagram, the Web browser 1021 and the AP server 1011 communicate with each other, and the Web application 1014 (the troubled year display program 100 shown in the first and second embodiments) called from the AP server 1011 and the session object 1100 are identified. It shows how to exchange information.

  First, the Web browser 1021 transmits an HTTP request for the first access, that is, the first screen (birth date input screen 101) to the AP server 1011 (step S3501). The AP server 1011 receives the HTTP request and calls the Web application 1014 corresponding to the content of the HTTP request (step S3502). The Web application 1014 executes the Japanese calendar → Western calendar conversion program 102 as the business logic 1015 (step S3503). In this process, writing to the session object 1100 is performed. Writing to the session object 1100 is performed according to the following procedure.

  The Web application 1014 makes an acquisition request for the session object 1100 to the AP server 1011 (step S3504). In order to respond to this acquisition request, the AP server 1011 first searches whether the session object 1100 for the session already exists (step S3505). If the session object 1100 is found, the AP server 1011 returns a reference to the session object 1100 to the Web application 1014 (step S3506).

  If the session object 1100 is not found, the session object 1100 constructor is called to create the session object 1100 (step S3505). The session object 1100 is executed because the constructor has been called (step S3507). Then, after calling the method of the session object 1100 and storing necessary information, a reference to the session object 1100 is returned to the Web application 1014 (step S3506).

  As a result, the Web application 1014 acquires the session object 1100 and can access the session object 1100 (step S3508). Next, the Web application 1014 makes a session write request (step S3509). Specifically, the setAttribute method of the session object 1100 is called to write information into the session object 1100 (step S3510).

  Finally, the Web application 1014 creates a response HTML and notifies the AP server 1011 (step S3511). The AP server 1011 passes this response HTML to the session information acquisition engine 1018, adds a session HTML comment to the end of the response HTML, and then returns the response HTML with session information to the Web browser 1021 (step S3512). The web browser 1021 analyzes the response HTML and displays it on the screen of the client 302 (step S3513).

  The same operation is performed for the second and subsequent screens. In FIG. 36, first, after entering the gender on the gender input screen 103, clicking the troublesome year calculation button transmits the HTTP request to the AP server 1011 (step S3601). The AP server 1011 receives the HTTP request and calls the Web application 1014 corresponding to the content of the HTTP request (step S3602). The Web application 1014 executes the troubled year calculation program 104 as the business logic 1015 (step S3603).

  In the second and subsequent screens, since the session object 1100 has already been created, when the Web application 1014 makes a session acquisition request (step S3604), the AP server 1011 creates an existing session object 1100 without creating a new session object 1100. A reference to the session object 1100 is returned (step S3605).

  As a result, the Web application 1014 acquires the session object 1100 and can access the session object 1100 (step S3606). Next, the Web application 1014 acquires information from the session object 1100 (step S3607). Specifically, the web application 1014 accesses the session information by calling the getAttribute method of the session object 1100 and retrieves the information (step S3608). The Web application 1014 executes a bad year calculation by the business logic 1015 (the bad year calculation program 104) based on the information acquired from the session object 1100 (step S3609).

  Finally, the Web application 1014 creates a response HTML and returns it to the AP server 1011 (step S3610). The AP server 1011 passes this response HTML to the session information acquisition engine 1018, adds a session HTML comment to the end of the response HTML, and then returns the response HTML with session information to the Web browser 1021 (step S3611). The Web browser 1021 analyzes the response HTML and displays the troubled year display screen 105 on the screen of the client 302 (step S3612).

  In the third embodiment, the behavior of the session object 1100 is changed by incorporating the aspect before and after the execution of the setAttribute method, which is a method for writing to the session object 1100 when performing the above-described operation, and the contents of the session object 1100 Specify when to change. The operation of this woven aspect will be described in detail.

  The aspect is woven when the setAttribute method of the HttpSession class that is a class of the session object 1100 is called. An aspect refers to a process of automatically adding another logic before and after a specific program code such as a method call. Here, another process is added before the setAttribute method is called. The setAttribute method may be called a plurality of times in one screen process (refers to the period from when the AP server 1011 receives an HTTP request and returns a response HTML). The aspect can be woven by a tool such as AspectJ in the case of Java language.

Specifically, the aspect has the following functions.
• Initialization for each call of each screen (records only the call information obtained by processing of one screen).
-Acquisition of the class name and method name of the caller of setAttribute ().
-Get the line number on the program that called setAttribute ().
-Acquisition of the first argument and the second argument of setAttribute (). Call toString () for the second argument to convert it to String type notation.
Create an attribute information object (List <SetAttributeInfo> type) that stores all the above information. This attribute information object is also stored with an attribute of HttpSession.
When setAttribute () is called multiple times, each information is stored in time series as serial information (each element of List).

  FIG. 37 is a flowchart showing an aspect operation processing procedure. First, it waits for the call of the setAttribute method to be detected (step S3701: No). If it is detected (step S3701: YES), the write data list is cleared (step S3702).

  The write data list is an object for managing a write process to the session object 1100 performed in one screen process, and a plurality of session write information can be stored as a list. This is because only the session writing information for the session object 1100 for one screen is taken out and stored in the test specification DB 310.

  Then, the class name, method name, and line number of the call source program of the setAttribute method are acquired (step S3703). Also, the values of the first argument and the second argument of the setAttribute method are acquired and converted into character string types, respectively (step S3704).

  Next, the aspect additionally records all the session writing information (class name, method name, line number, first argument, second argument) extracted in the write data list (step S3705). The write data list is also recorded as an attribute to the session object 1100 (step S3706). Then, the process returns to step S3701.

  In the third embodiment, the session information acquisition engine 1018 outputs the attribute information object as an HTML comment. As an output format, it is output as accompanying information for the session information output in the first embodiment in attribute units of the HTTP Session object.

  Specifically, for example, the first argument of setAttribute () is output to a position obtained using the key. If there is a plurality of pieces of session writing information for one session information, they are separated in commas in time series. The format of each session writing information is setAttributeInfo = “class name # attribute name (): line number: string expression of second argument”.

  FIG. 38 is an explanatory diagram of an example of a response HTML with session information according to the third embodiment. In response HTML 3800 with session information, initialization is performed (set null) with the init method of the E-change class, and a value is written with the execute method.

  FIG. 39 is a flowchart (part 1) illustrating a session information acquisition processing procedure by the session information acquisition engine 1018 according to the third embodiment. The same processes as those in the flowchart shown in FIG. 16 are denoted by the same step numbers, and the description thereof is omitted.

  In FIG. 39, after acquiring the session object 1100 (step S1602), a write data list is extracted from the session object 1100 (step S3901). Then, it is determined whether there is an unselected attribute (step S1603). In step S1605, after extracting the character string representation of the selection attribute, session writing information (class name, method name, line number, first argument, second argument) of the selection attribute is extracted from the write data list. (Step S3902). Then, the session HTML comment character string including the session information and the session writing information is embedded as a comment sentence in the response HTML (step S3903). Then, the process returns to step S1603.

  40 and 41 are flowcharts (part 2) illustrating the session information acquisition processing procedure by the session information acquisition engine 1018 according to the third embodiment. The same processes as those in the flowcharts shown in FIGS. 33 and 34 are denoted by the same step numbers, and the description thereof is omitted.

  In FIG. 40, after acquiring the session object 1100 (step S1602), a write data list is extracted from the session object 1100 (step S4001). Then, it is determined whether there is an unselected attribute (step S1603). In step S1605, after extracting the character string representation of the selection attribute, session writing information (class name, method name, line number, first argument, second argument) of the selection attribute is extracted from the write data list. (Step S4002).

  Then, the session HTML comment character string including the session information and the session writing information is embedded as a comment sentence in the response HTML (step S4003). Then, the process returns to step S1603.

  Also, in FIG. 41, after extracting the character string representation of the selected property (step S3404), the session writing information (class name, method name, line number, first argument, second argument) of the selected attribute from the write data list. ) Is extracted (step S4101). Then, the session HTML comment character string including the session information and the session writing information is embedded as a comment sentence in the response HTML (step S4102). Then, the process returns to step S3401.

(Data structure of test specification data for initial test)
FIG. 42 is an explanatory diagram of the data structure of the test specification data for the initial test according to the third embodiment. FIG. 42 shows the test specification data D31 for the initial test, and the cell in the expected value information is blank because it is before the initial test. The difference from the test specification data D1 used in the first and second embodiments is that session writing information is added as expected value information. Since the class, method, line number, and second argument are embedded in the session write information, these are written when the first test is executed.

  FIG. 43 is an explanatory diagram of a data structure of the test specification data D31 that has been subjected to the initial test according to the third embodiment. Since the initial test has been executed, information is written in the cells in the expected value information.

(Expected value information extraction process)
FIG. 44 is a flowchart of a detailed processing procedure of expected value information extraction processing according to the third embodiment. The same processes as those shown in FIG. 20 are denoted by the same step numbers and description thereof is omitted. After identification in step S2005, the part after “setAttributeInfo =” is analyzed and divided into a class name, a method name, a line number, and a second argument (step S4400). Thereby, in step S1905, the screen item expected value, the session expected value, and the session writing information are written in the test specification data D31.

  In the case of FIG. 38, for the first session writing information, the class name is “EraChanger”, the method name is “init”, the line number is “123”, and the second argument is “null”. For the second session write information, the class name is “EraChanger”, the method name is “execute”, the line number is “234”, and the second argument is “October 25, 2001”. By this expected value information extraction process, the data structure as shown in FIG. 43 is obtained.

(Data structure of test specification data for regression testing)
FIG. 45 is an explanatory diagram of a data structure of test specification data for a regression test according to the third embodiment. FIG. 45 shows the test specification data D32 for the regression test, and since the regression test is performed, the cells in the actual value information are blank. The difference from the test specification data D2 used in the first and second embodiments is that session writing information is added as actual value information. Since the class, method, line number, and second argument are embedded in the session write information, these are written when the regression test is executed.

  FIG. 46 is an explanatory diagram of a data structure of the test specification data D32 that has been subjected to the regression test according to the third embodiment. Since the first test has been executed, information is written in the cells in the actual value information.

(Actual value information extraction processing)
FIG. 47 is a flowchart of a detailed processing procedure of performance value information extraction processing according to the third embodiment. The same processes as those shown in FIG. 25 are denoted by the same step numbers and description thereof is omitted. After identification in step S2505, the part after “setAttributeInfo =” is analyzed and divided into a class name, a method name, a line number, and a second argument (step S4700). Thereby, in step S2405, the screen item result value, the session result value, and the session writing information are written in the test specification data D32.

(Bug location processing)
FIG. 48 is a flowchart of a bug position specifying process procedure according to the third embodiment. The same steps as those shown in FIG. 27 are denoted by the same step numbers and description thereof is omitted. In FIG. 27, the test specification data D1 and D2 are used here. However, here, the test specification data D31 and D32 are used.

  If the session does not match in step S2707 (step S2707: No), the session result value and the session writing information are highlighted (step S4800). Then, control goes to a step S2709. As a result, the session writing information can be highlighted, the screen called by the program having the bug can be specified, and the class name, method name, line number, and second argument of the calling source program can also be specified. Can do.

  FIG. 49 is an explanatory diagram showing the data structure of the test specification data D32 after the bug position specifying process. On the sex input screen 103 of the test case TC1, the attribute value is set to null in the 123rd line of the EraChanger class and init method, and “October 25, 2000” is set in the 234th line of the EraChanger class and execute method. Can be confirmed.

  On the other hand, in the test specification data D31 shown in FIG. 43, the expected session value is “October 25, 2001”, the session writing information is EraChanger class, the 123rd line of the init method is null, and EraChanger The 234th line of the class and execute method is “October 25, 2001”. Compared to these, it can be determined that the bug is embedded in the 234th line of the EraChanger class and execute method.

  As described above, according to the third embodiment, it is possible to specify the position where the bug exists, not to the screen unit, but to the specific position of the program, and it is possible to specify the bug position with higher accuracy.

(Combination with static analysis)
FIG. 50 is an explanatory diagram showing a source code of a program for explaining a combination with static analysis. In the third embodiment, there is a possibility that the session writing information is processed at another place on the program and the final form stored in a variable or the like is visible.

  For example, in the case of the source code 5000 as shown in FIG. 50, if only the application of the third embodiment is applied, only the fifth line is specified as the bug position, but the factday variable is actually processed as shown in FIG. All underlined lines are relevant. That is, the content of the year variable obtained by processing in the ninth line is written into the session object 1100 through function call, return, and the like.

  In such a case, by combining with a static analysis tool of a source program that has already been proposed such as checkstyle or Findbugs, it is possible to specify the assignment position to a variable associated with a code considered to have a bug. Because it is possible, the location of the bug can be specified and guessed in more detail.

  FIG. 51 is a flowchart showing a bug position specifying process procedure when static analysis is applied. From the execution result shown in FIG. 48, the class name and line number causing the failure are acquired (step S5101). Next, the source code of the class having the acquired class name is acquired (step S5102). In the above example, the fifth line of the source code in FIG. 50 is acquired. Then, the source code associated with the acquired line number and the line number are acquired by static analysis (step S5103). In the above example, the fourth, fifth and ninth to twelfth lines of the source code in FIG. 50 are acquired. Then, the program name and line number of the acquired source code are output (step S5104). As a result, the tester is notified.

<Functional configuration of Web application 1014 inspection system>
Next, a functional configuration of the Web application inspection system 300 according to the first to third embodiments will be described. FIG. 52 is a block diagram of a functional configuration of the Web application inspection system 300 according to the first to third embodiments. Specifically, for example, each block is executed by causing the CPU 401 to execute a program stored in a storage area such as the ROM 402, the RAM 403, the magnetic disk 405, and the optical disk 407 shown in FIG. 4 or by the I / F 409. Realize its function.

  First, the Web server 301 will be described. The Web server 301 includes a communication unit 5201, an execution unit 5202, a storage unit 5203, a generation unit 5204, and an insertion unit 5205. The communication unit 5201 has a function of receiving, from the client 302, a request for requesting a Web screen having a screen transition specification selected from a series of screen transition specifications included in the test case of the Web application 1014. Specifically, an HTTP request is received from the client 302. For example, when the date of birth input screen 101 is displayed on the Web browser 1021 of the client 302, an HTTP request for requesting the sex input screen 103, which is the Web screen of the transition destination, is received.

  The communication unit 5201 has a function of transmitting a response related to the Web screen to the client 302. Specifically, a response HTML for the HTTP request from the client 302 is transmitted. For example, when an HTTP request for requesting the gender input screen 103 is received, a response HTML of the gender input screen 103 is transmitted. The response HTML to be transmitted is a response HTML with session information. The communication unit 5201 corresponds to the AP server 1011 illustrated in FIG.

  Based on the request received by the communication unit 5201, the execution unit 5202 executes a program that calls a Web screen in the program group, and outputs an output value related to a screen item to be displayed on the Web screen, an output value related to the program, and an attribute thereof. Has a function of outputting. Specifically, the execution unit 5202 analyzes the received request and specifies a program that calls the requested Web screen. Then, the specified program is executed.

  The output value related to the screen item displayed on the Web screen is the above-described expected screen item value or actual screen item value. Further, the output value related to the program and its attribute are the attribute value (session expected value or session result value) of the session information described above and its attribute.

  For example, in the case of an HTTP request for requesting the gender input screen 103, the Japanese calendar → Western calendar conversion program 102 that calls the gender input screen 103 is called and values included in the HTTP (year “Heisei”, year “13”, Month "10", day "25"). Then, the gender input screen 103 is called. Then, “October 25, 2001” is output as the output value for the screen item to be displayed on the Web screen, and the attribute value of the session information and its attribute are “birth date of the year (attribute) = 2001”. “October 25 (attribute value)” is output. The execution unit 5202 corresponds to the AP server 1011 that compiles and executes the Web application 1014 using a compiler.

  The storage unit 5203 has a function of storing an output value related to the program output by the execution unit 5202 and its attribute as session information in a storage area. Specifically, for example, the session information is stored in the session object 1100 described above. In the above-described example, the attribute value of the session information and “date of birth (attribute) = October 25, 2001 (attribute value)” output as the attribute are stored as the session information.

  The stored session information is used as input information for a program to be executed next. For example, in the above-described example, “date of birth (attribute) = October 25, 2001 (attribute value)” which is session information is a troubled year calculation program 104 called next to the Japanese calendar → West calendar conversion program 102. Used as input information.

  Further, the storage unit 5203 stores information (session writing information) for specifying an execution position in the program in the storage area as session information together with an output value related to the program and its attribute. Specifically, for example, as described in the third embodiment, the session writing information is stored as at least one of the class name, method name, line number, and second argument of the program being executed. The storage unit 5203 corresponds to the AP server 1011 that stores the session object 1100 according to the Web application 1014.

  The generation unit 5204 has a function of generating a response regarding the Web screen in which the output value regarding the screen item output by the execution unit 5202 is embedded. Specifically, the execution unit 5202 generates a response HTML related to the Web screen called by the program being executed. In this response HTML, an output value related to a screen item to be displayed on the Web screen (in the above example, “October 25, 2001”) is embedded.

  Further, as illustrated in FIGS. 12 to 15, the generation unit 5204 specifies the output position of the output value related to the screen item to be displayed on the Web screen by the meta information insertion engine 1017, the template file 1016, the preprocessor 1012, and the compiler 1013. Then, a response HTML is generated. The generation unit 5204 corresponds to the AP server 1011 that executes the template file 1016, the preprocessor 1012, and the meta information insertion engine 1017.

  The insertion unit 5205 has a function of inserting the session information stored in the storage area by the storage unit 5203 into the response related to the Web screen generated by the generation unit 5204. Specifically, the session information acquisition process (step S1206) shown in FIGS. 16 and 39 described above is executed. In the above-described example, the session information “date of birth (attribute) = October 25, 2001 (attribute value)” stored in the session object 1100 is added to the end of the response HTML of the generated gender input screen 103. Embed as comment text. By embedding it as a comment sentence in this way, it is not displayed on the Web browser 1021 of the client 302, but can be analyzed in the execution navigator 1022 of the client 302.

  Also, as described in the second embodiment (FIGS. 33 and 34) and the third embodiment (FIGS. 40 and 41), when the attribute is expressed in JavaBean, it is desired to record it as a session expected value or a session actual value. Annotation “@Ignore” is added before a property that does not exist. The inserting unit 5205 determines whether or not this annotation is added. If an annotation is added, the expected session value (or actual session value) of the property is not stored in the session object 1100.

  Thereby, it is possible to prevent erroneous detection of bugs by not comparing session information that inevitably changes every time a test is performed, such as an access date. Further, since such session information is not reflected in the test specification data D1 and D2, it is not a test target. Accordingly, the test time can be shortened.

  Next, the client 302 will be described. The client 302 includes a reception unit 5211, an acquisition unit 5212, an extraction unit 5213, a writing unit 5214, a reading unit 5215, a specifying unit 5216, a determination unit 5217, a setting unit 5218, and an output unit 5219. Part 5220. These are functions corresponding to the execution navigator 1022.

  The reception unit 5211 has a function of receiving test specification data in which a series of screen transition specifications included in a test case of the Web application 1014 installed in the Web server 301 is described. Specifically, for example, the test specification data shown in FIG. 5 is read.

  The acquisition unit 5212 has a function of transmitting a request for requesting a Web screen having an arbitrary screen transition specification to the Web server 301. Specifically, this request is a request for requesting a Web screen of a screen transition specification selected from the series of screen transition specifications of the test specification data shown in FIG. Then, by transmitting this request to the Web server 301, a response HTML with session information is received.

  The extraction unit 5213 has a function of extracting expected value information and actual value information from the response regarding the Web screen acquired by the acquisition unit 5212. Specifically, when meta information is included in the response HTML, the meta information is extracted. If the output value related to the screen item is included, the output value related to the screen item is extracted. Further, if session information is included, the session information is also extracted.

  For example, when the response HTML related to the gender input screen 103 is received in the test case TC1 of the initial test, the year “Heisei”, the year “13”, the month “10”, the day “25” are displayed as expected values of the screen items. Is extracted. Similarly, “date of birth (attribute) = October 25, 2001 (expected session value)” is extracted as session information.

  Further, in the test case TC1 of the regression test, when the response HTML related to the gender input screen 103 is received, the year “Heisei”, the year “13”, the month “10”, the day “25” are displayed as the screen item actual values. Is extracted. Similarly, “date of birth (attribute) = October 25, 2001 (session result value)” is extracted as session information. The extraction unit 5213 corresponds to the execution navigator 1022.

  In addition, the writing unit 5214 associates the expected value information and the actual value information extracted by the extracting unit 5213 with the screen transition specification and writes the test specification data received by the receiving unit 5211. Specifically, for example, as shown in FIG. 9, in the test case TC1 of the initial test, the year name “Heisei”, the year “13”, the month “10”, and the day “25” are extracted as the expected values of the screen items. In this case, the year “Heisei”, the year “13”, the month “10”, and the day “25” are written in the expected values of the gender input screen 103 corresponding to the response HTML of the test case TC1.

  Similarly, “date of birth of the year (attribute) = October 25, 2001 (expected value of session)” is written as the session information. Thereby, when the record of the sex input screen 103 of the test case TC1 is referred to, the screen item expected value and the session information (attribute and session expected value) are written in the record. Therefore, both will be associated.

  Similarly, as shown in FIG. 22, in the test case TC1 of the regression test, when the year “Heisei”, the year “13”, the month “10”, and the day “25” are extracted as the expected values of the screen items, The year “Heisei”, the year “13”, the month “10”, and the day “25” are written in the screen item actual values of the gender input screen 103 corresponding to the response HTML of the case TC1.

  Similarly, “date of birth (attribute) = October 25, 2000 (session result value)” is written as session information. Thereby, when the record of the sex input screen 103 of the test case TC1 is referred to, the screen item actual value and the session information (attribute and session actual value) are written in the record. Therefore, both will be associated.

  The reading unit 5215 writes the first test specification data written by the writing unit 5214 for the first test related to the Web application 1014 and the second test written by the writing unit 5214 for the second test after the first test. The test specification data is read. Specifically, for example, test specification data D1 and D2 (see FIGS. 9 and 22) created by the writing unit 5214 are read. In addition, test specification data D31 and D32 (see FIGS. 43 and 46) created by the writing unit 5214 may be read.

  The specifying unit 5216 has a function of specifying session information associated with the Web screen for each Web screen in the first and second test specification data read by the reading unit 5215. Specifically, for example, in each test specification data D1, D2 (D31, D32), the session information in the record of the same Web screen of the same test case TCi is specified. Further, the specifying unit 5216 specifies the expected screen item value of the test specification data D1 and the actual screen item value of the test specification data D2 for each Web screen on the same Web screen of the same test case TCi.

  The determination unit 5217 has a function of determining whether or not the session information specified by the specification unit 5216 matches between the first and second test specification data. Specifically, for example, for each specified session information, whether the session information specified in the test specification data D1 (D31) matches the session information specified in the test specification data D2 (D32). Determine whether. If they match, the expected session value of the initial test and the session result value of the regression test match, so the program that calls the Web screen (business logic 1015) is determined to be normal (no bugs). .

  The determination unit 5217 also displays the expected screen item value of the test specification data D1 (D31) and the actual screen item value of the test specification data D2 (D32) for each Web screen on the same Web screen of the same test case TCi. May be determined to match the expected value of the screen item and the actual value of the screen item. If they match, it is determined that the program that calls the Web screen (business logic 1015) does not display a bug.

  The setting unit 5218 has a function of performing a setting to highlight the session information in the test specification data D1, D2 (D31, D32) when the determination unit 5217 determines that there is a mismatch. Specifically, for example, the character size, color, and font of the session information are specified in the tag so as to be different from other matching information. Further, when the screen item expected value and the screen item actual value do not coincide with each other, the highlighting may be set similarly. Note that highlighting may be set for at least one of the test specification data D1 and D2.

  The output unit 5219 has a function of outputting the first or / and second test specification data set by the setting unit 5218. Specifically, for example, the test specification data D1, D2 (D31, D32) highlighted for the session information, the expected screen item value, and the actual screen item value are displayed on the screen or printed out. Or send to other devices.

  The determination unit 5220 has a function of determining the Web screen associated with the session information as a bug position based on the determination result determined by the determination unit 5217. Specifically, for example, when the session information specified in the test specification data D1 (D31) matches the session information specified in the test specification data D2 (D32), the Web associated with the session information The program that calls the screen (business logic 1015) has no bug.

  On the other hand, if they do not match, the program (business logic 1015) that calls the Web screen associated with the session information may have a bug or be affected by a program executed before that. Therefore, the web screen that is first called out of the series of web screen groups determined to be inconsistent is determined as the bug position. Thereby, it can be seen that there is a bug in the program (business logic 1015) that calls the Web screen determined at the bug position.

  For example, when the test specification data D1 (D31) in FIG. 9 and the test specification data D2 (D32) in FIG. 22 are compared, in the test case TC1, the Web screen in which the session expected value and the session actual value do not match is An input screen 103 and a troubled year display screen 105. Since the first web screen called out of the web screen group is the gender input screen 103, the gender input screen 103 is determined as the bug position. Therefore, it can be seen that there is a bug in the Japanese calendar → Western calendar conversion program 102 that calls the gender input screen 103.

  When the expected screen item value of the test specification data D1 (D31) and the actual screen item value of the test specification data D2 (D32) on the same Web screen of the same test case TCi do not match, It is determined whether or not it is the same screen as the Web screen that is first called out of a series of Web screen groups determined to be inconsistent. If the screens are not the same, the Web screen in which the expected screen item value of the test specification data D1 (D31) and the actual screen item value of the test specification data D2 (D32) do not match is determined as the bug display position.

  For example, when the test specification data D1 (D31) in FIG. 9 and the test specification data D2 (D32) in FIG. 22 are compared, in the test case TC1, the Web screen in which the expected screen item value and the actual screen item value do not match. This is a troubled year display screen 105. On the other hand, the web screen in which the session expected value and the session actual value do not match is the gender input screen 103 and the troubled year display screen 105. The web screen that is called first in the web screen group is the gender input screen 103 and therefore does not match the troubled year display screen 105. Therefore, the bad year display screen 105 is determined as the bug display position.

  Specifically, for example, a Web screen determined as a bug position or a bug display position is displayed via the Web browser 1021. Further, the setting unit 5218 described above may highlight and set the expected screen item value or session information determined at the bug position in the test specification data D1. Further, in the test specification data D2 (D32), the screen item result value or the session information determined at the bug position may be highlighted and set.

  In this case, the output unit 5219 outputs the determination result by the determination unit 5220. Specifically, for example, a Web screen determined as a bug position is displayed, printed out, or transmitted to another device. When the highlighting is set, the test specification data D1, D2 (D31, D32) highlighted for the session information, the screen item expected value, and the screen item actual value are displayed on the screen or printed out. Or send to other devices.

  From the above, according to the first embodiment, it is possible to reduce the time for finding a bug occurrence location on a program when a bug is detected. Therefore, it is possible to shorten the overall time required for bug correction, shorten the development cycle, and reduce the work period for the entire software development. Further, according to the second embodiment, it is possible to prevent a misdiagnosis that diagnoses a program (business logic 1015) unrelated to a bug as a bug, and to improve the diagnosis accuracy. Further, according to the third embodiment, since the position of the bug can be specified in more detail, the time required for correcting the bug can be further shortened.

  The computer method described in this embodiment can be realized by executing a program prepared in advance on a computer such as a personal computer or a workstation. This program is recorded on a computer-readable recording medium such as a hard disk, a flexible disk, a CD-ROM, an MO, and a DVD, and is executed by being read from the recording medium by the computer. The program may be a medium that can be distributed through a network such as the Internet.

  The following additional notes are disclosed with respect to the embodiment described above.

(Supplementary note 1) A Web server on which a Web application including a series of programs is installed.
Receiving means for receiving a request for requesting a Web screen of a screen transition specification selected from a series of screen transition specifications included in a test case of the Web application from a client;
Based on the request received by the receiving means, a program that calls the Web screen in the program group is executed, an output value related to a screen item to be displayed on the Web screen, an output value related to the program, and an attribute thereof Execution means to output,
A storage unit that stores an output value related to the program output by the execution unit and its attribute in a storage area as session information;
Generating means for generating a response relating to the Web screen in which an output value relating to the screen item output by the executing means is embedded;
Inserting means for inserting the session information stored in the storage area by the storing means into the response relating to the Web screen generated by the generating means;
Transmitting means for transmitting a response regarding the Web screen into which the session information has been inserted by the inserting means to the client;
Web application inspection program characterized by causing it to function as

(Appendix 2) The storage means includes
The Web application inspection program according to appendix 1, wherein an output value related to the program is stored in the storage area as session information input to a program executed next to the program.

(Supplementary Note 3) The storage means includes
The Web application inspection program according to appendix 1 or 2, wherein information for specifying an execution position in the program is stored in the storage area as the session information together with an output value and an attribute related to the program.

(Supplementary Note 4) The insertion means includes
The Web application inspection program according to any one of appendices 1 to 3, wherein the session information is inserted into a response related to the Web screen in a format that cannot be displayed on the Web screen in the Web browser of the client.

(Supplementary note 5)
Function as a determination unit that determines whether or not the session information can be inserted into a response related to the Web screen;
The insertion means includes
The Web application inspection program according to any one of Supplementary notes 1 to 4, wherein the session information is inserted into a response related to the Web screen based on a determination result determined by the determination unit.

(Supplementary Note 6) A test execution apparatus in which a Web application including a series of programs is installed,
Receiving means for receiving a request for requesting a Web screen of a screen transition specification selected from a series of screen transition specifications included in a test case of the Web application from a client;
Based on the request received by the receiving means, a program that calls the Web screen in the program group is executed, an output value related to a screen item to be displayed on the Web screen, an output value related to the program, and an attribute thereof Execution means for outputting;
A storage unit that stores an output value related to the program output by the execution unit and its attribute in a storage area as session information;
Generating means for generating a response related to the Web screen in which an output value related to the screen item output by the executing means is embedded;
Inserting means for inserting session information stored in the storage area by the storing means into the response relating to the Web screen generated by the generating means;
Transmitting means for transmitting a response regarding the Web screen in which the session information is inserted by the inserting means to the client;
A test execution device comprising:
(Appendix 7) A web server on which a web application including a series of programs is installed is
A receiving step of receiving, from a client, a request for requesting a Web screen of a screen transition specification selected from a series of screen transition specifications included in the test case of the Web application;
Based on the request received by the receiving step, the program that calls the Web screen in the program group is executed, and an output value related to a screen item to be displayed on the Web screen, an output value related to the program, and an attribute thereof are displayed. Execution process to output;
A storage step of storing the output value and the attribute of the program output by the execution step in a storage area as session information;
A generation step of generating a response related to the Web screen in which an output value related to the screen item output in the execution step is embedded;
An insertion step of inserting the session information stored in the storage area by the storage step into the response relating to the Web screen generated by the generation step;
A transmission step of transmitting a response related to the Web screen into which the session information has been inserted by the insertion step to the client;
The test execution method characterized by performing.

It is a screen process transition diagram which shows the transition of the screen of a bad year display program, and a process. It is explanatory drawing which shows the source code of a bad year display program. 1 is an explanatory diagram illustrating a schematic configuration of a Web application inspection system according to a first embodiment; 1 is a block diagram illustrating a hardware configuration of a computer device according to a first embodiment; It is explanatory drawing which shows the data structure of the test specification data for initial tests. It is explanatory drawing which shows the example of a screen of a birth date input screen. It is explanatory drawing which shows the example of a screen of a sex input screen. It is explanatory drawing which shows the example of a screen of a bad year display screen. It is explanatory drawing which shows the test specification data after the first test. It is a block diagram which shows the detailed internal structure of each computer apparatus. It is explanatory drawing which shows a session object. It is a sequence diagram which shows the sequence of a web server. It is explanatory drawing which shows the web application execution processing content (the 1) by a web server. It is explanatory drawing which shows the web application execution processing content (the 2) by a web server. It is explanatory drawing which shows the execution result of a Web application. It is a flowchart which shows the detailed process sequence of a session information acquisition process. It is explanatory drawing which shows an example of the response HTML with session information. It is a flowchart which shows the test specification creation process procedure at the time of the first test by a client. It is a flowchart which shows the specific process sequence of the expected value information write process of a test case. It is a flowchart which shows the detailed process sequence of an expected value information extraction process. It is explanatory drawing which shows the test specification data for a regression test. It is explanatory drawing which shows the test specification data after the automatic preparation at the time of a regression test. It is a flowchart which shows the test specification creation process procedure at the time of the regression test by a client. It is a flowchart which shows the specific process sequence of the performance value information write-in process of a test case. It is a flowchart which shows the detailed process sequence of a performance value information extraction process. It is explanatory drawing which shows the test specification data for a regression test after the comparison with the test specification data for initial tests. It is a flowchart which shows a bug position specific process procedure (the 1). It is a flowchart (the first half) which shows a bug position specific process procedure (the 2). It is a flowchart (second half) which shows a bug position specific process procedure (the 2). It is explanatory drawing which shows the program for recording information on a session object. It is explanatory drawing which shows the source code example (the 1) of JavaBean. It is explanatory drawing which shows the source code example (the 2) of JavaBean. 10 is a flowchart showing a session information acquisition processing procedure (first half) by the session information acquisition engine according to the second embodiment; 10 is a flowchart showing a session information acquisition processing procedure (second half) by the session information acquisition engine according to the second embodiment; It is a sequence diagram at the time of executing a Web application. It is a sequence diagram at the time of executing a Web application. It is a flowchart which shows the operation processing procedure of an aspect. It is explanatory drawing which shows an example of the response HTML with session information concerning Embodiment 3. FIG. 10 is a flowchart showing a session information acquisition processing procedure by the session information acquisition engine according to the third embodiment; 10 is a flowchart showing a session information acquisition processing procedure (first half) by a session information acquisition engine according to a third embodiment; 14 is a flowchart showing a session information acquisition processing procedure (second half) by the session information acquisition engine according to the third embodiment; FIG. 10 is an explanatory diagram showing a data structure of test specification data for an initial test according to a third embodiment; FIG. 10 is an explanatory diagram illustrating a data structure of test specification data that has been subjected to an initial test according to a third embodiment; 10 is a flowchart illustrating a detailed processing procedure of expected value information extraction processing according to the third exemplary embodiment; FIG. 10 is an explanatory diagram showing a data structure of test specification data for a regression test according to a third embodiment; It is explanatory drawing which shows the data structure of the test specification data D32 which has been subjected to the regression test concerning Embodiment 3. 14 is a flowchart showing a detailed processing procedure of performance value information extraction processing according to the third exemplary embodiment; 10 is a flowchart showing a bug position specifying process procedure according to the third embodiment; It is explanatory drawing which shows the data structure of the test specification data after a bug position specific process. It is explanatory drawing which shows the source code of the program for demonstrating the combination with a static analysis. It is a flowchart which shows the bug position specific process sequence at the time of applying a static analysis. It is a block diagram which shows the functional structure of the Web application inspection system concerning Embodiment 1-3.

Explanation of symbols

DESCRIPTION OF SYMBOLS 100 Bad year display program 101 Date of birth input screen 102 Japanese calendar-to-West calendar conversion program 103 Gender input screen 104 Bad year calculation program 105 Bad year display screen 300 Web application inspection system 301 Web server 302 Client 1018 Session information acquisition engine 1100 Session object D1, D2 , D31, D32 Test specification data 1700, 3800 Response HTML with session information
5201 Communication unit 5202 Execution unit 5203 Storage unit 5204 Generation unit 5205 Insertion unit 5211 Reception unit 5212 Acquisition unit 5213 Extraction unit 5214 Writing unit 5215 Reading unit 5216 Determination unit 5217 Determination unit 5218 Setting unit 5219 Output unit 5220 Determination unit

Claims (5)

A web server on which a web application including a series of programs is installed
Receiving means for receiving a request for requesting a Web screen of a screen transition specification selected from a series of screen transition specifications included in a test case of the Web application from a client;
Based on the request received by the receiving means, a program that calls the Web screen in the program group is executed, an output value related to a screen item to be displayed on the Web screen, an output value related to the program, and an attribute thereof Execution means to output,
Storage means for storing , as session information , an output value and its attribute relating to the program output by the execution means and information for specifying an execution position in the program ;
Generating means for generating a response relating to the Web screen in which an output value relating to the screen item output by the executing means is embedded;
Inserting means for inserting the session information stored in the storage area by the storing means into the response relating to the Web screen generated by the generating means;
Transmitting means for transmitting a response regarding the Web screen into which the session information has been inserted by the inserting means to the client;
Web application inspection program characterized by causing it to function as The storage means includes
The Web application inspection program according to claim 1, wherein an output value related to the program is stored in the storage area as session information input to a program executed next to the program. The insertion means includes
3. The Web application inspection program according to claim 1, wherein the session information is inserted into a response relating to the Web screen in a format that cannot be displayed on the Web screen in the Web browser of the client. A test execution device in which a web application including a series of programs is installed,
Receiving means for receiving a request for requesting a Web screen of a screen transition specification selected from a series of screen transition specifications included in a test case of the Web application from a client;
Based on the request received by the receiving means, a program that calls the Web screen in the program group is executed, an output value related to a screen item to be displayed on the Web screen, an output value related to the program, and an attribute thereof Execution means for outputting;
Storage means for storing in the storage area as session information , an output value related to the program output by the execution means and its attributes, and information for specifying an execution position in the program ;
Generating means for generating a response related to the Web screen in which an output value related to the screen item output by the executing means is embedded;
Inserting means for inserting session information stored in the storage area by the storing means into the response relating to the Web screen generated by the generating means;
Transmitting means for transmitting a response regarding the Web screen in which the session information is inserted by the inserting means to the client;
A test execution device comprising: A web server on which a web application including a series of programs is installed is
A receiving step of receiving, from a client, a request for requesting a Web screen of a screen transition specification selected from a series of screen transition specifications included in the test case of the Web application;
Based on the request received by the receiving step, the program that calls the Web screen in the program group is executed, and an output value related to a screen item to be displayed on the Web screen, an output value related to the program, and an attribute thereof are displayed. Execution process to output;
An output value related to the program output by the execution step and the attribute thereof, information for specifying an execution position in the program, and a storage step for storing the session information as a storage area;
A generation step of generating a response related to the Web screen in which an output value related to the screen item output in the execution step is embedded;
An insertion step of inserting the session information stored in the storage area by the storage step into the response relating to the Web screen generated by the generation step;
A transmission step of transmitting a response related to the Web screen into which the session information has been inserted by the insertion step to the client;
The test execution method characterized by performing.

Images