WO2015198473A1 - 試験プログラム、試験装置及び試験方法 - Google Patents

試験プログラム、試験装置及び試験方法 Download PDF

Info

Publication number
WO2015198473A1
WO2015198473A1 PCT/JP2014/067162 JP2014067162W WO2015198473A1 WO 2015198473 A1 WO2015198473 A1 WO 2015198473A1 JP 2014067162 W JP2014067162 W JP 2014067162W WO 2015198473 A1 WO2015198473 A1 WO 2015198473A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
scenario
source code
xpath
correction data
Prior art date
Application number
PCT/JP2014/067162
Other languages
English (en)
French (fr)
Inventor
正志 荒山
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to PCT/JP2014/067162 priority Critical patent/WO2015198473A1/ja
Priority to JP2015531373A priority patent/JP5958655B2/ja
Publication of WO2015198473A1 publication Critical patent/WO2015198473A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/28—Error detection; Error correction; Monitoring by checking the correct order of processing

Definitions

  • the present invention relates to a test program, a test apparatus, and a test method.
  • the web system provides a service that provides information such as the operating status of the monitored system on the web screen.
  • the layout of the web screen may be changed accordingly.
  • the layout of the web screen may be changed to display information about the function added to 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.
  • the regression test is executed by the 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.
  • 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 Japanese Patent Laid-Open No. 2005-266554
  • 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.
  • test scenario 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.
  • 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.
  • this method is a manual test scenario correction, the correction takes time.
  • 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.
  • the present invention aims to automatically create a test scenario after a function change based on a test scenario before the function change for testing a web screen.
  • 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
  • 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 the first web screen is provided. .
  • a test scenario after the function change can be automatically created based on the test scenario before the function change for testing the web screen.
  • FIG. 2A is a comparison diagram for explaining manual creation of a test scenario
  • FIG. 2B is a diagram for explaining automatic creation of a test scenario according to an embodiment.
  • 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.
  • wrist of FIG. The flowchart which shows an example of the test execution process 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.
  • FIG. 27A shows a test scenario for the system before the function change
  • 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 2nd test scenario The figure which shows the example of execution of the test scenario before a function change.
  • the web system 20 provides information such as the operating status of the monitored server / storage system 1 on a web screen.
  • the functional configuration information 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.
  • the web system 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.
  • 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.
  • a position specifying method using XPath is used for specifying the position of an HTML element.
  • 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 W3C (World Wide Web Consortium).
  • W3C World Wide Web Consortium
  • test scenario the operation for the element of the HTML file that describes the specified 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.
  • XPath which is a location specification
  • the location specification 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.
  • FIG. 7 and FIG. 8 show an example of the XPath after the layout change of the web screen 11 of FIG. 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.
  • the (5) in FIG. XPath shown in FIG. 4 is “/ html / body / table / tr [2] / td [2]”.
  • XPath is “/ html / body / table / tr [4] / td [2]”.
  • the web test system 30 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.
  • 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.
  • a source code DB Data Base
  • a modified source code DB 42 a test scenario DB 43
  • a scenario modification DB 44 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 a 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).
  • FIG. 10 shows a function list 100 showing an example of the predetermined notation.
  • 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.
  • 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.
  • 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”.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • automatic creation of a test scenario and execution of a test based on the test scenario are repeatedly performed.
  • FIG. 12 is a flowchart illustrating an example of a test execution process according to the present embodiment.
  • the left side is a test execution process of the web screen 11 before the function change provided in the web system 20
  • 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.
  • the source code reading unit 31 reads the source code before the function change (step S10).
  • the source code before the function change is also referred to as a first source code.
  • 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.
  • 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).
  • the web system 20 displays the web screen 11 in accordance with the generated latest HTML file (step S18).
  • the first web screen is displayed based on the first source code.
  • information such as operation information of the server / storage system 1 before the function change is displayed.
  • 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.
  • 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).
  • the modification data creation unit 34 creates the next first scenario modification data based on the first modification source code (step S26).
  • the test execution processing unit 37 determines whether or not there is a next first test scenario (step S28), and if it is determined that there is no next first test scenario, this 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.
  • the source code reading unit 31 reads the source code after the function change (step S30).
  • the source code after the function change is also referred to as a second source code.
  • 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).
  • 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).
  • the web system 20 displays the web screen 11 in accordance with the generated latest HTML file (step S38).
  • the second web screen is displayed based on the second source code.
  • information such as operation information of the server / storage system 1 after the function change is displayed.
  • 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.
  • 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).
  • the correction data creation unit 34 creates the next second scenario correction data based on the generated second correction source code (step S46).
  • the test execution processing unit 37 determines whether or not there is a next test scenario (step S48), and if it is determined that there is no next test scenario, this 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.
  • 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.
  • the modified source code creation unit 32 executes a function list generation process (FIG. 14) (step S50).
  • the list is formed (step S70). However, "! and "// ⁇ line feed" are not divided.
  • 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.
  • 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.
  • HTML output function list generation step S75
  • Database write function list generation step S76
  • Function name Function type Function argument step S77
  • 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, “;”.
  • 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.
  • 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.
  • step S54 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).
  • 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.
  • step S61 the modified source code creation unit 32 inserts a function argument (step S61).
  • 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.
  • 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 is completed, and the source code listed when it is determined that the scanning is 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.
  • a modified source code is created from one source code.
  • 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.
  • FIG. 20 is a flowchart showing details of the test scenario automatic creation processing according to the present embodiment.
  • the correction source code creation unit 32 determines whether or not the 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).
  • 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
  • step S82 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.
  • the correction data creation unit 34 acquires one line in order from the top of the HTML file (step S101). For example, in FIG.
  • step S102 determines whether all the lines of the HTML file have been processed. 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.
  • 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.
  • step S116 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, if the correction data creation unit 34 determines that “/” is not included in the tree information, the tree information is emptied (step S118), and the process returns to step S102.
  • 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), and if it is determined to be the same, increases the number of appearances of the tag “+1” (step S108).
  • the correction data creation unit 34 determines what the tree information is (step S109).
  • 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”.
  • 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).
  • 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.
  • 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”.
  • step S83 of FIG. 20 The example of the scenario correction data creation process called up 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.
  • step S85 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.
  • step S88 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.
  • 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.
  • 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.
  • 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.
  • test scenario creation unit 36 removes the line starting 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.
  • 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.
  • 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.
  • the test scenario creation unit 36 acquires one 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.
  • 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).
  • test scenario creation unit 36 determines that the first line acquired from the first scenario correction data and the second scenario correction data does not match, the process 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.
  • 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.
  • 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.
  • 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).
  • the XPath of the first test scenario is replaced and the second test scenario is automatically created.
  • the correspondence information 2 the XPath of the first test scenario is replaced, and the second test scenario is automatically created.
  • 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. .
  • the second test scenario after the function change can be automatically created from the first test scenario before the function change of the system.
  • the place (Xpath) for inputting the value “1 + 2” is “/ html / body / table / tr / td”. / input ".
  • the place (Xpath) where the value “1 + 2” is input is “/ html / body / table / tr [2]”. Automatically changed to “/ td / input”.
  • the value “3” is the location (Xpath) “/ html / body / table / tr / td [ 2] ”is checked.
  • the location (Xpath) for checking that the value “3” is displayed is “/ html / body / table / tr [2] / td [2] "is automatically changed.
  • 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.
  • 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.
  • 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
  • FIG. 35 shows an execution example of the test scenario after the function change.
  • 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.
  • 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.
  • 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.
  • FIG. 36 is a diagram illustrating a hardware configuration example of the web test system 30 according to the present embodiment.
  • 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 each is connected to each other via a bus B.
  • a bus B A bus B.
  • the input device 101 includes a keyboard, a mouse, and the like, 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 for connecting 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.
  • 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.
  • External I / F 103 is an interface with an external device.
  • the external device includes a recording medium 103a.
  • the web test system 30 can read and / or write the recording medium 103a via the external I / F 103.
  • the recording medium 103 a includes 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.
  • the CPU 106 executes the test of the web screen 11 based on the operation procedure of the test scenario using data and programs stored in the ROM 105 and the HDD 108.
  • source code DB 41 may be stored in the RAM 104 and the HDD 108.
  • These DBs may be stored in a cloud server connected to the web test system 30 via a network.
  • test program 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.
  • 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. .
  • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

　システムの機能変更前の処理が記述された第１のソースコードに所定の表記を付加した第１の修正ソースコードに基づき、機能変更前の第１のウェブ画面の位置を指定する第１のＸPathと所定の表記とを含んだ第１のシナリオ修正用データを作成し、システムの機能変更後の処理が記述された第２のソースコードに所定の表記を付加した第２の修正ソースコードに基づき、機能変更後の第２のウェブ画面の位置を指定する第２のＸPathと所定の表記とを含んだ第２のシナリオ修正用データを作成し、第１のシナリオ修正用データと第２のシナリオ修正用データとに含まれる所定の表記が一致する位置に応じて第１のＸPathと第２のＸPathとの対応情報を抽出し、抽出した対応情報に基づき、第１のウェブ画面の操作手順を示す第１のテストシナリオから第２のウェブ画面の操作手順を示す第２のテストシナリオを作成する、処理をコンピュータに実行させるための試験プログラムが提供される。

Description

試験プログラム、試験装置及び試験方法
　本発明は、試験プログラム、試験装置及び試験方法に関する。
　ウェブシステムは、監視対象のシステムの稼働状況等の情報をウェブ画面に表示して提供するサービスを行っている。サーバ／ストレージシステムのある機能が変更すると、これに伴いウェブ画面のレイアウトが変更される場合がある。一例としては、サーバ／ストレージシステムに新機能が追加された場合、サーバ／ストレージシステムに追加された機能に関する情報を表示するためにウェブ画面のレイアウトが変わる場合がある。同様に、サーバ／ストレージシステムからある機能が削除された場合、サーバ／ストレージシステムから削除した機能に関する情報を削除するために画面のレイアウトが変わることがある。
　サーバ／ストレージシステムでは、このような機能の変更以外の機能についての処理に変更はない。よって、ウェブシステムは、追加又は削除した機能以外の機能に関しては、機能変更の前後においてウェブ画面上で同じ動作が行われ、結果が表示されることを保証しなければならない。そのためのテスト方法としてリグレッションテストが知られている。
　リグレッションテストはウェブテストシステムにより実行される。ウェブテストシステムはテストシナリオを実行して、変更した機能以外の機能に関し機能変更の前後でウェブ画面の結果が同じことを確認する。テストシナリオは、ウェブ画面のテスト用の操作手順を示す。テストシナリオには、ウェブ画面を記述するＨＴＭＬ(Hyper Text Markup Language)上の要素が指定される。ウェブ画面とそれに対するテストシナリオの一例を図３４及び図３５に示す。ＨＴＭＬ上の各要素の位置指定にはウェブ画面上の位置を指定するＸPathが用いられる。
特開２００９－１４０１５５号公報 特開２００５－２６６９５４号公報
　しかしながら、ＸPathは、ウェブ画面のレイアウトが変化するとそれに応じて変化する。よって、ウェブ画面のレイアウトが変わると機能変更前のＸPathを、同じ要素の位置を指定する機能変更後のＸPathとして使用することができない場合がある。
　つまり、テストシナリオにはＸPathが記述されている。このため、サーバ／ストレージシステムの機能変更に応じてウェブ画面のレイアウトが変わると、機能変更前のＸPathを含むテストシナリオを機能変更後のリグレッションテストのテストシナリオとしてそのまま使用することができなくなる。
　そこで、図１のフローチャート及び図２（ａ）に示すように、機能変更前後のサーバ／ストレージシステムの機能仕様書１，２から差分を抽出し、差分に基づき機能変更前の第１のテストシナリオを手動で修正して、機能変更後の第２のテストシナリオを作成することが行われている。しかし、この方法は、手動によるテストシナリオの修正であるため、修正に手間がかかる。加えて、その複雑さは、ウェブ画面の中の表示項目数、画面の数の多さに比例し、今後ますます多機能化するシステムのテストシナリオの修正にはさらに大きな手間がかかることが予想される。
　さらに、連続性のあるテストシナリオに対しては、テストシナリオの修正漏れのためにテストが実行できない場合、修正漏れによるエラー箇所以降のテストが正しく実行されない可能性が高いため、エラーの修正とテストの実行とを手動で繰り返し行わなければならず、追加工数が発生する。
　そこで、一側面では、本発明は、ウェブ画面をテストするための機能変更前のテストシナリオに基づき、機能変更後のテストシナリオを自動作成することを目的とする。
　一つの案では、システムの機能変更前の処理が記述された第１のソースコードに所定の表記を付加した第１の修正ソースコードに基づき、機能変更前の第１のウェブ画面の位置を指定する第１のＸPathと前記所定の表記とを含んだ第１のシナリオ修正用データを作成し、システムの機能変更後の処理が記述された第２のソースコードに所定の表記を付加した第２の修正ソースコードに基づき、機能変更後の第２のウェブ画面の位置を指定する第２のＸPathと前記所定の表記とを含んだ第２のシナリオ修正用データを作成し、前記第１のシナリオ修正用データと前記第２のシナリオ修正用データとに含まれる前記所定の表記が一致する位置に応じて前記第１のＸPathと前記第２のＸPathとの対応情報を抽出し、前記抽出した対応情報に基づき、前記第１のウェブ画面の操作手順を示す第１のテストシナリオから前記第２のウェブ画面の操作手順を示す第２のテストシナリオを作成する、処理をコンピュータに実行させるための試験プログラムが提供される。
　一態様によれば、ウェブ画面をテストするための機能変更前のテストシナリオに基づき、機能変更後のテストシナリオを自動作成することができる。
機能仕様書の差分情報からテストシナリオを手動で作成する例を示すフローチャート。 図２（ａ）はテストシナリオの手動作成を説明するための比較図、図２（ｂ）は一実施形態にかかるテストシナリオの自動作成を説明するための図。 一実施形態にかかるシステムの全体構成の一例を示す図。 ＨＴＭＬ上の各要素とＸPathの位置指定の例を示す図。 ＸPathを使用したテストシナリオの一例を示す図。 ウェブ画面のレイアウト変更例を示す図。 図４に対してウェブ画面のレイアウト変更後のＸPathの一例を示す図。 図４に対してウェブ画面のレイアウト変更後のＸPathの他の例を示す図。 一実施形態にかかるウェブテストシステムの機能構成の一例を示す図。 一実施形態にかかる関数リストの一例を示す図。 図１０の関数リストの本体の一例を示す図。 一実施形態にかかるテスト実行処理の一例を示すフローチャート。 一実施形態にかかる関数付加処理の一例を示すフローチャート。 一実施形態にかかる関数リスト生成処理の一例を示すフローチャート。 一実施形態にかかるソースコードの一例を示す図。 一実施形態にかかるリスト化されたソースコードの一例を示す図。 図１６の構文解析結果を示す図。 一実施形態にかかる修正ソースコードの一例を示す図。 一実施形態にかかる修正ソースコードを元のソースコードに戻した例を示す図。 一実施形態にかかるテストシナリオの自動作成処理の詳細を示すフローチャート。 一実施形態にかかるシナリオ修正用データ（機能変更前）の作成例を示す図。 一実施形態にかかるシナリオ修正用データの作成処理を示すフローチャート。 一実施形態にかかるシナリオ修正用データ（機能変更後）の作成例を示す図。 一実施形態にかかるテストシナリオの自動作成処理を示すフローチャート。 一実施形態にかかるシナリオ修正用データ（機能変更前後）の一致検出例を示す図。 一実施形態にかかるＸPathの検出例を示す図。 図２７（ａ）は、機能変更前のシステムに対するテストシナリオを示し、図２７（ｂ）は、機能変更後のシステムに対するテストシナリオを示す図。 機能変更前のＨＴＭＬを示す図。 機能変更前のシステムに対する第１のテストシナリオを適用するウェブ画面例を示す図。 機能変更後のＨＴＭＬを示す図。 機能変更後のシステムに対する第２のテストシナリオを適用するウェブ画面例を示す図。 第１のテストシナリオを使用したテスト例を示す図。 第２のテストシナリオを使用したテスト例を示す図。 機能変更前のテストシナリオの実行例を示す図。 機能変更後のテストシナリオの実行例を示す図。 一実施形態にかかるウェブテストシステムのハードウェア構成例を示す図。
　以下、本発明の実施形態について添付の図面を参照しながら説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複した説明を省く。
　［システムの全体構成］
　まず、。本発明の一実施形態に係るサーバ／ストレージシステム１、ウェブシステム２０及びウェブテストシステム３０の関係について、図３を参照しながら説明する。ウェブシステム２０は、監視対象のサーバ／ストレージシステム１の稼働状況等の情報をウェブ画面に表示して提供する。
　本実施形態にかかるサーバ／ストレージシステム１において、サーバ／ストレージ装置１０の機能構成の情報は、ウェブ画面１１を用いて入力される。ウェブ画面１１への入力及びウェブ画面１１の更新は、ウェブシステム２０により制御される。
　サーバ／ストレージシステム１において機能の追加や機能の削除が行われた場合、ウェブシステムは、追加又は削除した機能以外の機能に関しては、機能変更の前後において同じ動作が行われウェブ画面上に表示されることを保証しなければならない。そのためのテスト方法としてリグレッションテストが知られている。
　リグレッションテストは、ウェブテストシステム３０により実行される。ウェブテストシステム３０は、まず、サーバ／ストレージ装置１０の機能仕様書からウェブ画面１１のテスト用の操作手順を作成する。ウェブ画面１１のテスト用の操作手順を、以下「テストシナリオ」という。
　ウェブテストシステム３０は、テストシナリオを入力し、テストシナリオの操作手順に基づきウェブ画面１１を操作してテストを実行し、その実行結果を検証する。このとき、ウェブテストシステム３０は、テストシナリオに従ってウェブ画面１１の操作を自動で行う。
　テストシナリオには、ウェブ画面を記述するＨＴＭＬ上の各要素が指定される。ＨＴＭＬの要素の位置指定には、ＸPathによる位置指定方法が用いられる。図４は、ＨＴＭＬ上の各要素とＸPathの位置指定の例を示す。ＸPathは、ＨＴＭＬなどのＸＭＬ(Extensible Markup Language)文書の中の特定の要素を指し示す記述方法を定めた規格であり、Ｗ３Ｃ（World Wide Web Consortium）が勧告した標準仕様に基づく。図４（ｂ）に示すＨＴＭＬファイルの要素（Ｅ１）に対して、図４（ａ）のウェブ画面１１に対応するテーブルの（１）で示される位置、は、図４（ｃ）の（１）のＸPathで示される。図４（ｂ）に示すＨＴＭＬファイルの要素（Ｅ２）に対して、図４（ａ）のテーブルの（２）で示される位置は、図４（ｃ）の（２）のＸPathで示される。図４（ｂ）に示すＨＴＭＬファイルの要素（Ｅ３）に対して、図４（ａ）のテーブルの（３）で示される位置は、図４（ｃ）の（３）のＸPathで示される。
　テストシナリオでは、指定したウェブ画面を記述するＨＴＭＬファイルの要素に対する操作を記載する。ＸPathを使用したテストシナリオの一例を図５に示す。テストシナリオに記載されるコマンドには、文字入力（ｉｎｐｕｔ）、クリック（Ｃｌｉｃｋ）、任意のデータとの比較（Ｃｈｅｃｋ）等がある。テストシナリオに記載のＸPathには、そのコマンドを実行する場所が指定される。
　図５に示すようにテストシナリオには場所の指定であるＸPathが記述されており、ウェブ画面１１のレイアウトが変わるとＨＴＭＬファイルの要素の位置指定、つまりＸPathが変わってしまう。このため、機能変更に応じてウェブ画面１１のレイアウトが変わると、機能変更前のＸPathを含むテストシナリオをそのまま機能変更後のテストシナリオとして使用することは困難である。
　例えば、図６の上図のウェブ画面１１の「注釈２」が削除され、下図のウェブ画面１１に示すようにレイアウトが変更した場合、レイアウト変更と共にＸPathも変更される。このため、レイアウト変更後のウェブ画面１１に対して元のテストシナリオをそのまま使用してテストを行うことはできない。
　図４のウェブ画面１１のレイアウト変更後のＸPathの一例を図７及び図８に示す。図７は、図４に対して画面要素（Ｄｅ）が削除されたためＸPathが変更になった例、図８は、図４に対して画面要素（Ａｄ）が追加されたためＸPathが変更になった例である。
　図４（ｂ）に示すＨＴＭＬファイルの要素（Ｅ３）に対する変更前の図４（ｃ）の（３）に示すＸPathは「/html/body/table/tr[3]/td[2]」である。これに対して、図７（ｂ）に示すＨＴＭＬファイルの要素（Ｄｅ）で示す部分が削除された場合、図７（ｂ）に要素（Ｅ３）に対する変更後の図７（ｃ）の（５）に示すＸPathは「/html/body/table/tr[2]/td[2]」である。
　また、図８（ｂ）に示すＨＴＭＬファイルの要素（Ａｄ）で示す部分が追加された場合、図８（ｂ）に要素（Ｅ３）に対する変更後の図８（ｃ）の（６）に示すＸPathは「/html/body/table/tr[4]/td[2]」である。このように、ウェブ画面１１のレイアウトが変更され、ＨＴＭＬファイルの要素が変更になるとＸPathで示されるウェブ画面１１上の位置の指定が変更される。
　以下に説明する一実施形態にかかるウェブテストシステム３０は、機能変更前のウェブ画面１１のテストに使用したテストシナリオから機能変更後のウェブ画面１１のテストに使用するテストシナリオを自動作成する。これにより、ウェブテストシステム３０が使用するテストシナリオを、機能仕様書に基づき手動で変更することを不要とする。なお、一実施形態にかかるウェブテストシステム３０は、ウェブ画面１１をテストする試験装置の一例である。ウェブテストシステム３０は、例えばＰＣ上で動くテストシステムであり、テストシナリオを入力してテストシナリオの操作手順に従いウェブ画面１１のテストを行う。
　［ウェブテストシステムの機能構成］
　本発明の一実施形態に係るウェブテストシステム３０の機能構成について、図９を参照しながら説明する。図９は、一実施形態に係るウェブテストシステム３０の機能構成の一例を示す。一実施形態に係るウェブテストシステム３０は、ソースコード読込部３１、修正ソースコード作成部３２、テストシナリオ読込部３３、修正用データ作成部３４、ＸPath抽出部３５、テストシナリオ作成部３６、テスト実行処理部３７及び記憶部４０を有する。
　記憶部４０は、ソースコードＤＢ（Ｄａｔａ　Ｂａｓｅ）４１、修正ソースコードＤＢ４２、テストシナリオＤＢ４３、シナリオ修正用ＤＢ４４及びテスト実行結果ＤＢ４５を有する。
　ソースコード読込部３１は、ソースコードＤＢ４１に格納された所定のソースコードを読み込む。ソースコードＤＢ４１は、ウェブシステム２０が提供する機能変更前のウェブ画面１１（第１のウェブ画面）を記述する。
　修正ソースコード作成部３２は、ソースコードに、所定の表記を付加した修正ソースコードを作成する。例えば、修正ソースコード作成部３２は、第１のソースコードに所定の関数又は固定値の表記を付加して第１の修正ソースコードを作成する（図２（ｂ）：（１）関数追加）。また、例えば、修正ソースコード作成部３２は、第２のソースコードに所定の関数又は固定値の表記を付加して第２の修正ソースコードを作成する（図２（ｂ）：（３）関数追加）。
　第１のソースコードには、サーバ／ストレージシステム１の機能変更前の内部処理が記述されている。第２のソースコードには、サーバ／ストレージシステム１の機能変更後の内部処理が記述されている。
　所定の表記の一例を示した関数リスト１００を図１０に示す。関数リスト１００は、外部から入力する。関数リスト１００は、関数の表記として変数対象関数名１０１及び挿入関数名１０２を有する。関数リスト１００は、固定値の表記として第１のデバッグ出力情報１０３、第２のデバッグ出力情報１０４、第３のデバッグ出力情報１０５、第４のデバッグ出力情報１０６・・・を有する。なお、図１１は、図１０の関数リストの本体の一例を示す。所定の表記には、関数の表記、固定値（固定文字等）の表記、関数に記載された引数を含む。
　テストシナリオ読込部３３は、テストシナリオＤＢ４３に格納された所定のテストシナリオを読み込む。
　修正用データ作成部３４は、第１の修正ソースコードに基づき、機能変更前の第１のウェブ画面の位置を指定する第１のＸPathと前記所定の表記とを含んだ第１のシナリオ修正用データを作成する。修正用データ作成部３４は、第２の修正ソースコードに基づき、機能変更後の第２のウェブ画面の位置を指定する第２のＸPathと前記所定の表記とを含んだ第２のシナリオ修正用データを作成する。
　例えば、図６の上図に示すウェブ画面１１を第１のウェブ画面とし、システムの機能変更に応じて図６の下図に示すようにウェブ画面１１のレイアウトの一部が変更された、ウェブ画面１１を第２のウェブ画面とする。
　第２のウェブ画面をテストする場合、修正用データ作成部３４は、第１の修正ソースコードに基づく処理を実行してシナリオ修正用データを作成する（図２（ｂ）：（２）実行）。作成されたシナリオ修正用データは、第１のウェブ画面のレイアウトを表記するための第１のＸPathを含み、以下、「第１のシナリオ修正用データ」ともいう。
　また、例えば、修正用データ作成部３４は、第２の修正ソースコードに基づく処理を実行してシナリオ修正用データを作成する（図２（ｂ）：（４）実行）。作成されたシナリオ修正用データは、第２のウェブ画面のレイアウトを表記するための第２のＸPathを含み、以下、「第２のシナリオ修正用データ」ともいう。第１のシナリオ修正用データ及び第２のシナリオ修正用データは、シナリオ修正用ＤＢ４４に格納される。
　ＸPath抽出部３５は、第１のシナリオ修正用データと第２のシナリオ修正用データとに含まれる前記所定の表記が一致する位置に応じて第１のＸPathと第２のＸPathとの対応情報を抽出する。
　テストシナリオ作成部３６は、対応情報に基づき、第１のウェブ画面のテスト用の操作手順を示す第１のテストシナリオから第２のウェブ画面のテスト用の操作手順を示す第２のテストシナリオを作成する（図２（ｂ）：（５）作成）。
　テスト実行処理部３７は、第２のテストシナリオの操作手順に従い機能変更後の第２のウェブ画面のテストを行う。テストの実行結果のデータは、テスト実行結果ＤＢ４５に保存される。
　［テストシナリオ自動作成の前提条件］
　以上に説明したテストシナリオ自動作成のための前提条件１～３について説明する。
　前提条件１：ＨＴＭＬファイルの生成前にウェブシステム２０で実行する処理（関数）に変更がないこと
　前提条件２：ＨＴＭＬファイルの生成後にウェブシステム２０で実行される処理（関数）に変更がないこと
　前提条件３：ウェブテストシステム３０においてテストシナリオの適用順序に変更がないこと
　本実施形態に係るウェブテストシステム３０によれば、上記前提条件の元、以下の仕組みでテストシナリオの再利用を可能とする。
（１）機能変更前と機能変更後のウェブシステム２０のソースコードを書き換えて以下の情報を出力する。
　・ＨＴＭＬファイルの生成前に実行した内部処理
　・ＨＴＭＬファイルの生成
　・ＨＴＭＬファイルの生成後に実行した内部処理
　上記の生成したＨＴＭＬファイルからＸPathが生成される。ＨＴＭＬファイルの生成前後の内部処理を付加したＸPath（シナリオ修正用データ中のＸPath）により、第１のウェブ画面用の機能変更前のテストシナリオから第２のウェブ画面用の機能変更後のテストシナリオが作成される。
（２）特定のＨＴＭＬファイル生成時の機能変更前処理と機能変更後処理の組み合わせは、同じ情報については、サーバ／ストレージシステム１のの機能変更の前後で変わらない。このことを前提として、ＨＴＭＬファイル生成前と、ＨＴＭＬファイル生成後に実行した内部処理の組み合わせが同じとなるものを見つけ出し、サーバ／ストレージシステム１の機能変更前後で変更のあるＸPathを見つけ出す。
（３）第１のシナリオ修正用データと第２のシナリオ修正用データとに含まれる所定の関数又は固定値の表記が一致する位置に応じて変更前の第１のＸPathと変更後の第２のＸPathとの対応情報を抽出する。これにより、サーバ／ストレージシステム１のの機能変更の前後でＸPathがどのように変わったかを取得できる。
（４）対応情報に基づき、機能変更前のテストシナリオから機能変更後のテストシナリオを書き換える。
　これにより、図２（ｂ）に示すように、サーバ／ストレージシステム１において機能変更前のウェブ画面１１のテスト用に作成した第１のテストシナリオを使用して、機能変更後のテスト用に第２のテストシナリオを自動作成することができる。ウェブテストシステム３０では、テストシナリオの自動作成とテストシナリオによるテストの実行とが繰り返し実施される。
　［テストシナリオの自動作成処理］
　次に、本実施形態に係るテストシナリオの自動作成処理について図１２を参照しながら説明する。図１２は、本実施形態にかかるテスト実行処理の一例を示すフローチャートである。以下のテストシナリオの自動作成処理は、左側がウェブシステム２０において提供される機能変更前のウェブ画面１１のテスト実行処理、右側がウェブシステム２０において提供される機能変更後のウェブ画面１１のテスト実行処理を示す。テストシナリオの自動作成処理は、右側に示す機能変更後のウェブ画面１１のテスト実行処理前に実行される。
　図１２の左側の機能変更前の処理が開始されると、ソースコード読込部３１は、機能変更前のソースコードを読み込む（ステップＳ１０）。以下、機能変更前のソースコードを第１のソースコードともいう。
　次に、修正ソースコード作成部３２は、第１のソースコードに関数及び固定値の表記を付加する処理（以下、「関数付加処理」ともいう。）を実行し、関数及び固定値の表記を付加した第１のソースコード（以下、「第１の修正ソースコード」ともいう。）を作成する（ステップＳ１２）。なお、後述されるステップＳ１２、Ｓ２４、Ｓ３２、Ｓ４４の関数等の付加処理は図１３に示され、付加する関数リストの生成処理は図１４に示され、後述される。
　次に、修正用データ作成部３４は、第１の修正ソースコードに基づき第１のシナリオ修正用データを作成し（ステップＳ１４）、テストシナリオ読込部３３は、テストシナリオ（以下、「第１のテストシナリオ」ともいう。）を読み込む（ステップＳ１６）。次に、ウェブシステム２０は、生成した最新のＨＴＭＬファイルに従いウェブ画面１１を表示する（ステップＳ１８）。ここでは、第１のソースコードに基づき第１のウェブ画面が表示される。第１のウェブ画面には、機能変更前のサーバ／ストレージシステム１の稼働情報などの情報が表示されている。
　次に、テスト実行処理部３７は、第１のテストシナリオを読み込み、第１のテストシナリオに基づきリグレッションテストを実行する（ステップＳ２０）。記憶部４０は、テストの実行処理結果をテスト実行結果ＤＢ４５に保存する。次に、ソースコード読込部３１は、機能変更前のウェブシステム２０の次の第１のソースコードを読み込み（ステップＳ２２）、修正ソースコード作成部３２は、第１のソースコードに関数及び固定値の表記を付加する関数付加処理を実行し、次の第１の修正ソースコードを作成する（ステップＳ２４）。次に、修正用データ作成部３４は、第１の修正ソースコードに基づき次の第１のシナリオ修正用データを作成する（ステップＳ２６）。
　次に、テスト実行処理部３７は、次の第１のテストシナリオがないかを判定し（ステップＳ２８）、次の第１のテストシナリオはないと判定した場合、本処理は終了する。一方、次の第１のテストシナリオがあると判定した場合、テスト実行処理部３７は、次の第１のテストシナリオを読み込む（ステップＳ２９）。次に、テスト実行処理部３７は、次の第１のテストシナリオに基づきステップＳ２０にてリグレッションテストを実行し、記憶部４０はテストの実行処理結果をテスト実行結果ＤＢ４５に保存する。ステップＳ２８にて次の第１のテストシナリオがないと判定されるまで、ステップＳ１８～Ｓ２９の処理が繰り返される。
　図１２の右側の処理が開始されると、ソースコード読込部３１は、機能変更後のソースコードを読み込む（ステップＳ３０）。以下、機能変更後のソースコードを第２のソースコードともいう。次に、修正ソースコード作成部３２は、第２のソースコードに関数付加処理を実行し、関数及び固定値の表記を付加した第２のソースコード（以下、「第２の修正ソースコード」ともいう。）を作成する（ステップＳ３２）。
　次に、修正用データ作成部３４は、第２の修正ソースコードに基づき第１のシナリオ修正用データを作成する（ステップＳ３４）。テストシナリオ作成部３６は、第１のシナリオ修正用データ及び第２のシナリオ修正用データに基づき第１のテストシナリオを修正した第２のテストシナリオを自動作成する（ステップＳ３６）。
　次に、ウェブシステム２０は、生成した最新のＨＴＭＬファイルに従いウェブ画面１１を表示する（ステップＳ３８）。ここでは、第２のソースコードに基づき第２のウェブ画面が表示される。第２のウェブ画面には、機能変更後のサーバ／ストレージシステム１の稼働情報などの情報が表示されている。
　次に、テスト実行処理部３７は、自動作成した第２のテストシナリオに基づきリグレッションテストを実行する（ステップＳ４０）。記憶部４０は、テストの実行処理結果をテスト実行結果ＤＢ４５に保存する。次に、ソースコード読込部３１は、次の第２のソースコードを読み込み（ステップＳ４２）、修正ソースコード作成部３２は、第１のソースコードに関数及び固定値の表記を付加する関数付加処理を実行する（ステップＳ４４）。次に、修正用データ作成部３４は、生成した第２の修正ソースコードに基づき次の第２のシナリオ修正用データを作成する（ステップＳ４６）。
　次に、テスト実行処理部３７は、次のテストシナリオがないかを判定し（ステップＳ４８）、次のテストシナリオはないと判定した場合、本処理は終了する。一方、次の第２のテストシナリオがあると判定した場合、テスト実行処理部３７は、次の第２のテストシナリオを修正（自動作成）し（ステップＳ４９）、ステップＳ４０にてリグレッションテストを実行する。記憶部４０は、テストの実行処理結果をテスト実行結果ＤＢ４５に保存する。ステップＳ４８にて次の第２のテストシナリオがないと判定されるまで、ステップＳ３８～Ｓ４９の処理が繰り返される。
　［関数付加処理］
　本実施形態にかかる関数付加処理について、図１３及び図１４を参照しながら説明する。図１３は、本実施形態にかかる関数付加処理を示すフローチャートである。図１４は、本実施形態にかかる関数リストの生成処理を示すフローチャートである。本処理は、図２（ｂ）の（１）に示す関数付加により第１のソースコードから第１の修正ソースコードを作成する処理である。また、図２（ｂ）の（３）に示す関数付加により、第２のソースコードから第２の修正ソースコードを作成する処理である。
　図１３の処理が開始されると、修正ソースコード作成部３２が関数リストの生成処理（図１４）を実行する（ステップＳ５０）。
（関数リスト生成処理）
　図１４の関数リストの生成処理では、修正ソースコード作成部３２は、ウェブシステム２０のソースコードを{,}、(,)、空白、カンマ、';' 、'=' 、改行コードで分割し、リスト化する（ステップＳ７０）。但し"…"、"//～改行"内は分割しない。
　次に、修正ソースコード作成部３２は、リスト化されたソースコードに含まれる関数を判定し（ステップＳ７１）、関数呼び出し部（関数Ｃａｌｌ）を走査する（ステップＳ７２）。修正ソースコード作成部３２は、走査が完了したかを判定し（ステップＳ７３）、走査が完了したと判定した場合、本処理を終了し、図１３の関数付加処理のステップＳ５１に戻る。
　一方、修正ソースコード作成部３２は、走査が完了していないと判定した場合、関数の種類によってソースコード内の関数を下記の３つに分ける（ステップＳ７４）。ステップＳ７５～Ｓ７７にてリストを生成した後、ステップＳ７２に戻り、ステップＳ７２～Ｓ７７の処理を走査が完了するまで繰り返す。
（１）ＨＴＭＬ出力関数リスト生成（ステップＳ７５）
・関数名　関数タイプ　関数引数
（２）データベース書き込み関数リスト生成（ステップＳ７６）
・関数名　関数タイプ　関数引数
（３）データベース読み込み関数リスト生成（ステップＳ７７）
・関数名　関数タイプ　関数引数
　図１３の付加処理（ステップＳ５１）に戻ると、修正ソースコード作成部３２は、ウェブシステム２０のソースコードを{,}、(,)、空白、カンマ、';' 、'=' 、改行コードで分割し、リスト化する。但し"…"、"//～改行"内は分割しない。なお、修正ソースコード作成部３２は、ステップＳ５１において、ステップＳ７０にてリスト化されたソースコードを取得してもよい。図１５はソースコードの一例を示す。図１６は図１５のソースコードを分割し、リスト化した一例を示す。
　次に、修正ソースコード作成部３２は、リスト化されたソースコードから関数を判定し（ステップＳ５２）、関数呼び出し部（関数Ｃａｌｌ）を走査する（ステップＳ５３）。修正ソースコード作成部３２は、走査が完了したかを判定し（ステップＳ５４）、走査が完了したと判定した場合、リスト化されたソースコードを元のソースコードに戻し（ステップＳ６３）、本処理を終了する。
　一方、修正ソースコード作成部３２は、ステップＳ５４にて走査が完了していないと判定した場合、関数呼び出し部の関数の種類が図１４にて生成した関数リストの対象関数と一致するかを判定する（ステップＳ５５）。修正ソースコード作成部３２は、関数呼び出し部の関数の種類が関数リストの対象関数と一致すると判定した場合、対象関数の直後に挿入関数名を挿入する（ステップＳ５６）。図１０は、上記の関数リスト生成のステップで使用する関数リストの一例を示す。
　修正ソースコード作成部３２は、図４の（ｂ）のソースコードをリスト化し（図１６）、リスト化したソースコードを構文解析し（図１７）、対象関数の直後に挿入関数名を挿入する（図１８）。
　次に、図１３のステップＳ５７にて、修正ソースコード作成部３２は、関数リストからデバッグ出力情報を取得する。修正ソースコード作成部３２は、デバッグ出力情報の取得が完了したかを判定し（ステップＳ５８）、デバッグ出力情報の取得が完了したと判定した場合、ステップＳ６２に進む。一方、修正ソースコード作成部３２は、デバッグ出力情報の取得が完了していないと判定した場合、固定文字かを判定する（ステップＳ５９）。固定文字の場合、修正ソースコード作成部３２は、その固定文字を挿入する（ステップＳ６０）。図１８には、ステップＳ６０の実行により挿入関数名の挿入後に固定文字が設定されている。一方、固定文字でない場合、修正ソースコード作成部３２は、関数引数を挿入する（ステップＳ６１）。図１８には、挿入関数名及び固定文字の挿入後に関数引数（デバッグ出力情報１０３～１０６の"ａｒｇ"の関数引数）が設定されている。ステップＳ５７に戻り、修正ソースコード作成部３２は、ステップＳ５７～Ｓ６１の処理を繰り返した後、ステップＳ５８にてデバッグ出力情報の取得が完了したと判定したとき、ステップＳ６２に進み、関数の終端表記を挿入し、ステップＳ５３に戻る。修正ソースコード作成部３２は、ステップＳ５３に続くステップＳ５４にて関数呼び出し部の走査が完了したと判定するまでＳ５３～Ｓ６２の処理を繰り返し、走査が完了したと判定したときリスト化したソースコードを元の状態に戻し（ステップＳ６３）、本処理を終了する。図１９は、リスト化したソースコードから元の状態に戻されたソースコードを示す。なお、ステップＳ６３の処理は省略できる。
　これにより、図１８に示すように、一のソースコードから修正ソースコードが作成される。以上、図２（ｂ）の（１）及び（３）の関数追加により修正ソースコードを作成する処理の詳細を説明した。図２では、修正ソースコード作成部３２は、機能変更前の第１のソースコードから第１の修正ソースコードを作成し、機能変更前の第２のソースコードから第２の修正ソースコードを作成する。
　次に、図２（ｂ）の（２）及び（４）の第１及び第２の修正ソースコードから第１及び第２のシナリオ修正用データを作成する処理の詳細、及び図２（ｂ）の（５）第１のテストシナリオから第２のテストシナリオを自動作成する処理の詳細を説明する。図２０は、本実施形態にかかるテストシナリオの自動作成処理の詳細を示すフローチャートである。
　図２０の処理が開始されると、修正ソースコード作成部３２は、シナリオ修正用ＤＢ４４にシナリオ修正用データが存在するかを判定する（ステップＳ８０）。図２（ｂ）の（１）の時点では、シナリオ修正用データは存在しない。よって、修正用データ作成部３４は、ソースコードに所定の関数等の表記を付加して修正ソースコードを作成する（ステップＳ８１）。ここでは、修正ソースコード作成部３２は、機能変更前のソースコードである第１のソースコードに所定の関数等の表記を付加して機能変更前の修正ソースコードである第１の修正ソースコードを作成する。
　次に、ウェブシステム２０が起動され（ステップＳ８２）、第１の修正ソースコードに基づく処理の実行によりＨＴＭＬファイルが生成され、修正用データ作成部３４は、ＨＴＭＬファイルに応じた第１のシナリオ修正用データを作成する（ステップＳ８３）。図２１の左側に機能変更前のＨＴＭＬファイルの例を示し、図２１の右側に作成した第１のシナリオ修正用データの例を示す。第１のシナリオ修正用データは、テストシナリオを修正するために使用される。
（シナリオ修正用データの作成処理）
　シナリオ修正用データの作成処理の詳細について、図２２を参照しながら説明する。図２２は、本実施形態にかかるシナリオ修正用データの作成処理を示すフローチャートである。まず、修正用データ作成部３４は、ＨＴＭＬファイルの上から順に一行を取得する（ステップＳ１０１）。例えば、図２１では、行番号「１」の一行が取得される。次に、修正用データ作成部３４は、ＨＴＭＬファイルの全行の処理が済んだかを判定する（ステップＳ１０２）。修正用データ作成部３４は、全行の処理が済んだと判定した場合、本処理を終了する。一方、修正用データ作成部３４は、全行の処理が済んでいないと判定した場合、取得した一行からタグの記述を取り出す（ステップＳ１０３）。タグの記述は、"＜・・・＞"又は"＜／・・・＞"で示される。次に、修正用データ作成部３４は、取得した一行に含まれる全データの処理が済んだかを判定する（ステップＳ１０４）。修正用データ作成部３４は、取得した一行に含まれる全データの処理が済んだと判定した場合、ステップＳ１０１に戻り、ステップＳ１０１以降の処理を繰り返す。
　一方、修正用データ作成部３４は、取得した一行に含まれる全データの処理が済んでいないと判定した場合、取り出したデータの種類を判定する（ステップＳ１０５）。修正用データ作成部３４は、取り出したデータがタグ以外と判定した場合、ステップＳ１０２に戻る。
　修正用データ作成部３４は、取り出したデータがタグの終端（＜／タグ名＞）と判定した場合、ステップＳ１１６に進み、ツリー情報に"／ "が入っているかを判定する（ステップＳ１１６）。ツリー情報は、ＨＴＭＬファイルのタグ構造を示す。修正用データ作成部３４は、ツリー情報に"／ "が入っていると判定した場合、ツリー情報終端の"/タグ名[タグ出現回数］"を除去し（ステップＳ１１７）、ステップＳ１０２に戻る。一方、修正用データ作成部３４は、ツリー情報に"／ "が入っていないと判定した場合、ツリー情報を空にし（ステップＳ１１８）、ステップＳ１０２に戻る。
　ステップＳ１０５において、修正用データ作成部３４は、取り出したデータがタグの開始（つまり、＜タグ名＞）と判定した場合、前回削除したタグ名と今回のタグ名とが同じかを判定する（ステップＳ１０６）。修正用データ作成部３４は、同じでないと判定した場合、タグの出現回数を「１」とし（ステップＳ１０７）、同じと判定した場合、タグの出現回数を「＋１」する（ステップＳ１０８）。
　次に、修正用データ作成部３４は、ツリー情報は何かを判定する（ステップＳ１０９）。修正用データ作成部３４は、ツリー情報が空であると判定した場合、ツリー情報に"／タグ名[タグ出現回数]"を保存する（ステップＳ１１０）。例えば、図２１では、行番号が「１」のとき、ツリー情報に"／ｈｔｍｌ[１]"が保存される。なお、タグ出現回数が１のときの[１]は省略されるため、ツリー情報に保存されるデータは、"／ｈｔｍｌ"となる。一方、修正用データ作成部３４は、ツリー情報に"／"が入っていると判定した場合、ツリー情報に"タグ名[タグ出現回数]"を保存する（ステップＳ１１１）。
　次に、修正用データ作成部３４は、ツリー情報をシナリオ修正用データのＸPathに保存する（ステップＳ１１２）。ツリー情報は、機能変更前の場合、第１のシナリオ修正用データのＸPathに保存され、機能変更後の場合、第２のシナリオ修正用データのＸPathに保存される。
　次に、修正用データ作成部３４は、タグの終端（つまり、＜／タグ名＞）かを判定する（ステップＳ１１３）。修正用データ作成部３４は、タグの終端でないと判定した場合、ステップＳ１０２に戻る。一方、修正用データ作成部３４は、タグの終端であると判定した場合、タグの出現回数から１を減算し（ステップＳ１１４）、ツリー情報終端の"/タグ名[タグ出現回数］"を除去し（ステップＳ１１５）、ステップＳ１０２に戻る。例えば、図２１では、行番号「１３」のとき、ツリー情報に保存されるデータは、"／ｈｔｍｌ／ｂｏｄｙ／ｔａｂｌｅ／ｔｒ"となる。
　以上、図２２を参照しながら、図２０のステップＳ８３で呼び出されるシナリオ修正用データの作成処理の一例を説明した。次に、図２０のステップＳ８４に進み、テストシナリオ読込部３３は、テストシナリオＤＢ４３から次に実行するテストシナリオを読み込む。次に、テスト実行処理部３７は、テストシナリオのすべてについてテストが完了したかを判定する（ステップＳ８５）。テスト実行処理部３７は、テストシナリオのすべてについてテストが完了していないと判定した場合、テストシナリオを実行し（ステップＳ８６）、ステップＳ８３に戻り、テストシナリオのすべてについてテストが完了するまで、ステップＳ８３～Ｓ８６の処理を繰り返す。ここでは、第１のテストシナリオの操作手順に従い機能変更前のウェブ画面１１のテストが行われる。テストの実行結果のデータは、テスト実行結果ＤＢ４５に保存される。
　ステップＳ８５において第１のテストシナリオのすべてについてテストが完了したと判定された場合、又は、ステップＳ８０においてシナリオ修正用データが存在すると判定された場合、修正用データ作成部３４は、ステップＳ８７に進む。修正用データ作成部３４は、ソースコードに所定の表記を付加して修正ソースコードを作成する。この時点では、サーバ／ストレージシステム１において機能変更がされている。よって、修正ソースコード作成部３２は、機能変更後のソースコードである第２のソースコードに所定の表記を付加して機能変更後の修正ソースコードである第２の修正ソースコードを作成する。
　次に、ウェブシステム２０が起動され（ステップＳ８８）、第２の修正ソースコードに基づく処理の実行によりＨＴＭＬファイルが生成され、修正用データ作成部３４は、ＨＴＭＬファイルに応じた第２のシナリオ修正用データを作成する（ステップＳ８９）。図２３の左側に機能変更後のＨＴＭＬファイルの例を示し、図２３の右側に作成した第２のシナリオ修正用データの例を示す。第２のシナリオ修正用データは、テストシナリオを修正するために使用される。
　次に、テストシナリオ作成部３６は、シナリオ修正用ＤＢ４４から、対応する機能変更前の第１のシナリオ修正用データを取得する（ステップＳ９０）。テストシナリオ作成部３６は、第１のシナリオ修正用データ及び第２のシナリオ修正用データに基づき、第１のテストシナリオから第２のテストシナリオを自動作成する（ステップＳ９１）。つまり、ＸPath抽出部３５は、第１のシナリオ修正用データと第２のシナリオ修正用データとに含まれる所定の表記が一致する位置に応じて第１のＸPathと第２のＸPathとの対応情報を抽出する。テストシナリオ作成部３６は、対応情報に基づき、第１のウェブ画面のテスト用の操作手順を示す第１のテストシナリオから第２のウェブ画面のテスト用の操作手順を示す第２のテストシナリオを作成する。
（テストシナリオの自動作成処理）
　テストシナリオの自動作成処理の詳細について、図２４を参照しながら説明する。図２４は、本実施形態にかかるテストシナリオの自動作成処理を示すフローチャートである。まず、テストシナリオ作成部３６は、第１のシナリオ修正用データから"ＨＴＭＬ"で始まる行を取り除く（ステップＳ１２０）。これにより、図２５の左図の斜線で示す"ＨＴＭＬ"で始まる行が取り除かれる。
　次に、テストシナリオ作成部３６は、第２のシナリオ修正用データから"ＨＴＭＬ"で始まる行を取り除く（ステップＳ１２１）。これにより、図２５の右図の斜線で示す"ＨＴＭＬ"で始まる行が取り除かれる。
　次に、テストシナリオ作成部３６は、第１のシナリオ修正用データから一行を取得する（ステップＳ１２２）。これにより、図２５の左図の行番号「９」の一行が取得される。次に、テストシナリオ作成部３６は、第１のシナリオ修正用データのすべての処理が済んだかを判定する（ステップＳ１２３）。テストシナリオ作成部３６は、第１のシナリオ修正用データのすべての処理が済んだと判定した場合、本処理を終了する。一方、テストシナリオ作成部３６は、第１のシナリオ修正用データのすべての処理は済んでいないと判定した場合、第１のシナリオ修正用データから次の一行を取得する（ステップＳ１２４）。これにより、図２５の左図の行番号「１１」の一行が取得される。
　次に、テストシナリオ作成部３６は、第２のシナリオ修正用データから一行を取得する（ステップＳ１２５）。これにより、図２５の右図の行番号「１６」の一行が取得される。次に、テストシナリオ作成部３６は、第２のシナリオ修正用データのすべての処理が済んだかを判定する（ステップＳ１２６）。テストシナリオ作成部３６は、第２のシナリオ修正用データのすべての処理が済んだと判定した場合、ステップＳ１３１に進む。一方、テストシナリオ作成部３６は、第２のシナリオ修正用データのすべての処理は済んでいないと判定した場合、第１のシナリオ修正用データ及び第２のシナリオ修正用データから取得した最初の一行が一致するかを判定する（ステップＳ１２７）。
　テストシナリオ作成部３６は、第１のシナリオ修正用データ及び第２のシナリオ修正用データから取得した最初の一行が一致しないと判定した場合、ステップＳ１２５に戻る。一方、テストシナリオ作成部３６は、一致すると判定した場合、第２のシナリオ修正用データから次の一行を取得する（ステップＳ１２８）。これにより、図２５の右図の行番号「１８」の一行が取得される。
　次に、ＸPath抽出部３５は、第１のシナリオ修正用データ及び第２のシナリオ修正用データから取得した次の一行が一致するかを判定する（ステップＳ１２９）。テストシナリオ作成部３６は、第１及び第２のシナリオ修正用データから取得した次の一行が一致しないと判定し場合、ステップＳ１２５に戻る。一方、ＸPath抽出部３５は、一致すると判定した場合、第１のシナリオ修正用データに含まれる第１のＸPathと第２のシナリオ修正用データに含まれる第２のＸPathとの対応情報を抽出する。ＸPath抽出部３５は、第１のシナリオ修正用データ及び第２のシナリオ修正用データに含まれる所定の表記が一致する位置に応じて第１のＸPathと第２のＸPathとの対応情報を抽出する。本実施形態では、対応情報を抽出するために所定の表記が一致する位置は、第１のシナリオ修正用データ及び第２のシナリオ修正用データから取得した最初の一行と次の一行との複数位置である。ただし、所定の表記が一致する位置は、これに限らず、第１のシナリオ修正用データ及び第２のシナリオ修正用データから取得した最初の一行のみであってもよいし、次の一行のみであってもよい。
　テストシナリオ作成部３６は、第１のシナリオ修正用データの取得した最初の行から次の行までの間のＸPathと、第２のシナリオ修正用データの取得した最初の行から次の行までの間のＸPathとの対応関係（対応情報）に基づき、第１のテストシナリオのＸPathを置き換え、第２のテストシナリオを自動作成する（ステップＳ１３０）。
　例えば、図２５の例では、第１のシナリオ修正用データの取得した二行の間（最初の行から次の行の間）と、第２のシナリオ修正用データの取得した二行の間（最初の行から次の行の間）との対応情報１に基づき、第１のテストシナリオのＸPathが置き換えられ、第２のテストシナリオが自動作成される。対応情報２についても同様に第１のテストシナリオのＸPathが置き換えられ、第２のテストシナリオが自動作成される。
　これにより、図２６に示すように、第１のテストシナリオの対応情報１のＸPathは、図２１の第１のシナリオ修正用データのＸPath（Ａ）から、図２３の第２のシナリオ修正用データのＸPath（ａ）に置き換えられる。また、第１のテストシナリオの対応情報２のＸPathは、図２１の第１のシナリオ修正用データのＸPath（Ｂ）から、図２３の第２のシナリオ修正用データのＸPath（ｂ）に置き換えられる。このようにして、システムの機能変更前の第１のテストシナリオから機能変更後の第２のテストシナリオを自動作成することができる。
　図２６の対応情報１では、図２７（ａ）の第１のテストシナリオのコマンドｉｎｐｕｔ（入力）において、値「１＋２」を入力する場所（Ｘpath）は「/html/body/table/tr/td/input」で示されている。これに対して、本実施形態では、図２７（ｂ）の第２のテストシナリオのコマンドｉｎｐｕｔにおいて、値「１＋２」を入力する場所（Ｘpath）が「/html/body/table/tr［2］/td/input」に自動変更される。
　また、図２６の対応情報２では、図２７（ａ）の第１のテストシナリオのコマンドＣｈｅｃｋ（チェック）において、値「３」が場所（Ｘpath）「/html/body/table/tr/td［2］」に表示されていることをチェックする。これに対して、本実施形態では、図２７（ｂ）の第２のテストシナリオのコマンドＣｈｅｃｋにおいて、値「３」が表示されていることをチェックする場所（Ｘpath）が「/html/body/table/tr［2］/td［2］」に自動変更される。
　図２８に示す機能変更前のＨＴＭＬファイルに基づき生成した図２９のウェブ画面１１（第１のウェブ画面例）において、図２８の「Ｐ」で示すテストシナリオの入力コマンドが実行されると、値「１＋２」が図２９に示す「注釈」の入力エリア（Ｘpathで示した場所）に入力される。また、図２８の「Ｑ」で示すテストシナリオの表示コマンドが実行されると、図２９に示す「結果」（Ｘpathで示した場所）に表示された値「３」がチェックされる。
　これに対して、機能変更後のＨＴＭＬファイルには、図３０の「Ｒ」で示す「注釈２」が追加される。これにより、機能変更後の図３１のウェブ画面１１（第２のウェブ画面例）では、機能変更前の図２９のウェブ画面１１に対して「注釈」の前に「注釈２」が表示される。
　機能変更後の図３１のウェブ画面１１に対して、図２７（ａ）に示す第１のテストシナリオのＸpathが示す画面上の場所に値を表示しようとすると、テストでは、図３２のように「注釈２」に値「１＋２」を入力しようとしてしまう。また、図３２のように「注釈」に値「３」が表示されていることを確認してしまう。
　しかしながら、本実施形態では、自動作成された第２のテストシナリオに基づき、図３３に示したように、自動作成した第２のテストシナリオの図２７（ｂ）に示すＸpathに基づき、「注釈」に値「１＋２」が入力され、「結果」に値「３」が表示されていることが確認される。このようにして、第１のテストシナリオの機能変更前のＸpathと機能変更後のＸpathとを対応させて第２のテストシナリオを自動作成することで、機能変更後のテストシナリオのコマンドを機能変更後のウェブ画面１１のレイアウトに合致させて実行できる。
　以上に説明したように、テストは、第１のテストシナリオから自動作成された第２のテストシナリオに基づき繰り返し実行される。すべてのテストシナリオが実行された後、テストが終了される。
　図３４は機能変更前のテストシナリオの実行例を示し、図３５は機能変更後のテストシナリオの実行例を示す。図３４及び図３５では、左上図のログイン画面でウェブシステム２０が起動され、ログイン後に図３４及び図３５の左下図のウェブ画面１１に画面が遷移する。図３４の左下図のウェブ画面１１に対する第１のテストシナリオから、図３５の左下図のウェブ画面１１に新たな機能表示（ディスク使用量）が追加された場合の第２のテストシナリオが自動作成された一例が示されている。
　以上に説明したように、一実施形態に係るウェブテストシステム３０によれば、システムに機能変更が生じた場合、機能変更前のテストシナリオに基づきシステムの機能変更後のウェブ画面をテストするためのテストシナリオを自動作成することができる。つまり、システムの機能変更前後でウェブ画面１１のレイアウトが変更されても、機能変更前後におけるテストシナリオに記述されたＸpathの対応情報を抽出することで機能変更前のウェブ画面１１をテストするためのテストシナリオから機能変更後のウェブ画面１１をテストするためのテストシナリオを自動作成できる。これにより、手動によるテストシナリオの変更が不要になり、また、ＯＳやブラウザに依存せずに画面のテストを行うことができる。
　（ハードウェア構成例）
　最後に、本実施形態に係るウェブテストシステム３０のハードウェア構成例について、図３６を参照して説明する。図３６は、本実施形態に係るウェブテストシステム３０のハードウェア構成例を示す図である。
　図３６に示すように、ウェブテストシステム３０は、入力装置１０１、表示装置１０２、外部Ｉ／Ｆ１０３、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）１０４、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）１０５、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）１０６、通信Ｉ／Ｆ１０７、及びＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）１０８などを備え、それぞれがバスＢで相互に接続されている。
　入力装置１０１は、キーボードやマウスなどを含み、ウェブテストシステム３０に各操作信号を入力するのに用いられる。表示装置１０２は、各種の処理結果を表示する。
　通信Ｉ／Ｆ１０７は、ウェブテストシステム３０をネットワークに接続するインタフェースである。これにより、ウェブテストシステム３０は、通信Ｉ／Ｆ１０７を介してウェブシステム２０とデータ通信を行うことができる。
　ＨＤＤ１０８は、プログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータには、装置全体を制御する基本ソフトウェア及びアプリケーションソフトウェアがある。例えば、ＨＤＤ１０８には、ソースコードＤＢ４１、修正ソースコードＤＢ４２、テストシナリオＤＢ４３、シナリオ修正用ＤＢ４４及びテスト実行結果ＤＢ４５が格納されている。
　外部Ｉ／Ｆ１０３は、外部装置とのインタフェースである。外部装置には、記録媒体１０３ａなどがある。これにより、ウェブテストシステム３０は、外部Ｉ／Ｆ１０３を介して記録媒体１０３ａの読み取り及び／又は書き込みを行うことができる。
　記録媒体１０３ａには、フロッピー（登録商標）ディスク、ＣＤ（Ｃｏｍｐａｃｔ　Ｄｉｓｋ）、及びＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｋ）、ならびに、ＳＤメモリカード（ＳＤ　Ｍｅｍｏｒｙ　ｃａｒｄ）やＵＳＢメモリ（Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ　ｍｅｍｏｒｙ）などがある。
　ＲＯＭ１０５は、電源を切っても内部データを保持することができる不揮発性の半導体メモリ（記憶装置）である。ＲＯＭ１０５には、ネットワーク設定などのプログラムやデータが格納されている。ＲＡＭ１０４は、プログラムやデータを一時保持する揮発性の半導体メモリ（記憶装置）である。ＣＰＵ１０６は、上記記憶装置（例えば「ＨＤＤ１０８」や「ＲＯＭ１０５」など）から、プログラムやデータをＲＡＭ１０４上に読み出し、処理を実行することで、装置全体の制御や搭載機能を実現する演算装置である。
　上記ハードウェア構成により、例えば、ＣＰＵ１０６が、ＲＯＭ１０５やＨＤＤ１０８内に格納されたデータ及びプログラムを用いてテストシナリオの操作手順に基づきウェブ画面１１のテストを実行する。
　なお、ソースコードＤＢ４１、修正ソースコードＤＢ４２、テストシナリオＤＢ４３、シナリオ修正用ＤＢ４４及びテスト実行結果ＤＢ４５に関する情報は、ＲＡＭ１０４、ＨＤＤ１０８に格納されてもよい。これらのＤＢは、ネットワークを介してウェブテストシステム３０に接続されるクラウド上のサーバー等に格納されてもよい。
　以上、試験プログラム、試験装置及び試験方法を上記実施形態により説明したが、本発明にかかる試験プログラム、試験装置及び試験方法は上記実施形態に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能である。また、上記実施形態及び変形例が複数存在する場合、矛盾しない範囲で組み合わせることができる。
　例えば、上記実施形態に係る試験プログラム、試験装置及び試験方法の構成は一例であり、本発明の範囲を限定するものではなく、用途や目的に応じて様々なシステム構成例があることは言うまでもない。
　１：サーバ／ストレージシステム
　１０：サーバ／ストレージ装置
　１１：ウェブ画面
　２０：ウェブシステム
　３０：ウェブテストシステム
　３１：ソースコード読込部
　３２：修正ソースコード作成部
　３３：テストシナリオ読込部
　３４：修正用データ作成部
　３５：ＸPath抽出部
　３６：テストシナリオ作成部
　３７：テスト実行処理部
　４０：記憶部
　４１：ソースコードＤＢ
　４２：修正ソースコードＤＢ
　４３：テストシナリオＤＢ
　４４：シナリオ修正用ＤＢ
　４５：テスト実行結果ＤＢ

Claims (6)

  1. 　システムの機能変更前の処理が記述された第１のソースコードに所定の表記を付加した第１の修正ソースコードに基づき、機能変更前の第１のウェブ画面の位置を指定する第１のＸPathと前記所定の表記とを含んだ第１のシナリオ修正用データを作成し、
    　システムの機能変更後の処理が記述された第２のソースコードに所定の表記を付加した第２の修正ソースコードに基づき、機能変更後の第２のウェブ画面の位置を指定する第２のＸPathと前記所定の表記とを含んだ第２のシナリオ修正用データを作成し、
    　前記第１のシナリオ修正用データと前記第２のシナリオ修正用データとに含まれる前記所定の表記が一致する位置に応じて前記第１のＸPathと前記第２のＸPathとの対応情報を抽出し、
    　前記抽出した対応情報に基づき、前記第１のウェブ画面の操作手順を示す第１のテストシナリオから前記第２のウェブ画面の操作手順を示す第２のテストシナリオを作成する、
    　処理をコンピュータに実行させるための試験プログラム。
  2. 　前記抽出する処理は、
    　前記所定の表記が一致する位置に応じたＨＴＭＬファイルのタグ構造から前記第１のＸPathと前記第２のＸPathとの対応情報を抽出する、
    　請求項１に記載の試験プログラム。
  3. 　システムの機能変更前の処理が記述された第１のソースコードに所定の表記を付加して第１の修正ソースコードを作成し、システムの機能変更後の処理が記述された第２のソースコードに所定の表記を付加して第２の修正ソースコードを作成する修正ソースコード作成部と、
    　前記第１の修正ソースコードに基づき、機能変更前の第１のウェブ画面の位置を指定する第１のＸPathと前記所定の表記とを含んだ第１のシナリオ修正用データを作成し、前記第２の修正ソースコードに基づき、機能変更後の第２のウェブ画面の位置を指定する第２のＸPathと前記所定の表記とを含んだ第２のシナリオ修正用データを作成する修正用データ作成部と、
    　前記第１のシナリオ修正用データと前記第２のシナリオ修正用データとに含まれる前記所定の表記が一致する位置に応じて前記第１のＸPathと前記第２のＸPathとの対応情報を抽出する抽出部と、
    　前記抽出した対応情報に基づき、前記第１のウェブ画面の操作手順を示す第１のテストシナリオから前記第２のウェブ画面の操作手順を示す第２のテストシナリオを作成するテストシナリオ作成部と、
    　を有する試験装置。
  4. 　前記抽出部は、
    　前記所定の表記が一致する位置に応じたＨＴＭＬファイルのタグ構造から前記第１のＸPathと前記第２のＸPathとの対応情報を抽出する、
    　請求項３に記載の試験装置。
  5. 　システムの機能変更前の処理が記述された第１のソースコードに所定の表記を付加した第１の修正ソースコードに基づき、機能変更前の第１のウェブ画面の位置を指定する第１のＸPathと前記所定の表記とを含んだ第１のシナリオ修正用データを作成し、
    　システムの機能変更後の処理が記述された第２のソースコードに所定の表記を付加した第２の修正ソースコードに基づき、機能変更後の第２のウェブ画面の位置を指定する第２のＸPathと前記所定の表記とを含んだ第２のシナリオ修正用データを作成し、
    　前記第１のシナリオ修正用データと前記第２のシナリオ修正用データとに含まれる前記所定の表記が一致する位置に応じて前記第１のＸPathと前記第２のＸPathとの対応情報を抽出し、
    　前記抽出した対応情報に基づき、前記第１のウェブ画面の操作手順を示す第１のテストシナリオから前記第２のウェブ画面の操作手順を示す第２のテストシナリオを作成する、
    　処理をコンピュータが実行する試験方法。
  6. 　前記抽出する処理は、
    　前記所定の表記が一致する位置に応じたＨＴＭＬファイルのタグ構造から前記第１のＸPathと前記第２のＸPathとの対応情報を抽出する、
    　請求項５に記載の試験方法。
PCT/JP2014/067162 2014-06-27 2014-06-27 試験プログラム、試験装置及び試験方法 WO2015198473A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2014/067162 WO2015198473A1 (ja) 2014-06-27 2014-06-27 試験プログラム、試験装置及び試験方法
JP2015531373A JP5958655B2 (ja) 2014-06-27 2014-06-27 試験プログラム、試験装置及び試験方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2014/067162 WO2015198473A1 (ja) 2014-06-27 2014-06-27 試験プログラム、試験装置及び試験方法

Publications (1)

Publication Number Publication Date
WO2015198473A1 true WO2015198473A1 (ja) 2015-12-30

Family

ID=54937597

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/067162 WO2015198473A1 (ja) 2014-06-27 2014-06-27 試験プログラム、試験装置及び試験方法

Country Status (2)

Country Link
JP (1) JP5958655B2 (ja)
WO (1) WO2015198473A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7040272B2 (ja) * 2018-05-08 2022-03-23 富士通株式会社 ソースコード変換プログラムおよびソースコード変換方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130086560A1 (en) * 2011-09-30 2013-04-04 International Business Machines Corporation Processing automation scripts of software
JP2014106589A (ja) * 2012-11-26 2014-06-09 Fujitsu Ltd 情報処理装置、テストプログラム、およびテスト方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130086560A1 (en) * 2011-09-30 2013-04-04 International Business Machines Corporation Processing automation scripts of software
JP2014106589A (ja) * 2012-11-26 2014-06-09 Fujitsu Ltd 情報処理装置、テストプログラム、およびテスト方法

Also Published As

Publication number Publication date
JPWO2015198473A1 (ja) 2017-04-20
JP5958655B2 (ja) 2016-08-02

Similar Documents

Publication Publication Date Title
CN111142903B (zh) 一种基于文件对比的配置文件交互式更新方法及装置
EP3557423B1 (en) System and method for testing electronic visual user interface outputs
US10684839B2 (en) Plugin for software deployment
US9218269B2 (en) Testing multiple target platforms
US10146672B2 (en) Method and system for automated user interface (UI) testing through model driven techniques
Bisht Robot framework test automation
KR102341154B1 (ko) 모바일 장치들의 원격 구성을 허용하기 위해 모바일 장치들 상에 설치되는 고속 어플리케이션
JP4395761B2 (ja) プログラムテスト支援装置およびその方法
JP6217277B2 (ja) ソフトウェア開発方法及びそのためのシステム
US20130275946A1 (en) Systems and methods for test development process automation for a test harness
CN107015903B (zh) 一种界面测试程序的生成方法、装置及电子设备
US10169218B2 (en) Method for automatically validating data against a predefined data specification
CN115658529A (zh) 用户页面的自动化测试方法以及相关设备
CN112241311A (zh) 一种固件仿真模拟方法、装置、电子设备及可读存储介质
CN107038117B (zh) 一种基于事件处理函数间定义-引用的web自动化测试方法
KR20100056338A (ko) 재활용도를 높일 수 있는 ｇｕｉ 테스트 자동화 시스템 및 그 방법
US10599424B2 (en) Committed program-code management
JP5958655B2 (ja) 試験プログラム、試験装置及び試験方法
WO2020230241A1 (ja) テスト装置、テスト方法及びプログラム
Gilmore Easy Laravel 5
CN117421039B (zh) 前端Vue工程的版本信息生成方法、装置、设备和存储介质
WO2023162260A1 (ja) 環境構築支援装置、システム及び方法、並びに、コンピュータ可読媒体
JP2008129844A (ja) ストアドプロシージャジェネレート装置、方法、プログラム、及びシステム
Reynolds Learning Grunt
CN115291936A (zh) 部署文档的生成方法及其装置、电子设备

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2015531373

Country of ref document: JP

Kind code of ref document: A

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14895880

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14895880

Country of ref document: EP

Kind code of ref document: A1