WO2012066635A1 - テスト方法、テスト装置及びテスト実行用プログラム - Google Patents

テスト方法、テスト装置及びテスト実行用プログラム Download PDF

Info

Publication number
WO2012066635A1
WO2012066635A1 PCT/JP2010/070373 JP2010070373W WO2012066635A1 WO 2012066635 A1 WO2012066635 A1 WO 2012066635A1 JP 2010070373 W JP2010070373 W JP 2010070373W WO 2012066635 A1 WO2012066635 A1 WO 2012066635A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
execution
module
executed
information
Prior art date
Application number
PCT/JP2010/070373
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/JP2010/070373 priority Critical patent/WO2012066635A1/ja
Publication of WO2012066635A1 publication Critical patent/WO2012066635A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management

Definitions

  • the present invention relates to a technique for testing a program in system development.
  • agile development is known as a system development method that can easily cope with environmental changes.
  • a relatively small function is developed in a short period of time called iteration, and a system is developed by repeating a plurality of iterations.
  • One iteration includes processes such as design, implementation (build, programming), and test.
  • an automatic test including a degradation check is executed every time a function is implemented.
  • the automatic test is executed based on a test scenario (test definition information) in which a processing procedure to be executed is defined.
  • test scenario test definition information
  • every time a program is added or modified the content of the test scenario for operation check increases, so that in the case of a large scale system, it takes a lot of time to execute the test. For this reason, there is a demand for a mechanism for performing sufficient tests in a limited time and developing efficiently.
  • Patent Document 1 discloses a technique for holding configuration management information associated with a program changed to a test scenario and selecting and executing a test scenario related to the changed source file name.
  • Patent Document 2 discloses a technique for specifying a test range using a coverage rate and executing a retest using related test data.
  • the present invention aims to shorten the time required for testing and improve the quality of the system by providing a technique for efficiently executing a test in system development.
  • test apparatus which performs the test of the program containing the module which provides a predetermined function
  • the said test apparatus memorize
  • the test is executed by sequentially executing the test definition information based on a plurality of test definition information including a procedure for executing the module, and the test apparatus.
  • a line determination processing unit wherein the execution information processing unit detects a module executed based on the test definition information, and the execution information processing unit The identifier of the detected module is stored in the execution information, and the test scenario execution determination processing unit is updated after the test is executed based on the execution information when the test is re-executed.
  • Test definition information defined to execute the specified module is specified, and the test scenario control processing unit preferentially executes a test based on the specified test definition information.
  • test scenario test definition information
  • module changed program
  • FIG. 1 is a diagram illustrating the configuration of a test apparatus 100 according to the first embodiment of this invention.
  • the test apparatus 100 includes a memory 200, a CPU 300, a storage device 400, an input device 500, and an output device 600.
  • the test apparatus 100 may be a general computer.
  • CPU 300 executes a predetermined process by executing various programs stored in memory 200. Specifically, a test target program 220 described later is executed based on a test scenario 410 described later, or necessary information is collected while the test target program 220 is being executed.
  • the memory 200 is a storage medium that can be accessed at high speed by the CPU 300.
  • the memory 200 may be a volatile storage medium or a non-volatile storage medium.
  • the memory 200 stores a program executed by the CPU 300 and data necessary for executing the program. Specifically, a test execution processing unit 210, a test target program 220, and an operating system 230 are stored as programs executed by the CPU. Details of each program will be described later.
  • the storage device 400 is a nonvolatile storage medium capable of storing a large amount of data.
  • the storage device 400 is, for example, a hard disk drive.
  • the storage device 400 stores a test scenario 410, an execution information file 420, and a test result 430. Further, various programs stored in the memory 200 may be stored and loaded into the memory 200 as necessary.
  • the test scenario 410 stores information necessary for executing tests corresponding to various business processes.
  • the test scenario 410 defines a combination of modules to be executed, an execution order of modules (programs), parameters necessary for executing each module, and the like.
  • test scenario 410 identifiers of modules constituting the test target program 220 are defined together with the execution order.
  • the CPU 300 executes the test execution processing unit 210 and executes the modules defined according to the module execution order defined in the test scenario 410.
  • the input information is also defined in the test scenario 410.
  • the result to be output is also defined. The test result can be determined by comparing the defined output result with the result of actually executing the module.
  • the execution information file 420 stores information collected while a test is being executed based on the test scenario 410.
  • the module called during the execution of the test is specified, and the correspondence between the test scenario 410 and the module is recorded.
  • the correspondence between the test scenario 410 and the module is recorded.
  • the test result 430 stores the test result executed for each test scenario 410.
  • the input device 500 is a device for inputting necessary information to the test device 100. Specifically, a keyboard, a mouse, and the like.
  • the output device 600 is a device for displaying the result of the executed test. Specifically, it is a display device such as a display.
  • the test execution processing unit 210 is a program executed by the CPU 300 in order to execute a test according to the present invention.
  • the test execution processing unit 210 is stored and distributed in various storage media such as a CD-ROM. Further, it may be distributed from a predetermined server via a network.
  • the test execution processing unit 210 executes the test target program 220 based on the test scenario 410. Further, information necessary for test execution is collected and recorded in the execution information 421 described above.
  • test execution processing unit 210 determines the execution order of the test scenarios 410 based on the execution information 421 and the updated test target program 220.
  • the test execution processing unit 210 includes a test target program control processing unit 211, a test scenario control processing unit 212, an execution information processing unit 213, and a test scenario execution determination processing unit 214.
  • the test target program control processing unit 211 executes the test target program 220 instructed to be executed by the test scenario control processing unit 212 described later.
  • the test target program 220 includes a plurality of modules, and the test target program control processing unit 211 controls the test target program 220 in units of modules.
  • the test target program control processing unit 211 also has a debugger function such as collecting execution module information when each module is executed. It is also possible to collect execution module information not only for modules that are instructed to be directly executed but also for modules that are indirectly executed by the module being executed.
  • the test scenario control processing unit 212 specifies a module to be executed based on the test scenario 410 stored in the storage device 400, and sequentially instructs the test target program control processing unit 211 to execute the specified module. If parameters necessary for module execution are defined, the parameters are acquired from the test scenario 410 and transmitted to the test target program control processing unit 211.
  • the execution information processing unit 213 performs a test scenario based on the module execution result by the test target program control processing unit 211 and the parameters (input and output) included in the test scenario 410 input to the test scenario control processing unit 212.
  • the execution information 410 is created. Further, based on the created execution information, the created execution information is output to an execution information table 421 described later, or the data included in the execution information file 420 is updated.
  • the test scenario execution determination processing unit 214 determines whether or not to execute each test scenario 410 based on the execution information table 421 in cooperation with the test target program control processing unit 211 and the test scenario control processing unit 212.
  • the test scenario 410 to be executed with priority is selected. For example, the test scenario 410 for executing the changed module is processed so as to be executed with priority.
  • the test target program 220 is a module to be tested.
  • the test target program 220 includes a plurality of modules (module 1 (221), module 2 (222), module 3 (223),...)).
  • the system according to the present embodiment is configured to implement various functions by combining modules.
  • the test scenario 410 defines a combination of modules to be executed and an execution order, and is defined so that a predetermined function is implemented by executing the module specified in the test scenario 410. ing.
  • the module included in the test target program 220 may be a function unit that processes input data and outputs data, or a functional unit that provides a plurality of functions (for example, an executable file such as an EXE file, a DLL, etc. Etc.). Further, a module (command) for outputting processing detailed execution information to a source file of each module may be added to create (build) a module, and more detailed execution information may be acquired.
  • a module (command) for outputting processing detailed execution information to a source file of each module may be added to create (build) a module, and more detailed execution information may be acquired.
  • the operating system 230 is system software for managing resources (CPU 300 and memory 200) of the test apparatus 100.
  • the test execution processing unit 210 and the test target program 220 are executed in the operating system 230.
  • FIG. 2 is a diagram illustrating an example of the execution information table 421 included in the execution information file 420 according to the first embodiment of this invention.
  • the execution information table 421 stores information collected when a test based on the test scenario 410 is executed as described above.
  • the execution information table 421 stores execution information for each test scenario.
  • the execution information table 421 includes a test scenario name 4211, operation module information 4212, changed resource information 4213, a test execution time 4214, a test execution determination result 4215, and a test execution order 4216.
  • Test scenario name 4211 is the name of the test scenario 410 to be executed.
  • the operation module information 4212 stores information indicating the configuration of the module executed in the test scenario 410.
  • a separate table including the module name and the number of references referred to in the test scenario 410 is created in another region, and a pointer to the created separate table is stored in the operation module information 4212.
  • the execution information table 421 may directly hold the module name and the number of references.
  • the modules included in the operation module information include not only modules that are directly instructed to be executed in the test scenario 410 but also modules that are indirectly executed by the executed modules. That is, modules other than those directly defined in the test scenario 410 may be included. Therefore, the number of references also includes the number of modules that are indirectly executed by the executed modules, in addition to the modules that are directly referenced in the test scenario 410.
  • the changed resource information 4213 stores information on resources that are changed by executing the test scenario 410.
  • the list of resource information to be changed is stored in a table created in another area, but the execution information table 421 may directly hold the list.
  • the resource includes, for example, data stored in a database, data stored in the memory 200, data written to a file, and the like.
  • Test execution time 4214 is a time when a test based on the test scenario corresponding to each record is executed. By comparing the time stored in the test execution time 4214 with the time when each module was updated, it is possible to specify the module that has been updated after the test based on the corresponding test scenario is executed.
  • the test execution determination result 4215 stores information indicating whether or not the corresponding test scenario 410 is executed. Specifically, “1” is set when the test scenario 410 is re-executed, and “0” is set when the test is not a target to be re-executed, such as when the operation module is not changed. . In addition, when the test scenario 410 is a target of re-execution but the test is not actually executed (not executed), “ ⁇ 1” is set.
  • the test execution order 4216 is an order in which tests based on the test scenario 410 are executed. For example, when a test based on the test scenario 410 that executes the updated module is executed with priority, it may be set to a value smaller than the value of the test execution order 4216 corresponding to another test scenario.
  • FIG. 3 is a diagram illustrating the relationship between the test scenario 410 and the test target program 220 according to the first embodiment of this invention.
  • test scenario 410 includes two steps, and a module included in the test target program 220 is executed at each step.
  • module 1 (221) is executed in step 1, and module 1 (221) is also executed in step 2.
  • the same function (function) may be executed in step 1 and step 2, in the present embodiment, each module is configured to be able to provide a plurality of functions and can execute another function. .
  • test scenario 2 (410B) module 1 (221) is executed in step 1, and module 2 (222) is executed in step 2.
  • test scenario 3 module 2 (222) is executed in step 1, and module 2 (222) is also executed in step 2.
  • FIG. 4 is a diagram illustrating a procedure for creating the execution information file 420 according to the first embodiment of this invention.
  • FIG. 4 shows a procedure when a new execution information file 420 is created.
  • test execution processing unit 210 Each configuration included in the test execution processing unit 210 is a program executed by the CPU 300, but in order to simplify the description, each configuration will be mainly described.
  • test target program control processing unit 211 reads the test target program 220 into the memory 200. Subsequently, the test scenario control processing unit 212 reads the test scenario 410 and instructs the test target program control processing unit 211 to execute the module corresponding to each step of the test scenario 410 via the execution information processing unit 213.
  • the test target program control processing unit 211 controls to execute the instructed module (test target program 220).
  • the execution information processing unit 213 is notified of the execution result.
  • the execution information processing unit 213 creates an execution information table 421 in the memory 200 based on the test result notified from the test target program control processing unit 211 and the module execution instruction notified from the test scenario control processing unit 212. .
  • the execution information table 421 created in the memory 200 is stored in the execution information file 420 of the storage device 400.
  • FIG. 5 is a flowchart illustrating a procedure of related information collection processing for executing a test while creating the execution information table 421 according to the first embodiment of this invention.
  • the CPU 300 first executes the test target program control processing unit 211 and reads the test target program 220 (S501). At this time, all modules may be read into the memory 200. However, when the test target program 220 is divided into a plurality of files instead of a single file, the timing at which each module is actually executed. Each module may be read by.
  • the CPU 300 executes the test scenario control processing unit 212 and reads the test scenario 410 to be tested (S502). Furthermore, each step included in the test scenario 410 read in the process of S502 is sequentially executed (S503). In other words, since each step corresponds to a module included in the test target program, the corresponding modules are sequentially executed in the processing of S503.
  • the CPU 300 generates the execution information of the module executed in the process of S503 by executing the execution information processing unit 213 (S504).
  • the execution information includes, for example, information for identifying the executed module and code in the module, parameters necessary for executing the module, output results of the module, files changed by executing the module, and the like. It is. Further, the execution information includes the contents of the database, related files, or memory and the execution state when the test target program 220 is executed. In other words, the execution information includes information on the modules operating at the time of execution of each step of the test scenario 410 and resource information. Execution information can be acquired by existing debugger technology.
  • the CPU 300 determines whether or not all the steps of the test scenario 410 to be executed have been completed by the test scenario control processing unit 212, that is, whether or not the test scenario 410 to be executed has been completed (S505). If not completed (the result of S505 is “No”), the processing after S503 is executed to execute the next step.
  • the CPU 300 further determines whether or not an unexecuted test scenario 410 remains. (S506).
  • the unexecuted test scenario 410 remains (the result of S506 is “Yes”), the next test scenario 410 is selected, and the processes after S502 are executed.
  • the CPU 300 causes the execution information processing unit 213 to output the execution information table 421 stored in the memory 200 to the execution information file 420 ( S507).
  • 6A to 6F are diagrams illustrating a process of creating the execution information table 421 according to the first embodiment of this invention.
  • test scenario 410 and the test target program 220 have the relationship shown in FIG. 3, and the test scenario 410 includes three types of modules, and the test target program 220 includes two types of modules. Further, the test scenario name of the test scenario 1 is “Scenario 1”, the test scenario 2 is “Scenario 2”, and the test scenario 3 is “Scenario 3”.
  • FIG. 6A will be described.
  • the test scenario 1 (“Scenario1") is read (S502).
  • a record in which the test scenario name 4211 is “Scenario 1” is generated in the execution information table 421.
  • the current time is set as the test execution time 4214, and “ ⁇ 1” indicating non-execution is set as the test execution determination result 4215. Since the test execution order 4216 cannot be set at this stage, “0” is set. Note that the changed resource information 4213 is not considered in this embodiment, and NULL is set.
  • step 1 and step 2 are defined in the test scenario 1, and here, the first line of the test scenario, that is, step 1 is executed (S503).
  • step 1 since module 1 (“Module 1”) is executed, “Module 1” is set in the operation module information 4212, and 1 is set as the reference number.
  • FIG. 6B shows a state in which step 2 of test scenario 1 is being executed.
  • step 2 of test scenario 1 since module 1 is executed, 1 is added to the reference number of the operation module information 4212, and the reference number becomes 2.
  • FIG. 6C shows a state in which test scenario 1 is completed and step 1 of test scenario 2 is being executed. Therefore, a record corresponding to the test scenario 2 is newly added.
  • step 1 of the test scenario 2 in order to execute the module 1, "Module 1" is set in the operation module information 4212, and 1 is set as the reference number.
  • FIG. 6D shows a state in which step 2 of the test scenario 2 is being executed.
  • step 2 of the test scenario 1 in order to execute the module 2, “Module 2” is set in the operation module information 4212, and 1 is set as the reference number.
  • FIG. 6E shows a state in which the test scenario 2 is finished and step 1 of the test scenario 3 is executed. Therefore, a record corresponding to the test scenario 3 is newly added.
  • step 1 of the test scenario 3 in order to execute the module 2, “Module 2” is set in the operation module information 4212, and 1 is set as the reference number.
  • FIG. 6F shows a state in which step 2 of the test scenario 3 is being executed.
  • step 2 of the test scenario 3 since the module 2 is executed, 1 is added to the reference number of the operation module information 4212, and the reference number is 2.
  • the created execution information table 421 is stored in the execution information file 420 of the storage device 400.
  • FIG. 7 is a diagram illustrating an example of a screen for outputting an execution result of the related information collection process according to the first embodiment of this invention.
  • the related information collecting process is a process of acquiring the relationship between the test scenario 410 and each module included in the test target program 220.
  • the output device 600 outputs the relationship between the test scenario 410 (620) and each module (610) included in the test target program 220 as shown in FIG. (601).
  • the relationship is indicated by connecting the related module and the test scenario with a line (630). Further, the thickness of the connected line is set according to the number of references. Therefore, since the reference number of “Module 1” is 2 in “Scenario 1” and the reference number of “Module 1” is 1 in “Scenario 2”, the line connecting “Scenario 1” and “Module 1” is “Scenario 2” and “Module 1”. "It is displayed to be thicker than the connecting line.
  • the related information collection process is a process executed when a new execution information table 421 is created, such as when a new test is executed, information such as the correction information of each module and the execution order of test scenarios Is not output.
  • the execution result of the test scenario is not output, but the test result when the related information collection process is executed may be output.
  • test when the test is performed after the module is modified, a check is put in the modification column of the test target program. At this time, whether or not the test scenario is an execution target, the execution order of the test scenario, and the like are displayed. A specific procedure for performing the display will be described later with reference to FIG. .
  • test scenario order column For example, when test results are output, it is possible to collectively display test scenarios with normal test results or test scenarios with abnormal test results.
  • the name of the test scenario is selected, the content of the selected test scenario may be referred to, or when the module is selected, the source code of the module may be referred to. This makes it possible to immediately refer to the contents of the test scenario and the contents of the module when the test result is abnormal.
  • FIG. 8 is a diagram illustrating the relationship between the test scenario 410 and the test target program 220 when some modules included in the test scenario 410 according to the first embodiment of this invention are changed.
  • FIG. 8 is the same as the relationship shown in FIG. 3 between the test scenario 410 and the test target program 220 shown in FIG. However, FIG. 8 shows a state where the module 2 of the test target program 220 is updated from the state of FIG.
  • FIG. 9 is a diagram illustrating a procedure for updating the execution information file 420 when the test target program 220 according to the first embodiment of this invention is changed.
  • test execution processing unit 210 Each configuration included in the test execution processing unit 210 is a program executed by the CPU 300, but will be described mainly with each configuration as in the description of FIG.
  • test target program control processing unit 211 reads the test target program 220 into the memory 200. Further, the changed module is detected from the test target program 220.
  • the execution information processing unit 213 acquires the execution information table 421 from the execution information file 420.
  • test scenario control processing unit 212 reads the test scenario 410. Then, the test scenario execution determination processing unit 214 determines the test scenario execution order so as to give priority to the test scenario 410 that executes the changed module, and reflects it in the execution information table 421. The subsequent processing is the same as the processing shown in FIG.
  • FIG. 10 is a flowchart illustrating a procedure for re-execution of a test when the test target program 220 according to the first embodiment of this invention is changed.
  • the CPU 300 executes the test target program control processing unit 211 and reads the test target program 220 (S1001). Subsequently, the test target program 220 is analyzed to search for a changed module (S1002).
  • a comparison is made except for a part not related to an operation code such as date information from the module before the change and the module after the change, and if there is a difference, the module is changed. It is determined that Specifically, a so-called diff program is used to extract the difference between the operation code of the module before the change and the operation code of the module after the change, and if the difference is extracted, it is determined that the module has been changed. do it.
  • the diff program is a program for extracting differences between two data (files). Since the diff program comparison algorithm is a known technique, the description thereof is omitted.
  • the module comparison may compare the contents of the source code, or may compare the created module with a new module built with the latest source code of the module.
  • the changed module may be specified based on the source code change information and the module creation (build) date and time.
  • the CPU 300 reads the execution information table 421 included in the execution information file 420 by the test scenario execution determination processing unit 214 (S1003). Then, based on the read execution information table 421 and the changed module searched in the process of S1002, a test scenario execution order determination process is executed (S1004). In the test scenario execution order determination process, whether to execute a test scenario that does not execute the changed module, the execution order of the test scenario, and the like are determined, and the execution information table 421 is updated. Details of the test scenario execution order determination process will be described later with reference to FIG.
  • the CPU 300 executes the test scenario 410 based on the execution information table 421 updated in the test scenario execution order determination process by the test scenario control processing unit 212 (S1005). At this time, “ ⁇ 1” indicating non-execution is set in the test execution determination result 4215 corresponding to the test scenario 410 to be executed. When the execution of the test scenario is completed, “1” indicating that the re-execution of the test is completed is set in the test execution determination result 4215.
  • the corresponding record in the execution information table 421 is updated for the test scenario related to the test executed in the process of S1005. Specifically, when the test execution time 4214 is set and the combination of modules to be executed is changed, the operation module update information 4212 is also updated.
  • the CPU 300 causes the execution information processing unit 213 to output the updated execution information table 421 to the execution information file 420 (S1006).
  • FIG. 11 is a flowchart showing a procedure of test scenario execution order determination processing according to the first embodiment of this invention.
  • the test scenario execution order determination process is executed by the CPU 300 processing the test scenario execution determination processing unit 214.
  • the execution order management list is a list that temporarily holds test scenarios in order to determine the execution order of the test scenarios.
  • the CPU 300 reads one record from the execution information table 421, that is, acquires one test scenario (S1102).
  • the CPU 300 determines the execution order of the acquired test scenarios so as to execute only the test scenarios that execute the modified modules (S1103).
  • a value is set in the execution order 4216 in the order in which the test scenario is acquired. Further, “ ⁇ 1” indicating that the test execution determination result 4215 is not executed is set.
  • whether or not the module is a modified module may be determined by comparing the test execution time 4214 of the acquired test scenario with the update time of the module executed by the test scenario.
  • the CPU 300 determines whether or not the processing of S1103 has been executed for all the test scenarios included in the execution information table 421 (S1104).
  • the process of S1103 is executed for all the test scenarios (the result of S1104 is “Yes”), this process ends.
  • the processing of S1103 has not been executed for all test scenarios (the result of S1104 is “No”), an unexecuted test scenario is selected, and S1102 and subsequent steps are performed for the unexecuted test scenario. Execute the process.
  • FIG. 12 is a diagram illustrating an example of the execution information table 421 after the test re-execution according to the first embodiment of this invention.
  • the test scenario 1 (“Scenario 1”) that executes only the module 1 is not executed. That is, the value of the test execution determination result 4215 is set to “0” indicating that it is not a re-execution target.
  • test scenario 2 (“Scenario 2”) and the test scenario 3 (“Scenario 3”) for executing the module 2
  • the value of the test execution determination result 4215 is not executed in the processing of S1103 in FIG. -1 "is set. Thereafter, when the test scenario is re-executed by the processing of S1005 in FIG. 10, the value of the test execution determination result 4215 is set to “1” indicating that it is a re-execution target.
  • the test execution order 4216 is assigned the execution order in ascending order from the top record for the test scenario to be re-executed. For a test scenario that is not a target for re-execution of the test, “0” is set in the test execution order 4216.
  • FIG. 13 is a diagram illustrating an example of a screen for outputting a test re-execution result according to the first embodiment of this invention.
  • the screen shown in FIG. 13 shows the result of executing the retest after the test scenario has been executed and the modules included in the test target program 220 have been corrected. Specifically, the case where only the module 2 is corrected is shown. Therefore, in the table indicating the test target program, “ ⁇ ” indicating that the program has been corrected is output in the correction column corresponding to module 2 (“Module 2”).
  • test execution order is set so that the test scenario 3 is executed. Further, the test scenario 1 in which the module to be executed is not corrected is not subject to re-execution.
  • the value set in the order column is set based on the execution order 4216 of the execution information table 421. Also, by selecting the test scenario order column, it is possible to sort and display the test scenarios in the execution order, and the user can easily grasp the execution order of the test scenarios. At this time, the test scenario that is not to be re-executed may be displayed after the test scenario to be re-executed.
  • test re-execution in FIG. 13 After the test scenario 2 is executed, the test is interrupted (cancelled) while the test scenario 3 is being executed. Therefore, “ ⁇ ” indicating that the execution has been completed is output in the execution column corresponding to the test scenario 2, and “OK” indicating that the test result is normal (successful) is output in the result column. If the test result is abnormal (failure), for example, “NG” is output. In the execution column corresponding to the test scenario 3, “-” indicating that the test did not end normally is output.
  • a module to be executed for each test scenario at the time of test execution is acquired and the execution information table 421 is created, thereby associating the test scenario with the module. This can be done automatically. Therefore, it is possible to significantly reduce human error due to human beliefs.
  • the first embodiment of the present invention it is possible to intensively test changed portions (modules) in a test target program, thereby reducing the time required for testing and improving development efficiency. It becomes possible.
  • the first embodiment of the present invention by automatically extracting a changed module and comparing it with the execution information table 421, execution of a test scenario in which only a module that has not been changed operates is omitted. It becomes possible. Therefore, it is possible to execute only the test scenario that operates the changed module, it is possible to reduce the time required for the test while preventing test leakage, and further improve the quality of the entire system. It becomes.
  • FIG. 14 is a diagram illustrating an outline of a procedure for changing the execution order of the test scenarios according to the second embodiment of this invention.
  • test scenario (test scenario 2 and test scenario 3) for executing the changed module is specified, and the specified test scenario is Set the execution order to prioritize execution. Then, the execution order is set so that the test scenario (test scenario 1) for executing only the module without change is executed after the test scenario for executing the changed module.
  • the related information collection process is executed to create the execution information table 421 first.
  • the re-execution process is executed as in the first embodiment.
  • the procedure of the related information collection process and the re-execution process is the same as that of the first embodiment, but the procedure of the test scenario execution order determination process in the re-execution process is different.
  • FIG. 15 is a flowchart illustrating a procedure of test scenario execution order determination processing according to the second embodiment of this invention.
  • the CPU 300 When executing the test scenario execution order determination process, the CPU 300 first creates an execution order management list (S1101).
  • the CPU 300 reads one record from the execution information table 421, that is, acquires one test scenario (S1102).
  • CPU 300 determines the execution order so that the test scenario for executing the modified module is executed in preference to the test scenario for not executing the modified module (S1501).
  • the test execution order is set in the acquired order for each of the test scenario that executes the modified module and the test scenario that does not execute the corrected module. Then, when all the test scenarios are acquired, the execution order is reset so that the test scenario that does not execute the modified module is executed after the test scenario that executes the modified module. At this time, the number of test scenarios that execute a module that has been corrected in advance may be acquired, and the number acquired when setting the execution order of test scenarios that do not execute the corrected module may be added and set. Good.
  • test scenario that executes the modified module is placed from the top of the execution order management list
  • the test scenario that does not execute the modified module is set from the end of the execution order management list, and is executed from the top of the execution order management list
  • the order may be set.
  • the execution order of the test scenarios that do not execute the modified module is reverse to the order in which the test scenarios are acquired.
  • test scenarios are executed, so that all test scenarios are not executed in the test execution determination result 4215 as “ ⁇ 1”. Set.
  • FIG. 16 is a diagram illustrating an example of the execution information table 421 after the test re-execution according to the second embodiment of this invention.
  • the test scenario 1 that executes only the module 1 is later than the other scenarios (the test scenario 2 and the test scenario 3) that execute the changed module 2. Executed.
  • test execution order 4216 is set to 3 in the test scenario 1, and the test scenario 2 and the test scenario 3 are executed later.
  • the test based on the test scenario that executes the changed module is preferentially executed, and the test based on the test scenario that does not execute the changed module is executed later.
  • the test based on the test scenario that does not execute the changed module is executed later.
  • FIG. 17 is a diagram for explaining an overview of a procedure for changing the execution order of the test scenario of the first modified example of the second embodiment of the present invention.
  • test scenario 2 and test scenario 3 for executing a changed module is specified, and further, based on the number of changed modules.
  • the changed module 2 is referred to once in the test scenario 2 and twice in the test scenario 3. Therefore, the execution order is set so that the test scenario 3 is executed in preference to the test scenario 2.
  • the execution order is set so that the test scenario is executed after the test scenario that executes the changed module, as in the second embodiment.
  • the procedure of the test scenario execution order determination process is different from that of the second embodiment, and the other processes are the same.
  • FIG. 18 is a flowchart illustrating a procedure of test scenario execution order determination processing according to the first modification of the second embodiment of the present invention.
  • test scenario execution order determination process of the modification of the second embodiment the process of S1501 is replaced with the process of S1801, and other processes are common.
  • the CPU 300 acquires the reference number of the corrected module included in the test scenario corresponding to the read record, and determines the execution order so that the test scenario with the large number of corrected modules is executed preferentially ( S1801).
  • the reference number of the corrected module is acquired from the operation module information included in the read record, and when there are a plurality of corrected modules, the reference number of each module is totaled. Then, the test scenario is stored in the execution order management list together with the reference number of the corrected module.
  • test scenarios When all test scenarios are stored in the execution order management list, they are sorted in descending order of the number of modified module references. Then, the execution order of the test scenarios is set based on the sorted order. When the number of references is the same, the execution order of the test scenario corresponding to the previously read record is set first.
  • the execution determination result column corresponding to the test scenario with the corrected module reference number of 0 is used. Is set to 0 (not subject to re-execution), and the value of the execution determination result column corresponding to the test scenario in which the reference number of the corrected module is 1 or more is set to -1 (not executed).
  • the value in the execution determination result column is set to -1 (not executed) for all test scenarios. Set to.
  • FIG. 19A and 19B are diagrams illustrating an example of the execution information table 421 after the test re-execution according to the first modification of the second embodiment of this invention.
  • FIG. 19A illustrates a case where a test based on a test scenario not including a modified module is not executed
  • FIG. 19B illustrates a case where a test based on a test scenario not including a modified module is performed.
  • test scenario 1 that executes only the module 1 is later than the other scenarios (the test scenario 2 and the test scenario 3) that execute the changed module 2. Executed. Also, since test scenario 2 has a reference number of changed modules of 1, test scenario 3 has a reference number of changed modules of 2, test scenario execution order is "1" for test scenario 3, test scenario 2 Is set to "2".
  • test execution determination result of test scenario 1 is set to “0” (not to be reexecuted) as described above.
  • the test execution order is set to “0”.
  • test execution order when executing a test scenario that does not include a modified module, the test execution order is set so that test scenario 1 is executed after test scenario 2 and test scenario 3 are completed. “3” is set.
  • the test scenario having more changed portions among the test scenarios for executing the changed module. Since the execution is prioritized, it is possible to execute an effective test within a more limited time.
  • FIG. 20 is a diagram for explaining the outline of the procedure for changing the execution order of the test scenario of the second modified example of the second embodiment of the present invention.
  • the execution order is set so that the test scenario that has not been executed is preferentially executed.
  • the left side of FIG. 20 shows a state in which test execution is canceled after test scenario 1 and test scenario 2 are executed and before test scenario 3 is executed. Further, on the right side of FIG. 20, after the test scenario 1 and the test scenario 2 are executed, the test scenario execution order when the test is executed after the test execution is canceled before the test scenario 3 is executed. Is shown. That is, the execution order is set so that the test scenario 3 is executed first so that the unexecuted test scenario 3 is preferentially executed.
  • the second modification of the second embodiment is configured to set the test scenario execution order in the same procedure as that of the first modification of the second embodiment during normal times. Further, the procedure of the test scenario execution order determination process is different from the first modification of the second embodiment, and the other processes are the same.
  • FIG. 21 is a flowchart showing the procedure of the test scenario execution order determination process according to the second modification of the second embodiment of the present invention.
  • test scenario execution order determination process of the second modification example of the second embodiment the process of S1801 of the first modification example is replaced with the process of S2101, and other processes are common.
  • the CPU 300 executes the modified module and sets the execution order so that the unexecuted test scenario is preferentially executed during the previous test execution (S2101).
  • the test execution order is set in the test scenario in which the corrected module is executed, in which the test execution determination result is not executed ( ⁇ 1) and the reference number (total) is large.
  • the test execution order is set in the order in which the test execution determination result is not unexecuted (0 or 1) and the reference number (total) is large.
  • test execution determination result column of the test scenario that executes the modified module is set to not executed ( ⁇ 1). Further, the test execution determination result column of the test scenario in which the modified module is not executed is set to not to be reexecuted (0).
  • test execution determination result column is not executed ( ⁇ 1) and the number of references (total) is large in the test scenario that does not execute the corrected module. Set the test execution order sequentially.
  • test execution determination result column is not unexecuted (0 or 1) and the test execution order is set in the order of the number of references (total). Finally, the test execution determination result column for all test scenarios is set to unexecuted ( ⁇ 1).
  • the test scenario that was not executed is prioritized and executed when the test is executed next time. Let By doing so, it is possible to improve the completeness of the test and improve the quality of the system.
  • test scenario In the first embodiment and the second embodiment, the case where the test is re-executed when the module executed in the test scenario is updated has been described.
  • the test scenario is used. A case where the module to be executed is changed to another module will be described. For example, a case where a new module is created or a case where a module is reconfigured is assumed.
  • FIG. 22 is a diagram illustrating the relationship between the test scenario 410 and the test target program 220 according to the third embodiment of this invention.
  • module 1 was executed in step 1 of test scenario 3 (“Scenario 3”) at the first execution (left side in FIG. 22), but changed to execute module 2 at the time of retest execution. (Right side of FIG. 22).
  • FIG. 23 is a flowchart illustrating a procedure of related information difference extraction processing for executing the test again and creating the execution information file 420 when the module executed in the test scenario according to the third embodiment of this invention is changed. It is.
  • symbol is assigned about the process which is common in the procedure which produces the execution information file 420 in 1st Embodiment shown in FIG. 10, and description is abbreviate
  • the CPU 300 first executes the test target program control processing unit 211 and reads the test target program 220 (S1001). Subsequently, the test target program 220 is analyzed to search for a changed module (S1002). In the process of S1002, the changed module is detected, but it is not necessary to detect that the test scenario in which the module is executed has been changed.
  • the CPU 300 reads the execution information table 421 included in the execution information file 420 by the test scenario control processing unit 212 (S2301).
  • the execution information table 421 based on the test scenario of the configuration before the change read in the process of S2301 is assumed to be an execution information table (A).
  • the execution information table at the time of retest execution is defined as an execution information table (B).
  • the CPU 300 causes the test scenario execution determination processing unit 424 to execute a test scenario execution order determination process based on the execution information table (A) and the changed module searched in the process of S1002 (S1004).
  • the procedure described in the first embodiment or the second embodiment may be executed.
  • the CPU 300 sequentially executes the unexecuted test scenarios based on the execution information table (A).
  • the execution information processing unit 213 collects execution information of the test scenario being executed, and creates an execution information table (B) (S2302).
  • the CPU 300 compares the execution information table (A) and the execution information table (B) by the execution information processing unit 213 (S2303). . Then, it is determined whether there is a difference in the configuration of modules executed in each test scenario (S2304). If there is no difference (the result of S2304 is “No”), the execution information table (A) is output to the execution information file 420 as the execution information table 421 (S2307).
  • the CPU 300 outputs the difference information (S2305).
  • the difference information may be output to the screen (output device 600) or may be output to the storage device 400 as a file.
  • the CPU 300 reflects the operation module information 4212 of the execution information table (B) in the execution information table (A) (S2306). Thereafter, the execution information table (A) reflecting the operation module information 4212 of the execution information table (B) is output to the execution information file 420 as the execution information table 421 (S2307).
  • FIG. 24 is a diagram illustrating an example of a screen for outputting an execution result of the related information difference extraction process according to the third embodiment of this invention.
  • the configuration (1610, 1620) at the previous test execution and the configuration (2610, 2620) at the current test execution are output. Further, when there is a change in the relationship between the module and the test scenario, a line indicating the relationship is displayed as a thick line, for example, so as to be distinguished from a case where there is no change in the relationship (1630, 2630). Regarding the configuration at the time of the test execution this time, only the relationship between the module and the test scenario may be output, or the test result may be displayed at the same time.
  • the thickness of the line indicates whether or not the relationship between the module and the test scenario has changed
  • the number of references is displayed by selecting the line indicating the relationship between the module and the test scenario. You may do it.
  • the module executed in the test scenario can be quickly changed. It becomes possible to respond.
  • the difference information is output when the relationship between the test scenario and the module is changed, it is possible to grasp an unintended system configuration change at an early stage. It becomes possible.
  • execution information is generated in units of test scenarios.
  • execution information may be generated in units of steps of test scenarios. By generating execution information in units of steps, it is possible to prevent re-execution of a test of a module that has not been changed because a module executed in another step in the test scenario has been changed.
  • the present invention can be used in a program test process in system development.

Abstract

　所定の機能を提供するモジュールを含むプログラムをテストする方法であって、当該テストは、モジュールを実行する手順を含む複数のテスト定義情報に基づいて、当該テスト定義情報を順次実行することによって実行される。また、各テスト定義情報によって実行されるモジュールの識別子を含む実行情報が管理され、実行中のモジュールの識別子をテスト定義情報ごとに実行情報に記憶する。さらに、各テスト定義情報に基づくテストが完了すると、テストを再実行する場合には、実行情報に基づいてテストが実行された後に更新されたモジュールを実行するように定義されたテスト定義情報を特定し、特定されたテスト定義情報に基づくテストを優先して実行する。

Description

テスト方法、テスト装置及びテスト実行用プログラム
　本発明は、システム開発においてプログラムをテストする技術に関する。
　近年、環境の変化に対応しやすいシステム開発手法として、アジャイル開発が知られている。アジャイル開発では、例えば、イテレーションと呼ばれる短期間で、比較的小さな機能を開発し、複数のイテレーションを繰り返すことによってシステムを開発する。１イテレーションには、設計、実装（ビルド、プログラミング）、テストなどの工程が含まれる。
　アジャイル開発では、機能を実装するたびにデグレード確認を含めた自動テストを実行する。例えば、自動テストは、実行する処理手順などが定義されたテストシナリオ（テスト定義情報）に基づいて実行される。しかし、プログラムを追加したり、修正したりするたびに動作確認用テストシナリオの内容が増加するため、規模の大きいシステムの場合などではテストを実行するために多くの時間が必要となる。そのため、限られた時間で十分なテストを実行し、効率的に開発を行なうための仕組みが求められている。
　そこで、特許文献１には、テストシナリオに変更されたプログラムを関連付けた構成管理情報を保持し、変更されたソースファイル名に関連するテストシナリオを選択及び実行する技術が開示されている。また、特許文献２には、カバレジ率を用いてテスト範囲を特定し、関連するテストデータを使用して再テストを実行する技術が開示されている。
特開２００３－９１４３１号公報 特開平６－３５７５４号公報
　しかし、特許文献１に開示された技術では、構成管理情報を登録する際に、テストシナリオとプログラムのソースファイル名を関連付けて登録する必要があり、システム構成が変更された場合などには再登録が必要であった。また、特許文献２に開示された技術では、変更された部分の再テストを実行する際に特定し、変更部分を入力する必要があった。さらに、カバレジ率を取得する処理がプログラム言語に依存してしまうため、汎用的ではなかった。
　さらに、特許文献１及び特許文献２に開示された技術では、あらかじめ定義された情報に基づいてテストが実行されるため、間接的に実行されるプログラムの把握が困難であったり、条件分岐などによって実際に実行されなかったプログラムのテストが完了したと判断されたりするおそれがあった。
　本発明は、システム開発において効率的にテストを実行する技術を提供することによって、テストに必要な時間を短縮し、システムの品質を向上させることを目的とする。
　本発明の一形態では、所定の機能を提供するモジュールを含むプログラムのテストを実行するテスト装置におけるテスト方法であって、前記テスト装置は、前記プログラムを記憶する記憶部と、前記記憶部に記憶されたプログラムを実行するプロセッサと、を備え、前記テストは、前記モジュールを実行する手順を含む複数のテスト定義情報に基づいて、当該各テスト定義情報を順次実行することによって実行され、前記テスト装置は、前記テスト定義情報に基づくテストの実行を制御するテストシナリオ制御処理部と、前記各テスト定義情報によって実行されるモジュールの識別子を含む実行情報を作成する実行情報処理部と、前記実行情報に基づいて、前記各テスト定義情報に基づくテストを実行するか否かを判定するテストシナリオ実行判断処理部と、を備え、前記テスト方法は、前記実行情報処理部は、前記テスト定義情報に基づいて実行されたモジュールを検出し、前記実行情報処理部は、前記テスト定義情報ごとに、前記検出されたモジュールの識別子を前記実行情報に記憶し、前記テストシナリオ実行判断処理部は、前記テストを再実行する場合には、前記実行情報に基づいて、当該テストが実行された後に更新されたモジュールを実行するように定義されたテスト定義情報を特定し、前記テストシナリオ制御処理部は、前記特定されたテスト定義情報に基づくテストを優先して実行する。
　本発明の代表的な一形態によれば、変更されたプログラム（モジュール）を実行するテスト定義情報（テストシナリオ）に基づくテストを優先して実行することによって、システムの品質を向上させることができる。
本発明の第１の実施の形態のテスト装置の構成を説明する図である。 本発明の第１の実施の形態の実行情報ファイルに含まれる実行情報テーブルの一例を示す図である。 本発明の第１の実施の形態のテストシナリオとテスト対象プログラムとの関係を説明する図である。 本発明の第１の実施の形態の実行情報ファイルを作成する手順を説明する図である。 本発明の第１の実施の形態の実行情報テーブルを作成しながらテストを実行する関連情報採取処理の手順を示すフローチャートである。 本発明の第１の実施の形態の実行情報テーブルを作成する過程を説明する図であり、テストシナリオ１のステップ１が実行された状態を示す図である。 本発明の第１の実施の形態の実行情報テーブルを作成する過程を説明する図であり、テストシナリオ１のステップ２が実行された状態を示す図である。 本発明の第１の実施の形態の実行情報テーブルを作成する過程を説明する図であり、テストシナリオ１が終了し、テストシナリオ２のステップ１が実行された状態を示す図である。 本発明の第１の実施の形態の実行情報テーブルを作成する過程を説明する図であり、テストシナリオ２のステップ２が実行された状態を示す図である。 本発明の第１の実施の形態の実行情報テーブルを作成する過程を説明する図であり、テストシナリオ２が終了し、テストシナリオ３のステップ１が実行された状態を示す図である。 本発明の第１の実施の形態の実行情報テーブルを作成する過程を説明する図であり、テストシナリオ３のステップ２が実行された状態を示す図である。 本発明の第１の実施の形態の関連情報採取処理の実行結果を出力する画面の一例を示す図である。 本発明の第１の実施の形態のテストシナリオに含まれるモジュールが変更された場合のテストシナリオとテスト対象プログラムとの関係を説明する図である。 本発明の第１の実施の形態のテスト対象プログラムが変更された場合に実行情報ファイルを更新する手順を説明する図である。 本発明の第１の実施の形態のテスト対象プログラムが変更された場合にテストを再実行する手順を示すフローチャートである。 本発明の第１の実施の形態のテストシナリオ実行順序決定処理の手順を示すフローチャートである。 本発明の第１の実施の形態のテスト再実行後の実行情報テーブルの一例を示す図である。 本発明の第１の実施の形態のテストの再実行結果を出力する画面の一例を示す図である。 本発明の第２の実施の形態のテストシナリオの実行順序を変更する手順の概要を説明する図である。 本発明の第２の実施の形態のテストシナリオ実行順序決定処理の手順を示すフローチャートである。 本発明の第２の実施の形態のテスト再実行後の実行情報テーブルの一例を示す図である。 本発明の第２の実施の形態の第１変形例のテストシナリオの実行順序を変更する手順の概要を説明する図である。 本発明の第２の実施の形態の第１変形例のテストシナリオ実行順序決定処理の手順を示すフローチャートである。 本発明の第２の実施の形態の第１変形例のテスト再実行後の実行情報テーブルの一例であり、修正されたモジュールを含まないテストシナリオを再実行しない場合を示す図である。 本発明の第２の実施の形態の第１変形例のテスト再実行後の実行情報テーブルの一例であり、修正されたモジュールを含まないテストシナリオを再実行する場合を示す図である。 本発明の第２の実施の形態の第２変形例のテストシナリオの実行順序を変更する手順の概要を説明する図である。 本発明の第２の実施の形態の第２変形例のテストシナリオ実行順序決定処理の手順を示すフローチャートである。 本発明の第３の実施の形態のテストシナリオとテスト対象プログラムとの関係を説明する図である。 本発明の第３の実施の形態のテストシナリオで実行されるモジュールが変更された場合に再度テストを実行して実行情報ファイルを作成する関連情報差分抽出処理の手順を示すフローチャートである。 本発明の第３の実施の形態の関連情報差分抽出処理の実行結果を出力する画面の一例を示す図である。
　以下、本発明の実施の形態について、図面を参照しながら説明する。本発明では、システムを開発する過程において、所定の機能を実現するプログラム（モジュール）作成時及び更新時のテストを実行するために必要な情報を生成する。具体的には、一連の処理を実行するために必要なモジュールの実行順序などが定義されたテストシナリオ（テスト定義情報）に基づくテストを実行する場合に、テストシナリオの実行順序を決定するために必要な情報を作成する。
　（第１の実施の形態）
　図１は、本発明の第１の実施の形態のテスト装置１００の構成を説明する図である。
　本発明の第１の実施の形態のテスト装置１００は、メモリ２００、ＣＰＵ３００、記憶装置４００、入力装置５００及び出力装置６００を備える。テスト装置１００は、一般的な計算機であってもよい。
　ＣＰＵ３００は、メモリ２００に記憶された各種プログラムを実行することによって所定の処理を実行する。具体的には、後述するテストシナリオ４１０に基づいて後述するテスト対象プログラム２２０を実行したり、テスト対象プログラム２２０を実行している間に必要な情報を収集したりする。
　メモリ２００は、ＣＰＵ３００によって高速にアクセス可能な記憶媒体である。メモリ２００は、揮発性記億媒体であってもよいし、不揮発性記憶媒体であってもよい。メモリ２００は、ＣＰＵ３００によって実行されるプログラム及び当該プログラムを実行するために必要なデータを記憶する。具体的には、ＣＰＵによって実行するプログラムとして、テスト実行処理部２１０、テスト対象プログラム２２０、及びオペレーティングシステム２３０が記憶される。各プログラムの詳細については後述する。
　記憶装置４００は、大容量のデータを記憶可能な不揮発性記憶媒体である。記憶装置４００は、例えば、ハードディスクドライブなどである。本実施形態では、記憶装置４００は、テストシナリオ４１０、実行情報ファイル４２０及びテスト結果４３０を格納する。また、メモリ２００に記憶される各種プログラムを格納し、必要に応じてメモリ２００にロードするようにしてもよい。
　テストシナリオ４１０は、各種業務処理に対応したテストを実行するために必要な情報が格納されている。例えば、テストシナリオ４１０は、実行されるモジュールの組み合わせ、モジュール（プログラム）の実行順序、各モジュールを実行する際に必要なパラメータなどが定義される。
　さらに説明すると、テストシナリオ４１０には、テスト対象プログラム２２０を構成するモジュールの識別子が実行順序とともに定義されている。ＣＰＵ３００は、テスト実行処理部２１０を実行し、テストシナリオ４１０に定義されたモジュールの実行順序にしたがって定義されたモジュールを実行する。
　また、モジュールの実行においてユーザからの入力が必要な場合には、入力される情報もテストシナリオ４１０に定義される。さらに、モジュールを実行することによって、出力されるべき結果も定義される。そして、定義された出力結果と実際にモジュールを実行した結果とを比較することによってテスト結果を判定できる。
　実行情報ファイル４２０は、テストシナリオ４１０に基づいてテストが実行されている間に収集された情報が格納される。本実施形態では、テストが実行されている間に呼び出されたモジュールを特定し、テストシナリオ４１０とモジュールとの対応を記録する。このように、テスト実行時にテストシナリオ４１０とモジュールとの対応を特定することによって、自動的にテスト範囲を特定することが可能となる。
　テスト結果４３０は、テストシナリオ４１０ごとに実行されたテスト結果が格納される。
　入力装置５００は、テスト装置１００に必要な情報を入力するための装置である。具体的には、キーボード、マウスなどである。
　出力装置６００は、実行されたテストの結果などを表示するための装置である。具体的には、ディスプレイなどの表示装置である。
　ここで、メモリ２００に記憶されている各プログラムの詳細について説明する。
　テスト実行処理部２１０は、本発明によるテストを実行するために、ＣＰＵ３００によって実行されるプログラムである。テスト実行処理部２１０は、ＣＤ－ＲＯＭなどの各種記憶媒体に記憶されて配布される。また、所定のサーバからネットワークを介して配布するようにしてもよい。
　テスト実行処理部２１０は、テストシナリオ４１０に基づいてテスト対象プログラム２２０を実行する。さらに、テスト実行時に必要な情報を収集し、前述した実行情報４２１に記録する。
　また、テスト実行処理部２１０は、テスト対象プログラム２２０が更新された場合には、実行情報４２１と更新されたテスト対象プログラム２２０に基づいて、テストシナリオ４１０の実行順序を決定する。
　テスト実行処理部２１０には、テスト対象プログラム制御処理部２１１、テストシナリオ制御処理部２１２、実行情報処理部２１３、及びテストシナリオ実行判断処理部２１４が含まれる。
　テスト対象プログラム制御処理部２１１は、後述するテストシナリオ制御処理部２１２によって実行を指示されたテスト対象プログラム２２０を実行する。また、テスト対象プログラム２２０には複数のモジュールが含まれており、テスト対象プログラム制御処理部２１１は、テスト対象プログラム２２０をモジュール単位で制御する。テスト対象プログラム制御処理部２１１は、各モジュールを実行した際の実行モジュール情報を収集するなどのデバッガの機能も有している。また、直接実行を指示したモジュールだけではなく、実行中のモジュールによって間接的に実行されたモジュールの実行モジュール情報も収集することが可能である。
　テストシナリオ制御処理部２１２は、記憶装置４００に記憶されたテストシナリオ４１０に基づいて実行するモジュールを特定し、テスト対象プログラム制御処理部２１１に特定されたモジュールの実行を順次指示する。また、モジュールの実行に必要なパラメータが定義されている場合には、テストシナリオ４１０から取得し、テスト対象プログラム制御処理部２１１に送信する。
　実行情報処理部２１３は、テスト対象プログラム制御処理部２１１によるモジュールの実行結果と、テストシナリオ制御処理部２１２に入力されたテストシナリオ４１０に含まれるパラメータ（入力、出力）とに基づいて、テストシナリオ４１０の実行情報を作成する。さらに、作成された実行情報に基づいて、後述する実行情報テーブル４２１に作成された実行情報を出力したり、実行情報ファイル４２０に含まれるデータを更新したりする。
　テストシナリオ実行判断処理部２１４は、テスト対象プログラム制御処理部２１１及びテストシナリオ制御処理部２１２と連携し、実行情報テーブル４２１に基づいて、各テストシナリオ４１０を実行するか否かを判定したり、優先して実行するテストシナリオ４１０を選択したりする。例えば、変更されたモジュールを実行するテストシナリオ４１０を優先して実行するように処理する。
　テスト対象プログラム２２０は、テスト対象となるモジュールである。テスト対象プログラム２２０には、複数のモジュール（モジュール１（２２１）、モジュール２（２２２）、モジュール３（２２３）、・・・）が含まれている。本実施形態におけるシステムでは、モジュールを組み合わせることによって、各種機能が実装されるように構成されている。前述のように、テストシナリオ４１０には、実行されるモジュールの組み合わせ及び実行順序が定義されており、テストシナリオ４１０で指定されたモジュールを実行することによって所定の機能が実装されるように定義されている。
　テスト対象プログラム２２０に含まれるモジュールは、入力されたデータを処理してデータを出力する関数単位であってもよいし、複数の関数を提供する機能単位（例えば、ＥＸＥファイルなどの実行ファイル、ＤＬＬなどのライブラリ）であってもよい。また、各モジュールのソースファイルに処理詳細な実行情報を出力するためのプログラム（コマンド）を追加してモジュールを作成（ビルド）し、より詳細な実行情報を取得できるように構成してもよい。
　オペレーティングシステム２３０は、テスト装置１００の資源（ＣＰＵ３００及びメモリ２００）を管理するシステムソフトウェアである。テスト実行処理部２１０及びテスト対象プログラム２２０は、オペレーティングシステム２３０において実行される。
　図２は、本発明の第１の実施の形態の実行情報ファイル４２０に含まれる実行情報テーブル４２１の一例を示す図である。
　実行情報テーブル４２１は、前述のように、テストシナリオ４１０に基づくテストを実行した際に収集された情報を格納する。実行情報テーブル４２１には、テストシナリオごとに実行情報が格納される。
　実行情報テーブル４２１は、テストシナリオ名４２１１、動作モジュール情報４２１２、変更リソース情報４２１３、テスト実行時刻４２１４、テスト実行判定結果４２１５及びテスト実行順番４２１６を含む。
　テストシナリオ名４２１１は、実行されるテストシナリオ４１０の名称である。
　動作モジュール情報４２１２は、テストシナリオ４１０で実行されるモジュールの構成を示す情報が格納される。本実施形態では、モジュール名とテストシナリオ４１０内で参照される参照数を含む別表を別の領域に作成し、動作モジュール情報４２１２には作成された別表へのポインタを格納する。なお、モジュール名及び参照数を実行情報テーブル４２１が直接保持するようにしてもよい。
　また、動作モジュール情報に含まれるモジュールは、テストシナリオ４１０で直接実行が指示されたモジュールだけでなく、実行されたモジュールによって間接的に実行されるモジュールも含まれる。すなわち、テストシナリオ４１０において直接定義されたモジュール以外のモジュールが含まれる場合がある。したがって、参照数についても、テストシナリオ４１０に直接参照されるモジュール以外に、実行されたモジュールによって間接的に実行されるモジュールの数も含まれる。
　変更リソース情報４２１３は、テストシナリオ４１０を実行することによって変更されるリソースの情報を格納する。本実施形態では、変更されるリソース情報の一覧を別の領域に作成された表に格納するようにしているが、実行情報テーブル４２１が直接保持するようにしてもよい。リソースには、例えば、データベースに格納されたデータ、メモリ２００に記憶されたデータ、ファイルに書き出されたデータなどが含まれる。
　なお、モジュール間及びテストシナリオ間でリソースを共用することによって、テストシナリオ間に依存関係が生じる可能性があるが、本実施形態では、このような依存関係は生じないものとする。
　テスト実行時刻４２１４は、各レコードに対応するテストシナリオに基づくテストが実行された時刻である。テスト実行時刻４２１４に格納された時刻と、各モジュールが更新された時刻とを比較することによって、対応するテストシナリオに基づくテストが実行された後に更新されたモジュールを特定することが可能となる。
　テスト実行判定結果４２１５は、対応するテストシナリオ４１０を実行するか否かを示す情報を格納する。具体的には、テストシナリオ４１０が再実行された場合には"１"が設定され、動作モジュールが変更されていない場合など、テストを再実行する対象でない場合には"０"が設定される。また、テストシナリオ４１０が再実行の対象となっているが、実際にテストが実行されていない場合（未実行）には"－１"が設定される。
　テスト実行順番４２１６は、テストシナリオ４１０に基づくテストを実行する順序である。例えば、更新されたモジュールを実行するテストシナリオ４１０に基づくテストを優先して実行する場合には、他のテストシナリオに対応するテスト実行順番４２１６の値よりも小さい値に設定すればよい。
　図３は、本発明の第１の実施の形態のテストシナリオ４１０とテスト対象プログラム２２０との関係を説明する図である。
　本発明の第１の実施の形態では、テストシナリオ１（４１０Ａ）からテストシナリオ３（４１０Ｃ）の３つのテストシナリオが実行される。また、各テストシナリオ４１０は、それぞれ２つのステップが含まれ、各ステップでテスト対象プログラム２２０に含まれるモジュールが実行される。
　テストシナリオ１（４１０Ａ）では、ステップ１でモジュール１（２２１）を実行し、ステップ２でも同じくモジュール１（２２１）を実行する。ステップ１及びステップ２で同じ機能（関数）を実行するようにしてもよいが、本実施形態では、各モジュールが複数の機能を提供可能に構成され、別の機能を実行できるようになっている。
　テストシナリオ２（４１０Ｂ）では、ステップ１でモジュール１（２２１）を実行し、ステップ２でモジュール２（２２２）を実行する。テストシナリオ３（４１０Ｃ）では、ステップ１でモジュール２（２２２）を実行し、ステップ２でも同じくモジュール２（２２２）を実行する。
　図４は、本発明の第１の実施の形態の実行情報ファイル４２０を作成する手順を説明する図である。図４では、新たに実行情報ファイル４２０を作成する場合の手順を示している。
　テスト実行処理部２１０に含まれる各構成は、ＣＰＵ３００によって実行されるプログラムであるが、説明を簡単にするために、各構成を主体として説明する。
　まず、テスト対象プログラム制御処理部２１１は、テスト対象プログラム２２０をメモリ２００に読み込む。続いて、テストシナリオ制御処理部２１２は、テストシナリオ４１０を読み込み、実行情報処理部２１３を介して、テストシナリオ４１０の各ステップに対応するモジュールの実行をテスト対象プログラム制御処理部２１１に指示する。
　テスト対象プログラム制御処理部２１１は、指示されたモジュール（テスト対象プログラム２２０）を実行するように制御する。モジュールの実行が完了すると、実行結果を実行情報処理部２１３に通知する。
　実行情報処理部２１３は、テスト対象プログラム制御処理部２１１から通知されたテスト結果と、テストシナリオ制御処理部２１２から通知されたモジュールの実行指示に基づいて、実行情報テーブル４２１をメモリ２００に作成する。すべてのテストシナリオ４１０の実行が完了すると、メモリ２００に作成された実行情報テーブル４２１を記憶装置４００の実行情報ファイル４２０に格納する。
　続いて、図４に示した実行情報ファイル４２０を作成する手順を図５のフローチャートを参照しながらさらに説明する。
　図５は、本発明の第１の実施の形態の実行情報テーブル４２１を作成しながらテストを実行する関連情報採取処理の手順を示すフローチャートである。
　ＣＰＵ３００は、まず、テスト対象プログラム制御処理部２１１を実行し、テスト対象プログラム２２０を読み込む（Ｓ５０１）。このとき、すべてのモジュールをメモリ２００に読み込むようにしてもよいが、テスト対象プログラム２２０が単体のファイルでなく、複数のファイルに分割されている場合には、各モジュールが実際に実行されるタイミングで各モジュールを読み込むようにしてもよい。
　続いて、ＣＰＵ３００は、テストシナリオ制御処理部２１２を実行し、テストを実行する対象のテストシナリオ４１０を読み込む（Ｓ５０２）。さらに、Ｓ５０２の処理で読み込まれたテストシナリオ４１０に含まれる各ステップを順次実行する（Ｓ５０３）。換言すると、各ステップにはテスト対象プログラムに含まれるモジュールが対応しているため、Ｓ５０３の処理では対応したモジュールを順次実行する。
　ＣＰＵ３００は、実行情報処理部２１３を実行することによって、Ｓ５０３の処理で実行されたモジュールの実行情報を生成する（Ｓ５０４）。実行情報には、例えば、実行されたモジュール及び当該モジュール内のコードを特定する情報、モジュールの実行に必要なパラメータ、当該モジュールの出力結果、当該モジュールの実行によって変更されたファイルなどの情報が含まれる。さらに、テスト対象プログラム２２０実行時における、データベース、関連ファイル若しくはメモリの内容なども実行状態も実行情報に含まれる。すなわち、実行情報には、テストシナリオ４１０の各ステップの実行時点で動作しているモジュールの情報及びリソース情報が含まれる。なお、実行情報は、既存のデバッガの技術によって取得可能である。
　ＣＰＵ３００は、テストシナリオ制御処理部２１２によって、実行対象のテストシナリオ４１０のすべてのステップが終了したか、すなわち、実行対象のテストシナリオ４１０が終了したか否かを判定する（Ｓ５０５）。終了していない場合には（Ｓ５０５の結果が「Ｎｏ」）、次のステップを実行するためにＳ５０３以降の処理を実行する。
　一方、ＣＰＵ３００は、実行対象のテストシナリオ４１０に含まれる各ステップがすべて終了した場合には（Ｓ５０５の結果が「Ｙｅｓ」）、さらに、未実行のテストシナリオ４１０が残っているか否かを判定する（Ｓ５０６）。未実行のテストシナリオ４１０が残っている場合には（Ｓ５０６の結果が「Ｙｅｓ」）、次のテストシナリオ４１０を選択し、Ｓ５０２以降の処理を実行する。
　ＣＰＵ３００は、すべてのテストシナリオ４１０が実行されると（Ｓ５０６の結果が「Ｎｏ」）、実行情報処理部２１３によって、メモリ２００に記憶されている実行情報テーブル４２１を実行情報ファイル４２０に出力する（Ｓ５０７）。
　以上の手順を実行することによって、テストシナリオとモジュールとの関連付けを自動的に実行することが可能となり、開発者の思い込みなどによる人為的なミスを大幅に削減することが可能となる。そして、実行情報テーブル４２１に基づいて、変更されたモジュールに関連するテストシナリオを容易に特定することが可能となり、必要なテストのみを実行することが可能となる。
　以下、図４及び図５に示した手順にしたがって実行情報テーブル４２１を作成する具体例について、図６Ａから図６Ｆを参照しながら説明する。
　図６Ａから図６Ｆは、本発明の第１の実施の形態の実行情報テーブル４２１を作成する過程を説明する図である。
　ここでは、テストシナリオ４１０とテスト対象プログラム２２０とは、図３に示した関係となっており、テストシナリオ４１０は３種類、テスト対象プログラム２２０は２種類のモジュールが含まれている。また、テストシナリオ１のテストシナリオ名は"Ｓｃｅｎａｒｉｏ１"であり、テストシナリオ２は"Ｓｃｅｎａｒｉｏ２"、テストシナリオ３は"Ｓｃｅｎａｒｉｏ３"となっている。
　まず、図６Ａについて説明する。関連情報採取処理が開始され、テスト対象プログラム２２０が読み込まれると（Ｓ５０１）、まず、テストシナリオ１（"Ｓｃｅｎａｒｉｏ１"）が読み込まれる（Ｓ５０２）。このとき、実行情報テーブル４２１にテストシナリオ名４２１１を"Ｓｃｅｎａｒｉｏ１"とするレコードが生成される。そして、テスト実行時刻４２１４には現在時刻を設定し、テスト実行判定結果４２１５には未実行を示す"－１"を設定する。この段階ではテスト実行順番４２１６を設定できないため、"０"を設定する。なお、変更リソース情報４２１３については、本実施形態では考慮せず、ＮＵＬＬを設定する。
　また、図３に示したように、テストシナリオ１にはステップ１及びステップ２が定義されており、ここでは、テストシナリオの１行目、すなわち、ステップ１が実行される（Ｓ５０３）。そして、ステップ１では、モジュール１（"Ｍｏｄｕｌｅ１"）が実行されるため、動作モジュール情報４２１２に"Ｍｏｄｕｌｅ１"が設定され、さらに、参照数に１が設定される。
　次に、図６Ｂについて説明する。図６Ｂは、テストシナリオ１のステップ２が実行されている状態である。テストシナリオ１のステップ２では、モジュール１を実行するため、動作モジュール情報４２１２の参照数に１を加算し、参照数が２となる。
　次に、図６Ｃについて説明する。図６Ｃは、テストシナリオ１が終了し、テストシナリオ２のステップ１が実行されている状態である。したがって、テストシナリオ２に対応するレコードが新たに追加されている。また、テストシナリオ２のステップ１では、モジュール１を実行するため、動作モジュール情報４２１２に"Ｍｏｄｕｌｅ１"を設定し、参照数に１を設定する。
　次に、図６Ｄについて説明する。図６Ｄは、テストシナリオ２のステップ２が実行されている状態である。テストシナリオ１のステップ２では、モジュール２を実行するため、動作モジュール情報４２１２に"Ｍｏｄｕｌｅ２"を設定し、参照数に１を設定する。
　次に、図６Ｅについて説明する。図６Ｅは、テストシナリオ２が終了し、テストシナリオ３のステップ１が実行されている状態である。したがって、テストシナリオ３に対応するレコードが新たに追加されている。また、テストシナリオ３のステップ１では、モジュール２を実行するため、動作モジュール情報４２１２に"Ｍｏｄｕｌｅ２"を設定し、参照数に１を設定する。
　最後に、図６Ｆについて説明する。図６Ｆは、テストシナリオ３のステップ２が実行されている状態である。テストシナリオ３のステップ２では、モジュール２を実行するため、動作モジュール情報４２１２の参照数に１を加算し、参照数が２となっている。その後、すべてのテストシナリオ４１０に基づくテストが完了したため、作成された実行情報テーブル４２１を、記憶装置４００の実行情報ファイル４２０に格納する。
　図７は、本発明の第１の実施の形態の関連情報採取処理の実行結果を出力する画面の一例を示す図である。
　前述のように、関連情報採取処理は、テストシナリオ４１０とテスト対象プログラム２２０に含まれる各モジュールとの関連を取得する処理である。ユーザからの要求によって関連情報採取処理が実行されると、図７に示すように、出力装置６００によってテストシナリオ４１０（６２０）とテスト対象プログラム２２０に含まれる各モジュール（６１０）との関連が出力される（６０１）。
　図７に示す例では、関連するモジュールと、テストシナリオとを線で接続することによって関連を示している（６３０）。また、接続される線は、参照数に応じて太さが設定される。したがって、"Ｓｃｅｎａｒｉｏ１"では"Ｍｏｄｕｌｅ１"の参照数が２、"Ｓｃｅｎａｒｉｏ２"では"Ｍｏｄｕｌｅ１"の参照数が１であるため、"Ｓｃｅｎａｒｉｏ１"と"Ｍｏｄｕｌｅ１"とを接続する線が"Ｓｃｅｎａｒｉｏ２"と"Ｍｏｄｕｌｅ１"とを接続する線よりも太くなるように表示されている。
　また、関連情報採取処理は、新規にテストを実行する場合など、実行情報テーブル４２１を新たに作成する場合に実行される処理であるため、各モジュールの修正情報及びテストシナリオの実行順序などの情報は出力されていない。また、図７では、テストシナリオの実行結果が出力されていないが、関連情報採取処理実行時のテスト結果を出力するようにしてもよい。
　さらに、モジュールが修正された後にテストを行う場合には、テスト対象プログラムの修正欄にチェックが付けられる。このとき、テストシナリオが実行対象であるか否か、また、テストシナリオの実行順序などが表示されるが、これらの表示を行うための具体的な手順については図８以降を参照しながら後述する。
　なお、図７に示した画面では、項目毎、例えば、テストシナリオの順番欄を選択してソートすることが可能となっている。例えば、テスト結果が出力されている場合には、テスト結果が正常のテストシナリオ又はテスト結果が異常のテストシナリオをまとめて表示することが可能となる。また、テストシナリオの名前を選択すると、選択されたテストシナリオの内容を参照できるようにしてもよいし、モジュールを選択した場合にモジュールのソースコードを参照できるようにしてもよい。こうすることによって、テスト結果が異常であった場合にテストシナリオの内容とモジュールの内容とをすぐに参照することが可能となる。
　以上、テストシナリオ４１０に基づくテストが実行されている場合に実行情報を取得する手順について説明した。続いて、システム開発の過程でモジュールが変更され、変更されたモジュールをテストするために再度テストを実行する場合について説明する。
　図８は、本発明の第１の実施の形態のテストシナリオ４１０に含まれる一部のモジュールが変更された場合のテストシナリオ４１０とテスト対象プログラム２２０との関係を説明する図である。
　図８に示すテストシナリオ４１０とテスト対象プログラム２２０との関係は、図３に示した関係と同じである。ただし、図８では、図３の状態からテスト対象プログラム２２０のモジュール２が更新された状態を示している。
　以下、図８を例として、実行情報テーブル４２１が作成された後に、テスト対象プログラム２２０のモジュール２が更新され、テストを再実行する手順について説明する。詳細については後述するが、変更されたモジュールを含むテストシナリオの実行を優先するなどして、テストの精度を向上させるようにテストシナリオの実行順序を決定する。
　図９は、本発明の第１の実施の形態のテスト対象プログラム２２０が変更された場合に実行情報ファイル４２０を更新する手順を説明する図である。
　テスト実行処理部２１０に含まれる各構成は、ＣＰＵ３００によって実行されるプログラムであるが、図４の説明と同様に、各構成を主体として説明する。
　まず、テスト対象プログラム制御処理部２１１は、テスト対象プログラム２２０をメモリ２００に読み込む。さらに、テスト対象プログラム２２０から変更されたモジュールを検出する。
　続いて、実行情報処理部２１３は、実行情報ファイル４２０から実行情報テーブル４２１を取得する。
　さらに、テストシナリオ制御処理部２１２は、テストシナリオ４１０を読み込む。そして、テストシナリオ実行判断処理部２１４によって、変更されたモジュールを実行するテストシナリオ４１０を優先するように、テストシナリオの実行順序を決定し、実行情報テーブル４２１に反映させる。その後の処理は、図４に示した処理と同じである。
　図１０は、本発明の第１の実施の形態のテスト対象プログラム２２０が変更された場合にテストを再実行する手順を示すフローチャートである。
　ＣＰＵ３００は、まず、テスト対象プログラム制御処理部２１１を実行し、テスト対象プログラム２２０を読み込む（Ｓ１００１）。続いて、テスト対象プログラム２２０を解析し、変更されたモジュールを検索する（Ｓ１００２）。
　変更されたモジュールを検索する方法としては、例えば、変更前のモジュール及び変更後のモジュールから日付情報などの動作コードと関係しない部分を除いて比較し、相違点が存在する場合にモジュールが変更されたと判定する。具体的には、いわゆるｄｉｆｆプログラムを利用して、変更前のモジュールの動作コードと、変更後のモジュールの動作コードとの差分を抽出し、差分が抽出された場合にはモジュールが変更されたと判定すればよい。ｄｉｆｆプログラムとは２つのデータ（ファイル）の相違点を抽出するためのプログラムである。なお、ｄｉｆｆプログラムの比較アルゴリズムに関しては、公知の技術であるため説明を省略する。なお、モジュールの比較は、ソースコードの内容を比較してもよいし、作成済みのモジュールと、当該モジュールの最新のソースコードによってビルドされた新たなモジュールとを比較してもよい。
　また、構成管理システムによってソースコードが管理されている場合には、ソースコードの変更情報及びモジュールの作成（ビルド）日時に基づいて、変更されたモジュールを特定してもよい。
　ＣＰＵ３００は、テストシナリオ実行判断処理部２１４によって、実行情報ファイル４２０に含まれる実行情報テーブル４２１を読み込む（Ｓ１００３）。そして、読み込まれた実行情報テーブル４２１と、Ｓ１００２の処理で検索された変更モジュールに基づいて、テストシナリオ実行順序決定処理を実行する（Ｓ１００４）。テストシナリオ実行順序決定処理では、変更されたモジュールを実行しないテストシナリオを実行するか否か、また、テストシナリオの実行順番などを決定し、実行情報テーブル４２１を更新する。テストシナリオ実行順序決定処理の詳細については、図１１にて後述する。
　ＣＰＵ３００は、テストシナリオ制御処理部２１２によって、テストシナリオ実行順序決定処理で更新された実行情報テーブル４２１に基づいて、テストシナリオ４１０を実行する（Ｓ１００５）。このとき、実行するテストシナリオ４１０に対応するテスト実行判定結果４２１５には、未実行を示す"－１"が設定されている。テストシナリオの実行が完了すると、テスト実行判定結果４２１５にテストの再実行が完了したことを示す"１"を設定する。
　このとき、Ｓ１００５の処理で実行されたテストに関連するテストシナリオについて、実行情報テーブル４２１の対応するレコードを更新する。具体的には、テスト実行時刻４２１４が設定され、実行されるモジュールの組み合わせが変更されていた場合には、動作モジュール更新情報４２１２も更新する。
　最後に、ＣＰＵ３００は、実行情報処理部２１３によって、更新された実行情報テーブル４２１を実行情報ファイル４２０に出力する（Ｓ１００６）。
　図１１は、本発明の第１の実施の形態のテストシナリオ実行順序決定処理の手順を示すフローチャートである。テストシナリオ実行順序決定処理は、ＣＰＵ３００がテストシナリオ実行判断処理部２１４を処理することによって実行される。
　ＣＰＵ３００は、テストシナリオ実行順序決定処理を実行すると、まず、実行順番管理リストを作成する（Ｓ１１０１）。実行順番管理リストとは、テストシナリオの実行順序を決定するために、一時的にテストシナリオを保持するリストである。
　次に、ＣＰＵ３００は、実行情報テーブル４２１から１レコードを読み込み、すなわち、１つのテストシナリオを取得する（Ｓ１１０２）。
　さらに、ＣＰＵ３００は、修正されたモジュールを実行するテストシナリオのみを実行するように、取得されたテストシナリオの実行順序を決定する（Ｓ１１０３）。
　具体的には、取得されたテストシナリオによって実行されるモジュールが修正されたモジュールである場合に、テストシナリオが取得された順序で実行順番４２１６に値を設定する。さらに、テスト実行判定結果４２１５に未実行であることを示す"－１"を設定する。
　なお、修正されたモジュールであるか否かは、取得されたテストシナリオのテスト実行時刻４２１４と、当該テストシナリオによって実行されるモジュールの更新時刻とを比較することによって判定してもよい。
　また、取得されたテストシナリオによって実行されるモジュールが修正されていないモジュールである場合には、テスト実行判定結果４２１５に再実行対象外であることを示す"０"を設定する。
　このように、修正されたモジュールを実行するテストシナリオにのみテスト実行判定結果４２１５に未実行を設定することによって、変更されていないモジュールのみが実行されるテストシナリオを除外することができる。したがって、変更されたモジュールを含むテストシナリオのみを実行することが可能となり、テストに要する時間を削減することが可能となる。
　最後に、ＣＰＵ３００は、実行情報テーブル４２１に含まれるすべてのテストシナリオに対してＳ１１０３の処理を実行したか否かを判定する（Ｓ１１０４）。すべてのテストシナリオに対してＳ１１０３の処理を実行した場合には（Ｓ１１０４の結果が「Ｙｅｓ」）、本処理を終了する。一方、すべてのテストシナリオに対してＳ１１０３の処理を実行していない場合には（Ｓ１１０４の結果が「Ｎｏ」）、未実行のテストシナリオを選択し、当該未実行のテストシナリオに対してＳ１１０２以降の処理を実行する。
　図１２は、本発明の第１の実施の形態のテスト再実行後の実行情報テーブル４２１の一例を示す図である。
　図８に示したように、モジュール２が変更されているため、モジュール１のみを実行するテストシナリオ１（"Ｓｃｅｎａｒｉｏ１"）は実行されない。すなわち、テスト実行判定結果４２１５の値が再実行対象外であることを示す"０"に設定されている。
　一方、モジュール２を実行するテストシナリオ２（"Ｓｃｅｎａｒｉｏ２"）及びテストシナリオ３（"Ｓｃｅｎａｒｉｏ３"）については、図１１のＳ１１０３の処理でテスト実行判定結果４２１５の値が未実行であることを示す"－１"に設定される。その後、図１０のＳ１００５の処理によってテストシナリオが再実行されることで、テスト実行判定結果４２１５の値が再実行対象であることを示す"１"が設定されている。
　なお、テスト実行順番４２１６は、テストを再実行する対象のテストシナリオについて先頭のレコードから昇順に実行順序が割り当てられる。テストを再実行する対象でないテストシナリオについては、テスト実行順番４２１６に"０"が設定される。
　図１３は、本発明の第１の実施の形態のテストの再実行結果を出力する画面の一例を示す図である。
　図１３に示す画面は、テストシナリオが一通り実行された後、テスト対象プログラム２２０に含まれるモジュールが修正された後、再テストを実行した結果を示している。具体的には、モジュール２のみが修正された場合を示している。そのため、テスト対象プログラムを示す表で、モジュール２（"Ｍｏｄｕｌｅ２"）に対応する修正欄には、修正されたことを示す"○"が出力されている。
　このとき、モジュール２を参照するテストシナリオ２（"Ｓｃｅｎａｒｉｏ２"）及びテストシナリオ３（"Ｓｃｅｎａｒｉｏ３"）の対象欄にテストを再実行する対象となることを示す"○"が出力されている。
　さらに、図１３のテストシナリオ欄を参照すると、テストシナリオ２を実行した後、テストシナリオ３が実行されるようにテスト実行順番が設定されている。また、実行するモジュールが修正されていないテストシナリオ１については、再実行対象外となっている。
　なお、順番欄に設定される値は、実行情報テーブル４２１の実行順番４２１６に基づいて設定される。また、テストシナリオの順番欄を選択することによって、テストシナリオの実行順序でソートして表示することが可能となっており、ユーザが容易にテストシナリオの実行順序を把握することができる。このとき、再実行対象外のテストシナリオについては、再実行対象のテストシナリオの後に続けて表示すればよい。
　また、図１３におけるテスト再実行時には、テストシナリオ２が実行された後、テストシナリオ３の実行中にテストが中断（キャンセル）されている。このため、テストシナリオ２に対応する実行欄には実行が完了したことを示す"○"及び結果欄にはテスト結果が正常（成功）であることを示す"ＯＫ"が出力されている。なお、テスト結果が異常（失敗）の場合には、例えば"ＮＧ"が出力される。また、テストシナリオ３に対応する実行欄には、テストが正常に終了しなかったことを示す"－"が出力されている。
　以上のように、本発明の第１の実施の形態によれば、テスト実行時にテストシナリオ毎に実行されるモジュールを取得して実行情報テーブル４２１を作成することによって、テストシナリオとモジュールの関連付けを自動的に行うことが可能となる。したがって、人間の思い込みなどによる人為的なミスを大幅に削減することが可能となる。
　本発明の第１の実施の形態によれば、テスト対象プログラム内の変更箇所（モジュール）を集中的にテストすることが可能となるため、テストに要する時間を短縮し、開発効率の向上を図ることが可能となる。
　本発明の第１の実施の形態によれば、変更されたモジュールを自動的に抽出し、実行情報テーブル４２１と比較することによって、変更されていないモジュールのみが動作するテストシナリオの実行を省略することが可能となる。したがって、変更されたモジュールを動作させるテストシナリオのみを実行させることが可能となり、テストもれを防ぎながらテストに要する時間を短縮することが可能となり、さらに、システム全体の品質を向上させることが可能となる。
　（第２の実施の形態）
　本発明の第１の実施の形態では、テスト対象プログラム２２０に含まれるモジュールが修正されると、修正されたモジュールを実行するテストシナリオのみが実行されるように制御されていた。第２の実施の形態では、リソースの共用などによって、モジュール間で連携しなくても修正されたモジュールの影響を受ける場合に対応するため、修正されたモジュールを実行するテストシナリオを実行した後に、修正されていないモジュールのみを実行するテストシナリオも実行するように制御する。
　なお、第２の実施の形態では、第１の実施の形態と同じ構成及び処理については共通の符号を付与し、説明を省略して相違点のみを説明する。
　図１４は、本発明の第２の実施の形態のテストシナリオの実行順序を変更する手順の概要を説明する図である。
　本発明の第２の実施の形態では、第１の実施の形態と同様に、変更のあったモジュールを実行するテストシナリオ（テストシナリオ２、テストシナリオ３）を特定し、特定されたテストシナリオを優先して実行するように実行順番を設定する。そして、変更のないモジュールのみを実行するテストシナリオ（テストシナリオ１）を、変更のあったモジュールを実行するテストシナリオの後に実行するように実行順番を設定する。
　以下、具体的な処理の手順について説明する。第２の実施の形態では、第１の実施の形態と同様に、最初に実行情報テーブル４２１を作成するために関連情報採取処理を実行する。そして、モジュールが修正された後に再テストを実行する場合には、第１の実施の形態と同様に再実行処理を実行する。関連情報採取処理及び再実行処理の手順については、第１の実施の形態と同様であるが、再実行処理におけるテストシナリオ実行順序決定処理の手順が相違する。
　図１５は、本発明の第２の実施の形態のテストシナリオ実行順序決定処理の手順を示すフローチャートである。
　ＣＰＵ３００は、テストシナリオ実行順序決定処理を実行すると、まず、実行順番管理リストを作成する（Ｓ１１０１）。
　次に、ＣＰＵ３００は、実行情報テーブル４２１から１レコードを読み込み、すなわち、１つのテストシナリオを取得する（Ｓ１１０２）。
　ＣＰＵ３００は、修正されたモジュールを実行するテストシナリオを修正されたモジュールを実行しないテストシナリオよりも優先して実行するように実行順序を決定する（Ｓ１５０１）。
　具体的には、取得されたテストシナリオに対し、修正されたモジュールを実行するテストシナリオ、及び修正されたモジュールを実行しないテストシナリオについて、それぞれに取得された順序でテスト実行順番を設定する。そして、すべてのテストシナリオが取得された場合には、修正されたモジュールを実行しないテストシナリオが修正されたモジュールを実行するテストシナリオの後に実行されるように、実行順番を再設定する。このとき、あらかじめ修正されたモジュールを実行するテストシナリオの数を取得し、修正されたモジュールを実行しないテストシナリオの実行順番を設定する際に取得された数を加算して設定するようにしてもよい。
　また、修正されたモジュールを実行するテストシナリオを実行順番管理リストの先頭から配置し、修正されたモジュールを実行しないテストシナリオを実行順番管理リストの最後から設定し、実行順番管理リストの先頭から実行順番を設定するようにしてもよい。この場合には、修正されたモジュールを実行しないテストシナリオの実行順番がテストシナリオを取得した順序と逆順になる。
　さらに、第２の実施の形態では、第１の実施の形態と異なり、すべてのテストシナリオを実行するため、すべてのテストシナリオについてテスト実行判定結果４２１５に未実行であることを示す"－１"を設定する。
　図１６は、本発明の第２の実施の形態のテスト再実行後の実行情報テーブル４２１の一例を示す図である。
　図１４に示したように、モジュール２が変更されているため、モジュール１のみを実行するテストシナリオ１は変更されたモジュール２を実行する他のシナリオ（テストシナリオ２、テストシナリオ３）よりも後に実行される。
　図１６を参照すると、テストシナリオ１にはテスト実行順番４２１６が３に設定されており、テストシナリオ２及びテストシナリオ３がよりも後に実行される。
　以上のように、第２の実施の形態によれば、変更されたモジュールを実行するテストシナリオに基づくテストを優先して実行し、変更されたモジュールを実行しないテストシナリオに基づくテストを後で実行することによって、限られた時間内で必要なテストを優先的に行なわせることが可能となり、テストの効率化を図ることが可能となる。また、変更されたモジュールを実行しないテストシナリオに基づくテストも実行されるため、リソースの共用などによってテストシナリオ間に依存関係が生じる場合であっても動作確認を行うことが可能となる。
　（第２の実施の形態の第１変形例）
　第２の実施の形態では、テストシナリオに含まれるモジュールが変更されたか否かによって当該テストシナリオの実行を優先するか否かを決定し、変更箇所の数などを考慮していなかった。そこで、変更されたモジュールを実行するステップを多く含むテストシナリオを優先するように制御する変形例について説明する。
　図１７は、本発明の第２の実施の形態の第１変形例のテストシナリオの実行順序を変更する手順の概要を説明する図である。
　本発明の第２の実施の形態の第１変形例では、変更のあったモジュールを実行するテストシナリオ（テストシナリオ２、テストシナリオ３）を特定し、さらに、変更されたモジュールの数に基づいて実行順番を設定する。このとき、テストシナリオ２では変更されたモジュール２を１回、テストシナリオ３では２回参照している。したがって、テストシナリオ３をテストシナリオ２よりも優先して実行するように実行順番が設定される。
　なお、変更のないモジュールのみを実行するテストシナリオについては、第２の実施の形態と同様に、変更のあったモジュールを実行するテストシナリオの後に実行するように実行順番を設定する。
　以下、具体的な処理の手順について説明する。第２の実施の形態の第１変形例では、第２の実施の形態と、テストシナリオ実行順序決定処理の手順が相違し、他の処理については同様である。
　図１８は、本発明の第２の実施の形態の第１変形例のテストシナリオ実行順序決定処理の手順を示すフローチャートである。
　第２の実施の形態の変形例のテストシナリオ実行順序決定処理は、Ｓ１５０１の処理がＳ１８０１の処理に置き換わり、その他の処理は共通である。
　ＣＰＵ３００は、読み込まれたレコードに対応するテストシナリオに含まれる修正されたモジュールの参照数を取得し、修正されたモジュールの数が多いテストシナリオを優先して実行するように実行順序を決定する（Ｓ１８０１）。
　具体的には、読み込まれたレコードに含まれる動作モジュール情報から、修正されたモジュールの参照数を取得し、修正されたモジュールが複数存在する場合には各モジュールの参照数を合計する。そして、修正されたモジュールの参照数とともにテストシナリオを実行順番管理リストに格納する。
　すべてのテストシナリオが実行順番管理リストに格納されると、修正されたモジュールの参照数が多い順にソートする。そして、ソートされた順序に基づいてテストシナリオの実行順番を設定する。なお、参照数が同じ場合には、先に読み込まれたレコードに対応するテストシナリオの実行順序が先になるようにする。
　また、第１の実施の形態のように、修正されたモジュールの参照数が０のテストシナリオを実行しない場合には、修正されたモジュールの参照数が０のテストシナリオに対応する実行判定結果欄の値を０（再実行対象外）に設定し、修正されたモジュールの参照数が１以上のテストシナリオに対応する実行判定結果欄の値を－１（未実行）に設定する。
　一方、第２の実施の形態のように、修正されたモジュールの参照数が０のテストシナリオを実行する場合には、すべてのテストシナリオについて、実行判定結果欄の値を－１（未実行）に設定する。
　図１９Ａ及び図１９Ｂは、本発明の第２の実施の形態の第１変形例のテスト再実行後の実行情報テーブル４２１の一例を示す図である。図１９Ａは、修正されたモジュールを含まないテストシナリオに基づくテストを実行しない場合を示し、図１９Ｂは、修正されたモジュールを含まないテストシナリオに基づくテストを実行する場合を示している。
　図１７に示したように、モジュール２が変更されているため、モジュール１のみを実行するテストシナリオ１は変更されたモジュール２を実行する他のシナリオ（テストシナリオ２、テストシナリオ３）よりも後に実行される。また、テストシナリオ２は変更されたモジュールの参照数が１、テストシナリオ３は変更されたモジュールの参照数が２であるため、テストシナリオの実行順番はテストシナリオ３が"１"、テストシナリオ２が"２"に設定されている。
　また、図１９Ａに示すように、修正されたモジュールを含まないテストシナリオを実行しない場合には、前述のように、テストシナリオ１のテスト実行判定結果を"０"（再実行対象外）に設定し、さらに、テスト実行順番を"０"に設定している。
　また、図１９Ｂに示すように、修正されたモジュールを含まないテストシナリオを実行する場合には、テストシナリオ１がテストシナリオ２及びテストシナリオ３が終了した後に実行されるように、テスト実行順番を"３"に設定している。
　以上のように、第２の実施の形態の第１変形例によれば、第２の実施の形態の効果に加え、変更されたモジュールを実行するテストシナリオの中でもさらに変更箇所の多いテストシナリオを優先して実行するため、より限られた時間内で効果的なテストを実行することが可能となる。
　（第２の実施の形態の第２変形例）
　第１の実施の形態、第２の実施の形態及び第２の実施の形態の変形例では、テストが中断され、再度テストを実行する場合には、最初からテストを行っていた。そのため、修正されたモジュールの数のテストシナリオ、実行情報テーブル４２１の後半に格納されたテストモジュールはテストの実行回数が少なくなり、品質にばらつきが発生するおそれがあった。
　そこで、第２の実施の形態の変形例として、すべてのテストシナリオが実行されずに、途中でキャンセルされた場合には、実行が完了していないテストシナリオを優先して実行するように実行順番を設定する。
　図２０は、本発明の第２の実施の形態の第２変形例のテストシナリオの実行順序を変更する手順の概要を説明する図である。
　本発明の第２の実施の形態の第２変形例では、前述のように、実行が完了していないテストシナリオを優先して実行するように実行順番を設定する。図２０の左側には、テストシナリオ１及びテストシナリオ２が実行された後、テストシナリオ３が実行される前にテストの実行がキャンセルされた状態を示している。また、図２０の右側には、テストシナリオ１及びテストシナリオ２が実行された後、テストシナリオ３が実行される前にテストの実行がキャンセルされた後にテストを実行する場合のテストシナリオの実行順序を示している。すなわち、未実行のテストシナリオ３が優先して実行されるように、テストシナリオ３が最初に実行されるように実行順番が設定されていることを示している。
　続いて、具体的な処理の手順について説明する。第２の実施の形態の第２変形例では、通常時には、第２の実施の形態の第１変形例と同様の手順でテストシナリオの実行順序を設定するように構成されている。また、第２の実施の形態の第１変形例とは、テストシナリオ実行順序決定処理の手順が相違し、他の処理については同様である。
　図２１は、本発明の第２の実施の形態の第２変形例のテストシナリオ実行順序決定処理の手順を示すフローチャートである。
　第２の実施の形態の第２変形例のテストシナリオ実行順序決定処理は、第１変形例のＳ１８０１の処理がＳ２１０１の処理に置き換わり、その他の処理は共通である。
　ＣＰＵ３００は、修正されたモジュールを実行し、かつ、前回のテスト実行時に未実行のテストシナリオを優先して実行するように実行順序をする（Ｓ２１０１）。
　具体的には、まず、修正されたモジュールを実行するテストシナリオでテスト実行判定結果が未実行（－１）、かつ、参照数（合計）が多い順にテスト実行順番を設定する。
　次に、修正されたモジュールを実行するテストシナリオでテスト実行判定結果が未実行でない（０又は１）、かつ、参照数（合計）が多い順にテスト実行順番を設定する。
　そして、修正されたモジュールを実行しないテストシナリオを実行しない場合には、修正されたモジュールを実行するテストシナリオのテスト実行判定結果欄を未実行（－１）に設定する。さらに、修正されたモジュールを実行しないテストシナリオのテスト実行判定結果欄を再実行対象外（０）に設定する。
　一方、修正されたモジュールを実行しないテストシナリオを実行する場合には、修正されたモジュールを実行しないテストシナリオでテスト実行判定結果欄が未実行（－１）、かつ、参照数（合計）が多い順番にテスト実行順番を続きから設定する。
　さらに、修正されたモジュールを実行しないテストシナリオでテスト実行判定結果欄が未実行でない（０又は１）、かつ、参照数（合計）が多い順番にテスト実行順番を続きから設定する。最後に、すべてのテストシナリオのテスト実行判定結果欄を未実行（－１）に設定する。
　なお、各手順で参照数（合計）が同じ場合には先に読み込まれたレコードに対応するテストシナリオが優先される。
　本発明の第２の実施の形態の第２変形例によれば、途中でテストをキャンセルした場合であっても、次回にテストを実行する際に、実行しなかったテストシナリオを優先させて実行させる。こうすることによって、テストの網羅性を高めることが可能となりシステムの品質を向上させることができる。
　（第３の実施の形態）
　第１の実施の形態及び第２の実施の形態では、テストシナリオで実行されるモジュールが更新された場合にテストを再実行する場合について説明したが、第３の実施の形態では、テストシナリオで実行されるモジュールが他のモジュールに変更された場合について説明する。例えば、新たにモジュールが作成された場合、モジュールが再構成された場合などが想定される。
　図２２は、本発明の第３の実施の形態のテストシナリオ４１０とテスト対象プログラム２２０との関係を説明する図である。
　第３の実施の形態では、初回実行時にはテストシナリオ３（"Ｓｃｅｎａｒｉｏ３"）のステップ１でモジュール１が実行されていたが（図２２左側）、再テスト実行時にはモジュール２を実行するように変更される（図２２右側）。
　図２３は、本発明の第３の実施の形態のテストシナリオで実行されるモジュールが変更された場合に再度テストを実行して実行情報ファイル４２０を作成する関連情報差分抽出処理の手順を示すフローチャートである。なお、図１０に示した第１の実施の形態における実行情報ファイル４２０を作成する手順と共通する処理については同じ符号を割り当てて説明を適宜省略する。
　ＣＰＵ３００は、第１の実施の形態と同様に、まず、テスト対象プログラム制御処理部２１１を実行し、テスト対象プログラム２２０を読み込む（Ｓ１００１）。続いて、テスト対象プログラム２２０を解析し、変更されたモジュールを検索する（Ｓ１００２）。なお、Ｓ１００２の処理では、変更されたモジュールを検出するが、モジュールが実行されるテストシナリオが変更されたことを検出する必要はない。
　ＣＰＵ３００は、テストシナリオ制御処理部２１２によって、実行情報ファイル４２０に含まれる実行情報テーブル４２１を読み込む（Ｓ２３０１）。Ｓ２３０１の処理で読み込まれた、変更前の構成のテストシナリオに基づく実行情報テーブル４２１を実行情報テーブル（Ａ）とする。また、後述するが、テストシナリオが変更された後、再テスト実行時の実行情報テーブルを実行情報テーブル（Ｂ）とする。
　そして、ＣＰＵ３００は、テストシナリオ実行判断処理部４２４によって、実行情報テーブル（Ａ）と、Ｓ１００２の処理で検索された変更モジュールに基づいて、テストシナリオ実行順序決定処理を実行する（Ｓ１００４）。テストシナリオ実行順序決定処理については、第１の実施の形態又は第２の実施の形態にて説明した手順を実行すればよい。
　その後、ＣＰＵ３００は、実行情報テーブル（Ａ）に基づいて、未実行のテストシナリオを順次実行する。このとき、実行情報処理部２１３によって、実行中のテストシナリオの実行情報を収集し、実行情報テーブル（Ｂ）を作成する（Ｓ２３０２）。
　ＣＰＵ３００は、テストの再実行が完了し、実行情報テーブル（Ｂ）が作成されると、実行情報処理部２１３によって、実行情報テーブル（Ａ）と実行情報テーブル（Ｂ）とを比較する（Ｓ２３０３）。そして、各テストシナリオで実行されるモジュールの構成の差分が存在するか否かを判定する（Ｓ２３０４）。差分が存在しない場合には（Ｓ２３０４の結果が「Ｎｏ」）、実行情報テーブル（Ａ）を実行情報ファイル４２０に実行情報テーブル４２１として出力する（Ｓ２３０７）。
　一方、ＣＰＵ３００は、実行情報テーブル（Ａ）と実行情報テーブル（Ｂ）との間に差分がある場合には（Ｓ２３０４の結果が「Ｙｅｓ」）、差分情報を出力する（Ｓ２３０５）。差分情報の出力は、画面（出力装置６００）に出力してもよいし、ファイルとして記憶装置４００に出力してもよい。
　さらに、ＣＰＵ３００は、実行情報テーブル（Ｂ）の動作モジュール情報４２１２を、実行情報テーブル（Ａ）に反映させる（Ｓ２３０６）。その後、実行情報テーブル（Ｂ）の動作モジュール情報４２１２が反映された実行情報テーブル（Ａ）を実行情報ファイル４２０に実行情報テーブル４２１として出力する（Ｓ２３０７）。
　図２４は、本発明の第３の実施の形態の関連情報差分抽出処理の実行結果を出力する画面の一例を示す図である。
　図２４に示す画面１６０１では、前回のテスト実行時の構成（１６１０、１６２０）と、今回のテスト実行時の構成（２６１０、２６２０）が出力されている。また、モジュールとテストシナリオの関係に変更があった場合には、関係を示す線が太線で表示されるなど、関係に変更がなかった場合と区別して表示される（１６３０、２６３０）。なお、今回のテスト実行時の構成については、モジュールとテストシナリオの関係のみを出力するようにしてもよいし、同時にテスト結果を表示するようにしてもよい。
　また、線の太さなどがモジュールとテストシナリオとの関係が変更されたか否かを示すことを示しているため、モジュールとテストシナリオとの関係を示す線を選択することによって参照数を表示するようにしてもよい。
　本発明の第３の実施の形態によれば、テストを実行するたびにテストシナリオとモジュールの関係情報を取得することによって、テストシナリオで実行されるモジュールが変更された場合であっても迅速に対応することが可能となる。
　また、本発明の第３の実施の形態によれば、テストシナリオとモジュールとの関係が変更された場合には差分情報を出力するため、意図しないシステム構成の変更などを早期に把握することが可能となる。
　以上に説明した実施形態では、テストシナリオ単位で実行情報を生成していたが、テストシナリオのステップ単位で実行情報を生成するようにしてもよい。ステップ単位で実行情報を生成することによって、テストシナリオ内の他のステップで実行されるモジュールが変更されたために、変更されていないモジュールのテストを再実行することを防ぐことができる。
　なお、この場合には、テストシナリオ単位でレコードが格納されている実行情報テーブルなどの情報を、ステップ単位で保持するように変更する必要がある。
　以上、本発明を添付の図面を参照して詳細に説明したが、本発明はこのような具体的構成に限定されるものではなく、添付した請求の範囲の趣旨内における様々な変更及び同等
の構成を含むものである。
　本発明は、システム開発におけるプログラムのテスト工程で利用可能である。

Claims (10)

  1. 　所定の機能を提供するモジュールを含むプログラムのテストを実行するテスト装置におけるテスト方法であって、
    　前記テスト装置は、前記プログラムを記憶する記憶部と、前記記憶部に記憶されたプログラムを実行するプロセッサと、を備え、
    　前記テストは、前記モジュールを実行する手順を含む複数のテスト定義情報に基づいて、当該各テスト定義情報を順次実行することによって実行され、
    　前記テスト装置は、
    　前記テスト定義情報に基づくテストの実行を制御するテストシナリオ制御処理部と、
    　前記各テスト定義情報によって実行されるモジュールの識別子を含む実行情報を作成する実行情報処理部と、
    　前記実行情報に基づいて、前記各テスト定義情報に基づくテストを実行するか否かを判定するテストシナリオ実行判断処理部と、を備え、
    　前記テスト方法は、
    　前記実行情報処理部は、前記テスト定義情報に基づいて実行されたモジュールを検出し、
    　前記実行情報処理部は、前記テスト定義情報ごとに、前記検出されたモジュールの識別子を前記実行情報に記憶し、
    　前記テストシナリオ実行判断処理部は、前記テストを再実行する場合には、前記実行情報に基づいて、当該テストが実行された後に更新されたモジュールを実行するように定義されたテスト定義情報を特定し、
    　前記テストシナリオ制御処理部は、前記特定されたテスト定義情報に基づくテストを優先して実行するテスト方法。
  2. 　請求項１に記載のテスト方法であって、
    　前記実行情報には、前記各テスト定義情報に基づくテストの実行時刻がさらに含まれ、
    　前記テスト方法は、
    　前記実行情報処理部は、前記各テスト定義情報に基づくテストが完了すると、当該各テスト定義情報に基づくテストの実行時刻を前記実行情報に記憶し、
    　前記テストシナリオ実行判断処理部は、前記モジュールが更新された時刻と、当該モジュールを実行する各テスト定義情報に対応する実行時刻とを比較することによって、当該テストが実行された後に更新されたモジュールを特定するテスト方法。
  3. 　請求項１に記載のテスト方法であって、
    　前記テストシナリオ制御処理部は、前記複数のテスト定義情報に基づくテストが中断された後に当該テストを再実行する場合には、当該テストが中断された際にテストが完了しなかったテスト定義情報に基づくテストを優先して実行するテスト方法。
  4. 　請求項１に記載のテスト方法であって、
    　前記実行情報には、前記テスト定義情報ごとに実行されるモジュールの実行回数が含まれ、
    　前記テスト方法は、前記テストシナリオ制御処理部は、前記更新されたモジュールの実行回数が多いテスト定義情報を、前記更新されたモジュールの実行回数が少ないテスト定義情報よりも優先して実行するテスト方法。
  5. 　請求項１に記載のテスト方法であって、
    　前記実行情報処理部は、前記検出されたモジュールの識別子と、前記実行情報に記憶されていたモジュールの識別子とが一致しない場合には、実行中のテスト定義情報によって実行されるモジュールの構成と、直前に実行されたテストにおいて対応するテスト定義情報によって実行されたモジュールの構成との差分情報を抽出し、
    　前記実行情報処理部は、前記抽出された差分情報に基づいて、前記実行情報を更新するテスト方法。
  6. 　請求項５に記載のテスト方法であって、
    　前記実行情報処理部は、前記実行中のテスト定義情報によって実行されるモジュールの構成と、前記直前に実行されたテストにおいて対応するテスト定義情報によって実行されたモジュールの構成との差分情報を出力するテスト方法。
  7. 　請求項１に記載のテスト方法であって、
    　前記実行情報処理部は、前記テスト定義情報と当該テスト定義情報によって実行されるモジュールとの関係、前記各テスト定義情報に基づくテストを実行する順序と、各テスト定義情報に基づくテストの実行結果と、を出力するテスト方法。
  8. 　請求項１に記載のテスト方法であって、
    　前記実行情報は、前記テスト定義情報によって実行されたモジュールごとに記録されるテスト方法。
  9. 　所定の機能を提供するモジュールを含むプログラムのテストを実行するテスト装置であって、
    　前記プログラムを記憶する記憶部と、前記記憶部に記憶されたプログラムを実行するプロセッサと、を備え、
    　前記テストは、前記モジュールを実行する手順を含む複数のテスト定義情報に基づいて、当該テスト定義情報を順次実行することによって実行され、
    　前記テスト装置は、
    　前記テスト定義情報に基づくテストの実行を制御するテストシナリオ制御処理部と、
    　前記プログラムの実行を制御するプログラム制御処理部と、
    　前記各テスト定義情報によって実行されるモジュールの識別子を含む実行情報を作成する実行情報処理部と、
    　前記実行情報に基づいて、前記各テスト定義情報に基づくテストを実行するか否かを判定するテストシナリオ実行判断処理部と、を備え、
    　前記実行情報処理部は、
    　前記テスト定義情報によって実行されたモジュールを検出し、
    　前記テスト定義情報ごとに、前記検出されたモジュールの識別子を前記実行情報に記憶し、
    　前記テストシナリオ実行判断処理部は、前記テストを再実行する場合には、前記実行情報に基づいて、当該テストが実行された後に更新されたモジュールを含むテスト定義情報を特定し、
    　前記テストシナリオ制御処理部は、前記特定されたテスト定義情報に基づくテストを優先して実行するテスト装置。
  10. 　所定の機能を提供するモジュールを含むプログラムのテストを実行するテスト装置で実行されるテスト実行用プログラムであって、
    　前記テストは、前記モジュールを実行する手順を含む複数のテスト定義情報に基づいて、当該テスト定義情報を順次実行することによって実行され、
    　前記テスト装置は、前記各テスト定義情報によって実行されるモジュールの識別子を含む実行情報を記憶し、
    　前記プログラムは、
    　前記テスト定義情報によって実行されたモジュールを検出する手順と、
    　前記テスト定義情報ごとに、前記検出されたモジュールの識別子を前記実行情報に記憶する手順と、
    　前記テストを再実行する場合に、前記実行情報に基づいて、当該テストが実行された後に更新されたモジュールを含むテスト定義情報を特定する手順と、
    　前記特定されたテスト定義情報に基づくテストを優先して実行する手順と、を含むプログラム。
PCT/JP2010/070373 2010-11-16 2010-11-16 テスト方法、テスト装置及びテスト実行用プログラム WO2012066635A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/070373 WO2012066635A1 (ja) 2010-11-16 2010-11-16 テスト方法、テスト装置及びテスト実行用プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/070373 WO2012066635A1 (ja) 2010-11-16 2010-11-16 テスト方法、テスト装置及びテスト実行用プログラム

Publications (1)

Publication Number Publication Date
WO2012066635A1 true WO2012066635A1 (ja) 2012-05-24

Family

ID=46083599

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/070373 WO2012066635A1 (ja) 2010-11-16 2010-11-16 テスト方法、テスト装置及びテスト実行用プログラム

Country Status (1)

Country Link
WO (1) WO2012066635A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018150507A1 (ja) * 2017-02-16 2018-08-23 三菱電機株式会社 テストケース選択装置およびテストケース選択プログラム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10320234A (ja) * 1997-05-21 1998-12-04 Hitachi Ltd ソフトウェアの自動テスト方法
JPH10334125A (ja) * 1997-05-28 1998-12-18 Toshiba Corp Ｃａｄソフト自動試験装置、ｃａｄソフト自動試験システム及び方法並びに記録媒体
JP2009265810A (ja) * 2008-04-23 2009-11-12 Dainippon Screen Mfg Co Ltd 状態遷移テスト支援装置、状態遷移テスト支援プログラム、および状態遷移テスト支援方法
JP2010122959A (ja) * 2008-11-20 2010-06-03 Nec Corp テスト支援システム、方法、及び、プログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10320234A (ja) * 1997-05-21 1998-12-04 Hitachi Ltd ソフトウェアの自動テスト方法
JPH10334125A (ja) * 1997-05-28 1998-12-18 Toshiba Corp Ｃａｄソフト自動試験装置、ｃａｄソフト自動試験システム及び方法並びに記録媒体
JP2009265810A (ja) * 2008-04-23 2009-11-12 Dainippon Screen Mfg Co Ltd 状態遷移テスト支援装置、状態遷移テスト支援プログラム、および状態遷移テスト支援方法
JP2010122959A (ja) * 2008-11-20 2010-06-03 Nec Corp テスト支援システム、方法、及び、プログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018150507A1 (ja) * 2017-02-16 2018-08-23 三菱電機株式会社 テストケース選択装置およびテストケース選択プログラム

Similar Documents

Publication Publication Date Title
US9619373B2 (en) Method and apparatus to semantically connect independent build and test processes
JP4667386B2 (ja) 業務モデル図作成支援プログラム、業務モデル図作成支援方法、および業務モデル図作成支援装置
US9201632B2 (en) Systems and methods for incremental software development
US7926038B2 (en) Method, system and computer program for testing a command line interface of a software product
US20140380279A1 (en) Prioritizing test cases using multiple variables
EP3265916B1 (en) A method for identifying a cause for a failure of a test
US9632769B2 (en) Software build optimization
US20100218168A1 (en) System and Method for Generating a Test Environment Script File
US8584095B2 (en) Test support system, method and computer program product, which optimize test scenarios to minimize total test time
US20030088810A1 (en) Methods and apparatus for determining software component sizes associated with errors
JP6070847B2 (ja) 検証方法、検証装置および検証プログラム
US20090217259A1 (en) Building Operating System Images Based on Applications
JP2008204405A (ja) ソフトウェアのリグレッションテストシステム、リグレッションテストプログラムおよびリグレッションテスト方法
CN110737573B (zh) 用户界面ui自动化测试的方法和装置
WO2012066635A1 (ja) テスト方法、テスト装置及びテスト実行用プログラム
JP2005338987A (ja) 例外テスト支援プログラム及び例外テスト支援装置
CN109019217B (zh) 一种电梯控制软件现场调试系统
US20100251246A1 (en) System and Method for Generating Job Schedules
JP2013008304A (ja) プログラム分析装置、プログラム分析方法、及びプログラム
JP2009157505A (ja) ソフトウェア変更影響分析装置
JP2009064125A (ja) サーバ装置、そのプログラム
JP6926921B2 (ja) コンパイルプログラム、コンパイル方法及び並列処理装置
JP6397800B2 (ja) テスト支援システムおよびテスト支援方法
GB2539961A (en) Code hotspot encapsulation
CN113448825A (zh) 新增软件缺陷的确定方法、装置、设备及存储介质

Legal Events

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

Ref document number: 10859661

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: 10859661

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP