JP5082797B2 - Software partial test system - Google Patents

Description

The present invention relates to a software portion testing system for testing a portion of the computer software.

  Non-Patent Document 1 describes a method for performing a test by simulating a part outside a test target range using a stub as a technique related to a partial test of modularized software. A stub is a dummy module that simulates the behavior of a submodule called from a module within the test target range, and is expected to be limited to the input values required for test execution out of the original module behavior. It is made to return street output. For example, in the case of software that calls module X as another creation module Y and wants to test only module X, even if module Y is inoperable, the test can be performed by replacing module Y with a stub. Can be implemented. Further, for example, when it is desired to test the operation of the module X when the behavior of the module Y is changed, the object can be achieved by replacing the module Y with a stub.

Further, for example, Patent Literature 1 describes a temporary stub that receives a call to a stub and a software test method that is realized as an actual stub that performs a predetermined single operation. In the software test method described in Patent Document 1, the correspondence between a temporary stub and an actual stub is defined using an argument value and an internal condition at the time of calling the temporary stub, and the actual stub determination process is performed when the test is performed. argument values and internal conditions when calling run to determine the actual stub to be executed based on.

JP 2000-132425 A Boris Beizer, Akira Onoma, "Software Test Technique", 1st edition, Nikkei BP Publishing Center, February 1994, p. 375

  The problem is that if you want to change or supplement the behavior of the module used for the test instead of the entire input value, it is necessary to re-implement the input value that does not need to be changed or completed in the stub. That is.

  In the test method described in Patent Document 1, the operation of the stub can be switched according to the test condition, but the behavior of the module used for the test is partially changed or supplemented by the stub. Nothing is taken into account. That is, it is the same as a general stub in that the stub replaces the operation of the entire module.

Accordingly, the present invention is, intended to provide to test a portion of software, or partially modify the behavior of the module to be used for testing by a stub, the software portion testing system that can be or supplemented To do.

A software partial test system according to the present invention is a software partial test system for testing a part of computer software, and includes at least a module to be tested, a dependent module that is a submodule called from the module, and the dependent module Module execution means that executes stubs that perform only part of the behavior of the procedure performed by the module according to the contents of each description, and the module execution means receives a call from the test target module to the dependent module on behalf of the dependent module. Upon receiving the call, to determine whether to or stub to the module that executes the processing of the call and the dependent module according conditional expression described with respect to the contents of the data in the program at the time the call Characterized in that it comprises a processing delegation means for the determined module to execute processing of the call.

  According to the present invention, when a part of software is tested, the behavior of the module used for the test can be partially changed or supplemented by the stub.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a block diagram showing a configuration example of a software partial test system according to the present invention. The software partial test system shown in FIG. 1 includes at least a module to be tested, a dependent module that is a submodule called from the module, and a stub that acts as a proxy for the procedure performed by the dependent module. Module execution means 10 is provided for executing according to the description content. Then, the module execution means 10 detects a call from the test target module to the dependent module, determines whether it is a dependent module or a stub as a module for executing the processing of the call, according to a predetermined condition, and in response to the determination, Processing delegation means 11 for executing processing is included.

  For example, the process delegation unit 11 performs the process of the call based on the truth value of the conditional expression described with respect to the contents of the data in the program at the time of the call (for example, the parameter value or other variable value of the call). A module to be executed may be determined.

  Specifically, the module execution means 10 is realized by an information processing apparatus that operates according to a program such as a CPU. Note that the processing delegation unit 11 may be implemented as a module of a test application, for example. For example, it may be incorporated as a function of a debugger or a test tool.

  Hereinafter, a more specific configuration will be described. FIG. 2 is a block diagram showing a more specific configuration example of the software partial test system. As shown in FIG. 2, the software partial test system in this embodiment includes a control unit 100. The control unit 100 includes a test driver execution unit 101, a test target module execution unit 102, a delegation destination control unit 103, a dependency module execution unit 104, and a stub execution unit 105.

  The test driver execution unit 101 executes a test driver that makes a procedure call to the test target module according to the test case in order to test the test target module group. Note that the test driver execution unit 101 is a processing unit corresponding to a part of the module execution unit 10 shown in FIG.

  The test target module execution unit 102 executes the test target module group in response to the procedure call from the test driver execution unit 101. The test target module execution unit 102 is a processing unit corresponding to a part of the module execution unit 10 illustrated in FIG. 1 that executes the test target module.

  The delegation destination control unit 103 temporarily intercepts and accepts a call to a dependent module that is a submodule called from the test target module, and determines whether to delegate the execution of the process to the dependent module or to the stub according to the conditional expression 201. Decide and delegate execution of the processing of the call according to the decision (hand over control). The delegation destination control unit 103 is a processing unit corresponding to the processing delegation unit 11 shown in FIG. In the present embodiment, the delegation destination control unit 103 is described as the conditional expression 201 for determining the transfer destination regarding the contents of data in the program at the time of the call (for example, the parameter value of the call and other variable values). Holds logical expressions.

  The dependency module execution unit 104 executes a dependency module having a call relationship with a procedure with the test target module. For example, when there is a statement in the test target module A that calls the module B that is not the test target module, the test target module A has a calling relationship with the dependency module B. In this embodiment, in the call from the test target module A to the dependency module B, the control is not transferred directly to the dependency module execution unit 104 but is once transferred to the delegation destination control unit 103. The dependency module execution unit 104 is a processing unit corresponding to a part that executes the dependency module in the module execution unit 10 shown in FIG.

  For example, using an aspect-oriented language, the code that calls the procedure performed by the dependent module is grouped into a single component as a cross-cutting concern. It can be realized by operating according to a program written to be controlled. Also, for example, by defining the type of procedure executed by the dependent module in advance, and implementing a debug command that rewrites the execution code at the breakpoint using the code that calls the procedure that matches the type as the breakpoint It is also possible to do.

  The stub execution unit 105 executes a stub that replaces the procedure of the dependent module that is a sub-module called from the test target module. The dependency module execution unit 104 is a processing unit corresponding to a part that executes a stub in the module execution unit 10 shown in FIG.

  In the above example, the test driver execution unit 101, the test target module execution unit 102, the delegation destination control unit 103, the dependency module execution unit 104, and the stub execution unit 105 are shown as separate processing units. It is not necessary to be implemented as a processing unit that operates. For example, each processing unit can be implemented as a module of a test application. In such a case, each processing unit is realized by a single CPU that executes an application program in which modules that operate the respective processing units are combined by a linker or the like. Further, for example, each processing unit can be incorporated as a function of a debugger or a test tool. In such a case, each processing unit reads the source code or object file of the test target module, and the CPU that operates according to the debug program described to perform the operation of each processing unit according to the execution code. Realized.

  FIG. 3 shows a configuration example of a software partial test system in which all procedures performed by the dependency module are replaced with stubs in comparison with the present invention. The difference from the embodiment shown in FIG. 2 is that the delegation destination control unit 103 is not provided. In the example shown in FIG. 3, all procedures performed by the dependency module are delegated by stubs. On the other hand, in the present invention, instead of completely replacing a dependent module with a stub, the delegation destination control unit 103 receives the call and delegates the processing to either the dependent module or the stub. Yes.

  Next, the operation of this embodiment will be described. FIG. 4 is a flowchart showing an example of the operation of the software partial test system in the present embodiment. In the example illustrated in FIG. 4, the test driver execution unit 101 executes the test driver, and the test target module execution unit 102 executes the test target module group in response to the procedure call from the test driver, thereby The instructions included in the module are sequentially issued (step A110). At this time, if the issued instruction is not a call to the dependency module (No in step A111), the test target module execution unit 102 follows the content of the context in which the instruction is issued (that is, the description of the test target module). The process is executed (step A112). When the processing for the instruction in the test target module is completed, control may be returned to the call source test driver execution unit 101.

  On the other hand, when the issued instruction is a call to the dependent module (Yes in Step A111), the delegation destination control unit 103 receives a call instruction by the instruction instead of the dependent module execution unit 104 (Step A113). ).

  The delegation destination control unit 103 evaluates the conditional expression 201 associated with the procedure related to the received call instruction (the procedure of the called delegation module) (step A114). The conditional expression 201 is, for example, a conditional expression described regarding the parameter value of the call. Further, for example, it may be a conditional expression described with respect to a variable value at the time of calling. Further, for example, it may be a conditional expression described with respect to the parameter value of the call and the variable value at the time of the call. For example, the delegation destination control unit 103 may evaluate by executing the conditional expression 201 described as the program code in the context in which the received instruction is issued. Further, for example, the evaluation may be performed by substituting the data contents in the program at the current time into the conditional expression 201 held independently of the program code.

  Here, if the evaluation result of the conditional expression 201 is true, the delegation destination control unit 103 delegates the execution of the process to the dependent module execution unit 104 in order to cause the dependent module to execute the procedure related to the call instruction. (Steps A115 and A116).

  On the other hand, if the evaluation result of the conditional expression 201 is false, the execution of the procedure is delegated to the stub execution unit 105 in order to cause the stub to execute the procedure related to the call instruction (steps A115 and A117).

  The process shown in the flowchart of FIG. 4 is repeated each time an instruction included in the test target module group is executed.

  Next, the operation of this embodiment will be described using a specific example. FIG. 5 is an explanatory diagram showing an example of a program module to be implemented in the software partial test system. In the Java (registered trademark) program shown in FIG. 5, the test target module X has a calling relationship with the dependency module Y and the dependency module Z. The only method func1 that the test target module X has is realized by using the method func2 that the dependency module Y has and the methods func31, func32, and func33 that the dependency module Z has.

  Now, func2 is incomplete and correct operation is guaranteed only when the argument n is positive. Otherwise, an exception is generated. In this situation, in order to suppress the occurrence of exceptions and complete the test, in this embodiment, the behavior of the dependency module Y is partially changed.

  FIG. 6 is an explanatory diagram showing an example of the software partial test system in the present embodiment. In the example shown in FIG. 6, an aspect Y_deregulator is defined by an aspect-oriented language as a component for processing delegation. In aspect-oriented languages, functions that have been assigned apart so as to span related components and objects (called “interests” in aspect-oriented languages. These are points to consider in implementation such as entities on the model and distributed processing. Is a language whose goal is to implement a function that bundles it as an independent component. The example shown in FIG. 6 is an example in which the delegation destination control unit 103 is realized by creating a program using AspectJ, which is a programming language in which an extension for the aspect-oriented technology is applied to the Java language.

  In AspectJ, in addition to components such as class and interface, a component called aspect can be declared so that crossing concerns can be combined into a single component. In the aspect component, some advice can be described. The advice here corresponds to a method called class. For example, the body of advice is automatically inserted at the location specified by the pointcut in the method body so that the method is automatically inserted into the child class definition by the inheritance mechanism. Therefore, when the execution of the program arrives at the location specified by the pointcut, the advice body can be executed like a method.

  The aspect Y_deregulator shown in FIG. 6 is an aspect component whose point cut is the code that calls the method func2 possessed by the dependency module Y, and as an advice, the method func2 possessed by the dependency module Y is called as it is based on a conditional expression or is replaced with a stub. A code for switching whether to call the method Y_stub_func2 is written.

  In FIG. 6, “pointcut atFunc2 (int n): call (int Y.func2 (int n) && (args (i))” is a point for intercepting the call to the method func2 of the dependent module Y together with the argument information. Cut is defined, and “int around (int n): atFunc2” means that the processing contents for the intercepted call are defined in the subsequent block, and “proceed (n) "" Indicates that the procedure of the original call destination is executed.

  In this example, when a test for confirming that “func1 (5,10)> 0” and “func1 (−5,10) <0” is executed, when the first argument p = 5 of the method func1, Since the argument n = 5 is passed to func2, the logic of the method func2 of the original dependency module Y is executed according to the conditional expression “(n> 0)?”. Since the argument n = -5 is passed to the method func2 when the first argument p = -5 of the method func1, the logic of the method Y_stub_func2 implemented as a stub of the dependency module Y follows the similar conditional expression. Executed.

  Here, for example, even if it becomes necessary to test the first argument p = 7, 10 of the method func1 as a test pattern, there is no need to change the stub accordingly, and the conditional expression “(n> 0)? The logic of func2 whose operation is guaranteed with "" can be used as it is.

  As described above, according to the present embodiment, it is not necessary to substitute all of the dependent modules with stubs, and only partial behavior can be delegated to stubs. For example, when it is desired to change the behavior of the dependency module only for a part of the input range, only the behavior related to the input range to be changed needs to be defined in the stub. This is because, in the present embodiment, since the delegation destination control unit 103 is provided, it is possible to switch whether the call to the dependency module is directly processed by the dependency module or the stub by a conditional expression.

  In the above-described embodiment, at least the module to be tested, the dependent module that is a sub-module called from the module, and the stub that substitutes the behavior of the procedure performed by the dependent module are described in the respective contents. The module execution means detects a call from the test target module to the dependent module and determines whether the module that executes the processing of the call is a dependent module or a stub according to a predetermined condition. A configuration example of a software partial test system including a process delegation unit that executes the process of the call according to the determination is shown (see FIG. 1).

  In the above embodiment, the software delegation unit determines a module that executes the process of the call based on the truth value of the conditional expression described with respect to the content of the data in the program at the time of the call. A configuration example of the test system is shown.

  In the above embodiment, there is a configuration example of the software partial test system in which the process delegation unit determines a module that executes the process of the call based on the truth value of the conditional expression described with respect to the parameter value of the call. It is shown.

  In the above-described embodiment, the configuration of the software partial test system in which the process delegation unit determines the module that executes the process of the call based on the truth value of the conditional expression described with respect to the variable value at the time of the call. An example is shown.

  In the above-described embodiment, the process delegation means determines the module for executing the call processing based on the truth value of the conditional expression described with respect to the parameter value of the call and the variable value at the time of the call. A configuration example of a partial test system is shown.

  Also, in the above embodiment, the process delegation means uses an aspect-oriented language to control the delegation destination of the process by a conditional expression in an aspect component whose point cut is a code that calls a procedure performed by a dependent module. A configuration example of a software partial test system realized by an information processing apparatus that operates according to a programmed program is shown.

  The present invention can be suitably applied to a partial test when software is divided into a plurality of modules and developed in parallel.

It is a block diagram which shows the structural example of the software partial test system by this invention. It is a block diagram which shows the more specific structural example of a software partial test system. It is explanatory drawing which shows the structural example of the software partial test system which substitutes all the procedures which a dependence module performs with a stub. It is a flowchart which shows an example of operation | movement of the software partial test system in this embodiment. It is explanatory drawing which shows the example of the program module used as implementation object. It is explanatory drawing which shows one Example of a software partial test system.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 Module execution means 11 Processing delegation means 100 Control part 101 Test driver execution part 102 Test object module execution part 103 Delegation destination control part 104 Dependent module execution part 105 Stub execution part

Claims (5)

A software partial test system for testing a part of computer software,
A module that executes at least a module to be tested, a dependent module that is a submodule called from the module, and a stub that performs only a part of the behavior of the procedure performed by the dependent module in accordance with each description content With execution means,
Said module execution means
Receiving from the test target module on behalf of the call to the dependent module to the dependent module, upon receiving the call, or to or stub to the module that executes the processing of the call and the dependent module at the time the call A software partial test system comprising processing delegation means for determining according to a conditional expression described with respect to data contents in a program and causing the determined module to execute the processing of the call. Processing delegation means, software portions testing system of claim 1, based on the truth value of the described condition with respect to calls of parameter values to determine a module for executing the processing of the call. Processing delegation means, software portions testing system according to claim 1 for determining based on the truth value of the described condition with respect to the variable value of a call point, the module for executing the processing of the call. Processing delegation means, based on the truth value of the described condition with respect to the variable value at the time of parameter values and call invocation, software portions testing according to claim 1 for determining a module that performs processing of the call system. The process delegation means uses an aspect-oriented language to process information according to a program written to control the process delegation destination by a conditional expression within an aspect component whose point cut is the code that calls the procedure performed by the dependent module. software portion testing system according to any one of claims 1 to 4 which is realized by the device.

Images