JP2014203384A - Unit test support device, and unit test support program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a unit test support device capable of simplifying a work in a unit test of a software.SOLUTION: A function replacement part 121 inputs an identifier of a replaced function 112 rewritten in a test object program 110, and an identifier of a substitution function 102 for rewriting the replaced function 112. An address solution part 122 acquires an address of a rewritten position of the test object program 110 from the identifier of the replaced function 112. A program rewritable part 123 rewrites the test object program 110 at the address acquired by the address solution part 122 to rewrite the replaced function 112 with the substitution function 102.

Description

  The present invention relates to a unit test support apparatus and a program for performing a unit test of software.

  A software engineer may test a program under test in units of functions in a software unit test. In general, a unit test is composed of a test target function, a test driver, and a test stub. The test driver sets the test precondition, calls the function under test, and checks the postcondition. The test stub is a dummy of another function called by the test target function. By replacing the function used by the test target function with a dummy test stub as the software configuration at the time of the test, the execution flow of the test target function can be easily controlled. As a result, the software engineer can proceed with testing more efficiently.

  In general, replacement of a function with a dummy stub is performed by linking an object file including a definition of a dummy stub with a file including a test driver or a test target function instead of an object file including a definition of a function to be replaced. Therefore, when the function to be tested and the function to be replaced by the test stub are described in the same source file, it is difficult to replace the function to be replaced with the test stub.

  For this reason, in software development for testing using test stubs, even if the software configuration is unnatural, the replacement candidate function can be described in a source file separate from the test target program, or the preprocessor can be used only during testing. It was necessary to devise such as excluding replacement candidate functions from the compilation target by directives. As a result, the use of the test stub has a problem that the maintainability of the software deteriorates in some cases.

  In order to solve such a problem, even if the function to be replaced is defined in the same file as the test target program, a mechanism for changing the behavior of the program without changing the source code is required. As a method of providing such a mechanism, there has been a method of converting a code (for example, Patent Document 1).

JP 2009-237610 A

  However, in the conventional method, it is necessary to describe the function hook conditions separately from the test description in the test driver. For this reason, in order to create a test case, a software engineer needs to edit a plurality of files, and there is a problem that the work is complicated.

  The present invention has been made to solve the above-described problems, and an object of the present invention is to provide a unit test support apparatus that can simplify the work in the unit test of software.

  The unit test support apparatus according to the present invention tests from the identifier of the function to be replaced that is rewritten in the program to be tested, the function replacement unit that inputs the identifier of the replacement function for rewriting the function to be replaced, and the identifier of the function to be replaced. An address resolution unit that acquires the address of the rewrite position of the target program, and a program rewrite unit that rewrites the function to be replaced with a replacement function by rewriting the test target program at the address acquired by the address resolution unit.

  Since the unit test support device of the present invention acquires the address of the rewriting position of the test target program from the identifier of the replacement function, and rewrites the replacement target function with the replacement function by rewriting the test target program of this address, Work in software unit tests can be simplified.

It is a block diagram which shows the unit test assistance apparatus by Embodiment 1 of this invention. It is a flowchart which shows operation | movement of the test driver of the unit test assistance apparatus by Embodiment 1 of this invention. It is explanatory drawing which shows typically the function call before the function substitution of the unit test assistance apparatus by Embodiment 1 of this invention. It is explanatory drawing which shows typically the function call after function substitution by the function head rewriting of the unit test assistance apparatus by Embodiment 1 of this invention. It is a flowchart which shows the process of the test assistance part by the function head rewriting of the unit test assistance apparatus by Embodiment 1 of this invention. It is a flowchart which shows the detail of the object file read-out process of the unit test assistance apparatus by Embodiment 1 of this invention. It is a flowchart which shows the detail of the function head address acquisition process of step ST502 of the unit test assistance apparatus by Embodiment 1 of this invention. It is a flowchart which shows the detail of the symbol search process of the unit test assistance apparatus by Embodiment 1 of this invention. It is a flowchart which shows the function head address acquisition process of the unit test assistance apparatus by Embodiment 2 of this invention. It is a flowchart which shows the function head address acquisition process of the unit test assistance apparatus by Embodiment 3 of this invention. It is explanatory drawing which shows typically the function head address acquisition of the unit test assistance apparatus by Embodiment 4 of this invention. It is a flowchart which shows the function head address acquisition process of the unit test assistance apparatus by Embodiment 4 of this invention. It is explanatory drawing which shows typically the section head address acquisition of the unit test assistance apparatus by Embodiment 4 of this invention. It is a flowchart which shows the section head address acquisition process of the unit test assistance apparatus by Embodiment 4 of this invention. It is a flowchart which shows the process of the test assistance part of the unit test assistance apparatus by Embodiment 5 of this invention. It is explanatory drawing which shows typically the shared library function call before the function substitution of the unit test assistance apparatus by Embodiment 6 of this invention. It is explanatory drawing which shows typically the shared library function call after the function substitution of the unit test assistance apparatus by Embodiment 6 of this invention. It is a flowchart which shows the process of the test assistance part of the unit test assistance apparatus by Embodiment 6 of this invention. It is a flowchart which shows the function address reference rewriting process of the unit test assistance apparatus by Embodiment 6 of this invention. It is a flowchart which shows the function substitution process of the unit test assistance apparatus by Embodiment 7 of this invention. It is a block diagram which shows the unit test assistance apparatus by Embodiment 8 of this invention. It is a block diagram which shows the unit test assistance apparatus by Embodiment 9 of this invention.

Embodiment 1 FIG.
FIG. 1 is a block diagram showing a unit test support apparatus according to Embodiment 1 of the present invention.
The unit test support apparatus shown in FIG. 1 includes a test setting unit 100, a test target program 110, a test support unit 120, and a language processing unit 130. This unit test support apparatus assumes a unit test of the test target function 111 in the test target program 110. The purpose of the unit test is to confirm that the test target function 111 is implemented as specified.

  The test setting unit 100 includes a test driver 101 and a replacement function (test stub) 102. The test setting unit 100 is realized by a computer executing a test description program. This test description program is composed of one or more source programs.

  During the test, the test target function 111 is executed by replacing the replacement function 112 originally used by the test target program 110 with the replacement function 102 which is a test stub. The test driver 101 calls the test target function 111. Further, the test driver 101 has a function of replacing the function to be replaced 112 with the replacement function 102 at the time of execution by calling the function replacement unit 121 of the test support unit 120.

  The test target program 110 is a program to be tested, and the test target function 111 is a function to be a unit test target in the test target program 110. The replacement function 112 is a function that is called from the test target function 111 and replaced by the replacement function 102.

  The test support unit 120 is called by the test driver 101 and performs processing for replacing the function to be replaced 112 in the test target program 110 with the replacement function 102. The function replacement unit 121, the address resolution unit 122, and the program rewrite unit 123 are I have. The function replacement unit 121 has a function of inputting the identifier of the function to be replaced 112 and the identifier of the replacement function 102 and causing the address resolution unit 122 and the program rewriting unit 123 to execute based on these inputs. The address resolution unit 122 is a processing unit that acquires the address of the rewrite position of the program from the identifier of the function 112 to be replaced. The program rewriting unit 123 is a processing unit that replaces the replacement function 112 with the replacement function 102 by rewriting the program at the address acquired by the address resolution unit 122.

  The language processing unit 130 is a processing unit that creates an executable file for performing a test from the test description program used by the test setting unit 100, the test target program 110, the replacement result in the test support unit 120, and a necessary library. The test program 140 is an executable file.

  The function units and the language processing unit 130 in the test setting unit 100 and the test support unit 120 are configured by programs for realizing the respective functions and hardware such as a CPU and a memory for executing these programs. And implemented using a computer. These programs can be stored in a storage medium in the form of source code, relocatable object file, static library, shared library, or the like.

Next, the test driver 101 in the test setting unit 100 will be described. The main process of the test driver 101 is to set a precondition necessary for the execution of the test target function 111, call the test target function 111, and confirm the post condition after the call.
FIG. 2 shows a processing flow of the test driver 101.
In step ST201, the test driver 101 sets a precondition that is assumed to be executed by the test target function. Specifically, initialization of input variables used by the test target function 111 is performed. Step ST202 is processing to replace the function used by the test target function 111 with the replacement function 102. The test driver 101 calls the function replacement unit 121 provided by the test support unit 120, so that the test support unit 120 replaces the replaced function 112 with the replacement function 102. In the present embodiment, the identifier of the test target program 110 itself, the identifier of the function to be replaced 112, and the identifier of the replacement function 102 are input to the function replacement unit 121. In the following description, the file name of the test target program 110 is specifically used as the identifier of the test target program 110, the name of the function to be replaced is used as the identifier of the function to be replaced 112, and the address of the replacement function is used as the identifier of the replacement function 102. However, it should be noted that the identifier format is not limited to this. In the case of the test driver 101 configured in the C / C ++ language, the address of the replacement function 102 is a value that can be acquired by & as the address reference operator.

In step ST203, the test target function 111 is called. At this time, if there is a return value of the test target function 111 later, the test driver 101 stores it.
Step ST204 is processing for confirming whether or not the test target function 111 operates as expected. As a post-condition, a value changed by the test target function 111, a return value of the test target function stored in step ST203, and the like are confirmed. When a general test framework such as xUNIT is used, the test driver 101 uses an assertion provided by the framework to check the post-condition.

Next, function replacement processing will be described.
First, referring to FIG. 3 and FIG. 4, the state of function calls before and after function replacement in the test target function 111 will be described, and then function replacement processing will be described.
FIG. 3 is a schematic diagram of a function call before function replacement. The test target function 301 and the function to be replaced 302 are programs stored in the main memory of the computer. The test target function 301 and the replaced function 302 correspond to the test target function 111 and the replaced function 112 in FIG. The test target function 301 includes a call instruction CALL to the replaced function 302. When the computer executes a call instruction to the function to be replaced 302, the program counter of the computer moves to the address of the function to be replaced 302. When the computer executes the function to be replaced 302 and executes the function return instruction ret of the function to be replaced 302, the control is transferred to the test target function 301.

FIG. 4 is a schematic diagram of function call after function replacement by function head rewriting in the present embodiment. FIG. 4 also shows a replacement function 403 on the main memory in addition to FIG. Here, the test target function 401, the replaced function 402, and the replacement function 403 correspond to the test target function 111, the replaced function 112, and the replacement function 102 in FIG.
The difference from FIG. 3 is the head portion of the function to be replaced 402. The instruction at the head of the function to be replaced 402 is rewritten as an unconditional branch instruction JMP instruction to the replacement function 403. When the computer executes a call instruction CALL to the replacement function 402 of the test target function 401, the program counter becomes the start address of the replacement function 402. Since there is an unconditional branch instruction to the replacement function 403 at the head, the computer control immediately moves to the head of the replacement function 403. When the function return instruction ret is executed in the replacement function 403, control is transferred to the instruction immediately after the replacement function 402 call instruction in the test target function 401.

Next, a function replacement process for changing the function call of FIG. 3 to the function call of FIG. 4 will be described with reference to FIG.
FIG. 5 is a processing flow of the test support unit 120 of FIG. 1 by function head rewriting. Note that the processing of the address resolution unit 122 in FIG. 1 corresponds to step ST502, and the processing of the program rewriting unit 123 corresponds to step ST503.
The input of the function replacement process is the file name of the test target program 110, the name of the function to be replaced 112, and the address of the replacement function 102. The outline of this process is to analyze the executable file of the test target program 110 to be input, resolve the address of the program rewrite location, and rewrite the program at that location. In the present embodiment, the program rewrite location is the start address of the function to be replaced 112. Further, the start address of the function to be replaced 112 is acquired from the symbol information of the test target program 110. In the following description, the symbol table included in the executable file of the test target program 110 is assumed as the symbol information, but the same result can be obtained by using a MAP file generated by the language processor instead of the symbol table. it can.

  Step ST501 is a process of loading information such as a symbol table necessary for obtaining the head address of the function to be replaced 112 later onto the main memory. Details of this processing will be described later with reference to FIG. In the description of the present embodiment, the object file information is collectively loaded onto the main memory in step ST501. However, the file may be accessed each time information is used.

  In step ST502, the name of the function to be replaced 112 is input, and the start address of the function to be replaced 112 is acquired from the symbol table read in step ST502. Details of this processing will be described later with reference to FIG.

In step ST503, the instruction at the head address of the function to be replaced acquired in step ST502 is rewritten to an unconditional branch instruction to the replacement function. As a specific example, when the unit test is performed on a CPU of an AMD64 architecture CPU, the unconditional branch instruction is a JMP instruction whose operation code is 0xE9. The JMP instruction is a program counter relative jump instruction. Here, (replacement function address) − (function start address) − (JMP instruction byte length) is set as the operand of the jump instruction. Note that the value of the instruction byte length of the JMP instruction is 5.
Thus, in step ST503, which is the processing of the program rewriting unit 123, when the test target program 110 calls the function to be replaced 112 by rewriting the code at the head address of the function to an instruction that unconditionally branches to the replacement function, the result Thus, the effect that the replacement function is executed can be obtained.

  Hereinafter, the object file read process in step ST501 and the function head address acquisition process in step ST502 will be described. Specifically, the object file format will be described assuming ELF (Executable and Linkable Format), but different object file formats such as Windows PE (Windows is a registered trademark / hereinafter abbreviated) and Mach-O are also used. The present invention is equally applicable.

  FIG. 6 is a flowchart showing details of the object file reading process in FIG. 5, and here, the ELF file reading process is shown. In the ELF file read processing flow, information necessary for the analysis of the ELF file is read out to the memory by using the name of the ELF file as input. The information read out here is a symbol table necessary for acquiring the function head address in step ST502 of FIG. 5 in the present embodiment.

  Step ST601 is an ELF file name file open process. At this time, the file name given as the input of the ELF file reading process is used to open the file. Although it is necessary to close the opened file, since the close process is not directly related to the present invention, the description of the close process will be omitted hereinafter.

  In step ST602, the file header stored at the head of the ELF file is read. The file header holds an offset of a section header table used in later processing, the number of section headers, and the like.

  Step ST603 is processing to read the section header table. With reference to the position and number of section header tables included in the ELF header read in step ST602, the section data table is read from the corresponding position in the ELF file into the memory. At this time, the position of the section header table is stored in the e_shoff field of the file header. The number of section headers is stored in e_shnum.

  Step ST604 is a process of reading the character string table for the section header from the file to the memory. First, using the value of the e_shstrndx field of the file header read in step ST602, the offset in the section header string table file from the e_shstrndx-th section header counted from the beginning of the section header table read in step ST603 And get the size. The offset and size of the section header character string table can be obtained from the sh_offset field and sh_size field of the section header, respectively.

  Step ST605 is processing to read the character string table. In the ELF file, the string table is stored in a section with the name .strtab. First, the section name with the name .strtab is obtained from the section header table. The name of the section header can be obtained using the value of the sh_name field of the section header. Specifically, the zero-terminated character string existing in the sh_name field byte from the head of the character string table for the section header is the section header name.

  Step ST606 is processing to read a symbol table. The symbol table is a section with the name .symtab. As in the case of the character string table in step ST605, .symtab is searched from the section header table, and the symbol table is read into the memory from the position described in the section header. At this time, the symbol position and size are the values of the sh_offset field and sh_size field of the section header, respectively. Note that the quotient of the sh_size value and the symbol table entry is the number of symbol table entries. In step ST606, the number of entries is also stored in the memory.

  Step ST607 is processing to read the relocation table. A relocation table exists for each section to be relocated. Each relocation table is also stored in an independent section. The section in which the relocation table is stored is stored in a section having a name that starts with the name of the section to be relocated following .rel or .rela. For example, a relocation table for a .text section is stored in a section whose name is .rel.text or .rela.text. In step ST607, the .rel or .rela section is loaded into the memory.

  Next, details of the function head address acquisition process in step ST502 will be described with reference to FIG. FIG. 7 is a flow of function start address acquisition processing based on executable file symbol information. In this process, the name of the function to be replaced 112 is input, and the symbol matching the name of the function to be replaced 112 is searched from the symbol table read in step ST501, thereby acquiring the address of the function to be replaced 112.

  Step ST701 is a process of searching for a symbol table entry having the name of the function to be replaced 112 as a symbol name. Details of the symbol search processing will be described later with reference to FIG. Here, it is specified that the name of the symbol matches the name of the function to be replaced 112 as a search condition to be input to the symbol table search process. The symbol name is obtained from a zero-terminated character string from which the value of the st_name field of the symbol table entry can be read as an index of the character string table. From the symbol search process, a list of symbols that match the search conditions is obtained.

  Step ST702 is a conditional branch process based on whether or not the symbol searched in step ST701 is found in the symbol table. Whether or not a symbol is found can be determined based on whether or not the symbol list obtained in step ST701 is not empty. If no symbol is found, exit with an error. On the other hand, if a symbol is found, the process branches to step ST703.

  Step ST703 is a conditional branch process based on whether or not two or more symbols searched in step ST701 are found in the symbol table. If more than one symbol is found, exit with an error. On the other hand, if only one symbol is found, the process branches to step ST704.

  In step ST704, the value of the found symbol, that is, the address of the function to be replaced 112 is stored in the main result. The value of the symbol is the value of the st_value field of the symbol table entry obtained only as a result of the search in step ST701.

  As described above, step ST502, which is the process of the address resolution unit 122, searches the symbol information of the executable file of the test target program 110 using the name of the function 112 to be replaced, thereby obtaining the start address of the function 112 to be replaced. Therefore, even if the test target program 110 does not hold debug information, it is possible to obtain the effect that the start address of the function to be replaced 112 can be acquired.

Next, the symbol search process in step ST701 will be described with reference to FIG.
The symbol search process is a process that circulates through the symbol table entries and returns a list of symbol table entries that match the input search conditions. Step ST801 is processing to clear the search result. Steps ST802 to ST805 are a loop process for circulating symbol table entries. That is, in step ST803, it is determined whether the symbol matches the search condition. If the symbol matches, the symbol table entry is added to the search result in step ST804, and if not, the process proceeds to the next symbol table entry. The number of symbol table entries can be obtained by referring to the value stored at the time of step ST606 of the ELF file reading process of FIG.

  As described above, in the first embodiment, the function replacement unit 121 can be called from the test driver 101, so that the function to be replaced 112 can be replaced with the replacement function 102 during the process of the test driver 101. In addition, by providing the address resolution unit 122, it is possible to acquire an address that is a target of program rewriting when the test target program 110 is executed. Also, by providing the program rewriting unit 123, the replacement function 112 can be called when the test driver 101 is executed.

  As described above, according to the unit test support apparatus of the first embodiment, the function replacement unit that inputs the identifier of the replacement function to be rewritten in the test target program and the identifier of the replacement function for rewriting the replacement function An address resolution unit that acquires the address of the rewriting position of the test target program from the identifier of the function to be replaced, and a program rewriting unit that rewrites the replacement function with the replacement function by rewriting the test target program at the address acquired by the address resolution unit Therefore, the software unit test can be simplified.

  Further, according to the unit test support apparatus of the first embodiment, the address resolution unit acquires the start address of the function to be replaced as the address of the rewrite position of the test target program from the identifier of the function to be replaced. Since the memory contents from the start address are rewritten to one or more instructions that branch directly or indirectly to the replacement function, the replacement function is executed when the program under test calls the function to be replaced. It can be easily realized.

  Further, according to the unit test support apparatus of the first embodiment, the address resolution unit retrieves the symbol information of the test target program using the identifier of the function to be replaced, thereby acquiring the start address of the function to be replaced. Therefore, even if the test target program does not have debug information, the start address of the function to be replaced can be acquired.

  Further, according to the unit test support program of the first embodiment, the computer for performing the unit test of the software includes the identifier of the replacement function to be rewritten in the test target program and the replacement function for rewriting the replacement function. The function replacement unit for inputting the identifier, the address resolution unit for acquiring the address of the rewriting position of the test target program from the identifier of the function to be replaced, and the function to be replaced by rewriting the test target program of the address acquired by the address resolution unit Since it is made to function as a program rewriting unit for rewriting with a replacement function, a unit test support device that can simplify the work in the unit test of software can be realized on a computer.

Embodiment 2. FIG.
In the first embodiment, when a local function having the same name is defined in a plurality of source files in the source file group of the test target program 110, a plurality of entries having the same symbol name exist in the symbol table. . In such a case, the problem is that the start address of the function to be replaced 112 cannot be resolved correctly. Specifically, an error occurs because a plurality of symbols are found in step ST703 of FIG. The second embodiment solves such a problem. The configuration on the drawing is the same as that in FIG. 1 and will be described using the configuration in FIG.

  In the present embodiment, the basic mechanism is to avoid ambiguity of symbol resolution by transmitting the source file in which the replacement function 112 is defined from the test driver 101 to the function replacement unit 121. . In this way, since a plurality of functions having the same name are not defined in one source file, the replacement function 112 included in the test target program 110 can be uniquely identified by the source file and the function name. . That is, in the second embodiment, the address resolution unit 122 searches the debug information of the test target program 110 using the name of the function 112 to be replaced and the identifier of the source file including the function 112 to be replaced, thereby replacing the function to be replaced. The first address of 112 is acquired. Other configurations are the same as those of the first embodiment.

Hereinafter, differences from the first embodiment will be described as an operation description of the present embodiment.
First, in the second embodiment, the function head address acquisition process in step ST502 of FIG. 5 uses the debug information of the test target program 110 instead of the symbol information, and the name of the source file including the replaced function 112 is extra. This is different from the first embodiment in that it is input. In addition, as an input to the function replacement unit 121, a source file identifier including the function to be replaced 112 is added to the input. Similarly, in step ST202 of FIG. 2, the source file identifier is added as an input to the input.

  In the following description, the source file name is used as the identifier. However, any identifier can be used as long as it can be finally converted into the source file name. For example, if the fact that the difference between an object file name and a source file name is generally only an extension is used, the source file name can be easily obtained using the object file name or its base file name as an identifier.

Next, the function head address acquisition process in step ST502 of FIG. 5 in the present embodiment will be described with reference to FIG.
FIG. 9 is a flow of a function head address acquisition process using debug information. The input of the process is the name of the function 112 to be replaced and the name of the source file containing the function 112 to be replaced.
In step ST901, the address of the function to be replaced 112 is acquired from the debug information included in the test target program 110 that is the input of the function replacement process, using the source name and the function name to be replaced as keys. In this process, since the process of acquiring the address of the function from the debug information by the pair of the source name and the function name is known, only the outline of the process is shown here. If the debug information is in DWARF format, the debug information is stored in the .debug_info section. In step ST901, first, a DIE search is performed in which the attribute DW_AT_name matches the source file name from the DIEs whose tag is DW_TAG_compilation_unit. Next, a DIE whose tag has the same DW_AT_name as the function name is searched from DW_TAG_subprogram among subsequent DIEs of the DIE. The value of the DIE attribute DW_AT_low_pc found as a result is the function start address to be obtained.

  Step ST902 is a conditional branch process based on the result of step ST901. If the address of the function to be replaced 112 cannot be acquired in step ST901, the process ends in error. On the other hand, if the address can be acquired in step ST901, the process branches to step ST903. In step ST903, the value of the function to be replaced 112 acquired in step ST901 is output as a result.

  As described above, according to the unit test support apparatus of the second embodiment, the address resolution unit searches for debug information of the test target program using the name of the function to be replaced and the identifier of the source file including the function to be replaced. As a result, the start address of the function to be replaced is acquired, so even if there are multiple functions with the same name as the function to be replaced in the test target program, the function to be replaced is uniquely acquired. be able to.

Embodiment 3 FIG.
In the second embodiment, the start address of the function to be replaced 112 is acquired using the file name in which the function to be replaced 112 is defined. For this reason, if the source file defining the function to be replaced 112 is changed, the test cannot be executed correctly. Specifically, when the source file defining the function to be replaced 112 is changed, information on the function to be replaced 112 is not found in step ST902 in FIG. Therefore, in order to correctly execute the test even after the source file defining the replaced function 112 is changed, the test driver 101 side needs to be corrected. Specifically, it is necessary to update the source file identifier including the input function 112 to be replaced in step ST202 of FIG. As an example of changing the source file, there is a case where the function to be replaced 112 defined in the same source file as the test target function 111 is moved to another source file by refactoring or the like.

  This embodiment solves such a problem. That is, even if the file in which the function to be replaced 112 is defined is changed, the change on the test driver 101 side is not required. Hereinafter, the present embodiment will be described based on differences from the second embodiment. The configuration on the drawing is the same as in FIG.

  This embodiment is different from the second embodiment in that the source file identifier of the test target function 111 is used as the input of the function replacing unit 121 instead of the source file identifier of the function 112 to be replaced. That is, the address resolution unit 122 according to the third embodiment obtains the head address of the function to be replaced 112 using the name of the function to be replaced 112 and the source program identifier of the function to be tested 111. The head address of the function to be replaced 112 is searched using only the name 112. Other configurations are the same as those of the first embodiment.

In the following description, it is assumed that the source file name is used as the source file identifier.
The input of the function head address acquisition process in step ST502 in FIG. 5 is not the name of the source file including the function to be replaced 112 but the source file identifier of the test target function 111. Similarly, the input to the function replacement unit 121 is not the source file identifier including the function to be replaced 112 but the source file identifier of the test target function 111. Similarly, in step ST202 of FIG. 2, the source file identifier of the test target function 111 is input.

Next, the function head address acquisition process in step ST502 of FIG. 5 in the present embodiment will be described with reference to FIG.
FIG. 10 is a flowchart showing a function head address acquisition process using a source file name. The input of the process is the name of the function 112 to be replaced and the name of the source file containing the test target function 111.
In step ST1001, the address of the function is searched based on the name of the source file including the test target function 111 and the name of the function to be replaced 112. Specifically, the address of the function having the name of the function to be replaced 112 is acquired from the functions defined in the source file of the test target function 111. This process is substantially the same as step ST901 in the second embodiment.

Step ST1002 is a branching process based on the processing result of step ST1001. If information on the function to be replaced 112 is found in step ST1001, the process branches to step ST1003. Otherwise, the process branches to step ST1004.
In step ST1003, the head address is acquired from the information on the function to be replaced found in step ST1001, and is output as the processing result.

  Step ST1004 is a process of searching for a global function whose function name matches the function to be replaced. Since this process is known, only an outline of the process is shown here. Specifically, when the debug information is in DWARF format, a DIE whose attribute DW_AT_name matches the name of the function to be replaced and whose attribute DW_AT_external is 1 may be searched from the DIEs having the tag DW_TAG_subprogram. This is the address for which the value of the found DIE attribute DW_AT_low_pc is obtained.

Step ST1005 is a branching process based on the result of step ST1004. If information on the function to be replaced 112 is found in step ST1004, the process branches to step ST1006. Otherwise, end in error.
In step ST1006, the head address is acquired from the information of the function to be replaced 112 found in step ST1004, and is output as a processing result.

  As described above, as the means for realizing step ST502, which is the process of the address resolution unit 122, in the function address acquisition process, the start address of the function to be replaced 112 is acquired using the name of the function to be replaced 112 and the source program identifier ( Step ST1001) If it is not found, only the name of the function to be replaced 112 is used to search for the start address of the function to be replaced 112 (step ST1004), so that the replaced function 112 is defined at the position of the file. The replacement function 112 can be replaced with the replacement function 102 without depending on it. Therefore, even when the replacement function 112 is moved to another file after the test driver 101 is created, it is possible to obtain an effect that the test driver 101 does not need to be corrected.

  In the above description, the source program identifier of the test target function 111 is described as the file name of the source program. However, the name of the test target function 111 or the address of the test target function 111 can be substituted. This is because searching the debug information of the test target program 110 can identify the source program defining the test target function 111 from the name of the test target function 111 and the address of the test target function 111.

  Further, by using the address of the test target function 111 instead of the file name as the source program identifier of the test target function 111, it is not necessary to change the test driver 101 even if the name of the source file of the test target function 111 is changed. A new effect can also be obtained.

  As described above, the address resolution unit uses the name of the function to be replaced and the source program identifier of the function to be tested that calls the function to be replaced when the program to be tested is executed to determine the start address of the function to be replaced. If it is not found, the head address of the function to be replaced is searched using only the name of the function to be replaced. Therefore, the function to be replaced is not dependent on the position of the file where the function to be replaced is defined. Can be replaced with a replacement function. For this reason, even when the replacement function is moved to another file after the test driver is created, there is an effect that it is not necessary to modify the test driver.

Embodiment 4 FIG.
In the second and third embodiments, debug information is used to obtain the address of the function 112 to be replaced. For this reason, the object file itself including the function to be replaced 112 needs to hold debug information. For this purpose, an option for outputting debug information needs to be specified in the compiler when compiling a source file that defines the function to be replaced 112. Therefore, the second embodiment cannot be applied when the source code of the object file including the replaced function 112 cannot be obtained. In the present embodiment, a method for solving this problem is provided. In the present embodiment also, the configuration on the drawing is the same as that in FIG.

  This embodiment is characterized in that function start address acquisition processing using symbol information is performed instead of function start address acquisition processing using debug information in steps ST1001 and ST1004 of FIG. That is, the address resolution unit 122 of the fourth embodiment uses the name of the function to be replaced 112 and the relocatable file of the test target function 111 that calls the function to be replaced 112 when the test target program 110 is executed. If the head address of the function 112 is not found, the head address of the function 112 to be replaced is searched using only the name of the function 112 to be replaced.

Next, the operation of the unit test support apparatus according to the fourth embodiment will be described.
First, the function head address acquisition process using the symbol information in step ST1004 where the process is simple will be described. In step ST1004, the purpose is to acquire the address of the global replacement function 112. Therefore, in the present embodiment, an entry of a global symbol that matches the name of the function to be replaced 112 may be acquired from the symbol table of the test target program 110 read out in step ST501. The symbol search process is as described in the first embodiment. Whether or not a symbol is global can be determined by whether or not the upper 4 bits of st_info of the symbol table entry are STB_GLOBAL. Whether a symbol is a function or not can be determined by checking whether the lower 4 bits of the st_info field of the symbol table entry are STT_FUNC.

Next, processing corresponding to step ST1001 will be described using FIG. 11 and FIG.
FIG. 11 is a schematic diagram of function start address acquisition based on symbol information of a relocatable file. The address space 1101 is an address space of a process including the test target program 110. The relocatable file 1103 is a relocatable file including the test target function 111. The relocatable file 1103 holds a .text section 1105 including a code. Further, it is assumed that a replaced function 1106 corresponding to the replaced function 112 in FIG. 1 exists in the .text section 1105. The .text section 1105 is mapped to the position of the section head address B1102 in the address space 1101. The relocatable file 1103 also includes a relocatable file symbol table 1104. The relocatable file symbol table 1104 has an entry corresponding to the replaced function 1106. In the symbol table entry, an offset A from the .text section 1105 of the function to be replaced is stored as a value. In this embodiment, the computer calculates (section start address B) + (offset A), thereby realizing function start address acquisition processing based on symbol information of the locable file.

FIG. 12 is a flowchart showing a function head address acquisition process based on symbol information of a relocatable file.
In step ST1201, an object file read process is performed with the relocatable file name including the function to be replaced 1106 as an input. The object file reading process is as described in the first embodiment. The name of the relocatable file 1103 is obtained by changing the extension of the source file name. For example, in the case of a C language source file, the extension may be changed from .c to .o or .obj.

  In step ST1202, the symbol of the function name to be replaced is searched from the symbol table read in step ST1201. The symbol search process is as described in the first embodiment. Here, the search condition given to the input of the symbol search process is that the name of the symbol matches the name of the function to be replaced 1106. The symbol name of the symbol table entry is a zero-terminated character string that can be read as the index of the character string table read in step ST1201 from the st_name field of the symbol table entry.

  The st_value field of the symbol table entry obtained in step ST1202 is an offset from the beginning of the section in which the function is defined. In addition, here, in order to simplify the description, it is assumed that the section in which the function is defined is a standard .text section, but another section may be used. In that case, the section in which the symbol exists is stored in step ST1202, and in the process of step ST1205, the start address may be acquired for the stored section. By referring to the st_shndx field of the symbol table entry, the section where the symbol exists can be specified.

  Step ST1203 is a conditional branch process based on the process result of step ST1202. If no symbol is found in step ST1202, the process ends as an error. On the other hand, if a symbol matching the condition is found in step ST1202, the process branches to step ST1204.

  In step ST1204, the value of the found symbol is stored in variable A. Next, in step ST1205, it is a process which acquires the head address in the address space 1101 of the .text section 1105 in the relocatable file 1103 read in step ST1201. Details of step ST1205 will be described later with reference to FIGS.

  In step ST1206, the section head address acquired in step ST1205 is stored in B. In step ST1207, the function head address is calculated by calculating A + B and output as a result.

Next, the section head address acquisition processing in step ST1205 in FIG. 12 will be described using FIG. 13 and FIG.
FIG. 13 is a schematic diagram of section start address acquisition. An address space 1301 is an address space of a process of the test target program 110. The relocatable file 1303 is a relocatable file including the test target program 110, and includes a .text section 1304 and a relocatable file symbol table 1306. Further, it is assumed that the .text section 1304 includes one arbitrary global function G1305. The relocatable file symbol table 1306 holds an entry corresponding to the global function G1305. This entry holds the offset X from the .text section 1304 of the global function G1305. The executable file symbol table 1307 is a symbol table of an executable file of the test target program 110. The executable file symbol table 1307 also holds an entry corresponding to the global function G1305. This entry holds the address Y of the global function G1305 in the address space 1301. In the present embodiment, the section head address acquisition processing in step ST1205 calculates the text head address by calculating (address Y of global function G1305) − (offset X from section head 1 of global function G1305).

FIG. 14 is a flowchart showing the section head address acquisition process. The input of the section head address acquisition process is the name of the executable file and the relocatable information read by the caller of this process.
Step ST1401 is processing for acquiring a symbol of a global function from the relocatable file read out in step ST1201. The symbol search process is as described in the first embodiment, but the search condition specifies that the symbol is a global function. Whether or not a symbol is global can be determined by whether or not the upper 4 bits of st_info of the symbol table entry are STB_GLOBAL. Whether a symbol is a function or not can be determined by checking whether the lower 4 bits of the st_info field of the symbol table entry are STT_FUNC.

  Step ST1402 is a conditional branch process based on the result of step ST1401. If no symbol is found in step ST1401, the process ends in error. On the other hand, if a symbol is found, the process branches to step ST1403. In step ST1403, the symbol list obtained in step ST1401 is assigned to the variable X. Although the top of the symbol list is selected here, in practice, any symbol that satisfies the condition that the symbol is a global function may be substituted for X.

In step ST1404, an object file read process is performed with an executable file name as an input. Details of the object file read processing are as described in the first embodiment. Since the same information is read out also in step ST501, this process can be omitted by using the information as it is.
In step ST1405, a symbol is searched from the file information read in step ST1404. At this time, the search condition is designated to match the name of the symbol X assigned in step ST1403.
Step ST1406 is a conditional branch process based on the result of step ST1405. If no symbol is found in step ST1405, the process ends in error. On the other hand, if a symbol is found, the process branches to step ST1407.

Step ST1407 is a process of substituting the top of the symbol list obtained as a result of step ST1406 for variable Y. In step ST1405, since the search is performed using the name of the symbol X of the global function, the list obtained as a normal result includes only one symbol.
In step ST1408, the section head address is calculated by calculating YX. Specifically, the symbol value is the value of the st_value field of each of X and Y. The symbol value of Y is the start address of the global function, and the symbol value of X is an offset from the beginning of the section. By taking the difference between the two, the head address of the section can be acquired.

  As described above, according to the unit test support apparatus of the fourth embodiment, the address resolution unit includes the name of the function to be replaced and the relocatable function of the test target function that calls the function to be replaced when the test target program is executed. Since the start address of the function to be replaced is obtained using the file, and the start address of the function to be replaced is searched using only the name of the function to be replaced if it is not found, the file in which the function to be replaced is defined The function to be replaced can be replaced with a replacement function without depending on the position of. For this reason, even when the function to be replaced is moved to another file after the test driver is created, it is possible to obtain an effect that it is not necessary to modify the test driver.

  Also, according to the unit test support apparatus of the fourth embodiment, the address resolution unit determines the start of the replacement function from the symbol information of the relocatable file including the definition of the replacement function, the symbol information of the test program, and the section start address. Since the address is calculated, the address of the function to be replaced defined in the same file as the function to be tested can be acquired without using debug information. At this time, even if the function to be replaced is a local function and a plurality of local functions with the same name are included in the test program, the address of the function to be replaced can be uniquely specified. This is because when the function to be replaced is a local function, the function to be called called by the test target function is always defined only in the same source file as the function to be replaced.

Embodiment 5. FIG.
In the first to fourth embodiments, each address resolution unit 122 acquires the start address using different function start address acquisition means. Specifically, in the first embodiment, the function head address acquisition unit using the symbol information of the executable file shown in FIG. 7 is used. Further, in the second embodiment, the function head address acquisition means based on the debug information shown in FIG. 9 is used. In the third embodiment, the means realized by using debug information as the function head address acquisition means using the source file name of FIG. 10 is shown. In the fourth embodiment, the means realized by using the symbol information of the relocatable file as the function head address acquisition means using the source file name of FIG. 10 is shown. Thus, there are a plurality of function head address acquisition means in the address resolution unit 122. Each function head address acquisition unit acquires the address of the function to be replaced 112 using different information such as symbol information and debug information. Therefore, there is a problem that the test driver creator needs to select an appropriate function head address acquisition unit based on available information. The present embodiment solves the above problem.

  The present embodiment is characterized by having an address resolution unit 122 including a plurality of function head address acquisition means trial means. That is, the address resolution unit 122 according to the fifth embodiment has means for acquiring the start address of the function to be replaced 112 based on the presence / absence of debug information of the test target program 110 or the presence / absence of the relocatable file of the test target function 111. Configured to select.

The processing flow of the test support unit 120 in this embodiment is shown in FIG.
The input of the function replacement unit 121 is the source file name of the test target function 111, the executable file name of the test target program 110, and the name of the function 112 to be replaced.
Step ST1501 is a process of reading information on the executable file of the test target program 110. This process is the same as step ST501. Step ST1502 is a branch process based on whether or not there is debug information. If there is debug information, the process branches to step ST1505. Otherwise, the process branches to step ST1504. Whether or not there is debug information can be determined by searching the section header table read in step ST1501 and confirming whether or not there is a section including debug information. For example, if the executable file format is ELF format and the debug information format is DWARF, it can be assumed that debug information exists if there is a .debug_info section, and that it does not exist otherwise.

  Step ST1503 is a function head address acquisition process using debug information. This process is the same as the process of FIG. 10 in the third embodiment.

  Step ST1504 is a conditional branch process based on the presence or absence of a relocatable file corresponding to the source file of the test target function 111. The presence / absence of the relocatable file can be confirmed by checking whether or not the relocatable file name acquired from the source file name exists on the file system. If there is a relocatable file, the process branches to step ST1505. Otherwise, the process branches to step ST1506.

Step ST1505 is a function head address acquisition process using the symbol information of the relocatable file. This process is the same as the process of FIG. 10 based on the description of the fourth embodiment.
Step ST1506 is a function head address acquisition process using executable file symbol information. This process is the same as the process of FIG. 7 of the first embodiment.
Step ST1507 is a process of writing an unconditional branch instruction to the replacement function 102 to the function start address acquired in step ST1503, step ST1505, or step ST1506. Details of this processing are as described in the first embodiment.

  As described above, according to the unit test support apparatus of the fifth embodiment, the address resolution unit determines whether the function to be replaced is based on the presence or absence of debug information of the test target program or the presence or absence of the relocatable file of the test target function. Since the means for acquiring the start address of the test driver is selected, the test driver creator does not create an information test driver that can use the means for acquiring the start address of the function to be replaced. Can be reduced.

Embodiment 6 FIG.
In the first embodiment, the function replacement process is realized by rewriting the function to be replaced itself. However, if the function to be replaced is a shared library function, the problem is that it cannot be replaced. In general, since the shared library is shared by a plurality of processes, if the shared library function is rewritten, the program other than the test target program 110 is affected. Thus, in the present embodiment, the function replacement process when the function to be replaced 112 is a shared library function is realized.

  The address resolution unit 122 according to the present embodiment acquires the address of the location that refers to the function to be replaced 112 in the address space of the test target program 110, and the program rewrite unit 123 uses the address acquired by the address resolution unit 122. The location is rewritten to the address reference of the replacement function 102. Other configurations are the same as those of the first embodiment shown in FIG.

First, using FIG. 16 and FIG. 17, the state of function calls before and after function replacement in the test target function 111 will be described, and then function replacement processing will be described.
FIG. 16 is a schematic diagram of a shared library function call before function replacement. Here, the state of a shared library function call when the object file format is ELF is specifically shown. However, since Windows PE and Mach-o are also a shared library function call using a similar trampoline code, the present invention is It is possible to apply. Here, the state where the dynamic link is completed is shown.

  The test target function 1601, the function to be replaced 1604, the PLT 1602, the GOT. The PLT 1603 is a program and data stored on the main memory of the computer. The test target function 1601 and the replacement function 1604 are programs corresponding to the test target function 111 and the replacement function 112 in FIG. When calling the replacement function of the shared library, the test target function 1601 calls an entry PLT [n] of a PLT (Procedure Linkage Table) corresponding to the replacement function 1604 instead of directly calling the replacement function 1604. The entry PLT [N] of the PLT includes GOT. Jump to the address stored in the entry of PLT1603. GOT. The entry GOT [N] of the PLT 1603 includes the address of the function to be replaced 1604. As a result, the function to be replaced 1604 is called through the jump instruction of the PLT entry PLT [N]. When the function return instruction RET is executed in the function to be replaced 1604, the processing control is transferred to the instruction immediately after the instruction to call the function to be replaced 1604 of the function to be tested 1601.

  FIG. 17 is a schematic diagram of a shared library function call after function replacement. In FIG. 17, a test target function 1701, a replaced function 1704, and a replacement function 1705 are programs corresponding to the test target function 111, the replaced function 112, and the replacement function 102 in FIG. A replacement function 1705 is a replacement function stored in the main memory. GOT. The entry GOT [N] corresponding to the function to be replaced 1704 of the PLT 1703 holds the address of the replacement function 1705, not the address of the function to be replaced 1704. As a result, when the test target function 1701 calls the entry PLT [N] of the PLT 1702, an indirect jump is made to the address of the replacement function 1705 held by GOT.PLT [N]. As a result, the process control shifts to the head of the replacement function 1705. When the function return instruction RET is executed in the replacement function 1705, the process control is transferred to the instruction immediately after the replacement target function 1704 of the test target function 1701 is called.

Next, a function replacement process for changing the shared library function call of FIG. 16 to the shared library function call of FIG. 17 will be described with reference to FIG.
FIG. 18 is a processing flow of the test support unit 120 for the shared library function. In step ST1801, the object file is read with the file name of the test target program 110 as an input. The details of this process have been described in Embodiment 1, and will be omitted.

  Step ST1802 is a function address reference rewriting process. Pass the dynamic relocation table for GOT.PLT as input to the function address reference process. In the case of an ELF file, .rela.plt or .rel.plt holds a relocation table that is input to the function address reference process.

Next, details of the function address reference rewriting process in step ST1802 will be described using the flowchart of FIG.
In the function address reference rewriting process, the relocation information is used to rewrite the entry of the function to be replaced 112 in .GOT.PLT from the address of the function to be replaced 112 to the address of the replacement function 102.
In the function address reference rewriting process shown in FIG. 19, the name of the function to be replaced 112, the .text section start address, and the address of the replacement function 102 are input. In the function address reference rewriting process, the relocation table of the .text section read in step ST1901 is also used.

Steps ST1901 to ST1905 are loop processing for circulating through the entries in the relocation table of the section read out in step ST1901.
Step ST1902 is conditional branch processing based on whether or not the target of the relocation table entry being visited is the replaced function 112. When the target of the cyclic entry is not the replacement function 112, step ST1903 and step ST1904 are skipped. On the other hand, if the entry in circulation corresponds to the function to be replaced 112, the process branches to step ST1903.

  Whether or not the entry in circulation corresponds to the replaced function 112 can be confirmed by whether or not the name of the symbol table entry to which the relocation table entry is linked matches the name of the replaced function 112. The symbol to which the relocation table entry is linked can be obtained by referring to the r_info field of the relocation table entry. A target symbol can be obtained by acquiring a symbol table index from the r_info field and accessing the symbol table read in step ST1901. Further, the symbol name can be acquired by reading the index of the character string table from the st_name field of the symbol table entry and accessing the character string table read in step ST1901.

  Step ST1903 is processing for acquiring the address of the reference location of the function to be replaced. Here, the address of the place where the function to be replaced is called is obtained from the offset of the relocation table entry. Specifically, the offset of the relocation table entry is the value of the r_offset field. This value is the same as the GOT. This is the address of the entry GOT [N] of the PLT 1603.

  Step ST1904 is a process of rewriting data existing at the address of the replacement function reference location acquired in step ST1903 to the address of the replacement function 102. As a result, as shown in FIG. The entry GOT [N] of the PLT 1703 holds the address of the replacement function 1705.

  As described above, according to the unit test support apparatus of the sixth embodiment, the address resolution unit acquires the address of the location that refers to the function to be replaced in the address space of the test program, and the program rewriting unit Since the address portion acquired by the address resolution unit is rewritten with the address reference of the replacement function, the replacement function can be replaced with the replacement function even when the replacement function is a function in the shared library.

Embodiment 7 FIG.
In the sixth embodiment, the function replacement process in the case where the function to be replaced 112 is a shared library is shown. However, in such a case, the test driver creator needs to select a function replacement process corresponding to the specification of the test driver 101 depending on whether or not the function to be replaced 112 is a shared library function. Therefore, in this embodiment, a function replacement process that can replace a function regardless of whether or not the function to be replaced 112 is a shared library function will be described. That is, the address resolution unit 122 according to the seventh embodiment determines whether or not the function to be replaced 112 is a shared library, and if it is a shared library, performs the processing according to the sixth embodiment and also implements the program rewriting unit. It is comprised so that the process of the form 6 may be performed. Other configurations are the same as those of the first embodiment shown in FIG.

The function replacement process according to the present embodiment is shown in the flowchart of FIG.
In step ST2001, object file information of the test target program 110 is read. Details of this processing are as described in the description of the first embodiment.

  Step ST2002 is a branch process based on whether or not the function to be replaced 112 is a shared library function. If the replaced function 112 is a shared library function, the process branches to step ST2003; otherwise, the process branches to step ST2004. Whether or not the function to be replaced 112 is a shared library function can be determined by searching a dynamic relocation table entry for GOT.PLT and by the presence or absence of an entry corresponding to the function to be replaced 112. If an entry corresponding to the function to be replaced 112 is found, the function to be replaced 112 is a shared library function.

Step ST2003 is a function address reference rewriting process. Since this process is the same as the process of FIG. 19 according to the sixth embodiment, a description thereof is omitted here.
Step ST2004 is a function head address acquisition process. The function start address acquisition means is arbitrary, and the function start address acquisition processing described in the first to fifth embodiments may be used.
In step ST2005, the code of the function start address acquired in step ST2004 is rewritten to an unconditional branch instruction to the replacement function 102. Details of this processing are as shown in the first embodiment.

  As described above, according to the unit test support apparatus of the seventh embodiment, the address resolution unit determines whether or not the function to be replaced is a shared library, and if it is a shared library, acquires an address. In addition, since the address is rewritten by the program rewriting unit, the test driver creator can create a test driver without selecting a function replacement process depending on whether or not the function to be replaced is a shared library. Further, even when the function to be replaced is changed to a shared library function later, it is not necessary to modify the test driver.

Embodiment 8 FIG.
In the first to seventh embodiments, the function to be replaced is replaced with the replacement function by dynamically rewriting the test program being executed. For this reason, when another test driver is called after execution of the test driver that calls the function replacement process, another test driver may not operate as expected. Therefore, in the present embodiment, means for restoring the replaced function is added to the first to seventh embodiments.

  FIG. 21 shows an overall configuration diagram of the present embodiment. In this configuration, a function replacement restoration unit 124 is present in addition to any of the configurations of the first to seventh embodiments. The program rewriting unit 123 according to the present embodiment is configured to store, as a replacement history, a set of a replaced address and size and data before replacement when the function to be replaced 112 is replaced with the replacement function 102. The function replacement restoration unit 124 is a processing unit that restores function replacement based on the stored replacement history. Since other configurations are the same as those in FIG. 1, the corresponding parts are denoted by the same reference numerals and description thereof is omitted.

In the present embodiment, the restoration of the replaced function is realized by the program rewriting unit 123 and the function replacement restoring unit 124 operating in cooperation. Specifically, in the function replacement process, the program is rewritten during the process, and at the same time, a set consisting of the rewritten address, the rewritten size, and the data before rewriting is stored in the memory as a replacement history. Further, in the function replacement process, the identifier of the replacement history stored in the memory during the function replacement process is output. For example, the identifier of the replacement history list may be an address of a memory that stores the replacement history list.
The timing for storing the replacement history is specifically described as step ST503 in FIG. 5, step 1507 in FIG. 15, step ST1904 in FIG. 19, and step ST2005 in FIG.

  Next, the operation of the function replacement restoration unit 124 will be described. The function replacement restoration unit 124 receives the replacement history identifier output from the program rewriting unit 123 as an input, and rewrites the data before rewriting to the address stored in the corresponding replacement history by the rewritten data size. Restore function substitution.

  As described above, according to the unit test support device of the eighth embodiment, when a function to be replaced is replaced with a replacement function, a set of the replaced address and size and the data before replacement is stored as a replacement history. Since the function replacement restoring unit that restores the function replacement based on the stored replacement history is provided, it is possible to prevent the function replacement process from being affected by the function replacement process even when the function replacement process is performed.

Embodiment 9 FIG.
In the first embodiment, the function replacement is performed by replacing the function address on the memory with the jump code in the jump code insertion process. However, in an operating system such as Linux (Linux is a registered trademark / hereinafter abbreviated), writing to a code area is often prohibited for security measures. Therefore, a memory access violation occurs in the jump code insertion process of the first embodiment on an operating system that prohibits writing to the code area, such as Linux. This embodiment solves this problem.

An overall configuration diagram of the unit test support apparatus of the present embodiment is shown in FIG.
The present embodiment is characterized in that a memory release unit 125 is added to the test support unit 120b in addition to the configuration of any of the first to eighth embodiments. 22 shows a configuration in which a memory release unit 125 is added to the configurations of the first to seventh embodiments. The memory release unit 125 is a processing unit that performs a memory protection release process before the program rewrite process by the program rewrite unit 123. Other configurations are the same as those in any one of the first to eighth embodiments, and thus the description thereof is omitted here.

  In the present embodiment, the memory release unit 125 executes a memory release process before the rewrite function 102 of the replacement function 112 in the program rewrite unit 123, and releases the memory protection of the rewrite target area. The timing for executing the memory release processing specifically corresponds to immediately before executing step ST503 in FIG. 5, but any timing may be used as long as it is before rewriting.

  As a specific example of the memory release process, the memory protection release process in the case of Linux is shown below. In the case of Linux, the memory protection is canceled using the mprotect system call. The address of the first argument of mprotect must be the top address of the page including the symbol address. The page head address can be obtained by setting the lower 12 bits of the symbol address to zero. The second argument of mprotect is the size of the target area for which authority is set. Symbol address + symbol size-page start address is the second argument of mprotect. The third argument of mprotect is a protection attribute. Here, PROT_READ | PROT_WRITE | PROT_EXEC is given to give the authority of reading / writing / execution. Here, | means a bitwise OR operation. PROT_READ, PROT_WRITE, and PROT_EXEC mean that the authority of reading, writing, and execution is given.

  As described above, according to the unit test support apparatus of the ninth embodiment, since the memory release unit that performs the memory protection release process before the program rewrite process by the program rewrite unit is provided, the code area is protected from memory. A function to be replaced can be replaced with a replacement function on an operating system.

  In the present invention, within the scope of the invention, any combination of the embodiments, or any modification of any component in each embodiment, or omission of any component in each embodiment is possible. .

  100 test setting unit, 101 test driver, 102 replacement function, 110 test target program, 111 test target function, 112 function to be replaced, 120, 120a, 120b test support unit, 121 function replacement unit, 122 address resolution unit, 123 program rewrite Part, 124 function replacement restoration part, 125 memory release part, 130 language processing part, 140 test program.

Claims (13)

A function replacement unit for inputting an identifier of a function to be rewritten in the program to be tested, and an identifier of a replacement function for rewriting the function to be replaced;
An address resolution unit for acquiring an address of a rewrite position of the test target program from the identifier of the function to be replaced;
A unit test support apparatus comprising: a program rewriting unit that rewrites the function to be replaced with the replacement function by rewriting the program to be tested at the address acquired by the address resolution unit. The address resolution unit obtains a head address of the function to be replaced as an address of a rewrite position of the test target program from the identifier of the function to be replaced,
2. The unit test support apparatus according to claim 1, wherein the program rewriting unit rewrites the memory contents from the head address into one or more instructions that branch directly or indirectly to the replacement function.   3. The unit test according to claim 2, wherein the address resolution unit obtains a head address of the replaced function by searching symbol information of the test target program using an identifier of the replaced function. Support device.   The address resolution unit obtains a start address of the replaced function by searching for debug information of the test target program using a name of the replaced function and an identifier of a source file including the replaced function. The unit test support device according to claim 2.   The address resolution unit obtains the start address of the replaced function using the name of the replaced function and the source program identifier of the test target function that calls the replaced function when the test target program is executed. 3. A unit test support apparatus according to claim 2, wherein if it is not found, the head address of the function to be replaced is searched using only the name of the function to be replaced.   The address resolution unit uses the name of the function to be replaced and the relocatable file of the function to be tested that calls the function to be replaced when the program to be tested is executed to obtain the start address of the function to be replaced. 3. The unit test support apparatus according to claim 2, wherein if it is not found, the head address of the function to be replaced is searched using only the name of the function to be replaced.   The address resolution unit calculates a head address of the replaced function from symbol information of a relocatable file including the definition of the replaced function, symbol information of the test program, and a section head address. 2. The unit test support apparatus according to 2.   The address resolution unit selects a means for acquiring a head address of the function to be replaced based on the presence or absence of debug information of the test target program or the presence or absence of a relocatable file of the test target function. The unit test support device according to claim 1. The address resolution unit obtains an address of a location referring to the function to be replaced in an address space of the test target program;
The unit test support apparatus according to claim 1, wherein the program rewriting unit rewrites the location of the address acquired by the address resolution unit to an address reference of the replacement function.   The address resolution unit determines whether the function to be replaced is a shared library, acquires the address when the function is the shared library, and rewrites the address by the program rewriting unit. 10. The unit test support device according to claim 9, When the replaced function is replaced with the replacement function, the replacement address and size and the data set before replacement are stored as a replacement history,
The unit test support apparatus according to claim 1, further comprising a function replacement restoration unit that restores function replacement based on the stored replacement history.   The unit test support apparatus according to claim 1, further comprising a memory release unit that performs a memory protection release process before the program rewrite process by the program rewrite unit. A computer for software unit testing,
A function replacement unit for inputting an identifier of a function to be rewritten in the program to be tested, and an identifier of a replacement function for rewriting the function to be replaced;
An address resolution unit for acquiring an address of a rewrite position of the test target program from the identifier of the function to be replaced;
A unit test support program for functioning as a program rewriting unit that rewrites the function to be replaced with the replacement function by rewriting the test target program at the address acquired by the address resolution unit.

Images