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

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/28Error 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

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

Description

試験プログラム、試験装置及び試験方法
 本発明は、試験プログラム、試験装置及び試験方法に関する。
 ウェブシステムは、監視対象のシステムの稼働状況等の情報をウェブ画面に表示して提供するサービスを行っている。サーバ/ストレージシステムのある機能が変更すると、これに伴いウェブ画面のレイアウトが変更される場合がある。一例としては、サーバ/ストレージシステムに新機能が追加された場合、サーバ/ストレージシステムに追加された機能に関する情報を表示するためにウェブ画面のレイアウトが変わる場合がある。同様に、サーバ/ストレージシステムからある機能が削除された場合、サーバ/ストレージシステムから削除した機能に関する情報を削除するために画面のレイアウトが変わることがある。
 サーバ/ストレージシステムでは、このような機能の変更以外の機能についての処理に変更はない。よって、ウェブシステムは、追加又は削除した機能以外の機能に関しては、機能変更の前後においてウェブ画面上で同じ動作が行われ、結果が表示されることを保証しなければならない。そのためのテスト方法としてリグレッションテストが知られている。
 リグレッションテストはウェブテストシステムにより実行される。ウェブテストシステムはテストシナリオを実行して、変更した機能以外の機能に関し機能変更の前後でウェブ画面の結果が同じことを確認する。テストシナリオは、ウェブ画面のテスト用の操作手順を示す。テストシナリオには、ウェブ画面を記述するHTML(Hyper Text Markup Language)上の要素が指定される。ウェブ画面とそれに対するテストシナリオの一例を図34及び図35に示す。HTML上の各要素の位置指定にはウェブ画面上の位置を指定するXPathが用いられる。
特開2009-140155号公報 特開2005-266954号公報
 しかしながら、XPathは、ウェブ画面のレイアウトが変化するとそれに応じて変化する。よって、ウェブ画面のレイアウトが変わると機能変更前のXPathを、同じ要素の位置を指定する機能変更後のXPathとして使用することができない場合がある。
 つまり、テストシナリオにはXPathが記述されている。このため、サーバ/ストレージシステムの機能変更に応じてウェブ画面のレイアウトが変わると、機能変更前のXPathを含むテストシナリオを機能変更後のリグレッションテストのテストシナリオとしてそのまま使用することができなくなる。
 そこで、図1のフローチャート及び図2(a)に示すように、機能変更前後のサーバ/ストレージシステムの機能仕様書1,2から差分を抽出し、差分に基づき機能変更前の第1のテストシナリオを手動で修正して、機能変更後の第2のテストシナリオを作成することが行われている。しかし、この方法は、手動によるテストシナリオの修正であるため、修正に手間がかかる。加えて、その複雑さは、ウェブ画面の中の表示項目数、画面の数の多さに比例し、今後ますます多機能化するシステムのテストシナリオの修正にはさらに大きな手間がかかることが予想される。
 さらに、連続性のあるテストシナリオに対しては、テストシナリオの修正漏れのためにテストが実行できない場合、修正漏れによるエラー箇所以降のテストが正しく実行されない可能性が高いため、エラーの修正とテストの実行とを手動で繰り返し行わなければならず、追加工数が発生する。
 そこで、一側面では、本発明は、ウェブ画面をテストするための機能変更前のテストシナリオに基づき、機能変更後のテストシナリオを自動作成することを目的とする。
 一つの案では、システムの機能変更前の処理が記述された第1のソースコードに所定の表記を付加した第1の修正ソースコードに基づき、機能変更前の第1のウェブ画面の位置を指定する第1のXPathと前記所定の表記とを含んだ第1のシナリオ修正用データを作成し、システムの機能変更後の処理が記述された第2のソースコードに所定の表記を付加した第2の修正ソースコードに基づき、機能変更後の第2のウェブ画面の位置を指定する第2のXPathと前記所定の表記とを含んだ第2のシナリオ修正用データを作成し、前記第1のシナリオ修正用データと前記第2のシナリオ修正用データとに含まれる前記所定の表記が一致する位置に応じて前記第1のXPathと前記第2のXPathとの対応情報を抽出し、前記抽出した対応情報に基づき、前記第1のウェブ画面の操作手順を示す第1のテストシナリオから前記第2のウェブ画面の操作手順を示す第2のテストシナリオを作成する、処理をコンピュータに実行させるための試験プログラムが提供される。
 一態様によれば、ウェブ画面をテストするための機能変更前のテストシナリオに基づき、機能変更後のテストシナリオを自動作成することができる。
機能仕様書の差分情報からテストシナリオを手動で作成する例を示すフローチャート。 図2(a)はテストシナリオの手動作成を説明するための比較図、図2(b)は一実施形態にかかるテストシナリオの自動作成を説明するための図。 一実施形態にかかるシステムの全体構成の一例を示す図。 HTML上の各要素とXPathの位置指定の例を示す図。 XPathを使用したテストシナリオの一例を示す図。 ウェブ画面のレイアウト変更例を示す図。 図4に対してウェブ画面のレイアウト変更後のXPathの一例を示す図。 図4に対してウェブ画面のレイアウト変更後のXPathの他の例を示す図。 一実施形態にかかるウェブテストシステムの機能構成の一例を示す図。 一実施形態にかかる関数リストの一例を示す図。 図10の関数リストの本体の一例を示す図。 一実施形態にかかるテスト実行処理の一例を示すフローチャート。 一実施形態にかかる関数付加処理の一例を示すフローチャート。 一実施形態にかかる関数リスト生成処理の一例を示すフローチャート。 一実施形態にかかるソースコードの一例を示す図。 一実施形態にかかるリスト化されたソースコードの一例を示す図。 図16の構文解析結果を示す図。 一実施形態にかかる修正ソースコードの一例を示す図。 一実施形態にかかる修正ソースコードを元のソースコードに戻した例を示す図。 一実施形態にかかるテストシナリオの自動作成処理の詳細を示すフローチャート。 一実施形態にかかるシナリオ修正用データ(機能変更前)の作成例を示す図。 一実施形態にかかるシナリオ修正用データの作成処理を示すフローチャート。 一実施形態にかかるシナリオ修正用データ(機能変更後)の作成例を示す図。 一実施形態にかかるテストシナリオの自動作成処理を示すフローチャート。 一実施形態にかかるシナリオ修正用データ(機能変更前後)の一致検出例を示す図。 一実施形態にかかるXPathの検出例を示す図。 図27(a)は、機能変更前のシステムに対するテストシナリオを示し、図27(b)は、機能変更後のシステムに対するテストシナリオを示す図。 機能変更前のHTMLを示す図。 機能変更前のシステムに対する第1のテストシナリオを適用するウェブ画面例を示す図。 機能変更後のHTMLを示す図。 機能変更後のシステムに対する第2のテストシナリオを適用するウェブ画面例を示す図。 第1のテストシナリオを使用したテスト例を示す図。 第2のテストシナリオを使用したテスト例を示す図。 機能変更前のテストシナリオの実行例を示す図。 機能変更後のテストシナリオの実行例を示す図。 一実施形態にかかるウェブテストシステムのハードウェア構成例を示す図。
 以下、本発明の実施形態について添付の図面を参照しながら説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複した説明を省く。
 [システムの全体構成]
 まず、。本発明の一実施形態に係るサーバ/ストレージシステム1、ウェブシステム20及びウェブテストシステム30の関係について、図3を参照しながら説明する。ウェブシステム20は、監視対象のサーバ/ストレージシステム1の稼働状況等の情報をウェブ画面に表示して提供する。
 本実施形態にかかるサーバ/ストレージシステム1において、サーバ/ストレージ装置10の機能構成の情報は、ウェブ画面11を用いて入力される。ウェブ画面11への入力及びウェブ画面11の更新は、ウェブシステム20により制御される。
 サーバ/ストレージシステム1において機能の追加や機能の削除が行われた場合、ウェブシステムは、追加又は削除した機能以外の機能に関しては、機能変更の前後において同じ動作が行われウェブ画面上に表示されることを保証しなければならない。そのためのテスト方法としてリグレッションテストが知られている。
 リグレッションテストは、ウェブテストシステム30により実行される。ウェブテストシステム30は、まず、サーバ/ストレージ装置10の機能仕様書からウェブ画面11のテスト用の操作手順を作成する。ウェブ画面11のテスト用の操作手順を、以下「テストシナリオ」という。
 ウェブテストシステム30は、テストシナリオを入力し、テストシナリオの操作手順に基づきウェブ画面11を操作してテストを実行し、その実行結果を検証する。このとき、ウェブテストシステム30は、テストシナリオに従ってウェブ画面11の操作を自動で行う。
 テストシナリオには、ウェブ画面を記述するHTML上の各要素が指定される。HTMLの要素の位置指定には、XPathによる位置指定方法が用いられる。図4は、HTML上の各要素とXPathの位置指定の例を示す。XPathは、HTMLなどのXML(Extensible Markup Language)文書の中の特定の要素を指し示す記述方法を定めた規格であり、W3C(World Wide Web Consortium)が勧告した標準仕様に基づく。図4(b)に示すHTMLファイルの要素(E1)に対して、図4(a)のウェブ画面11に対応するテーブルの(1)で示される位置、は、図4(c)の(1)のXPathで示される。図4(b)に示すHTMLファイルの要素(E2)に対して、図4(a)のテーブルの(2)で示される位置は、図4(c)の(2)のXPathで示される。図4(b)に示すHTMLファイルの要素(E3)に対して、図4(a)のテーブルの(3)で示される位置は、図4(c)の(3)のXPathで示される。
 テストシナリオでは、指定したウェブ画面を記述するHTMLファイルの要素に対する操作を記載する。XPathを使用したテストシナリオの一例を図5に示す。テストシナリオに記載されるコマンドには、文字入力(input)、クリック(Click)、任意のデータとの比較(Check)等がある。テストシナリオに記載のXPathには、そのコマンドを実行する場所が指定される。
 図5に示すようにテストシナリオには場所の指定であるXPathが記述されており、ウェブ画面11のレイアウトが変わるとHTMLファイルの要素の位置指定、つまりXPathが変わってしまう。このため、機能変更に応じてウェブ画面11のレイアウトが変わると、機能変更前のXPathを含むテストシナリオをそのまま機能変更後のテストシナリオとして使用することは困難である。
 例えば、図6の上図のウェブ画面11の「注釈2」が削除され、下図のウェブ画面11に示すようにレイアウトが変更した場合、レイアウト変更と共にXPathも変更される。このため、レイアウト変更後のウェブ画面11に対して元のテストシナリオをそのまま使用してテストを行うことはできない。
 図4のウェブ画面11のレイアウト変更後のXPathの一例を図7及び図8に示す。図7は、図4に対して画面要素(De)が削除されたためXPathが変更になった例、図8は、図4に対して画面要素(Ad)が追加されたためXPathが変更になった例である。
 図4(b)に示すHTMLファイルの要素(E3)に対する変更前の図4(c)の(3)に示すXPathは「/html/body/table/tr[3]/td[2]」である。これに対して、図7(b)に示すHTMLファイルの要素(De)で示す部分が削除された場合、図7(b)に要素(E3)に対する変更後の図7(c)の(5)に示すXPathは「/html/body/table/tr[2]/td[2]」である。
 また、図8(b)に示すHTMLファイルの要素(Ad)で示す部分が追加された場合、図8(b)に要素(E3)に対する変更後の図8(c)の(6)に示すXPathは「/html/body/table/tr[4]/td[2]」である。このように、ウェブ画面11のレイアウトが変更され、HTMLファイルの要素が変更になるとXPathで示されるウェブ画面11上の位置の指定が変更される。
 以下に説明する一実施形態にかかるウェブテストシステム30は、機能変更前のウェブ画面11のテストに使用したテストシナリオから機能変更後のウェブ画面11のテストに使用するテストシナリオを自動作成する。これにより、ウェブテストシステム30が使用するテストシナリオを、機能仕様書に基づき手動で変更することを不要とする。なお、一実施形態にかかるウェブテストシステム30は、ウェブ画面11をテストする試験装置の一例である。ウェブテストシステム30は、例えばPC上で動くテストシステムであり、テストシナリオを入力してテストシナリオの操作手順に従いウェブ画面11のテストを行う。
 [ウェブテストシステムの機能構成]
 本発明の一実施形態に係るウェブテストシステム30の機能構成について、図9を参照しながら説明する。図9は、一実施形態に係るウェブテストシステム30の機能構成の一例を示す。一実施形態に係るウェブテストシステム30は、ソースコード読込部31、修正ソースコード作成部32、テストシナリオ読込部33、修正用データ作成部34、XPath抽出部35、テストシナリオ作成部36、テスト実行処理部37及び記憶部40を有する。
 記憶部40は、ソースコードDB(Data Base)41、修正ソースコードDB42、テストシナリオDB43、シナリオ修正用DB44及びテスト実行結果DB45を有する。
 ソースコード読込部31は、ソースコードDB41に格納された所定のソースコードを読み込む。ソースコードDB41は、ウェブシステム20が提供する機能変更前のウェブ画面11(第1のウェブ画面)を記述する。
 修正ソースコード作成部32は、ソースコードに、所定の表記を付加した修正ソースコードを作成する。例えば、修正ソースコード作成部32は、第1のソースコードに所定の関数又は固定値の表記を付加して第1の修正ソースコードを作成する(図2(b):(1)関数追加)。また、例えば、修正ソースコード作成部32は、第2のソースコードに所定の関数又は固定値の表記を付加して第2の修正ソースコードを作成する(図2(b):(3)関数追加)。
 第1のソースコードには、サーバ/ストレージシステム1の機能変更前の内部処理が記述されている。第2のソースコードには、サーバ/ストレージシステム1の機能変更後の内部処理が記述されている。
 所定の表記の一例を示した関数リスト100を図10に示す。関数リスト100は、外部から入力する。関数リスト100は、関数の表記として変数対象関数名101及び挿入関数名102を有する。関数リスト100は、固定値の表記として第1のデバッグ出力情報103、第2のデバッグ出力情報104、第3のデバッグ出力情報105、第4のデバッグ出力情報106・・・を有する。なお、図11は、図10の関数リストの本体の一例を示す。所定の表記には、関数の表記、固定値(固定文字等)の表記、関数に記載された引数を含む。
 テストシナリオ読込部33は、テストシナリオDB43に格納された所定のテストシナリオを読み込む。
 修正用データ作成部34は、第1の修正ソースコードに基づき、機能変更前の第1のウェブ画面の位置を指定する第1のXPathと前記所定の表記とを含んだ第1のシナリオ修正用データを作成する。修正用データ作成部34は、第2の修正ソースコードに基づき、機能変更後の第2のウェブ画面の位置を指定する第2のXPathと前記所定の表記とを含んだ第2のシナリオ修正用データを作成する。
 例えば、図6の上図に示すウェブ画面11を第1のウェブ画面とし、システムの機能変更に応じて図6の下図に示すようにウェブ画面11のレイアウトの一部が変更された、ウェブ画面11を第2のウェブ画面とする。
 第2のウェブ画面をテストする場合、修正用データ作成部34は、第1の修正ソースコードに基づく処理を実行してシナリオ修正用データを作成する(図2(b):(2)実行)。作成されたシナリオ修正用データは、第1のウェブ画面のレイアウトを表記するための第1のXPathを含み、以下、「第1のシナリオ修正用データ」ともいう。
 また、例えば、修正用データ作成部34は、第2の修正ソースコードに基づく処理を実行してシナリオ修正用データを作成する(図2(b):(4)実行)。作成されたシナリオ修正用データは、第2のウェブ画面のレイアウトを表記するための第2のXPathを含み、以下、「第2のシナリオ修正用データ」ともいう。第1のシナリオ修正用データ及び第2のシナリオ修正用データは、シナリオ修正用DB44に格納される。
 XPath抽出部35は、第1のシナリオ修正用データと第2のシナリオ修正用データとに含まれる前記所定の表記が一致する位置に応じて第1のXPathと第2のXPathとの対応情報を抽出する。
 テストシナリオ作成部36は、対応情報に基づき、第1のウェブ画面のテスト用の操作手順を示す第1のテストシナリオから第2のウェブ画面のテスト用の操作手順を示す第2のテストシナリオを作成する(図2(b):(5)作成)。
 テスト実行処理部37は、第2のテストシナリオの操作手順に従い機能変更後の第2のウェブ画面のテストを行う。テストの実行結果のデータは、テスト実行結果DB45に保存される。
 [テストシナリオ自動作成の前提条件]
 以上に説明したテストシナリオ自動作成のための前提条件1~3について説明する。
 前提条件1:HTMLファイルの生成前にウェブシステム20で実行する処理(関数)に変更がないこと
 前提条件2:HTMLファイルの生成後にウェブシステム20で実行される処理(関数)に変更がないこと
 前提条件3:ウェブテストシステム30においてテストシナリオの適用順序に変更がないこと
 本実施形態に係るウェブテストシステム30によれば、上記前提条件の元、以下の仕組みでテストシナリオの再利用を可能とする。
(1)機能変更前と機能変更後のウェブシステム20のソースコードを書き換えて以下の情報を出力する。
 ・HTMLファイルの生成前に実行した内部処理
 ・HTMLファイルの生成
 ・HTMLファイルの生成後に実行した内部処理
 上記の生成したHTMLファイルからXPathが生成される。HTMLファイルの生成前後の内部処理を付加したXPath(シナリオ修正用データ中のXPath)により、第1のウェブ画面用の機能変更前のテストシナリオから第2のウェブ画面用の機能変更後のテストシナリオが作成される。
(2)特定のHTMLファイル生成時の機能変更前処理と機能変更後処理の組み合わせは、同じ情報については、サーバ/ストレージシステム1のの機能変更の前後で変わらない。このことを前提として、HTMLファイル生成前と、HTMLファイル生成後に実行した内部処理の組み合わせが同じとなるものを見つけ出し、サーバ/ストレージシステム1の機能変更前後で変更のあるXPathを見つけ出す。
(3)第1のシナリオ修正用データと第2のシナリオ修正用データとに含まれる所定の関数又は固定値の表記が一致する位置に応じて変更前の第1のXPathと変更後の第2のXPathとの対応情報を抽出する。これにより、サーバ/ストレージシステム1のの機能変更の前後でXPathがどのように変わったかを取得できる。
(4)対応情報に基づき、機能変更前のテストシナリオから機能変更後のテストシナリオを書き換える。
 これにより、図2(b)に示すように、サーバ/ストレージシステム1において機能変更前のウェブ画面11のテスト用に作成した第1のテストシナリオを使用して、機能変更後のテスト用に第2のテストシナリオを自動作成することができる。ウェブテストシステム30では、テストシナリオの自動作成とテストシナリオによるテストの実行とが繰り返し実施される。
 [テストシナリオの自動作成処理]
 次に、本実施形態に係るテストシナリオの自動作成処理について図12を参照しながら説明する。図12は、本実施形態にかかるテスト実行処理の一例を示すフローチャートである。以下のテストシナリオの自動作成処理は、左側がウェブシステム20において提供される機能変更前のウェブ画面11のテスト実行処理、右側がウェブシステム20において提供される機能変更後のウェブ画面11のテスト実行処理を示す。テストシナリオの自動作成処理は、右側に示す機能変更後のウェブ画面11のテスト実行処理前に実行される。
 図12の左側の機能変更前の処理が開始されると、ソースコード読込部31は、機能変更前のソースコードを読み込む(ステップS10)。以下、機能変更前のソースコードを第1のソースコードともいう。
 次に、修正ソースコード作成部32は、第1のソースコードに関数及び固定値の表記を付加する処理(以下、「関数付加処理」ともいう。)を実行し、関数及び固定値の表記を付加した第1のソースコード(以下、「第1の修正ソースコード」ともいう。)を作成する(ステップS12)。なお、後述されるステップS12、S24、S32、S44の関数等の付加処理は図13に示され、付加する関数リストの生成処理は図14に示され、後述される。
 次に、修正用データ作成部34は、第1の修正ソースコードに基づき第1のシナリオ修正用データを作成し(ステップS14)、テストシナリオ読込部33は、テストシナリオ(以下、「第1のテストシナリオ」ともいう。)を読み込む(ステップS16)。次に、ウェブシステム20は、生成した最新のHTMLファイルに従いウェブ画面11を表示する(ステップS18)。ここでは、第1のソースコードに基づき第1のウェブ画面が表示される。第1のウェブ画面には、機能変更前のサーバ/ストレージシステム1の稼働情報などの情報が表示されている。
 次に、テスト実行処理部37は、第1のテストシナリオを読み込み、第1のテストシナリオに基づきリグレッションテストを実行する(ステップS20)。記憶部40は、テストの実行処理結果をテスト実行結果DB45に保存する。次に、ソースコード読込部31は、機能変更前のウェブシステム20の次の第1のソースコードを読み込み(ステップS22)、修正ソースコード作成部32は、第1のソースコードに関数及び固定値の表記を付加する関数付加処理を実行し、次の第1の修正ソースコードを作成する(ステップS24)。次に、修正用データ作成部34は、第1の修正ソースコードに基づき次の第1のシナリオ修正用データを作成する(ステップS26)。
 次に、テスト実行処理部37は、次の第1のテストシナリオがないかを判定し(ステップS28)、次の第1のテストシナリオはないと判定した場合、本処理は終了する。一方、次の第1のテストシナリオがあると判定した場合、テスト実行処理部37は、次の第1のテストシナリオを読み込む(ステップS29)。次に、テスト実行処理部37は、次の第1のテストシナリオに基づきステップS20にてリグレッションテストを実行し、記憶部40はテストの実行処理結果をテスト実行結果DB45に保存する。ステップS28にて次の第1のテストシナリオがないと判定されるまで、ステップS18~S29の処理が繰り返される。
 図12の右側の処理が開始されると、ソースコード読込部31は、機能変更後のソースコードを読み込む(ステップS30)。以下、機能変更後のソースコードを第2のソースコードともいう。次に、修正ソースコード作成部32は、第2のソースコードに関数付加処理を実行し、関数及び固定値の表記を付加した第2のソースコード(以下、「第2の修正ソースコード」ともいう。)を作成する(ステップS32)。
 次に、修正用データ作成部34は、第2の修正ソースコードに基づき第1のシナリオ修正用データを作成する(ステップS34)。テストシナリオ作成部36は、第1のシナリオ修正用データ及び第2のシナリオ修正用データに基づき第1のテストシナリオを修正した第2のテストシナリオを自動作成する(ステップS36)。
 次に、ウェブシステム20は、生成した最新のHTMLファイルに従いウェブ画面11を表示する(ステップS38)。ここでは、第2のソースコードに基づき第2のウェブ画面が表示される。第2のウェブ画面には、機能変更後のサーバ/ストレージシステム1の稼働情報などの情報が表示されている。
 次に、テスト実行処理部37は、自動作成した第2のテストシナリオに基づきリグレッションテストを実行する(ステップS40)。記憶部40は、テストの実行処理結果をテスト実行結果DB45に保存する。次に、ソースコード読込部31は、次の第2のソースコードを読み込み(ステップS42)、修正ソースコード作成部32は、第1のソースコードに関数及び固定値の表記を付加する関数付加処理を実行する(ステップS44)。次に、修正用データ作成部34は、生成した第2の修正ソースコードに基づき次の第2のシナリオ修正用データを作成する(ステップS46)。
 次に、テスト実行処理部37は、次のテストシナリオがないかを判定し(ステップS48)、次のテストシナリオはないと判定した場合、本処理は終了する。一方、次の第2のテストシナリオがあると判定した場合、テスト実行処理部37は、次の第2のテストシナリオを修正(自動作成)し(ステップS49)、ステップS40にてリグレッションテストを実行する。記憶部40は、テストの実行処理結果をテスト実行結果DB45に保存する。ステップS48にて次の第2のテストシナリオがないと判定されるまで、ステップS38~S49の処理が繰り返される。
 [関数付加処理]
 本実施形態にかかる関数付加処理について、図13及び図14を参照しながら説明する。図13は、本実施形態にかかる関数付加処理を示すフローチャートである。図14は、本実施形態にかかる関数リストの生成処理を示すフローチャートである。本処理は、図2(b)の(1)に示す関数付加により第1のソースコードから第1の修正ソースコードを作成する処理である。また、図2(b)の(3)に示す関数付加により、第2のソースコードから第2の修正ソースコードを作成する処理である。
 図13の処理が開始されると、修正ソースコード作成部32が関数リストの生成処理(図14)を実行する(ステップS50)。
(関数リスト生成処理)
 図14の関数リストの生成処理では、修正ソースコード作成部32は、ウェブシステム20のソースコードを{,}、(,)、空白、カンマ、';' 、'=' 、改行コードで分割し、リスト化する(ステップS70)。但し"…"、"//~改行"内は分割しない。
 次に、修正ソースコード作成部32は、リスト化されたソースコードに含まれる関数を判定し(ステップS71)、関数呼び出し部(関数Call)を走査する(ステップS72)。修正ソースコード作成部32は、走査が完了したかを判定し(ステップS73)、走査が完了したと判定した場合、本処理を終了し、図13の関数付加処理のステップS51に戻る。
 一方、修正ソースコード作成部32は、走査が完了していないと判定した場合、関数の種類によってソースコード内の関数を下記の3つに分ける(ステップS74)。ステップS75~S77にてリストを生成した後、ステップS72に戻り、ステップS72~S77の処理を走査が完了するまで繰り返す。
(1)HTML出力関数リスト生成(ステップS75)
・関数名 関数タイプ 関数引数
(2)データベース書き込み関数リスト生成(ステップS76)
・関数名 関数タイプ 関数引数
(3)データベース読み込み関数リスト生成(ステップS77)
・関数名 関数タイプ 関数引数
 図13の付加処理(ステップS51)に戻ると、修正ソースコード作成部32は、ウェブシステム20のソースコードを{,}、(,)、空白、カンマ、';' 、'=' 、改行コードで分割し、リスト化する。但し"…"、"//~改行"内は分割しない。なお、修正ソースコード作成部32は、ステップS51において、ステップS70にてリスト化されたソースコードを取得してもよい。図15はソースコードの一例を示す。図16は図15のソースコードを分割し、リスト化した一例を示す。
 次に、修正ソースコード作成部32は、リスト化されたソースコードから関数を判定し(ステップS52)、関数呼び出し部(関数Call)を走査する(ステップS53)。修正ソースコード作成部32は、走査が完了したかを判定し(ステップS54)、走査が完了したと判定した場合、リスト化されたソースコードを元のソースコードに戻し(ステップS63)、本処理を終了する。
 一方、修正ソースコード作成部32は、ステップS54にて走査が完了していないと判定した場合、関数呼び出し部の関数の種類が図14にて生成した関数リストの対象関数と一致するかを判定する(ステップS55)。修正ソースコード作成部32は、関数呼び出し部の関数の種類が関数リストの対象関数と一致すると判定した場合、対象関数の直後に挿入関数名を挿入する(ステップS56)。図10は、上記の関数リスト生成のステップで使用する関数リストの一例を示す。
 修正ソースコード作成部32は、図4の(b)のソースコードをリスト化し(図16)、リスト化したソースコードを構文解析し(図17)、対象関数の直後に挿入関数名を挿入する(図18)。
 次に、図13のステップS57にて、修正ソースコード作成部32は、関数リストからデバッグ出力情報を取得する。修正ソースコード作成部32は、デバッグ出力情報の取得が完了したかを判定し(ステップS58)、デバッグ出力情報の取得が完了したと判定した場合、ステップS62に進む。一方、修正ソースコード作成部32は、デバッグ出力情報の取得が完了していないと判定した場合、固定文字かを判定する(ステップS59)。固定文字の場合、修正ソースコード作成部32は、その固定文字を挿入する(ステップS60)。図18には、ステップS60の実行により挿入関数名の挿入後に固定文字が設定されている。一方、固定文字でない場合、修正ソースコード作成部32は、関数引数を挿入する(ステップS61)。図18には、挿入関数名及び固定文字の挿入後に関数引数(デバッグ出力情報103~106の"arg"の関数引数)が設定されている。ステップS57に戻り、修正ソースコード作成部32は、ステップS57~S61の処理を繰り返した後、ステップS58にてデバッグ出力情報の取得が完了したと判定したとき、ステップS62に進み、関数の終端表記を挿入し、ステップS53に戻る。修正ソースコード作成部32は、ステップS53に続くステップS54にて関数呼び出し部の走査が完了したと判定するまでS53~S62の処理を繰り返し、走査が完了したと判定したときリスト化したソースコードを元の状態に戻し(ステップS63)、本処理を終了する。図19は、リスト化したソースコードから元の状態に戻されたソースコードを示す。なお、ステップS63の処理は省略できる。
 これにより、図18に示すように、一のソースコードから修正ソースコードが作成される。以上、図2(b)の(1)及び(3)の関数追加により修正ソースコードを作成する処理の詳細を説明した。図2では、修正ソースコード作成部32は、機能変更前の第1のソースコードから第1の修正ソースコードを作成し、機能変更前の第2のソースコードから第2の修正ソースコードを作成する。
 次に、図2(b)の(2)及び(4)の第1及び第2の修正ソースコードから第1及び第2のシナリオ修正用データを作成する処理の詳細、及び図2(b)の(5)第1のテストシナリオから第2のテストシナリオを自動作成する処理の詳細を説明する。図20は、本実施形態にかかるテストシナリオの自動作成処理の詳細を示すフローチャートである。
 図20の処理が開始されると、修正ソースコード作成部32は、シナリオ修正用DB44にシナリオ修正用データが存在するかを判定する(ステップS80)。図2(b)の(1)の時点では、シナリオ修正用データは存在しない。よって、修正用データ作成部34は、ソースコードに所定の関数等の表記を付加して修正ソースコードを作成する(ステップS81)。ここでは、修正ソースコード作成部32は、機能変更前のソースコードである第1のソースコードに所定の関数等の表記を付加して機能変更前の修正ソースコードである第1の修正ソースコードを作成する。
 次に、ウェブシステム20が起動され(ステップS82)、第1の修正ソースコードに基づく処理の実行によりHTMLファイルが生成され、修正用データ作成部34は、HTMLファイルに応じた第1のシナリオ修正用データを作成する(ステップS83)。図21の左側に機能変更前のHTMLファイルの例を示し、図21の右側に作成した第1のシナリオ修正用データの例を示す。第1のシナリオ修正用データは、テストシナリオを修正するために使用される。
(シナリオ修正用データの作成処理)
 シナリオ修正用データの作成処理の詳細について、図22を参照しながら説明する。図22は、本実施形態にかかるシナリオ修正用データの作成処理を示すフローチャートである。まず、修正用データ作成部34は、HTMLファイルの上から順に一行を取得する(ステップS101)。例えば、図21では、行番号「1」の一行が取得される。次に、修正用データ作成部34は、HTMLファイルの全行の処理が済んだかを判定する(ステップS102)。修正用データ作成部34は、全行の処理が済んだと判定した場合、本処理を終了する。一方、修正用データ作成部34は、全行の処理が済んでいないと判定した場合、取得した一行からタグの記述を取り出す(ステップS103)。タグの記述は、"<・・・>"又は"</・・・>"で示される。次に、修正用データ作成部34は、取得した一行に含まれる全データの処理が済んだかを判定する(ステップS104)。修正用データ作成部34は、取得した一行に含まれる全データの処理が済んだと判定した場合、ステップS101に戻り、ステップS101以降の処理を繰り返す。
 一方、修正用データ作成部34は、取得した一行に含まれる全データの処理が済んでいないと判定した場合、取り出したデータの種類を判定する(ステップS105)。修正用データ作成部34は、取り出したデータがタグ以外と判定した場合、ステップS102に戻る。
 修正用データ作成部34は、取り出したデータがタグの終端(</タグ名>)と判定した場合、ステップS116に進み、ツリー情報に"/ "が入っているかを判定する(ステップS116)。ツリー情報は、HTMLファイルのタグ構造を示す。修正用データ作成部34は、ツリー情報に"/ "が入っていると判定した場合、ツリー情報終端の"/タグ名[タグ出現回数]"を除去し(ステップS117)、ステップS102に戻る。一方、修正用データ作成部34は、ツリー情報に"/ "が入っていないと判定した場合、ツリー情報を空にし(ステップS118)、ステップS102に戻る。
 ステップS105において、修正用データ作成部34は、取り出したデータがタグの開始(つまり、<タグ名>)と判定した場合、前回削除したタグ名と今回のタグ名とが同じかを判定する(ステップS106)。修正用データ作成部34は、同じでないと判定した場合、タグの出現回数を「1」とし(ステップS107)、同じと判定した場合、タグの出現回数を「+1」する(ステップS108)。
 次に、修正用データ作成部34は、ツリー情報は何かを判定する(ステップS109)。修正用データ作成部34は、ツリー情報が空であると判定した場合、ツリー情報に"/タグ名[タグ出現回数]"を保存する(ステップS110)。例えば、図21では、行番号が「1」のとき、ツリー情報に"/html[1]"が保存される。なお、タグ出現回数が1のときの[1]は省略されるため、ツリー情報に保存されるデータは、"/html"となる。一方、修正用データ作成部34は、ツリー情報に"/"が入っていると判定した場合、ツリー情報に"タグ名[タグ出現回数]"を保存する(ステップS111)。
 次に、修正用データ作成部34は、ツリー情報をシナリオ修正用データのXPathに保存する(ステップS112)。ツリー情報は、機能変更前の場合、第1のシナリオ修正用データのXPathに保存され、機能変更後の場合、第2のシナリオ修正用データのXPathに保存される。
 次に、修正用データ作成部34は、タグの終端(つまり、</タグ名>)かを判定する(ステップS113)。修正用データ作成部34は、タグの終端でないと判定した場合、ステップS102に戻る。一方、修正用データ作成部34は、タグの終端であると判定した場合、タグの出現回数から1を減算し(ステップS114)、ツリー情報終端の"/タグ名[タグ出現回数]"を除去し(ステップS115)、ステップS102に戻る。例えば、図21では、行番号「13」のとき、ツリー情報に保存されるデータは、"/html/body/table/tr"となる。
 以上、図22を参照しながら、図20のステップS83で呼び出されるシナリオ修正用データの作成処理の一例を説明した。次に、図20のステップS84に進み、テストシナリオ読込部33は、テストシナリオDB43から次に実行するテストシナリオを読み込む。次に、テスト実行処理部37は、テストシナリオのすべてについてテストが完了したかを判定する(ステップS85)。テスト実行処理部37は、テストシナリオのすべてについてテストが完了していないと判定した場合、テストシナリオを実行し(ステップS86)、ステップS83に戻り、テストシナリオのすべてについてテストが完了するまで、ステップS83~S86の処理を繰り返す。ここでは、第1のテストシナリオの操作手順に従い機能変更前のウェブ画面11のテストが行われる。テストの実行結果のデータは、テスト実行結果DB45に保存される。
 ステップS85において第1のテストシナリオのすべてについてテストが完了したと判定された場合、又は、ステップS80においてシナリオ修正用データが存在すると判定された場合、修正用データ作成部34は、ステップS87に進む。修正用データ作成部34は、ソースコードに所定の表記を付加して修正ソースコードを作成する。この時点では、サーバ/ストレージシステム1において機能変更がされている。よって、修正ソースコード作成部32は、機能変更後のソースコードである第2のソースコードに所定の表記を付加して機能変更後の修正ソースコードである第2の修正ソースコードを作成する。
 次に、ウェブシステム20が起動され(ステップS88)、第2の修正ソースコードに基づく処理の実行によりHTMLファイルが生成され、修正用データ作成部34は、HTMLファイルに応じた第2のシナリオ修正用データを作成する(ステップS89)。図23の左側に機能変更後のHTMLファイルの例を示し、図23の右側に作成した第2のシナリオ修正用データの例を示す。第2のシナリオ修正用データは、テストシナリオを修正するために使用される。
 次に、テストシナリオ作成部36は、シナリオ修正用DB44から、対応する機能変更前の第1のシナリオ修正用データを取得する(ステップS90)。テストシナリオ作成部36は、第1のシナリオ修正用データ及び第2のシナリオ修正用データに基づき、第1のテストシナリオから第2のテストシナリオを自動作成する(ステップS91)。つまり、XPath抽出部35は、第1のシナリオ修正用データと第2のシナリオ修正用データとに含まれる所定の表記が一致する位置に応じて第1のXPathと第2のXPathとの対応情報を抽出する。テストシナリオ作成部36は、対応情報に基づき、第1のウェブ画面のテスト用の操作手順を示す第1のテストシナリオから第2のウェブ画面のテスト用の操作手順を示す第2のテストシナリオを作成する。
(テストシナリオの自動作成処理)
 テストシナリオの自動作成処理の詳細について、図24を参照しながら説明する。図24は、本実施形態にかかるテストシナリオの自動作成処理を示すフローチャートである。まず、テストシナリオ作成部36は、第1のシナリオ修正用データから"HTML"で始まる行を取り除く(ステップS120)。これにより、図25の左図の斜線で示す"HTML"で始まる行が取り除かれる。
 次に、テストシナリオ作成部36は、第2のシナリオ修正用データから"HTML"で始まる行を取り除く(ステップS121)。これにより、図25の右図の斜線で示す"HTML"で始まる行が取り除かれる。
 次に、テストシナリオ作成部36は、第1のシナリオ修正用データから一行を取得する(ステップS122)。これにより、図25の左図の行番号「9」の一行が取得される。次に、テストシナリオ作成部36は、第1のシナリオ修正用データのすべての処理が済んだかを判定する(ステップS123)。テストシナリオ作成部36は、第1のシナリオ修正用データのすべての処理が済んだと判定した場合、本処理を終了する。一方、テストシナリオ作成部36は、第1のシナリオ修正用データのすべての処理は済んでいないと判定した場合、第1のシナリオ修正用データから次の一行を取得する(ステップS124)。これにより、図25の左図の行番号「11」の一行が取得される。
 次に、テストシナリオ作成部36は、第2のシナリオ修正用データから一行を取得する(ステップS125)。これにより、図25の右図の行番号「16」の一行が取得される。次に、テストシナリオ作成部36は、第2のシナリオ修正用データのすべての処理が済んだかを判定する(ステップS126)。テストシナリオ作成部36は、第2のシナリオ修正用データのすべての処理が済んだと判定した場合、ステップS131に進む。一方、テストシナリオ作成部36は、第2のシナリオ修正用データのすべての処理は済んでいないと判定した場合、第1のシナリオ修正用データ及び第2のシナリオ修正用データから取得した最初の一行が一致するかを判定する(ステップS127)。
 テストシナリオ作成部36は、第1のシナリオ修正用データ及び第2のシナリオ修正用データから取得した最初の一行が一致しないと判定した場合、ステップS125に戻る。一方、テストシナリオ作成部36は、一致すると判定した場合、第2のシナリオ修正用データから次の一行を取得する(ステップS128)。これにより、図25の右図の行番号「18」の一行が取得される。
 次に、XPath抽出部35は、第1のシナリオ修正用データ及び第2のシナリオ修正用データから取得した次の一行が一致するかを判定する(ステップS129)。テストシナリオ作成部36は、第1及び第2のシナリオ修正用データから取得した次の一行が一致しないと判定し場合、ステップS125に戻る。一方、XPath抽出部35は、一致すると判定した場合、第1のシナリオ修正用データに含まれる第1のXPathと第2のシナリオ修正用データに含まれる第2のXPathとの対応情報を抽出する。XPath抽出部35は、第1のシナリオ修正用データ及び第2のシナリオ修正用データに含まれる所定の表記が一致する位置に応じて第1のXPathと第2のXPathとの対応情報を抽出する。本実施形態では、対応情報を抽出するために所定の表記が一致する位置は、第1のシナリオ修正用データ及び第2のシナリオ修正用データから取得した最初の一行と次の一行との複数位置である。ただし、所定の表記が一致する位置は、これに限らず、第1のシナリオ修正用データ及び第2のシナリオ修正用データから取得した最初の一行のみであってもよいし、次の一行のみであってもよい。
 テストシナリオ作成部36は、第1のシナリオ修正用データの取得した最初の行から次の行までの間のXPathと、第2のシナリオ修正用データの取得した最初の行から次の行までの間のXPathとの対応関係(対応情報)に基づき、第1のテストシナリオのXPathを置き換え、第2のテストシナリオを自動作成する(ステップS130)。
 例えば、図25の例では、第1のシナリオ修正用データの取得した二行の間(最初の行から次の行の間)と、第2のシナリオ修正用データの取得した二行の間(最初の行から次の行の間)との対応情報1に基づき、第1のテストシナリオのXPathが置き換えられ、第2のテストシナリオが自動作成される。対応情報2についても同様に第1のテストシナリオのXPathが置き換えられ、第2のテストシナリオが自動作成される。
 これにより、図26に示すように、第1のテストシナリオの対応情報1のXPathは、図21の第1のシナリオ修正用データのXPath(A)から、図23の第2のシナリオ修正用データのXPath(a)に置き換えられる。また、第1のテストシナリオの対応情報2のXPathは、図21の第1のシナリオ修正用データのXPath(B)から、図23の第2のシナリオ修正用データのXPath(b)に置き換えられる。このようにして、システムの機能変更前の第1のテストシナリオから機能変更後の第2のテストシナリオを自動作成することができる。
 図26の対応情報1では、図27(a)の第1のテストシナリオのコマンドinput(入力)において、値「1+2」を入力する場所(Xpath)は「/html/body/table/tr/td/input」で示されている。これに対して、本実施形態では、図27(b)の第2のテストシナリオのコマンドinputにおいて、値「1+2」を入力する場所(Xpath)が「/html/body/table/tr[2]/td/input」に自動変更される。
 また、図26の対応情報2では、図27(a)の第1のテストシナリオのコマンドCheck(チェック)において、値「3」が場所(Xpath)「/html/body/table/tr/td[2]」に表示されていることをチェックする。これに対して、本実施形態では、図27(b)の第2のテストシナリオのコマンドCheckにおいて、値「3」が表示されていることをチェックする場所(Xpath)が「/html/body/table/tr[2]/td[2]」に自動変更される。
 図28に示す機能変更前のHTMLファイルに基づき生成した図29のウェブ画面11(第1のウェブ画面例)において、図28の「P」で示すテストシナリオの入力コマンドが実行されると、値「1+2」が図29に示す「注釈」の入力エリア(Xpathで示した場所)に入力される。また、図28の「Q」で示すテストシナリオの表示コマンドが実行されると、図29に示す「結果」(Xpathで示した場所)に表示された値「3」がチェックされる。
 これに対して、機能変更後のHTMLファイルには、図30の「R」で示す「注釈2」が追加される。これにより、機能変更後の図31のウェブ画面11(第2のウェブ画面例)では、機能変更前の図29のウェブ画面11に対して「注釈」の前に「注釈2」が表示される。
 機能変更後の図31のウェブ画面11に対して、図27(a)に示す第1のテストシナリオのXpathが示す画面上の場所に値を表示しようとすると、テストでは、図32のように「注釈2」に値「1+2」を入力しようとしてしまう。また、図32のように「注釈」に値「3」が表示されていることを確認してしまう。
 しかしながら、本実施形態では、自動作成された第2のテストシナリオに基づき、図33に示したように、自動作成した第2のテストシナリオの図27(b)に示すXpathに基づき、「注釈」に値「1+2」が入力され、「結果」に値「3」が表示されていることが確認される。このようにして、第1のテストシナリオの機能変更前のXpathと機能変更後のXpathとを対応させて第2のテストシナリオを自動作成することで、機能変更後のテストシナリオのコマンドを機能変更後のウェブ画面11のレイアウトに合致させて実行できる。
 以上に説明したように、テストは、第1のテストシナリオから自動作成された第2のテストシナリオに基づき繰り返し実行される。すべてのテストシナリオが実行された後、テストが終了される。
 図34は機能変更前のテストシナリオの実行例を示し、図35は機能変更後のテストシナリオの実行例を示す。図34及び図35では、左上図のログイン画面でウェブシステム20が起動され、ログイン後に図34及び図35の左下図のウェブ画面11に画面が遷移する。図34の左下図のウェブ画面11に対する第1のテストシナリオから、図35の左下図のウェブ画面11に新たな機能表示(ディスク使用量)が追加された場合の第2のテストシナリオが自動作成された一例が示されている。
 以上に説明したように、一実施形態に係るウェブテストシステム30によれば、システムに機能変更が生じた場合、機能変更前のテストシナリオに基づきシステムの機能変更後のウェブ画面をテストするためのテストシナリオを自動作成することができる。つまり、システムの機能変更前後でウェブ画面11のレイアウトが変更されても、機能変更前後におけるテストシナリオに記述されたXpathの対応情報を抽出することで機能変更前のウェブ画面11をテストするためのテストシナリオから機能変更後のウェブ画面11をテストするためのテストシナリオを自動作成できる。これにより、手動によるテストシナリオの変更が不要になり、また、OSやブラウザに依存せずに画面のテストを行うことができる。
 (ハードウェア構成例)
 最後に、本実施形態に係るウェブテストシステム30のハードウェア構成例について、図36を参照して説明する。図36は、本実施形態に係るウェブテストシステム30のハードウェア構成例を示す図である。
 図36に示すように、ウェブテストシステム30は、入力装置101、表示装置102、外部I/F103、RAM(Random Access Memory)104、ROM(Read Only Memory)105、CPU(Central Processing Unit)106、通信I/F107、及びHDD(Hard Disk Drive)108などを備え、それぞれがバスBで相互に接続されている。
 入力装置101は、キーボードやマウスなどを含み、ウェブテストシステム30に各操作信号を入力するのに用いられる。表示装置102は、各種の処理結果を表示する。
 通信I/F107は、ウェブテストシステム30をネットワークに接続するインタフェースである。これにより、ウェブテストシステム30は、通信I/F107を介してウェブシステム20とデータ通信を行うことができる。
 HDD108は、プログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータには、装置全体を制御する基本ソフトウェア及びアプリケーションソフトウェアがある。例えば、HDD108には、ソースコードDB41、修正ソースコードDB42、テストシナリオDB43、シナリオ修正用DB44及びテスト実行結果DB45が格納されている。
 外部I/F103は、外部装置とのインタフェースである。外部装置には、記録媒体103aなどがある。これにより、ウェブテストシステム30は、外部I/F103を介して記録媒体103aの読み取り及び/又は書き込みを行うことができる。
 記録媒体103aには、フロッピー(登録商標)ディスク、CD(Compact Disk)、及びDVD(Digital Versatile Disk)、ならびに、SDメモリカード(SD Memory card)やUSBメモリ(Universal Serial Bus memory)などがある。
 ROM105は、電源を切っても内部データを保持することができる不揮発性の半導体メモリ(記憶装置)である。ROM105には、ネットワーク設定などのプログラムやデータが格納されている。RAM104は、プログラムやデータを一時保持する揮発性の半導体メモリ(記憶装置)である。CPU106は、上記記憶装置(例えば「HDD108」や「ROM105」など)から、プログラムやデータをRAM104上に読み出し、処理を実行することで、装置全体の制御や搭載機能を実現する演算装置である。
 上記ハードウェア構成により、例えば、CPU106が、ROM105やHDD108内に格納されたデータ及びプログラムを用いてテストシナリオの操作手順に基づきウェブ画面11のテストを実行する。
 なお、ソースコードDB41、修正ソースコードDB42、テストシナリオDB43、シナリオ修正用DB44及びテスト実行結果DB45に関する情報は、RAM104、HDD108に格納されてもよい。これらのDBは、ネットワークを介してウェブテストシステム30に接続されるクラウド上のサーバー等に格納されてもよい。
 以上、試験プログラム、試験装置及び試験方法を上記実施形態により説明したが、本発明にかかる試験プログラム、試験装置及び試験方法は上記実施形態に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能である。また、上記実施形態及び変形例が複数存在する場合、矛盾しない範囲で組み合わせることができる。
 例えば、上記実施形態に係る試験プログラム、試験装置及び試験方法の構成は一例であり、本発明の範囲を限定するものではなく、用途や目的に応じて様々なシステム構成例があることは言うまでもない。
 1:サーバ/ストレージシステム
 10:サーバ/ストレージ装置
 11:ウェブ画面
 20:ウェブシステム
 30:ウェブテストシステム
 31:ソースコード読込部
 32:修正ソースコード作成部
 33:テストシナリオ読込部
 34:修正用データ作成部
 35:XPath抽出部
 36:テストシナリオ作成部
 37:テスト実行処理部
 40:記憶部
 41:ソースコードDB
 42:修正ソースコードDB
 43:テストシナリオDB
 44:シナリオ修正用DB
 45:テスト実行結果DB

Claims (6)

  1.  システムの機能変更前の処理が記述された第1のソースコードに所定の表記を付加した第1の修正ソースコードに基づき、機能変更前の第1のウェブ画面の位置を指定する第1のXPathと前記所定の表記とを含んだ第1のシナリオ修正用データを作成し、
     システムの機能変更後の処理が記述された第2のソースコードに所定の表記を付加した第2の修正ソースコードに基づき、機能変更後の第2のウェブ画面の位置を指定する第2のXPathと前記所定の表記とを含んだ第2のシナリオ修正用データを作成し、
     前記第1のシナリオ修正用データと前記第2のシナリオ修正用データとに含まれる前記所定の表記が一致する位置に応じて前記第1のXPathと前記第2のXPathとの対応情報を抽出し、
     前記抽出した対応情報に基づき、前記第1のウェブ画面の操作手順を示す第1のテストシナリオから前記第2のウェブ画面の操作手順を示す第2のテストシナリオを作成する、
     処理をコンピュータに実行させるための試験プログラム。
  2.  前記抽出する処理は、
     前記所定の表記が一致する位置に応じたHTMLファイルのタグ構造から前記第1のXPathと前記第2のXPathとの対応情報を抽出する、
     請求項1に記載の試験プログラム。
  3.  システムの機能変更前の処理が記述された第1のソースコードに所定の表記を付加して第1の修正ソースコードを作成し、システムの機能変更後の処理が記述された第2のソースコードに所定の表記を付加して第2の修正ソースコードを作成する修正ソースコード作成部と、
     前記第1の修正ソースコードに基づき、機能変更前の第1のウェブ画面の位置を指定する第1のXPathと前記所定の表記とを含んだ第1のシナリオ修正用データを作成し、前記第2の修正ソースコードに基づき、機能変更後の第2のウェブ画面の位置を指定する第2のXPathと前記所定の表記とを含んだ第2のシナリオ修正用データを作成する修正用データ作成部と、
     前記第1のシナリオ修正用データと前記第2のシナリオ修正用データとに含まれる前記所定の表記が一致する位置に応じて前記第1のXPathと前記第2のXPathとの対応情報を抽出する抽出部と、
     前記抽出した対応情報に基づき、前記第1のウェブ画面の操作手順を示す第1のテストシナリオから前記第2のウェブ画面の操作手順を示す第2のテストシナリオを作成するテストシナリオ作成部と、
     を有する試験装置。
  4.  前記抽出部は、
     前記所定の表記が一致する位置に応じたHTMLファイルのタグ構造から前記第1のXPathと前記第2のXPathとの対応情報を抽出する、
     請求項3に記載の試験装置。
  5.  システムの機能変更前の処理が記述された第1のソースコードに所定の表記を付加した第1の修正ソースコードに基づき、機能変更前の第1のウェブ画面の位置を指定する第1のXPathと前記所定の表記とを含んだ第1のシナリオ修正用データを作成し、
     システムの機能変更後の処理が記述された第2のソースコードに所定の表記を付加した第2の修正ソースコードに基づき、機能変更後の第2のウェブ画面の位置を指定する第2のXPathと前記所定の表記とを含んだ第2のシナリオ修正用データを作成し、
     前記第1のシナリオ修正用データと前記第2のシナリオ修正用データとに含まれる前記所定の表記が一致する位置に応じて前記第1のXPathと前記第2のXPathとの対応情報を抽出し、
     前記抽出した対応情報に基づき、前記第1のウェブ画面の操作手順を示す第1のテストシナリオから前記第2のウェブ画面の操作手順を示す第2のテストシナリオを作成する、
     処理をコンピュータが実行する試験方法。
  6.  前記抽出する処理は、
     前記所定の表記が一致する位置に応じたHTMLファイルのタグ構造から前記第1のXPathと前記第2のXPathとの対応情報を抽出する、
     請求項5に記載の試験方法。
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) 재활용도를 높일 수 있는 gui 테스트 자동화 시스템 및 그 방법
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