JP5958655B2 - Test program, test apparatus and test method - Google Patents

Description

  The present invention relates to a test program, a test apparatus, and a test method.

  The web system provides a service for displaying information such as the operating status of a monitored system on a web screen. When a certain function of the server / storage system is changed, the layout of the web screen may be changed accordingly. As an example, when a new function is added to the server / storage system, the layout of the web screen may be changed to display information about the function added to the server / storage system. Similarly, when a certain function is deleted from the server / storage system, the layout of the screen may change in order to delete information related to the function deleted from the server / storage system.

  In the server / storage system, there is no change in processing for functions other than such a function change. Therefore, the web system must ensure that the functions other than the added or deleted functions are performed on the web screen before and after the function change and the result is displayed. A regression test is known as a test method for that purpose.

  The regression test is performed by a web test system. The web test system executes a test scenario, and confirms that the result of the web screen is the same before and after the function change for the function other than the changed function. The test scenario indicates an operation procedure for testing the web screen. In the test scenario, an element on HTML (Hyper Text Markup Language) describing a web screen is specified. An example of a web screen and a test scenario for the web screen are shown in FIGS. XPath for specifying the position on the web screen is used for specifying the position of each element on the HTML.

JP 2009-140155 A JP 2005-266554 A

  However, XPath changes accordingly when the web screen layout changes. Therefore, if the layout of the web screen changes, the XPath before the function change may not be used as the XPath after the function change that specifies the position of the same element.

  That is, XPath is described in the test scenario. For this reason, if the layout of the web screen changes according to the function change of the server / storage system, the test scenario including the XPath before the function change cannot be used as it is as the test scenario of the regression test after the function change.

  Therefore, as shown in the flowchart of FIG. 1 and FIG. 2A, the difference is extracted from the function specifications 1 and 2 of the server / storage system before and after the function change, and the first test scenario before the function change based on the difference. Is manually corrected to create a second test scenario after the function change. However, since this method is a manual test scenario correction, the correction takes time. In addition, the complexity is proportional to the number of display items and the number of screens in the web screen, and it is expected that it will take even more effort to correct test scenarios for systems that will become increasingly multifunctional in the future. Is done.

  In addition, for test scenarios that have continuity, if the test cannot be executed due to the omission of correction of the test scenario, it is highly likely that the test after the error location due to omission of correction will not be executed correctly. Must be manually repeated, resulting in additional man-hours.

  Therefore, in one aspect, an object of the present invention is to automatically create a test scenario after a function change based on a test scenario before a function change for testing a web screen.

  In one proposal, the position of the first web screen before the function change is specified based on the first modified source code in which a predetermined notation is added to the first source code in which the process before the function change of the system is described. The first scenario correction data including the first XPath to be performed and the predetermined notation is created, and a second notation in which the predetermined notation is added to the second source code in which processing after the function change of the system is described Based on the modified source code, a second scenario modification data including a second XPath designating the position of the second web screen after the function change and the predetermined notation is created, and the first scenario is created. Correspondence information between the first XPath and the second XPath is extracted according to a position where the predetermined notation included in the correction data and the second scenario correction data matches, and the extracted correspondence is extracted. Based on the information, A test program for causing a computer to execute a process for creating a second test scenario indicating an operation procedure of the second web screen from a first test scenario indicating an operation procedure of one web screen is provided.

  According to one aspect, a test scenario after a function change can be automatically created based on a test scenario before the function change for testing a web screen.

The flowchart which shows the example which produces a test scenario manually from the difference information of a functional specification. FIG. 2A is a comparison diagram for explaining manual creation of a test scenario, and FIG. 2B is a diagram for explaining automatic creation of a test scenario according to an embodiment. The figure which shows an example of the whole structure of the system concerning one Embodiment. The figure which shows the example of the position designation | designated of each element and XPath on HTML. The figure which shows an example of the test scenario which uses XPath. The figure which shows the example of a layout change of a web screen. The figure which shows an example of XPath after the layout change of a web screen with respect to FIG. The figure which shows the other example of XPath after the layout change of a web screen with respect to FIG. The figure which shows an example of a function structure of the web test system concerning one Embodiment. The figure which shows an example of the function list | wrist concerning one Embodiment. The figure which shows an example of the main body of the function list | wrist of FIG. The flowchart which shows an example of the test execution process concerning one Embodiment. The flowchart which shows an example of the function addition process concerning one Embodiment. The flowchart which shows an example of the function list production | generation process concerning one Embodiment. The figure which shows an example of the source code concerning one Embodiment. The figure which shows an example of the listed source code concerning one Embodiment. The figure which shows the syntax analysis result of FIG. The figure which shows an example of the correction source code concerning one Embodiment. The figure which shows the example which returned the correction source code concerning one Embodiment to the original source code. The flowchart which shows the detail of the automatic creation process of the test scenario concerning one Embodiment. The figure which shows the creation example of the data for scenario correction (before function change) concerning one Embodiment. The flowchart which shows the creation process of the data for scenario correction concerning one Embodiment. The figure which shows the example of creation of the data for scenario correction (after function change) concerning one Embodiment. The flowchart which shows the automatic creation process of the test scenario concerning one Embodiment. The figure which shows the example of a coincidence detection of the data for scenario correction (before and after function change) concerning one Embodiment. The figure which shows the example of a detection of XPath concerning one Embodiment. FIG. 27A shows a test scenario for the system before the function change, and FIG. 27B shows a test scenario for the system after the function change. The figure which shows HTML before a function change. The figure which shows the example of a web screen which applies the 1st test scenario with respect to the system before a function change. The figure which shows HTML after a function change. The figure which shows the example of a web screen which applies the 2nd test scenario with respect to the system after a function change. The figure which shows the example of a test using a 1st test scenario. The figure which shows the example of a test using a 2nd test scenario. The figure which shows the example of execution of the test scenario before a function change. The figure which shows the example of execution of the test scenario after a function change. The figure which shows the hardware structural example of the web test system concerning one Embodiment.

  Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. In addition, in this specification and drawing, about the component which has the substantially same function structure, the duplicate description is abbreviate | omitted by attaching | subjecting the same code | symbol.

[System overall configuration]
First of all. A relationship among the server / storage system 1, the web system 20, and the web test system 30 according to an embodiment of the present invention will be described with reference to FIG. The web system 20 provides information such as the operating status of the monitored server / storage system 1 on a web screen.

  In the server / storage system 1 according to the present embodiment, information on the functional configuration of the server / storage device 10 is input using the web screen 11. The input to the web screen 11 and the update of the web screen 11 are controlled by the web system 20.

  When a function is added or deleted in the server / storage system 1, the web system performs the same operation before and after the function change and displays it on the web screen for functions other than the added or deleted functions. We must guarantee that A regression test is known as a test method for that purpose.

  The regression test is executed by the web test system 30. The web test system 30 first creates an operation procedure for testing the web screen 11 from the functional specifications of the server / storage device 10. The test operation procedure on the web screen 11 is hereinafter referred to as “test scenario”.

  The web test system 30 inputs a test scenario, operates the web screen 11 based on the test scenario operation procedure, executes the test, and verifies the execution result. At this time, the web test system 30 automatically operates the web screen 11 according to the test scenario.

  Each element on the HTML describing the web screen is specified in the test scenario. For specifying the position of an HTML element, a position specifying method using XPath is used. FIG. 4 shows an example of specifying the position of each element on the HTML and the XPath. XPath is a standard that defines a description method for indicating a specific element in an XML (Extensible Markup Language) document such as HTML, and is based on a standard specification recommended by the W3C (World Wide Web Consortium). For the element (E1) of the HTML file shown in FIG. 4B, the position indicated by (1) in the table corresponding to the web screen 11 in FIG. 4A is (1) in FIG. ) XPath. For the element (E2) of the HTML file shown in FIG. 4B, the position indicated by (2) in the table of FIG. 4A is indicated by the XPath of (2) of FIG. 4C. For the element (E3) of the HTML file shown in FIG. 4B, the position indicated by (3) in the table of FIG. 4A is indicated by the XPath of (3) in FIG. 4C.

  In the test scenario, the operation for the element of the HTML file describing the designated web screen is described. An example of a test scenario using XPath is shown in FIG. The commands described in the test scenario include character input (input), click (click), comparison with arbitrary data (check), and the like. The XPath described in the test scenario specifies the location where the command is executed.

  As shown in FIG. 5, the test scenario describes the XPath, which is the designation of the location. When the layout of the web screen 11 changes, the position designation of the element of the HTML file, that is, the XPath changes. For this reason, when the layout of the web screen 11 changes according to the function change, it is difficult to use the test scenario including the XPath before the function change as it is as the test scenario after the function change.

  For example, when “annotation 2” on the web screen 11 in the upper diagram in FIG. 6 is deleted and the layout is changed as shown in the web screen 11 in the lower diagram, the XPath is also changed along with the layout change. For this reason, it is not possible to test the web screen 11 after the layout change using the original test scenario as it is.

  An example of the XPath after the layout change of the web screen 11 of FIG. 4 is shown in FIGS. 7 shows an example in which the XPath is changed because the screen element (De) is deleted from FIG. 4. FIG. 8 shows an example in which the XPath is changed because the screen element (Ad) is added to FIG. It is an example.

  The XPath shown in (3) of FIG. 4 (c) before the change to the element (E3) of the HTML file shown in FIG. 4 (b) is “/ html / body / table / tr [3] / td [2]”. is there. On the other hand, when the part indicated by the element (De) in the HTML file shown in FIG. 7B is deleted, the (5) in FIG. XPath shown in FIG. 4 is “/ html / body / table / tr [2] / td [2]”.

  Further, when the part indicated by the element (Ad) of the HTML file shown in FIG. 8B is added, it is shown in FIG. 8B (6) of FIG. 8C after the change to the element (E3). XPath is “/ html / body / table / tr [4] / td [2]”. As described above, when the layout of the web screen 11 is changed and the element of the HTML file is changed, the designation of the position on the web screen 11 indicated by XPath is changed.

  The web test system 30 according to the embodiment described below automatically creates a test scenario used for testing the web screen 11 after the function change from the test scenario used for testing the web screen 11 before the function change. This eliminates the need to manually change the test scenario used by the web test system 30 based on the functional specification. The web test system 30 according to an embodiment is an example of a test apparatus that tests the web screen 11. The web test system 30 is a test system that runs on a PC, for example, and inputs a test scenario and tests the web screen 11 according to the test scenario operation procedure.

[Functional configuration of Web test system]
The functional configuration of the web test system 30 according to an embodiment of the present invention will be described with reference to FIG. FIG. 9 shows an example of a functional configuration of the web test system 30 according to an embodiment. A web test system 30 according to an embodiment includes a source code reading unit 31, a modified source code creating unit 32, a test scenario reading unit 33, a modification data creating unit 34, an XPath extracting unit 35, a test scenario creating unit 36, and a test execution. A processing unit 37 and a storage unit 40 are included.

  The storage unit 40 includes a source code DB (Data Base) 41, a modified source code DB 42, a test scenario DB 43, a scenario modification DB 44, and a test execution result DB 45.

  The source code reading unit 31 reads a predetermined source code stored in the source code DB 41. The source code DB 41 describes the web screen 11 (first web screen) before the function change provided by the web system 20.

  The modified source code creation unit 32 creates modified source code in which a predetermined notation is added to the source code. For example, the modified source code creation unit 32 creates a first modified source code by adding a predetermined function or a fixed value notation to the first source code (FIG. 2B: (1) function addition). . Further, for example, the modified source code creation unit 32 creates a second modified source code by adding a predetermined function or a fixed value notation to the second source code (FIG. 2B: (3) function add to).

  The first source code describes internal processing before changing the function of the server / storage system 1. In the second source code, internal processing after the function change of the server / storage system 1 is described.

  A function list 100 showing an example of the predetermined notation is shown in FIG. The function list 100 is input from the outside. The function list 100 has a variable target function name 101 and an insertion function name 102 as function notations. The function list 100 has first debug output information 103, second debug output information 104, third debug output information 105, fourth debug output information 106,... As fixed value notations. FIG. 11 shows an example of the main body of the function list of FIG. The predetermined notation includes a function notation, a fixed value (fixed character etc.) notation, and an argument described in the function.

  The test scenario reading unit 33 reads a predetermined test scenario stored in the test scenario DB 43.

  The correction data creation unit 34 is based on the first correction source code, and includes a first XPath that designates the position of the first web screen before the function change and the first scenario correction that includes the predetermined notation. Create data. Based on the second correction source code, the correction data creation unit 34 is for the second scenario correction including the second XPath that specifies the position of the second web screen after the function change and the predetermined notation. Create data.

  For example, the web screen 11 shown in the upper diagram of FIG. 6 is the first web screen, and a part of the layout of the web screen 11 is changed as shown in the lower diagram of FIG. Let 11 be the second web screen.

  When testing the second web screen, the correction data creation unit 34 executes the process based on the first correction source code to create scenario correction data (execution of FIG. 2B: (2)). . The created scenario correction data includes a first XPath for expressing the layout of the first web screen, and is hereinafter also referred to as “first scenario correction data”.

  Further, for example, the correction data creation unit 34 executes the process based on the second correction source code to create scenario correction data (execution of FIG. 2B: (4)). The created scenario correction data includes a second XPath for expressing the layout of the second web screen, and is hereinafter also referred to as “second scenario correction data”. The first scenario correction data and the second scenario correction data are stored in the scenario correction DB 44.

  The XPath extraction unit 35 obtains correspondence information between the first XPath and the second XPath according to the position where the predetermined notation included in the first scenario correction data and the second scenario correction data matches. Extract.

  Based on the correspondence information, the test scenario creation unit 36 creates a second test scenario indicating an operation procedure for testing the second web screen from a first test scenario indicating the operation procedure for testing the first web screen. Create (FIG. 2B: (5) creation).

  The test execution processing unit 37 tests the second web screen after the function change according to the operation procedure of the second test scenario. The test execution result data is stored in the test execution result DB 45.

[Prerequisites for automatic test scenario creation]
Preconditions 1 to 3 for automatic test scenario creation described above will be described.

Precondition 1: There is no change in the processing (function) executed in the web system 20 before the generation of the HTML file. Precondition 2: There is no change in the processing (function) executed in the web system 20 after the generation of the HTML file. Precondition 3: There is no change in the test scenario application order in the web test system 30. According to the web test system 30 according to this embodiment, the test scenario can be reused by the following mechanism based on the above preconditions. To do.
(1) Rewrite the source code of the web system 20 before the function change and after the function change, and output the following information.

-Internal processing executed before generation of HTML file-Generation of HTML file-Internal processing executed after generation of HTML file XPath is generated from the generated HTML file. Test scenario after the function change for the second web screen from the test scenario before the function change for the first web screen by XPath (XPath in the scenario modification data) with internal processing before and after the generation of the HTML file Is created.
(2) The combination of pre-function change processing and post-function change processing at the time of generating a specific HTML file does not change before and after the function change of the server / storage system 1 for the same information. On the premise of this, an XPath that has the same combination of internal processing executed before the HTML file generation and after the HTML file generation is found, and an XPath that has changed before and after the function change of the server / storage system 1 is found.
(3) The first XPath before the change and the second after the change according to the position where the notation of the predetermined function or the fixed value included in the first scenario correction data and the second scenario correction data matches The corresponding information with XPath is extracted. Thereby, it is possible to acquire how the XPath has changed before and after the function change of the server / storage system 1.
(4) Based on the correspondence information, the test scenario after the function change is rewritten from the test scenario before the function change.

  As a result, as shown in FIG. 2B, the first test scenario created for testing the web screen 11 before the function change in the server / storage system 1 is used for the test after the function change. 2 test scenarios can be automatically created. In the web test system 30, automatic creation of a test scenario and execution of a test based on the test scenario are repeatedly performed.

[Automatic test scenario creation process]
Next, test scenario automatic creation processing according to the present embodiment will be described with reference to FIG. FIG. 12 is a flowchart illustrating an example of a test execution process according to the present embodiment. In the following test scenario automatic creation process, the left side is a test execution process of the web screen 11 before the function change provided in the web system 20, and the right side is a test execution of the web screen 11 after the function change provided in the web system 20 Indicates processing. The test scenario automatic creation process is executed before the test execution process of the web screen 11 after the function change shown on the right side.

  When the process before the function change on the left side of FIG. 12 is started, the source code reading unit 31 reads the source code before the function change (step S10). Hereinafter, the source code before the function change is also referred to as a first source code.

  Next, the modified source code creation unit 32 executes a process of adding a notation of a function and a fixed value to the first source code (hereinafter also referred to as “function adding process”), and displays the notation of the function and the fixed value. The added first source code (hereinafter also referred to as “first modified source code”) is created (step S12). Note that the addition processing of functions and the like in steps S12, S24, S32, and S44 described later is shown in FIG. 13, and the function list generation processing to be added is shown in FIG. 14 and will be described later.

  Next, the modification data creation unit 34 creates first scenario modification data based on the first modification source code (step S14), and the test scenario reading unit 33 creates a test scenario (hereinafter referred to as “first scenario data”). (Also referred to as “test scenario”) (step S16). Next, the web system 20 displays the web screen 11 in accordance with the generated latest HTML file (step S18). Here, the first web screen is displayed based on the first source code. On the first web screen, information such as operation information of the server / storage system 1 before the function change is displayed.

  Next, the test execution processing unit 37 reads the first test scenario and executes a regression test based on the first test scenario (step S20). The storage unit 40 stores the test execution process result in the test execution result DB 45. Next, the source code reading unit 31 reads the next first source code of the web system 20 before the function change (step S22), and the modified source code creation unit 32 adds a function and a fixed value to the first source code. A function addition process for adding the notation is executed, and the next first modified source code is created (step S24). Next, the modification data creation unit 34 creates the next first scenario modification data based on the first modification source code (step S26).

  Next, the test execution processing unit 37 determines whether or not there is a next first test scenario (step S28). If it is determined that there is no next first test scenario, the process ends. On the other hand, if it is determined that there is the next first test scenario, the test execution processing unit 37 reads the next first test scenario (step S29). Next, the test execution processing unit 37 executes a regression test in step S20 based on the next first test scenario, and the storage unit 40 stores the test execution processing result in the test execution result DB 45. Steps S18 to S29 are repeated until it is determined in step S28 that there is no next first test scenario.

  When the processing on the right side of FIG. 12 is started, the source code reading unit 31 reads the source code after the function change (step S30). Hereinafter, the source code after the function change is also referred to as a second source code. Next, the modified source code creation unit 32 executes a function addition process on the second source code and adds a function and a fixed value notation (hereinafter also referred to as “second modified source code”). Is created) (step S32).

  Next, the correction data creation unit 34 creates first scenario correction data based on the second correction source code (step S34). The test scenario creation unit 36 automatically creates a second test scenario in which the first test scenario is modified based on the first scenario modification data and the second scenario modification data (step S36).

  Next, the web system 20 displays the web screen 11 in accordance with the generated latest HTML file (step S38). Here, the second web screen is displayed based on the second source code. On the second web screen, information such as operation information of the server / storage system 1 after the function change is displayed.

  Next, the test execution processing unit 37 executes a regression test based on the automatically created second test scenario (step S40). The storage unit 40 stores the test execution process result in the test execution result DB 45. Next, the source code reading unit 31 reads the next second source code (step S42), and the modified source code creating unit 32 adds a function and a fixed value notation to the first source code. Is executed (step S44). Next, the correction data creation unit 34 creates the next second scenario correction data based on the generated second correction source code (step S46).

  Next, the test execution processing unit 37 determines whether there is a next test scenario (step S48). If it is determined that there is no next test scenario, the process ends. On the other hand, if it is determined that there is the next second test scenario, the test execution processing unit 37 corrects (automatically creates) the next second test scenario (step S49), and executes the regression test in step S40. To do. The storage unit 40 stores the test execution process result in the test execution result DB 45. Steps S38 to S49 are repeated until it is determined in step S48 that there is no next second test scenario.

[Function addition processing]
The function addition processing according to the present embodiment will be described with reference to FIGS. FIG. 13 is a flowchart showing the function addition processing according to the present embodiment. FIG. 14 is a flowchart showing a function list generation process according to the present embodiment. This process is a process for creating the first modified source code from the first source code by adding the function shown in (1) of FIG. Further, it is a process of creating the second modified source code from the second source code by adding the function shown in (3) of FIG.

When the process of FIG. 13 is started, the modified source code creation unit 32 executes a function list generation process (FIG. 14) (step S50).
(Function list generation processing)
In the function list generation process of FIG. 14, the modified source code creation unit 32 divides the source code of the web system 20 by {,}, (,), space, comma, “;”, “=”, and line feed code. The list is formed (step S70). However, "..." and "// ~ line feed" are not divided.

  Next, the modified source code creation unit 32 determines a function included in the listed source code (step S71), and scans the function call unit (function Call) (step S72). The modified source code creation unit 32 determines whether the scanning is completed (step S73). If it is determined that the scanning is completed, the modified source code creation unit 32 ends the process and returns to step S51 of the function addition process in FIG.

On the other hand, when it is determined that the scanning has not been completed, the modified source code creation unit 32 divides the function in the source code into the following three according to the function type (step S74). After the list is generated in steps S75 to S77, the process returns to step S72, and the processes in steps S72 to S77 are repeated until the scanning is completed.
(1) HTML output function list generation (step S75)
Function name Function type Function argument (2) Database write function list generation (step S76)
Function name Function type Function argument (3) Database reading function list generation (step S77)
Function Name Function Type Function Argument Returning to the additional processing of FIG. 13 (step S51), the modified source code creation unit 32 changes the source code of the web system 20 to {,}, (,), blank, comma, “;”. , '=', Split by line feed code and list. However, "..." and "// ~ line feed" are not divided. Note that the modified source code creation unit 32 may acquire the source code listed in step S70 in step S51. FIG. 15 shows an example of source code. FIG. 16 shows an example in which the source code of FIG. 15 is divided and listed.

  Next, the modified source code creation unit 32 determines a function from the listed source code (step S52), and scans the function call unit (function Call) (step S53). The corrected source code creation unit 32 determines whether the scanning is completed (step S54). If it is determined that the scanning is completed, the list of the source code is returned to the original source code (step S63), and this processing is performed. Exit.

  On the other hand, if it is determined in step S54 that the scanning has not been completed, the modified source code creation unit 32 determines whether the function type of the function calling unit matches the target function in the function list generated in FIG. (Step S55). If it is determined that the function type of the function calling unit matches the target function in the function list, the corrected source code creation unit 32 inserts the insertion function name immediately after the target function (step S56). FIG. 10 shows an example of a function list used in the above function list generation step.

  The modified source code creation unit 32 lists the source code of FIG. 4B (FIG. 16), parses the listed source code (FIG. 17), and inserts the insertion function name immediately after the target function. (FIG. 18).

  Next, in step S57 of FIG. 13, the modified source code creation unit 32 acquires debug output information from the function list. The corrected source code creation unit 32 determines whether or not the acquisition of debug output information is completed (step S58). If it is determined that the acquisition of debug output information is completed, the process proceeds to step S62. On the other hand, if it is determined that the acquisition of debug output information has not been completed, the modified source code creation unit 32 determines whether it is a fixed character (step S59). In the case of a fixed character, the modified source code creation unit 32 inserts the fixed character (step S60). In FIG. 18, a fixed character is set after the insertion function name is inserted by executing step S60. On the other hand, if it is not a fixed character, the modified source code creation unit 32 inserts a function argument (step S61). In FIG. 18, the function argument (the function argument of “arg” in the debug output information 103 to 106) is set after the insertion function name and the fixed character are inserted. Returning to step S57, the modified source code creation unit 32 repeats the processing of steps S57 to S61, and when it is determined in step S58 that the acquisition of debug output information has been completed, the process proceeds to step S62, where the function termination notation is displayed. And returns to step S53. The modified source code creation unit 32 repeats the processing of S53 to S62 until it is determined in step S54 following step S53 that the scanning of the function calling unit has been completed, and the source code listed when it is determined that the scanning has been completed. The original state is restored (step S63), and this process ends. FIG. 19 shows the source code returned from the listed source code to the original state. Note that the process of step S63 can be omitted.

  As a result, as shown in FIG. 18, a modified source code is created from one source code. The details of the process of creating the modified source code by adding the functions (1) and (3) in FIG. In FIG. 2, the modified source code creation unit 32 creates a first modified source code from the first source code before the function change, and creates a second modified source code from the second source code before the function change. To do.

  Next, details of processing for creating first and second scenario correction data from the first and second correction source codes of (2) and (4) of FIG. 2B, and FIG. (5) The details of the process of automatically creating the second test scenario from the first test scenario will be described. FIG. 20 is a flowchart showing details of the test scenario automatic creation processing according to the present embodiment.

  When the processing of FIG. 20 is started, the correction source code creation unit 32 determines whether or not scenario correction data exists in the scenario correction DB 44 (step S80). At the time of (1) in FIG. 2B, there is no scenario correction data. Therefore, the correction data creation unit 34 creates a modified source code by adding a notation such as a predetermined function to the source code (step S81). Here, the modified source code creation unit 32 adds the notation of a predetermined function or the like to the first source code that is the source code before the function change, and the first modified source code that is the modified source code before the function change. Create

Next, the web system 20 is activated (step S82), an HTML file is generated by executing processing based on the first correction source code, and the correction data creation unit 34 performs the first scenario correction corresponding to the HTML file. Business data is created (step S83). An example of the HTML file before the function change is shown on the left side of FIG. 21, and an example of the first scenario correction data created on the right side of FIG. The first scenario correction data is used to correct the test scenario.
(Scenario correction data creation process)
Details of the scenario correction data creation process will be described with reference to FIG. FIG. 22 is a flowchart showing a scenario correction data creation process according to this embodiment. First, the correction data creation unit 34 acquires one line in order from the top of the HTML file (step S101). For example, in FIG. 21, one line of the line number “1” is acquired. Next, the correction data creation unit 34 determines whether all the lines of the HTML file have been processed (step S102). If the correction data creation unit 34 determines that all the lines have been processed, the process ends. On the other hand, if the correction data creation unit 34 determines that all the lines have not been processed, it extracts the tag description from the acquired line (step S103). The description of the tag is indicated by "<...>" or "</ ...>". Next, the correction data creation unit 34 determines whether all the data included in the acquired line has been processed (step S104). If the correction data creation unit 34 determines that all the data included in the acquired line has been processed, the correction data creation unit 34 returns to step S101 and repeats the processing from step S101 onward.

  On the other hand, if the correction data creation unit 34 determines that all the data included in the acquired line has not been processed, it determines the type of the extracted data (step S105). If the correction data creation unit 34 determines that the extracted data is not a tag, the correction data creation unit 34 returns to step S102.

  If the correction data creation unit 34 determines that the extracted data is the end of the tag (</ tag name>), the process proceeds to step S116 and determines whether “/” is included in the tree information (step S116). The tree information indicates the tag structure of the HTML file. If the correction data creation unit 34 determines that “/” is included in the tree information, it removes “/ tag name [number of tag appearances]” at the end of the tree information (step S117), and returns to step S102. On the other hand, when the correction data creation unit 34 determines that “/” is not included in the tree information, the correction data creation unit 34 empties the tree information (step S118) and returns to step S102.

  In step S105, the correction data creation unit 34 determines whether the previously deleted tag name is the same as the current tag name when it is determined that the extracted data is the start of a tag (that is, <tag name>) ( Step S106). If it is determined that they are not the same, the correction data creation unit 34 sets the number of appearances of the tag to “1” (step S107).

  Next, the correction data creation unit 34 determines what the tree information is (step S109). When the correction data creation unit 34 determines that the tree information is empty, the correction data creation unit 34 stores “/ tag name [number of tag appearances]” in the tree information (step S110). For example, in FIG. 21, when the line number is “1”, “/ html [1]” is stored in the tree information. Since [1] when the tag appearance count is 1 is omitted, the data stored in the tree information is “/ html”. On the other hand, if the correction data creation unit 34 determines that “/” is included in the tree information, the correction data creation unit 34 stores “tag name [number of tag appearances]” in the tree information (step S111).

  Next, the correction data creation unit 34 stores the tree information in the XPath of the scenario correction data (step S112). The tree information is stored in the XPath of the first scenario correction data before the function change, and is stored in the XPath of the second scenario correction data after the function change.

  Next, the correction data creation unit 34 determines whether it is the end of the tag (that is, </ tag name>) (step S113). If the correction data creation unit 34 determines that it is not the end of the tag, the process returns to step S102. On the other hand, if the correction data creation unit 34 determines that it is the end of the tag, it subtracts 1 from the number of appearances of the tag (step S114), and removes "/ tag name [tag appearance count]" at the end of the tree information. Then (step S115), the process returns to step S102. For example, in FIG. 21, when the row number is “13”, the data stored in the tree information is “/ html / body / table / tr”.

  The example of the scenario correction data creation process called in step S83 of FIG. 20 has been described above with reference to FIG. Next, proceeding to step S84 of FIG. 20, the test scenario reading unit 33 reads the test scenario to be executed next from the test scenario DB 43. Next, the test execution processing unit 37 determines whether the test has been completed for all of the test scenarios (step S85). When the test execution processing unit 37 determines that the test has not been completed for all the test scenarios, the test execution process unit 37 executes the test scenario (step S86), returns to step S83, and continues until the test is completed for all the test scenarios. The processes of S83 to S86 are repeated. Here, the web screen 11 before the function change is tested according to the operation procedure of the first test scenario. The test execution result data is stored in the test execution result DB 45.

  If it is determined in step S85 that the test has been completed for all of the first test scenarios, or if it is determined in step S80 that there is scenario correction data, the correction data creation unit 34 proceeds to step S87. . The correction data creation unit 34 creates a modified source code by adding a predetermined notation to the source code. At this point, the function has been changed in the server / storage system 1. Therefore, the modified source code creation unit 32 creates a second modified source code that is a modified source code after the function change by adding a predetermined notation to the second source code that is the source code after the function modification.

  Next, the web system 20 is activated (step S88), an HTML file is generated by executing processing based on the second correction source code, and the correction data creation unit 34 performs the second scenario correction according to the HTML file. Business data is created (step S89). An example of the HTML file after the function change is shown on the left side of FIG. 23, and an example of the second scenario correction data created on the right side of FIG. The second scenario correction data is used to correct the test scenario.

Next, the test scenario creation unit 36 acquires the first scenario correction data before the corresponding function change from the scenario correction DB 44 (step S90). The test scenario creation unit 36 automatically creates a second test scenario from the first test scenario based on the first scenario correction data and the second scenario correction data (step S91). That is, the XPath extraction unit 35 associates the first XPath with the second XPath according to the position where the predetermined notation included in the first scenario correction data and the second scenario correction data matches. To extract. Based on the correspondence information, the test scenario creation unit 36 creates a second test scenario indicating an operation procedure for testing the second web screen from a first test scenario indicating the operation procedure for testing the first web screen. create.
(Test scenario automatic creation process)
Details of the test scenario automatic creation processing will be described with reference to FIG. FIG. 24 is a flowchart showing automatic test scenario creation processing according to the present embodiment. First, the test scenario creation unit 36 removes a line beginning with “HTML” from the first scenario correction data (step S120). As a result, the line beginning with “HTML” indicated by the diagonal lines in the left diagram of FIG. 25 is removed.

  Next, the test scenario creation unit 36 removes a line beginning with “HTML” from the second scenario correction data (step S121). As a result, the line beginning with “HTML” indicated by the oblique lines in the right diagram of FIG. 25 is removed.

  Next, the test scenario creation unit 36 acquires a line from the first scenario correction data (step S122). Thereby, one line of the line number “9” in the left diagram of FIG. 25 is acquired. Next, the test scenario creation unit 36 determines whether all the processes for the first scenario correction data have been completed (step S123). If the test scenario creation unit 36 determines that all the processes for the first scenario correction data have been completed, the process ends. On the other hand, if it is determined that the first scenario correction data has not been completely processed, the test scenario creation unit 36 acquires the next line from the first scenario correction data (step S124). Thereby, one line of the line number “11” in the left diagram of FIG. 25 is acquired.

  Next, the test scenario creation unit 36 acquires a line from the second scenario correction data (step S125). Thereby, one line of the line number “16” in the right figure of FIG. 25 is acquired. Next, the test scenario creation unit 36 determines whether all the processing of the second scenario correction data has been completed (step S126). If the test scenario creation unit 36 determines that all processing of the second scenario correction data has been completed, the process proceeds to step S131. On the other hand, when it is determined that the second scenario correction data has not been completely processed, the test scenario creation unit 36 obtains the first line obtained from the first scenario correction data and the second scenario correction data. Are matched (step S127).

  If the test scenario creation unit 36 determines that the first line acquired from the first scenario correction data and the second scenario correction data do not match, the test scenario creation unit 36 returns to step S125. On the other hand, if it is determined that they match, the test scenario creation unit 36 acquires the next line from the second scenario correction data (step S128). Thereby, one line of the line number “18” in the right diagram of FIG. 25 is acquired.

  Next, the XPath extraction unit 35 determines whether or not the next line acquired from the first scenario correction data and the second scenario correction data matches (step S129). If the test scenario creation unit 36 determines that the next line acquired from the first and second scenario correction data does not match, the test scenario creation unit 36 returns to step S125. On the other hand, if it is determined that they match, the XPath extraction unit 35 extracts correspondence information between the first XPath included in the first scenario correction data and the second XPath included in the second scenario correction data. . The XPath extraction unit 35 extracts correspondence information between the first XPath and the second XPath according to a position where a predetermined notation included in the first scenario correction data and the second scenario correction data matches. . In the present embodiment, the position where the predetermined notation matches in order to extract the correspondence information is a plurality of positions of the first line and the next line acquired from the first scenario correction data and the second scenario correction data. It is. However, the position where the predetermined notation matches is not limited to this, and may be only the first line acquired from the first scenario correction data and the second scenario correction data, or only the next line. There may be.

  The test scenario creation unit 36 includes the XPath between the first line acquired from the first scenario correction data and the next line, and the first line to the next line acquired from the second scenario correction data. Based on the corresponding relationship (corresponding information) with the XPath, the XPath of the first test scenario is replaced and the second test scenario is automatically created (step S130).

  For example, in the example of FIG. 25, between the two lines from which the first scenario correction data is acquired (between the first line and the next line) and between the two lines from which the second scenario correction data is acquired ( Based on the correspondence information 1 between the first line and the next line), the XPath of the first test scenario is replaced and the second test scenario is automatically created. Similarly, for the correspondence information 2, the XPath of the first test scenario is replaced, and the second test scenario is automatically created.

  Accordingly, as shown in FIG. 26, the XPath of the correspondence information 1 of the first test scenario is changed from the XPath (A) of the first scenario correction data in FIG. 21 to the second scenario correction data in FIG. XPath (a). Further, the XPath of the correspondence information 2 of the first test scenario is replaced with the XPath (b) of the second scenario correction data of FIG. 23 from the XPath (B) of the first scenario correction data of FIG. . In this way, the second test scenario after the function change can be automatically created from the first test scenario before the function change of the system.

  In the correspondence information 1 of FIG. 26, in the command input (input) of the first test scenario of FIG. 27A, the place (Xpath) for inputting the value “1 + 2” is “/ html / body / table / tr / td”. / input ". On the other hand, in this embodiment, in the command input of the second test scenario in FIG. 27B, the place (Xpath) where the value “1 + 2” is input is “/ html / body / table / tr [2]”. Automatically changed to “/ td / input”.

  26, in the command Check (check) of the first test scenario in FIG. 27A, the value “3” is the location (Xpath) “/ html / body / table / tr / td [ 2] ”is checked. On the other hand, in this embodiment, in the command Check of the second test scenario in FIG. 27B, the location (Xpath) for checking that the value “3” is displayed is “/ html / body / table / tr [2] / td [2] "is automatically changed.

  When the test scenario input command indicated by “P” in FIG. 28 is executed on the web screen 11 (first web screen example) in FIG. 29 generated based on the HTML file before the function change shown in FIG. “1 + 2” is input to the “annotation” input area (location indicated by Xpath) shown in FIG. When the test scenario display command indicated by “Q” in FIG. 28 is executed, the value “3” displayed in the “result” (location indicated by Xpath) shown in FIG. 29 is checked.

  On the other hand, “Note 2” indicated by “R” in FIG. 30 is added to the HTML file after the function change. Thereby, on the web screen 11 (second web screen example) in FIG. 31 after the function change, “annotation 2” is displayed before “annotation” on the web screen 11 in FIG. 29 before the function change. .

  If a value is to be displayed at a location on the screen indicated by Xpath of the first test scenario shown in FIG. 27A with respect to the web screen 11 of FIG. 31 after the function change, in the test, as shown in FIG. An attempt is made to input the value “1 + 2” in “annotation 2”. Further, as shown in FIG. 32, it is confirmed that the value “3” is displayed in “annotation”.

  However, in the present embodiment, based on the automatically created second test scenario, as shown in FIG. 33, based on the Xpath shown in FIG. 27B of the automatically created second test scenario, “annotation” It is confirmed that the value “1 + 2” is entered in “” and the value “3” is displayed in “Result”. In this way, the function of the command of the test scenario after the function change is created by automatically creating the second test scenario by associating the Xpath before the function change of the first test scenario with the Xpath after the function change. This can be executed in accordance with the layout of the web screen 11 later.

  As described above, the test is repeatedly executed based on the second test scenario automatically created from the first test scenario. After all test scenarios have been executed, the test is terminated.

  FIG. 34 shows an execution example of the test scenario before the function change, and FIG. 35 shows an execution example of the test scenario after the function change. 34 and 35, the web system 20 is activated on the login screen shown in the upper left diagram, and the screen transitions to the web screen 11 shown in the lower left diagram in FIGS. 34 and 35 after login. From the first test scenario for the web screen 11 in the lower left diagram in FIG. 34, a second test scenario is automatically created when a new function display (disk usage) is added to the web screen 11 in the lower left diagram in FIG. An example is shown.

  As described above, according to the web test system 30 according to the embodiment, when a function change occurs in the system, the web screen after the function change of the system is tested based on the test scenario before the function change. Test scenarios can be created automatically. That is, even if the layout of the web screen 11 is changed before and after the function change of the system, the Xpath correspondence information described in the test scenario before and after the function change is extracted to test the web screen 11 before the function change. A test scenario for testing the web screen 11 after the function change can be automatically created from the test scenario. This eliminates the need to manually change the test scenario, and allows the screen to be tested without depending on the OS or browser.

(Hardware configuration example)
Finally, a hardware configuration example of the web test system 30 according to the present embodiment will be described with reference to FIG. FIG. 36 is a diagram illustrating a hardware configuration example of the web test system 30 according to the present embodiment.

  As shown in FIG. 36, the web test system 30 includes an input device 101, a display device 102, an external I / F 103, a RAM (Random Access Memory) 104, a ROM (Read Only Memory) 105, a CPU (Central Processing Unit) 106, A communication I / F 107, an HDD (Hard Disk Drive) 108, and the like are provided and are connected to each other via a bus B.

  The input device 101 includes a keyboard and a mouse, and is used to input each operation signal to the web test system 30. The display device 102 displays various processing results.

  The communication I / F 107 is an interface that connects the web test system 30 to a network. Thereby, the web test system 30 can perform data communication with the web system 20 via the communication I / F 107.

  The HDD 108 is a non-volatile storage device that stores programs and data. The stored programs and data include basic software and application software that control the entire apparatus. For example, the HDD 108 stores a source code DB 41, a modified source code DB 42, a test scenario DB 43, a scenario modification DB 44, and a test execution result DB 45.

  The external I / F 103 is an interface with an external device. The external device includes a recording medium 103a. Thereby, the web test system 30 can read and / or write the recording medium 103a via the external I / F 103.

  Examples of the recording medium 103a include a floppy (registered trademark) disk, a CD (Compact Disk), a DVD (Digital Versatile Disk), an SD memory card (SD Memory card), a USB memory (Universal Serial Bus memory), and the like.

  The ROM 105 is a nonvolatile semiconductor memory (storage device) that can retain internal data even when the power is turned off. The ROM 105 stores programs and data such as network settings. The RAM 104 is a volatile semiconductor memory (storage device) that temporarily stores programs and data. The CPU 106 is an arithmetic unit that realizes control of the entire apparatus and mounting functions by reading programs and data from the storage device (for example, “HDD 108”, “ROM 105”, etc.) onto the RAM 104 and executing processing.

  With the above hardware configuration, for example, the CPU 106 executes a test on the web screen 11 based on the test scenario operation procedure using data and programs stored in the ROM 105 and the HDD 108.

  Information on the source code DB 41, the modified source code DB 42, the test scenario DB 43, the scenario modification DB 44, and the test execution result DB 45 may be stored in the RAM 104 and the HDD 108. These DBs may be stored in a server or the like on the cloud connected to the web test system 30 via a network.

  As described above, the test program, the test apparatus, and the test method have been described in the above embodiment. However, the test program, the test apparatus, and the test method according to the present invention are not limited to the above embodiment, and various modifications can be made within the scope of the present invention. Modifications and improvements are possible. In addition, when there are a plurality of the above-described embodiments and modifications, they can be combined within a consistent range.

  For example, the configuration of the test program, the test apparatus, and the test method according to the above embodiment is an example, and does not limit the scope of the present invention. Needless to say, there are various system configuration examples depending on the application and purpose. .

1: Server / Storage System 10: Server / Storage Device 11: Web Screen 20: Web System 30: Web Test System 31: Source Code Reading Unit 32: Modified Source Code Creation Unit 33: Test Scenario Reading Unit 34: Correction Data Creation Unit 35: XPath extraction unit 36: Test scenario creation unit 37: Test execution processing unit 40: Storage unit 41: Source code DB
42: Modified source code DB
43: Test scenario DB
44: DB for scenario correction
45: Test execution result DB

Claims (4)

First XPath that specifies the position of the first web screen before the function change based on the first modified source code in which a predetermined notation is added to the first source code in which the process before the function change of the system is described And first scenario correction data including the predetermined notation,
A second XPath for designating the position of the second web screen after the function change based on the second modified source code in which a predetermined notation is added to the second source code in which processing after the function change of the system is described And the second scenario correction data including the predetermined notation,
Corresponding information between the first XPath and the second XPath is extracted in accordance with a position where the predetermined notation included in the first scenario correction data and the second scenario correction data matches. ,
Based on the extracted correspondence information, a second test scenario indicating an operation procedure of the second web screen is created from a first test scenario indicating an operation procedure of the first web screen.
A test program for causing a computer to execute processing. The extraction process is:
Extracting correspondence information between the first XPath and the second XPath from the tag structure of the HTML file corresponding to the position where the predetermined notation matches;
The test program according to claim 1. A first modified source code is created by adding a predetermined notation to the first source code in which processing before the function change of the system is described, and second source code in which processing after the function change of the system is described A modified source code creation unit for creating a second modified source code by adding a predetermined notation to
Based on the first correction source code, first scenario correction data including a first XPath designating a position of the first web screen before the function change and the predetermined notation is created, and the first Based on the correction source code of No. 2, the correction data generation unit that generates the second scenario correction data including the second XPath that specifies the position of the second web screen after the function change and the predetermined notation When,
Corresponding information between the first XPath and the second XPath is extracted according to a position where the predetermined notation included in the first scenario correction data and the second scenario correction data matches. An extractor;
A test scenario creating unit that creates a second test scenario indicating the operation procedure of the second web screen from a first test scenario indicating the operation procedure of the first web screen based on the extracted correspondence information;
Test equipment with First XPath that specifies the position of the first web screen before the function change based on the first modified source code in which a predetermined notation is added to the first source code in which the process before the function change of the system is described And first scenario correction data including the predetermined notation,
A second XPath for designating the position of the second web screen after the function change based on the second modified source code in which a predetermined notation is added to the second source code in which processing after the function change of the system is described And the second scenario correction data including the predetermined notation,
Corresponding information between the first XPath and the second XPath is extracted in accordance with a position where the predetermined notation included in the first scenario correction data and the second scenario correction data matches. ,
Based on the extracted correspondence information, a second test scenario indicating an operation procedure of the second web screen is created from a first test scenario indicating an operation procedure of the first web screen.
A test method in which processing is performed by a computer.

Images