JP6397800B2 - Test support system and test support method - Google Patents

Description

  The present invention relates to a technique for supporting software testing.

  In order to ensure the quality of software, a test for confirming the operation of the software, such as whether it operates according to the design document or has a desired performance, is an important process. Patent Document 1 discloses a program creation unit that creates a software program, a specification information generation unit that generates software specification information based on an inter-object relationship description file generated in an intermediate process of program creation, and a specification information generation unit. By providing test scenario generation means for generating a test scenario that defines the operating procedure for system test based on the specification information generated by the means, and test scenario execution means, the system test can be performed from the software program creation process. A software development support apparatus that can efficiently perform a series of software development up to the process is described.

JP-A-9-223041

  However, the technique described in Patent Document 1 creates a software program in advance to generate a test scenario, and generates software specification information based on inter-object relationship description information generated in the intermediate process of program creation. It is necessary to keep it.

  Accordingly, an object of the present invention is to provide a test support method and a test support system that can generate a test scenario without creating a software program and specification information in advance.

  A typical example of the present invention is as follows. In other words, the test support system of the present invention is included in the test execution log obtained at the time of software test execution, a storage unit that stores association information between the test execution log and test items, and the test execution log. For each record, the test execution log storage processing unit that assigns a label representing the state or transition according to the content of the record, and the test execution log that has the label are merged with the test execution log having the same contents The test execution log group storage processing unit to be stored in the storage unit, and the merged test execution log, the test execution path is extracted by searching the path from the start to the end of the test, and the extracted Based on the test execution path and the test item correspondence table, a test scenario including digestible test items is extracted, and the storage unit And a test scenario extracting unit for storing.

  According to the present invention, a test scenario can be generated without creating a software program and specification information in advance.

It is a figure showing the structure of the test assistance system 1 in a 1st Example. It is a figure which shows the hardware structural example which implement | achieves the test management apparatus 100 and the test scenario output apparatus 110 in a 1st Example. It is a figure which shows the operation | movement outline | summary of the test assistance system 1 in a 1st Example. It is a figure which shows the flow of the test execution log storage process by the test execution log input part 102 in the 1st Example, and the test execution log group storage process by the test execution log storage process part 104. FIG. It is a figure which shows the flow of the test execution log storage process of the test execution log input part 102 in the 1st Example, and the test execution log group storage process of the test execution log storage process part 104. FIG. It is a figure which shows an example of the test execution log 500 input from the user via a user interface, and the test execution log 501 after the label provision stored in the test execution log storage part 103. FIG. It is a figure which shows an example of a structure of the test execution log group storage part 105 in a 1st Example. It is a figure which shows an example of a structure of the test item corresponding table storage part 107 in a 1st Example. It is a figure which shows the outline | summary of the flow of a process in the test scenario extraction process part 109 in a 1st Example. It is a figure which shows an example of a structure of the test scenario storage part 113 in a 1st Example. It is a figure which shows an example of the test scenario output by the test scenario output part 114 in a 1st Example. It is a figure which shows an example of a structure of the test scenario storage part 113 in a 2nd Example. It is a figure which shows an example of the screen image of the test scenario output apparatus 110 in a 1st Example. It is a figure which shows an example of the process for outputting the collection of the test scenario for digesting all the test items in the test scenario extraction part 104 in a 1st Example.

(First embodiment)

  FIG. 1 is a diagram illustrating an example of the overall configuration of a test support system 1 in the present embodiment. As shown in FIG. 1, the test support system 1 includes a test management device 100 and a test scenario output device 110. The test management apparatus 100 includes a user interface 101, input units of a test execution log input unit 102 and a test item correspondence table input unit 106, processing units of a test execution log storage processing unit 104 and a test scenario extraction unit 108, The test execution log storage unit 103, the test item correspondence table storage unit 107, and the test execution log group storage unit 105 have respective storage units.

  The test scenario output device 110 includes a user interface 111, a test scenario output unit 114 (processing unit), and test item correspondence table storage unit 112 and test scenario storage unit 113.

  Here, the test execution log input unit 102 accepts the test execution log input by the user via the user interface 101 and stores it in the test execution log storage unit 103.

  The test item correspondence table input unit 106 accepts a test item correspondence table that is input by the user via the user interface 101 and manages the correspondence between test items to be digested and test execution logs, and stores the test item correspondence table. Stored in the unit 107. The test execution log storage processing unit 104 analyzes the test execution log stored in the test execution log storage unit 103 and updates information in the test execution log group storage unit 105. The test scenario extraction unit 108 extracts a test scenario from the test execution log group storage unit 105 and stores the extracted test scenario in the test scenario storage unit 113. The test scenario output unit 114 extracts the test scenario instructed to be output from the test scenario storage unit 113 based on the test scenario output instruction input by the user via the user interface 111 and outputs the test scenario.

  The test scenario extracted by the test scenario extraction unit 108 may be stored in the test scenario storage unit 113 via a network or an external storage medium such as a USB memory. Similarly, the storage process of the test item correspondence table from the test item correspondence table storage unit 107 of the test management device 100 to the test item correspondence table storage unit 112 of the test scenario output device 110 may be performed via a network. You may carry out using external storage media, such as a USB memory.

  FIG. 2 is a diagram illustrating a hardware configuration example that implements the test management apparatus 100 and the test scenario output apparatus 110. As shown in FIG. 2, the test management device 100 and the test scenario output device 110 include a CPU (Central Processor Unit) 201, a RAM (Random Access Memory) 202 that performs various processes and operations, control of the entire computer, and the like. An external storage device 203 such as an HDD (Hard Disk Drive) for storing programs and data; an output device 205 such as a monitor or a printer; and an interface (for example, BUS) 204 for transmitting and receiving data between the devices. It is a general computer (electronic computer).

  The CPU 201 loads the various programs from the external storage device 203 to the RAM 202 and executes the predetermined programs to realize the above-described processing units. That is, the CPU 201 executes a program loaded in the RAM 202 to thereby execute a test execution log input unit 102, a test execution log storage processing unit 104, a test item correspondence table input unit 106, and a test scenario extraction unit 108 of the test management apparatus 100. And the test scenario output unit 114 of the test scenario output device 110 are embodied as processes. In addition, the test execution log storage unit 103, the test execution log group storage unit 105, and the test item correspondence table storage unit 107 of the test management device 100, and the test item correspondence table storage unit 112 and the test scenario storage unit 113 of the test scenario output device 110. Is realized as a RAM 202 or an external storage device 203 for storing the results of execution processing by the CPU 201.

  The predetermined program may be stored in advance in the external storage device 203, or may be read out as necessary from a portable external storage medium that can be used by a computer via a reader. Alternatively, it may be downloaded as needed from another computer connected to a network that is a communication medium that can be used by the computer or a communication device that uses a carrier wave propagating on the network, and stored in the external storage device 203. May be.

  FIG. 3 is a diagram showing an outline of the operation of the test support system 1 in the first embodiment.

Start Step 301: The test support system 1 repeatedly performs the processing of Step 302 and Step 303 on all test execution logs obtained by software test execution.

  Step 302: The test execution log input unit 102 receives the test execution log input via the input device 206, analyzes the received test execution log, and stores the analysis result in the test execution log storage unit 103.

  Step 303: The test execution log storage processing unit 104 updates the information in the test execution log group storage unit 105 based on the analysis result of the test execution log stored in the test execution log storage unit 103.

  Step 304: Return to Step 301.

  Step 305: The test scenario extraction unit 108 analyzes the test execution log group stored in the test execution log group storage unit 105. The test scenario obtained by the analysis is stored in the test scenario storage unit 113 via a network or an external storage medium.

  Step 306: The test scenario output unit 114 extracts the instructed test scenario from the test scenario storage unit 113 based on the test scenario output instruction input via the input device 206, and outputs it to the output device 205.

4A and 4B show the test execution log storage processing 420 by the test execution log input unit 102 and the test execution log group storage processing 421 by the test execution log storage processing unit 104 in the first embodiment. It is a figure which shows a flow. Through this process, a label indicating a state or transition is assigned to each test execution log, and a plurality of test execution logs having the same contents are merged and stored in the test execution log group storage unit 105. By assigning a label indicating a state or transition to each test execution log, the test execution log can be converted into a graph format composed of states and transitions.

start
[Test execution log storage processing 420 (steps 401 to 404)]
Step 401: The test execution log input unit 102 acquires the test execution log input by the user via the user interface 101.

  Step 402: The test execution lob input unit 102 performs the analysis process of step 403 on all the records in the test execution log received in step 401.

  Step 403: As shown in the test execution log 500 of FIG. 5, the test execution log is output in the format of “test log generation date (YYYYMMDD HHmm) test target device name / function processing content”. Therefore, the test execution lob input unit 102 analyzes the format of the test execution log, and divides the information of each record into test log generation date, test target device name / function, and unit of processing content. Then, the test execution lob input unit 102 gives each record a log ID that uniquely identifies each record, and a label indicating a state or transition based on the contents of the record. The device / function and processing content obtained as a result of dividing the test execution log are stored in the test execution log storage unit 103. FIG. 5 shows an execution log before labeling and an execution log after labeling.

  Step 404: Return to Step 402. When the process of step 403 is performed on all the records in the test execution log, the process proceeds to step 405.

[Test execution log group storage processing 421 (steps 405 to 414)]
Step 405: The test execution log storage processing unit 104 refers to the test execution log (after labeling) 501 of the test execution log storage unit 103, and performs steps 406 to 408 for all records whose labels indicate “state”. Process.

  Step 406: The test execution log storage processing unit 104 searches the test execution log (after label assignment) 501 for a record whose label 512 is “state”.

  Step 407: As a result of the search, if there is a record having the same information as the searched record in the test execution log management table 600, the process proceeds to step 409. Otherwise, the process proceeds to step 408.

Step 408: The test execution log storage processing unit 104 stores the information of the record stored in the test execution log (after label assignment) 501 in the test execution log management table 600 and sets the log ID of the record in the state management table 610. Stored in the execution log 612 of
A status ID for uniquely identifying the “status” is assigned to the log, and this is stored in the status ID 611 of the corresponding record. If the content 501 of the test execution log (after label assignment) 501 is “START” indicating the start of the test, or “FALSE” or “END” indicating the end of the test, “START” or “FALSE” is displayed. Alternatively, information indicating “END” is stored in the flag 613 of the corresponding record in the state management table 610.

  Step 409: Return to step 405.

  Step 410: The test execution log storage processing unit 104 refers to the test execution log (after label assignment) 501 of the test execution log storage unit 103, and performs steps 411 to 413 for all the records whose label indicates “transition”. Process.

  Step 411: The test execution log storage processing unit 104 searches the test execution log (after label assignment) 501 for a record whose label 512 is “transition”.

  Step 412: As a result of the search, if there is a record having the same information as the searched record, the process proceeds to step 414, and if it does not exist, the process proceeds to step 413.

  Step 413: The test execution log storage processing unit 104 stores the information of the record stored in the test execution log (after label assignment) 501 in the test execution log management table 600 and the state ID 611 corresponding to the log ID of the record. Are extracted from the state management table 610, and the extracted state ID and transition ID are stored in the transition management table 620.

  Step 414: Return to step 410.

End In step 401, for example, when the execution logs output from a plurality of devices such as a server and a client are input as separate files, the test execution log input unit 102 Based on the time information, etc., the records in the test execution log are arranged in time series and are combined into one test execution log.

  In addition, when generating a log at the time of a test execution in a test target apparatus that outputs a log, information that indicates whether it is in a state or a transition is given in advance to each log record. The test execution log input unit 102 may label each log record using this information. In addition, a correspondence table that describes whether the output content of the test execution log corresponds to a state or a transition is created in advance, and the test execution log input unit 102 uses this correspondence table for each log record. A label may be given. Also, the test start state is not necessarily one, such as when the initial value at the time of test execution is different.

  FIG. 5 is a diagram illustrating an example of the test execution log 500 input from the user via the user interface and the test execution log 501 after labeling stored in the test execution log storage unit 103.

  The test execution log is a log generated when the user (tester) operates the test target device or the system. For example, the user's screen operation, the system operation log, the memory state of the system, etc. It is a log that can be used for item confirmation. A test execution log 500 shown in FIG. 5 shows an example of a user's screen operation log. As shown in FIG. 5, each record of the test execution log 500 includes a log generation date, a test target device name / function, and a processing content. The test target device name represents the name of the test target device or test target system that is the log generation source, and the function represents a function for generating a test log in the test target device or test target system.

  In the test execution log 500, information indicating the state at the start and end of the test execution is described. For example, START indicates that the test execution has started, and END indicates that the test has been successful and the test has been completed. Although not shown, FALSE represents that the test failed due to an implementation error of the test target apparatus (or system) or an error in the test execution procedure. Information indicating the state at the start and end of the test may be given to each test execution log at the time of test execution, or given to each test execution log when the test execution log is input via the user interface 101. May be.

  The test execution log 500 may be created separately by a plurality of devices in the system or by each function in the device. In such a case, the log generation time is described in each record, and each record is stored in the test execution log storage unit 103 in chronological order, so that logs created by a plurality of devices or functions can be stored. Save in the same execution order as the test execution order. Alternatively, when the order of execution is clear, such as when function B is executed after function A due to the operation of the system, the output function and device name are described in each record, so that the records are time-series. You may make it arrange in order.

  The test execution log (after label assignment) 501 is a result of analyzing each record of the test execution log 500 by the test execution log input unit 102, giving a label and a log ID to the analysis result, and storing them in the test execution log storage unit 103. Indicates. As shown in FIG. 5, the test execution log (after label assignment) 501 includes a log ID 510 for uniquely identifying each record of the test execution log, a device / function 511 that is a log generation source, and the log It is composed of a label 512 indicating whether the content is a state or a transition, and a content 513 indicating the actual log content.

  The device / function 511 stores the name or identifier of the test target device or function that is the log generation source. For example, in the test execution log (after label assignment) 501, the log with the log ID “L2” is a log generated by the function “F1” of “device A”. When there is only one test target device or function, or when the test target device or function can be confirmed from the log contents, the device / function 511 is logged as a test execution log (after label assignment) 501. It does not have to be a component of the record.

  As described above, the test execution log 500 is output in the format of “test log generation date (YYYYMMDD HHmm) test target device name / function processing content”. Therefore, when converting the test execution log 500 to the test execution log (after labeling) 501, the test execution log input unit 102 analyzes the format of the test execution log 500, and generates the test log information from each record. Divide into units of date, test target device name / function, and processing content. Then, the test execution log input unit 102 assigns to each record a log ID that uniquely identifies each record, a label indicating a state or transition, and the assigned log ID, label, and test execution log. The device / function and the processing content obtained as a result of dividing 500 are stored in the log ID 510, the label 512, the device / function 511, and the content 513, respectively.

  The “state” of the label 512 represents the operation state of the test target system during the test execution, such as a screen transition such as a login screen or a top menu screen, a system operation mode, or a processing state. For "state", input the login name and password on the login screen, click the login button to indicate login completion, transition between states such as transition between system operation modes and processing flow, and It represents events such as processing and operations in the transition.

  In the test execution log (after label assignment) 501 illustrated in FIG. 5, status labels are displayed for logs indicating that the screen has moved to the next screen, such as “Open Window: Login Window” and “Update Window: Top menu”. Has been granted. These output the test execution log so that it can be identified as either state or transition, or prepare a correspondence table that defines whether to classify the state or transition for each log generated in advance In addition, it is only necessary to label each record of the test execution log by referring to this correspondence table. Note that the test execution log (after label assignment) 501 shows a test execution log in the case of a test failure due to a software implementation error, etc., or a test execution procedure error such as a re-login due to an incorrect password input. Alternatively, a test execution log with a redundant work procedure or a test execution log when the test itself fails due to an error in the work procedure may be stored. The test execution log (after label assignment) 501 only needs to know the test execution order and the execution contents. Therefore, in the example shown in FIG. 5, information unnecessary for future analysis, such as time information, is deleted. When the time information is included in the test execution log (after label assignment) 501, the time taken for each state or transition is calculated from the time information and stored in accordance with the test execution log (after label assignment) 501. You may do it. By storing such additional information, it is possible to extract a test scenario in consideration of an execution time related to test execution in a test scenario extraction process described later.

  The above processing is executed for each record of all test execution logs 500 in the test execution log storage processing 420 in FIG. 4A, so that all logs obtained at the time of test execution are executed together with labels. Stored in the log storage unit 103.

  FIG. 6 is a diagram illustrating an example of the configuration of the test execution log group storage unit 105. As shown in FIG. 6, the test execution log group storage unit 105 includes a test execution log management table 600, a state management table 610, and a transition management table 620. Similar to the configuration of the test execution log (after label assignment) 501, the test execution log management table 600 includes a log ID 601 for uniquely identifying a log, a device / function 602 indicating a log generation source, a label 603, and Contents 604 representing the contents of the log. A plurality of test execution logs having the same contents are merged by the test execution log storage processing unit 104 and stored in the test execution log management table 600. That is, if it is determined that the record having the same information as the search record is “present” by the processing of step 407 and step 412 in FIG. 4B, the information of this record is not stored in the test execution log management table 600. . Note that the device / function 602 does not necessarily have to be a component of the test execution log management table 600 when there is only one target device or function or when it can be confirmed from the log. Similarly to the test execution log (after label assignment) 501, the test execution log management table 600 has a test execution log in the case of a test failure due to a software implementation error or the like, or a re-login due to an incorrect password input. For example, a test execution log in which the work procedure becomes redundant due to an error in the test execution procedure, or a test execution log when the test itself fails due to an error in the work procedure may be stored.

  The state management table 610 further includes a state ID 611 for uniquely identifying the execution log whose label 512 indicates “state”, an execution log 612 indicating the ID 612 of the execution log corresponding to the state, and a test. It is comprised from the flag 613 showing the start and completion | finish state of.

  The transition management table 620 represents a transition ID 621 that uniquely identifies the transition of the execution log, a start 622 that represents the start state ID of the transition, an end 623 that represents the end state ID of the transition, and the corresponding execution log. It consists of an execution log 624.

  Such a test execution log management table 600, state management table 610, and transition management table 620 are shown in FIG. 4 by the test execution log storage processing unit 104 based on the information of the test execution log (after label assignment) 501. It is created by performing the test execution log group storage processing 421 from step 405 to step 414.

  Hereinafter, the information storage processing in the test execution log management table 600 and the state management table 610 in the processing from step 405 to step 409 in FIG. 4 will be described with reference to FIGS.

  First, in step 406, the test execution log storage processing unit 104 searches the test execution log (after label assignment) 501 for a record whose label 512 is “state”. When there is a record having the same information as the retrieved record (“Yes” in step 407), the test execution log storage processing unit 104 proceeds to step 409. On the other hand, when there is no record having the same information as the retrieved record in the test execution log management table 600 (“No” in step 407), in the next step 408, the test execution log storage processing unit 104 The information of the record stored in the test execution log (after label assignment) 501 is stored in the test execution log management table 600, and the log ID of the record is stored in the execution log 612 of the state management table 610. Further, a state ID representing “state” is further assigned and stored in the state ID 611. Note that if the contents 501 of the target test execution log (after label assignment) 501 is “START” indicating test start, or “FALSE” or “END” indicating test end, the test execution log is stored. The processing unit 104 stores information indicating “START”, “FALSE”, or “END” in the flag 613 based on the state.

  Next, information storage processing in the test execution log management table 600 and the transition management table 620 in the processing from step 410 to step 414 in FIG. 4 will be described using FIG. 5 and FIG. It should be noted that “→” described below represents the log generation order.

  First, in step 410, the test execution log storage processing unit 104 searches the test execution log (after label assignment) 501 for a record in which the label 512 is “state”, and starts from the “state” (referred to as the start state). A record group (called a transition execution log) having a label 512 of “transition” existing until “state” (called an end state) is extracted. The test execution log storage processing unit 104 performs information storage processing in the execution log management table 600 and the transition management table 620 in steps 411 to 413. If there is no transition execution log in the process of extracting the transition execution log between the start state and the end state described above, the process without the transition execution log is set to “empty” and the processing from step 411 to step 413 is performed. .

  The above processing will be described using a specific example. For example, in the example shown in FIGS. 5 and 6, the test execution log storage processing unit 104 creates the transition management table 620 as follows. First, in step 410, the test execution log storage processing unit 104 starts analysis in order from the first record (record ID 510 is L1) of the test execution log (after label assignment) 501. In step 411, the test execution log storage processing unit 104 further searches the log ID 510 “L1” as the start state from the first record of the test execution log (after label assignment) 501, and sets the log ID 510 as the end state. Specifies a record of “L2”. Next, the test execution log storage processing unit 104 extracts a log between “L1” and “L2”. Here, since there is no log between “L1” and “L2”, the transition execution log is “empty”. Further, in the process of step 413, the test execution log storage processing unit 104 refers to the execution log 612 of the state management table 610 and extracts the state IDs 611 (“S1” and “S2”) of “L1” and “L2”. To do. Then, the test execution log storage processing unit 104 refers to the start 622 and end 623 of the transition management table 620 and the execution log 624, and the extracted state IDs are “S1” and “S2” and “ Check for “empty” records. When the record does not exist (“No” in Step 412), the test execution log storage processing unit 104 replaces “S1” and “S2” with the start 622 and end 623 of the transition management table 620 in Step 413, respectively. And “E1” that uniquely identifies the record is assigned as the transition ID, and the assigned “E1” is stored in the transition ID 621. Here, since the transition execution log is “empty”, no information is stored in the execution log 624.

  After the processing of step 413, the test execution log storage processing unit 104 returns to step 410. In the same manner as described above, in the processing of step 411, the test execution log storage processing unit 104 searches the test execution log (after label assignment) 501, the log ID is “L2” as the next start state, and the log as the end state. As the transition execution log with ID “L6”, “L3 → L4 → L5” between “L2” and “L6” is extracted. Next, the test execution log storage processing unit 104 refers to the execution log 612 of the state management table 610 and extracts the state IDs 611 (“S2” and “S3”) of “L2” and “L6”. Then, the test execution log storage processing unit 104 refers to the start 622 and end 623 of the transition management table 620 and the execution log 624, and the extracted state IDs “S2” and “S3” and the transition execution log of the state are “L3”. The presence or absence of the record “→ L4 → L5” is confirmed. When the record does not exist (“No” in Step 412), the test execution log storage processing unit 104 replaces “S2” and “S3” with the start 622 and the end 623 of the transition management table 620 in Step 413, respectively. The above-mentioned “L3 → L4 → L5” is stored in the execution log 624, “E2” uniquely identifying the record is assigned as the transition ID, and the assigned “E2” is stored in the transition ID 621 (step 413). As described above, the transition management table 620 is created.

  FIG. 7 is a diagram illustrating an example of the configuration of the test item correspondence table 700 stored in the test item correspondence table storage unit 107. The test item correspondence table 700 includes a test ID 701 for uniquely identifying a test item, a test item 702 that represents the content of the test item, and a target log 703 that represents a log used for checking the test item 702.

  The target log 703 stores one or more corresponding logs for specifying the corresponding test item 702. For example, the target log 703 for confirming that the test item 702 “regular user can log in” with the test ID 701 “T1” includes two logs “Open Window: Login Window” and “Open Dialog: Login Successed”. Stored. In such a case, when the log “Open Dialog: Login Succeed” is output after the log “Open Window: Login Window” is output, it is determined that the test item “regular user can log in” is digested. To do.

  In FIG. 7, in the target log 703, “→” represents a plurality of logs. However, for example, an “OR” format in which one of the two logs is output regardless of the order relationship, or both are output. May be stored in a “AND” format or a combination of these. By extending the description in the target log column, it is possible to determine whether or not various test items can be digested.

  Further, the target log 703 has a format that can be searched by the complete matching of the character strings in the test execution log 500 shown in FIG. 5, but the pattern matching such as a regular expression is performed instead of the complete matching of the character strings. It may be used. Alternatively, when the test target device (or system) generates a test execution log, a log type is determined for each function and processing content, and only the log type is stored in the test item correspondence table 700. Also good.

  Next, an outline of the registration process in the test scenario storage unit 113 in the test scenario extraction unit 108 will be described with reference to FIG.

Start Step 801: Repeat until all test execution paths (path from the start to the end of the test) are obtained.

[Scenario Extraction Processing 820 from Test Execution Log (Steps 802 to 810)]
Step 802: The test scenario extraction unit 108 searches the state management table 610 and extracts a state having a START flag.

  Step 803: The test scenario extraction unit 108 performs the processing from Steps 804 to 810 until the End flag is reached.

  Step 804: The test scenario extraction unit 108 searches the transition management table 620 and extracts a transition whose start 622 matches the log ID of the target state.

  Step 805: The test scenario extraction unit 108 performs the processing from steps 806 to 810 for all the extracted transitions.

  Step 806: The test scenario extraction unit 108 acquires the log ID of the transition destination state from the end 623 of the target transition in the state management table 620.

  Step 807: The test scenario extraction unit 108 acquires a state having the log ID acquired in Step 806 in the execution log column 612 from the state management table 610, and confirms the content of the flag 613. The test scenario extraction unit 108 proceeds to Step 810 when “FALSE” is described in the flag 613, and proceeds to Step 808 otherwise.

  Step 808: The test scenario extraction unit 108 adds the extracted transition and state to the path.

  Step 809: The test scenario extraction unit 108 updates the analysis target state to the state described in the transition end 623.

  Step 810: Return to step 805.

  Step 811: Return to Step 803.

  Step 812: The test scenario extraction unit 108 follows a path (test path) from the extracted START to END, and stores the registered transition, the state related to the registered transition, and the corresponding record in the test scenario storage unit 113. Register with.

  Step 813: The test scenario extraction unit 108 refers to the test item correspondence table storage unit 112 and extracts test items that can be digested by the path.

Step 814: Returning to Step 801 Step 815: The test scenario extraction unit 108 extracts a set of test scenarios from which all test items can be digested from the obtained test scenarios.

End Through the above processing, one or more test scenarios that cover all test items that can be digested by all test execution logs are generated.

  In the processing of step 802, the test scenario extraction unit 108 analyzes information in the state management table 610 and searches for a state in which the flag column 613 is “START”. For example, in the state management table 613 in FIG. 6, the test scenario extraction unit 108 extracts the state ID “S1” as a record in which “START” is described in the flag column 613.

  Next, in step 804, the test scenario extraction unit 108 searches the transition management table 620, and extracts all records in which the state ID matches the state ID obtained by the above processing at start 622. For example, for the state with the state ID “S1”, the transition with the transition ID “E1” is extracted. Note that FIG. 6 illustrates only a part of the transition, so that only “E1” is extracted, but all transitions in which the state ID “S1” is described in the start column 622 are extracted.

  Next, in step 806, the test scenario extraction unit 108 refers to the end 623 of the extracted transition, refers to the state ID column 611 of the state management table 610, and extracts a corresponding state. For example, for the transition with the transition ID “E1”, since the state ID “S2” is described in the end 623, the state with the state ID “S2” is extracted from the state management table 610.

  Further, in step 807, the test scenario extraction unit 108 refers to the flag 613 in the extracted state, and when “FALSE” is described, the process proceeds to step 810 and the path search is terminated. This is because, when “FALSE” is written in the flag 613, the test execution indicates that the test execution has failed due to a procedure error or a software implementation error. This is to prevent extraction.

  On the other hand, if “FALSE” is not described in the flag 613 in step 807, the test scenario extraction unit 108 proceeds to step 808 and adds the obtained transition to the path. In the above example, the record with the state ID 611 “S2” in the state management table 610 is not described in the flag 613, so the state “S1”, the transition “E1”, and the state “S2” are added to the path. The test scenario extraction unit 108 further moves to the state “S2” (step 809), and returns to step 803, so that “END” is described in the flag 613 of the state management table 610 until the above-described step 804 to step 808. Perform the process.

  State obtained by repeating the above process from the start of the test (a state where “START” is described in the flag 613 of the state management table 610) to the end of the test (a state where “END” is described in the flag 613 of the state management table 610) The states and transitions obtained up to this point are registered as test execution paths (step 812). For example, in the above example, states and transitions such as S1 → E1 → S2 →... Are extracted and registered as execution paths.

  Next, the test scenario extraction unit 108 refers to the test item correspondence table 700 for the extracted test execution path, and extracts digestible test items for the extracted path.

  For this purpose, the test item correspondence table 700 stored in the test item correspondence table storage unit 107 of FIG. 7 may be used as follows.

  First, the extracted test execution path is configured as sequential data of a state ID and a transition ID. Therefore, the test scenario extraction unit 108 refers to the execution log 612 of the state management table 610 and the execution log 624 of the transition management table 620 based on the state ID and transition ID in the test execution path, and the corresponding log ID. To extract.

  The test scenario extraction unit 108 refers to the log ID 601 of the test execution log management table 600, searches for a corresponding test execution log record from the extracted log ID, and refers to the content 604 of the retrieved record. Regenerate the test execution log corresponding to the test execution path.

  The test scenario extraction unit 108 uses the regenerated test execution log to test each test item in the regenerated test execution log from the contents of the target log 703 for each test item in the test item correspondence table 700. Check if digestion is possible. Whether or not each test item can be digested is determined by referring to the target log 703 of the test item correspondence table 700 as described above, whether or not it completely matches the content of the regenerated test execution log, or pattern matching Thus, it can be determined whether or not digestion is possible by confirming whether or not they match. If all the conditions described in the target log column 700 are satisfied (logs match), digestion is possible.

  The obtained result may be managed as a set of a list of scenario IDs 901, scenarios 902, and digestible test items 903 as shown in the test scenario management table 900 of FIG.

  By repeating the above processing in steps 801 to 814 (steps 805 to 810), all test execution paths are extracted from the test execution logs stored in the test execution log group storage unit 105, and the extracted tests Digestible test items are extracted for each execution path.

  Next, in step 815, the test scenario extraction unit 108 extracts a combination of test scenarios that cover digestible test items using the extracted test execution path as a test scenario.

  Here, in the test scenario extraction in step 815, for example, test items that can be digested for each test scenario generated up to step 814 are checked. Next, digestible test items are confirmed for all combinations of test scenarios generated up to step 814, and a test scenario set covering digestible test items is output.

  At this time, if there are multiple test scenario sets that cover digestible test items, the test scenario set that minimizes the number of test scenarios is output, or the state within the test scenario, or The total number of transitions may be calculated, and a set of test scenarios that minimizes the total value may be output. Alternatively, when the test execution log (after labeling) 500 is created, if the cost related to test execution (test execution time) is saved, the execution time of each test scenario is calculated and the execution time is calculated. A set of minimum test scenarios may be generated.

  As described above, in order to perform the test as efficiently as possible using the generated test scenario, the cost of the test scenario (scenario) is output when a set of test scenarios covering digestible test items is output. It is desirable to reduce the number and execution time.

  FIG. 13 is a diagram illustrating an example of a process for outputting a set of test scenarios for digesting all test items in the test scenario extraction unit 104.

Start Step 1301: The test scenario extraction unit 104 stores all the extracted test scenarios as test scenario candidates.

  Step 1302: The test scenario extraction unit 104 refers to the test item correspondence table 700 and stores all test items as undigested test items.

  Step 1303: The test scenario extraction unit 104 performs the processing from step 1304 to step 1306 until the undigested test item becomes empty.

  Step 1304: The test scenario extraction unit 104 extracts a test scenario including the largest number of undigested test items among all test scenarios stored as test scenario candidates.

  Step 1305: The test scenario extraction unit 104 registers the test scenario extracted in step 1304 in the output test scenario and deletes it from the test scenario candidate.

  Step 1306: The test scenario extraction unit 104 deletes the test items corresponding to the test scenario extracted in step 1304 from the undigested test items.

Step 1307: Return to Step 1303 Step 1308: In Step 1305, the test scenario extraction unit 104 outputs the output test scenario as a set of test scenarios that can be digested by all test items.

End The scenario extraction process 820 from the test execution log provides a correspondence between test execution paths and test items that can be digested by each test execution path. In step 1301, the test scenario extraction unit 104 stores the test execution path and digestible test items obtained up to step 814 as test scenario candidates. In step 1302, the test scenario extraction unit 104 stores all test items as undigested test items. Step 1301 and step 1302 correspond to the initialization processing from step 1303 to step 1307.

  Steps 1303 to 1307 are main processes for outputting a set of test scenarios that can digest all test items. In steps 1304 to 1306, the test scenario extraction unit 104 extracts test items that digest most undigested test items from the test scenario candidates (step 1304), and adds the extracted test scenarios to the output result. Along with (Step 1305), the test scenario candidate and the corresponding test item are deleted from the undigested test item (Step 1305 and Step 1306). Then, the test scenario extraction unit 104 repeatedly performs the processing from step 1304 to step 1306 until there are no undigested test items, that is, until all test items can be digested.

  By the processing in step 1304, the test scenario that can digest the most digestible test items is selected from the test scenario candidates, so that the number of output test scenarios can be reduced.

  In step 1304, if all test scenario candidates do not include undigested test items, the processing may be interrupted. This occurs when all the test items stored in the test item correspondence table 700 cannot be digested in the test scenario obtained up to step 814.

  In step 1304, when there are a plurality of test scenarios that maximize the number of test items that can be digested, one of them is selected at random, or the test cost of the test scenario is referred to, and the test is performed. A test scenario with a low scenario execution cost may be selected.

  The above processing is an example for realizing Step 814, and the actual processing may be different from the above.

  In the description of step 815 described above, an example of processing for outputting a set of test scenarios that is the minimum for all combinations of extracted test scenarios has been described. However, the processing may be different from the processing described above. In the above description, step 815 is performed after the scenario extraction process 820 from the test execution log. However, in the scenario extraction process 820 from the test scenario execution log, the digestible test items are estimated and the test scenario is directly selected. You may make it extract.

  Further, in the above description, the process of step 815 has been described as the process performed in the test scenario extraction unit 108, but the process up to step 813 may be the process of the test scenario extraction processing unit 109. In this case, the process of step 814 is performed as the process of the test scenario output unit 114.

Step 801 in FIG. 8 is repeated until all test execution paths are obtained. However, when there are many test execution paths to be generated, it may take time to process the test scenario. In such a case, for example, a test execution path may be extracted until a certain number of test items can be digested or until a specific test item can be digested in advance.
Alternatively, the upper limit of the number of test scenarios to be generated may be determined in advance, and test execution paths may be extracted until the generated test scenarios reach the upper limit.

  In order to check digestible test items in each test execution path, the contents of the target log 703 in the test item correspondence table 700 are referred to, and the test execution path is determined from the contents described in the target log. What is necessary is just to judge by comparing with the content of the test execution log linked | related with each state and transition.

  In the test scenario extraction process 820 in FIG. 8, the test execution log stored in the test execution log group storage unit 105 can be managed in a graph format by the state management table 610 and the transition management table 620. It is also possible to use an algorithm for solving a route search or a set covering problem.

  FIG. 9 is a diagram illustrating an example of the configuration of the test scenario management table 900 stored in the test scenario storage unit 113. As shown in FIG. 9, the test scenario management table 900 includes a scenario ID 901 for uniquely specifying a test scenario, a scenario 902 that represents a test scenario, and a test item column 903 that represents a digestible test item. Yes.

  Similarly to the test execution log (after labeling) 501, the test scenario record management table 910 represents a log ID 911, a log generation source device, and a function for uniquely identifying each record of the corresponding test execution log. It is composed of a device / function 912, a label 913 representing any type of state and transition, and a log content 914. Note that the device / function 912 does not necessarily have to be a component of the test scenario record management table 910 when there is only one target device or function or when it can be confirmed from the log.

  The test scenario 902 shown in FIG. 9 stores the result obtained from the test scenario extraction process 820 shown in FIG.

  As shown in FIG. 9, in the test scenario management table 900, test items that can be digested for each test scenario are stored in the test items 903. Thus, for example, by specifying a test item that affects the redevelopment of software or a test item to be re-tested, it is possible to extract a test scenario including the target test item.

  FIG. 10 shows an example of a test scenario generated by the process of FIG. 10 is a part of the test scenario in which the scenario ID 901 in the test scenario management table 900 of FIG. 9 is P1, and the test scenario record is in accordance with the order of the log IDs described in the scenario 902. A test scenario is configured by referring to the log ID 911 of the management table 910 and connecting the contents of the content column 914 having the matching log ID.

  Information stored in FIGS. 9 and 10 from the output result of FIG. 8 will be described below.

  In the following, as one of the output results of FIG. 8, a case where a test execution path of “S1” → “E1” → “S2” → “E2” → “S3” →. (See FIG. 6 for ID and transition ID).

  At this time, by referring to the state ID 611 and the execution log 612 of the state management table 610 in FIG. 6, “L1” is obtained for S1, “L2” is obtained from “S2”, and “L6” is obtained from “S3”. Similarly, “L3 → L4 → L5” is obtained for “E2” by referring to the transition ID 621 and the execution log 624 of the transition table 620 (the execution log 624 is blank for “E1”. No logs are available). The above results are arranged according to the test execution path as follows.

・ S1: L1
・ E1:
・ S2: L2
E2: L3 → L4 → L5
・ S3: L6
:
From the above, if only the execution log is extracted, “L1 → L2 → L3 → L4 → L5 → L6 →...” Stored in the scenario 902 of the test scenario management table 900 is obtained.

  Further, by referring to the test scenario record management table 910 and referring to the contents 914 for each log ID (L1, L2, L3, L4, L5, L6,...) Of the above test scenario, the following is obtained. .

L1: START
L2: Open Window: Login Window
L3: Input Text “user01” in “ID”
L4: Input Text “user01” in “Password”
L5: Click: OK
L6: Open Dialog: Login Successed
:
From the above, by outputting only the content 914, the test scenario 1000 shown in FIG. 10 is obtained.

  In the test scenario 1000 illustrated in FIG. 10, only the content 914 is output to the test scenario, but the content of the device / function 912 may be output together.

  Further, although the content of the content 914 is output as it is as a test scenario, when it is output to the test scenario 1000, it may be converted and output so that the user can easily see it. For example, in the content 914 with the log ID 911 “L4”, “Input Text“ User01 ”in“ Password ”” is described, and this is entered as “Enter“ User01 ”in the“ Password ”column”. You may convert and output. For such conversion, a conversion table that defines a conversion method is prepared for each execution log in advance, and when the test scenario 1000 is output, the content 914 may be converted and output based on the content of the conversion table. .

  The above conversion may be shaped into a format that can be read by the test automatic execution program, instead of being shaped easily by the user. As a result, when the retest is performed, the test operation can be automated by the test automatic execution program.

  Further, when the test data can be separated when the test execution log is output, these values may be output as variable variables. For example, in the test scenario 1000 of FIG. 10, “user01” on the fourth line is an input by the user, and “UserId” is an ID representing a component on the screen.

  At this time, by generating a test execution log so that it can be understood that it is a variable such as “% USER_NAME%”, such as “user01”, “user01”, a portion corresponding to the test data can be tested when creating a test scenario. It may be used by replacing it at the time of execution. Such an operation is effective when, for example, the test scenario is generated as an execution script and the test execution is performed by arbitrarily replacing a portion corresponding to the test data when performing the test execution.

  In FIG. 10, only the test execution contents are output. Based on the test ID described in the test item 903, the test item correspondence table 700 is referred to and a list of test items that can be confirmed for each test scenario. Alternatively, the confirmation location of the test item may be output together with the test scenario.

  FIG. 12 is a diagram illustrating an example of a configuration of a GUI (Graphical User Interface) of the user interface 111 provided by the test scenario output unit 114.

  The GUI shown in FIG. 12 includes a common menu area 1201 including files, settings, and help, a test item list area 1202 that displays a test item list, a test scenario list area 1203 that displays a list of test scenarios, and a test Each display area includes a test scenario area 1204 for displaying a scenario.

  Each display area includes an operation menu for the test item list (test item list operation menu 1210), an operation menu for the test scenario list (test scenario list operation menu 1211), and an operation menu for the test scenario (test scenario operation menu). 1212) each menu area.

  The file menu in the common menu area 1201 is used, for example, when the test scenario output device 110 has the test scenario storage unit 113 for a plurality of test target systems and identifies the corresponding test scenario storage unit 113. Alternatively, when there are a plurality of test scenario sets to be subjected to test scenario extraction such as different test viewpoints, this is used when only the target test scenario set is specified.

  The setting menu is a menu for changing the display contents in each area and setting the format when outputting the test scenario to a file. Help includes explanations on how to use the software and copyright. This is a menu for displaying.

  Next, the test item list area 1202 is an area for displaying a list of test IDs 701 and test items 702 from the test item correspondence table 700. Here, the check column in the test item list area 1202 is a column for checking a test item that has been digested as a result of analysis of the test execution log. As a result, for example, it can be used to confirm undigested test items of the tool during the test process.

  The test item list operation menu 1210 includes an operation menu related to the test item list area 1202. The test item confirmation menu shown in FIG. 12 displays the contents of the corresponding target log 703 in a dialog when there is a test item being selected. In addition, the checked item confirmation menu and the unchecked item confirmation menu are the results of analysis of the test execution log, test items that can be digested (that is, test items described in the check column), and untested test items. This is a menu for displaying in the test item list area 1202 only (that is, test items whose “re” is not described in the check column).

  The related scenario display menu is a menu for highlighting the test scenario list including the test item being selected in the test item list area 1202 in the test scenario list area 1203. This can be done as follows.

  First, referring to the test scenario management table 900, a test scenario including the test ID of the test item being selected is extracted. Then, based on the scenario ID 901 of the extracted test scenario, the selected test item is included by displaying the ruled line of the corresponding test scenario in the test scenario list 1203 in a thick frame or changing the background color. Highlight the test scenario.

  Next, the test scenario list area 1203 is an area for displaying a list of test scenarios stored in the test scenario management table 900. The test scenario list area 1203 includes a check column, a valid column, and a comment column, in addition to a test item that describes a scenario ID that uniquely identifies a scenario and a test item ID that can be digested by the scenario.

  The scenario ID column and the test item column acquire the scenario ID 901 and the test item 903 from the test scenario management table 900 and display them.

  The comment column is a column for accepting input from the user and adding comments such as test execution contents and points to be noted to each test scenario. The check column is a column for inputting whether or not the test scenario has been executed, and the valid column is a column for inputting a determination result as to whether or not the generated test scenario can be used as an actual test scenario. It is.

  In this embodiment, the test scenario is automatically generated from the analysis result of the test execution log. Therefore, for example, when the description of the target log 703 of the test item correspondence table 700 is insufficient, the generated test scenario may not necessarily be an effective test scenario. Therefore, in the example of FIG. 12, an invalid column is provided so that an invalid test scenario can be recognized.

  The test scenario list operation menu 1211, which is a menu for operating the test scenario list area 1203, includes operation menus for scenario display, test item confirmation, and scenario regeneration.

  The scenario display menu is a menu for displaying the selected column in the test scenario list area 1203 in the test scenario display area 1204. The test item confirmation is a test described in the test item for the selected test scenario. This is a menu for displaying a list of test items corresponding to the ID in a dialog or the like.

  The scenario display menu may use the above-described conversion process from FIG. 9 to FIG. 10 for the test scenario being selected. In addition, the confirmation of the test item in the test item confirmation menu may be processed as follows, contrary to the related scenario display described above.

  First, the selected test scenario in the test scenario list area 1203 is extracted, and all test IDs described in the test item column are extracted. Next, the ID in the test item list area 1202 is referred to from the extracted test ID, and the test item that matches the extracted test ID is highlighted by displaying a ruled line in a thick frame or changing the background color. indicate.

  The scenario regeneration menu is a menu for regenerating a test scenario that changes to an invalid test scenario when the above-mentioned valid column is unchecked, that is, when there is an invalid test scenario. In order to perform this processing, all the test scenarios extracted in the test scenario extraction unit 108 may be stored in the test scenario storage unit 113.

  Alternatively, the test scenario extraction unit 108 and the test execution log group storage unit 105 may be included in the test scenario output device 110, or the test management device 100 and the test scenario output device 110 may be configured as one device. .

  The test scenario area 1204 is an area for displaying the content of the selected test scenario. The operation menu provided in the test scenario area (test scenario operation menu 1212) includes a scenario output menu for outputting the currently displayed test scenario as a file.

  By selecting the scenario output menu, the displayed test scenario is output to a file, for example, as a test procedure manual or a test automatic execution script. In such an output process, a batch output menu may be provided in the test scenario list operation menu 1211 so that all test scenarios that are currently selected or valid are output.

Note that the GUI described in FIG. 12 is an example of software that implements the present invention, and is not necessarily the GUI described in FIG.
(Second embodiment)

  In the first embodiment, the method for directly storing the test scenario extracted by the test scenario extraction unit 108 in the test scenario storage unit 113 has been described. In the second embodiment, a method for managing the test scenario extracted by the test scenario extraction unit 108 by dividing it into states and transitions as in the test execution log group storage unit 105 will be described. Thereby, when the test scenario output unit 114 in the test scenario output apparatus 110 generates the test scenario 1000, the test scenario can be reconfigured.

  FIG. 11 is a diagram illustrating an example of the configuration of the test scenario storage unit 113 in the second embodiment. The test scenario storage unit 113 in the second embodiment includes a test scenario record management table 1100, a state management table 1110, a transition management table 1120, and a test item confirmation location management table 1130.

  The test scenario record management table 1100 includes a log ID 1101 for uniquely identifying a corresponding test execution log record, a device / function 1102 for managing a device / function of a log transmission source, and a label for managing any type of state or transition 1103 and contents 1104 for storing the record contents of the test execution log. As in FIG. 9, the device / function 1102 is not necessarily a component of the test scenario record management table 1100 when there is only one target device or function or when it can be confirmed from the log. May be.

  The state management table 1110 includes a state ID 1111 for uniquely identifying a state, an execution log 1112 for storing a corresponding test execution log record, and a flag 1113 for storing a test start state and an end state. Reference numeral 1120 denotes a transition ID 1121 for uniquely storing a transition, a start 1122 for storing a state from which the transition is started, an end 1123 for managing the end state of the transition, and an execution log for storing a record of a corresponding test execution log 1124. Further, the test item confirmation location management table 1130 includes a test ID 1131 for identifying test items that can be digested, and a state for determining whether or not the test items can be digested, or a confirmation for managing transitions. Consists of location 1132.

  This table includes all records of the state management table 610 and the transition management table 620 that exist on the extracted test execution path in the registration process to the test scenario storage unit 113 described in the first embodiment, and Each record in the test execution log management table 600 corresponding to the execution log in the record (execution log 613 of the state management table 610, execution log 624 of the transition management table 620) is expressed as a test scenario management table 1100, a state management table 1110, Then, it may be copied to the transition management table 1120.

  Alternatively, the execution log on the test execution path may be classified again into a state and a transition state, and generated by performing the same processing as in steps 405 to 414.

  The test item confirmation location management table 1130 extracts the target log from the test item correspondence table 700, and refers to the record of the corresponding test execution log from the execution log in the state management table 1110 and the transition management table 1120. It should just be generated by.

  For example, for the test item 702 whose test ID 701 is T1 in the test item correspondence table 700 of FIG. 7 (that the authorized user can log in), the test item confirmation location management table 1130 is created as follows. First, “Open Window: Login Window” and “Open Dialog: Login Successed” are obtained from the target log 703 of the test item correspondence table 700. Next, a log having the same content as the obtained corresponding log is extracted from the content 1104 of the test scenario record management table 1100. In the case of FIG. 11, L2 is extracted for “Open Window: Login Window”, and L6 is extracted for “Open Dialog: Login Successed”. Next, the state management table 1110 and the transition management table 1120 are searched, the state having the extracted log ID in the execution log columns 1112 and 1124, the state ID of the transition, or the transition ID 1121 is extracted, and L2 For S2 and L6, S3 is obtained. Contents obtained by replacing T1 in the test ID 701 column with the test ID column 1131 of the test item confirmation location 1130 and the target log column 703 of the test item correspondence table 700 with the obtained state ID (or transition ID) (S2 → S3) Is registered in the confirmation location column 1132.

  As in the first embodiment, the process of extracting the content column 1104 of the test scenario record management table 1100 from the target log 703 of the test item correspondence table 700 is not only a complete match of the log content but also a regular expression. Simple pattern matching may be used. Further, when a plurality of states or transitions are extracted in the extraction of the state ID and transition ID from the state management table 1110 and the transition management table 1120, all of them are extracted as test item confirmation location management tables. 1130 is registered. For example, in the above, it is assumed that S3 and S10 are extracted for L6. In this case, for example, an OR symbol is used in the confirmation location column 1132 as S2 → (S3 OR S10) →... Indicates that the test item can be digested in any of S3 and S10. What should I do?

  By creating the test item confirmation location management table 1130, it is easy to confirm which test items can be confirmed when generating a test scenario from FIG. This is because when determining whether or not a test item can be digested, the content column 1104 of the test scenario management table 1100 and the target log column 703 of the test item correspondence table 700 are not sequentially confirmed, but the test item confirmation location management is performed. This is because it is possible to determine which test items can be digested by checking only the confirmation location column 1132 of the table 1130 (the test item correspondence table 700 and the test scenario record management table 1100 need not be referred to). As well as log matching / non-matching confirmation processing to confirm the contents column is not required).

  In the first embodiment, the test scenario storage unit 113 stores each test scenario extracted by the test scenario extraction unit 108. In the second embodiment, the extracted test scenarios are classified and stored into states and transitions as in the test execution log group storage unit 105.

  As a result, it is possible to eliminate duplication of states and transitions in each test scenario in the test scenario storage unit 113, and it can be expected to reduce the required data size. Further, by reextracting the test scenario using the state management table 1110 and the transition management table 1120, the test scenario can be easily reconfigured when the test scenario output unit 114 outputs the test scenario.

  For example, among the state IDs in the state management table 1110, the flag 1113 is set in the state management table 1110 using the state management table 1110 and the transition management table 1120 from the label 1113 whose flag 1113 is “START”. A search is performed until “END” is reached, and a test execution path is configured from the extracted states and transitions in the same manner as the processing in steps 803 to 810.

  At this time, a test item is specified as an additional input, and when the test execution path is configured, the test execution path is extracted as a test scenario by passing through the additionally input test item. In this way, it is possible to extract a test scenario related to a test item that needs to be retested when the software is modified.

  In addition, the test execution path may be extracted so as not to include the specified test item for the test item specified as the additional input, contrary to the generation of the test execution path. In this case, for example, it is possible to extract a test scenario in which unnecessary test items are not performed, for example, when a related test item is changed due to software modification.

  In the above description, the screen operation and the screen transition have been described as examples in both the first embodiment and the second embodiment. However, the present invention may be used for tests other than screen tests.

  For example, in the test item correspondence table 700 of the first embodiment, the test item for confirming the screen display item result is exemplified, but the test item for confirming the database and internal processing may be included.

  In addition, for example, in a train route control system, a train travel pattern (diagram) is created and tested on a target route map in order to test control processing of the route control system. At this time, since the test items that can be digested differ depending on the train traveling pattern, the test is performed until all the test items to be digested can be digested by creating a plurality of traveling patterns.

  In this embodiment, the train traveling pattern is regarded as a test scenario, and a test item correspondence table is created by associating test execution logs generated by the route control system with test items. Also good.

  As described above, the present invention may be used to extract a test scenario from a test execution log regardless of screen operations and transitions.

  Although the embodiments of the present invention have been specifically described above, the present invention is not limited to these embodiments, and various modifications can be made without departing from the scope of the present invention. For example, although FIG. 1 illustrates a test support system including two devices, the test management device 100 and the test scenario output device 110, the test management device 100 and the test scenario output device 110 may be realized by a single device. In the above-described embodiment, the case where the test execution log is given by user input has been described as an example. However, the test execution log generated by the test target apparatus or the system is directly input to the test management apparatus 100. The data may be input to the unit 102. Also, for example, if the test target device or system is built on a network, such as in a virtualization or cloud environment, the generated test execution log is automatically sent to the test management device 100. Also good.

  The processing unit may be realized by hardware by designing a part or all of the processing unit, for example, with an integrated circuit. Further, for example, the above-described embodiments have been described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described. Further, a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment. Further, it is possible to add, delete, and replace other configurations for a part of the configuration of each embodiment.

DESCRIPTION OF SYMBOLS 100 ... Test management apparatus 101, 111 ... User interface, 102 ... Test execution log input part, 103 ... Test execution log storage part, 104 ... Test execution log storage process part, 105 * ..Test execution log group storage unit 106... Test item correspondence table input unit 107, 112... Test item correspondence table storage unit 108... Test scenario extraction unit 113. , 114 ... test scenario output unit, 201 ... CPU, 202 ... RAM, 203 ... external storage device, 204 ... interface, 205 ... display device, 206 ... input device.

Claims (8)

A storage unit for storing a test execution log obtained at the time of executing a software test, and association information between the test execution log and a test item;
A test execution log storage processing unit that assigns a label indicating a state or a transition to each record included in the test execution log according to the content of the record;
A test execution log group storage processing unit that merges test execution logs having the same content and stores them in the storage unit, with respect to the test execution log assigned with the label;
A test execution path can be extracted from the merged test execution log by searching a path from the start to the end of the test, and digested based on the extracted test execution path and the association information A test scenario extraction unit that extracts a test scenario including various test items and stores the test scenario in the storage unit;
Having
Test support system characterized by that. The test scenario extraction unit
In the merged test execution log, the test execution path extraction process from the start to the end of the test is repeatedly executed,
Extracting test items that can be digested for each of the extracted test execution paths, extracting the test scenarios that cover digestible test items in the association information, and storing the test scenarios in the storage unit The test support system according to claim 1. The test scenario extraction unit
If there are a plurality of test scenarios covering digestible test items from the test scenarios covering the digestible test items, a test scenario that reduces the test execution time when executing the test is extracted, Store in the storage unit,
The test support system according to claim 2, wherein: Based on the test scenario output instruction, the test scenario output unit further acquires a test scenario from the storage unit and outputs the test scenario.
The test support system according to any one of claims 1 to 3, wherein the test support system is characterized in that: A test support method in a test support system that supports software testing,
The test support system includes a storage unit that stores a test execution log obtained when executing a software test, and association information between the test execution log and a test item,
By the test support system,
For each record included in the test execution log, depending on the content of the record, a label indicating a state or transition is given,
For the test execution log given the label, merge the test execution logs of the same content and store in the storage unit,
A test execution path is extracted by searching a path from the start to the end of the test for the merged test execution log,
Based on the extracted test execution path and the association information, a test scenario including digestible test items is extracted,
Storing the extracted test scenario in the storage unit;
A test support method characterized by that. By the test support system,
In the merged test execution log, the test execution path extraction process from the start to the end of the test is repeatedly executed,
Extracting test items that can be digested for each of the extracted test execution paths, extracting the test scenarios that cover digestible test items in the association information, and storing the test scenarios in the storage unit The test support method according to claim 5. By the test support system,
If there are a plurality of test scenarios covering digestible test items from the test scenarios covering the digestible test items, a test scenario that reduces the test execution time when executing the test is extracted, Store in the storage unit,
The test support method according to claim 6. Based on the output instruction of the test scenario by the test support system, the corresponding test scenario is acquired from the storage unit,
Output,
The test support method according to any one of claims 5 to 7, wherein the test support method is characterized in that:

Images