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

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

Info

Publication number
WO2020136880A1
WO2020136880A1 PCT/JP2018/048499 JP2018048499W WO2020136880A1 WO 2020136880 A1 WO2020136880 A1 WO 2020136880A1 JP 2018048499 W JP2018048499 W JP 2018048499W WO 2020136880 A1 WO2020136880 A1 WO 2020136880A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
execution
local variable
unreached
unit
Prior art date
Application number
PCT/JP2018/048499
Other languages
English (en)
French (fr)
Inventor
功平 千賀
Original Assignee
三菱電機株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 三菱電機株式会社 filed Critical 三菱電機株式会社
Priority to PCT/JP2018/048499 priority Critical patent/WO2020136880A1/ja
Publication of WO2020136880A1 publication Critical patent/WO2020136880A1/ja

Links

Images

Classifications

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

Definitions

  • the present invention relates to technology for executing software tests.
  • Fuzzing is a testing method for detecting vulnerabilities in software. In fuzzing, many unpredictable test cases are given to the program under test and the vulnerability is detected by monitoring the behavior of exception handling. However, in fuzzing, a large number of test cases are selected regardless of the test target program, and thus the elements of the program to be executed during the test in the test target program may be biased. In the case of bias, some elements remain partially untested.
  • Patent Document 1 describes a technique for generating a test case for an element that is insufficiently tested.
  • an execution history is acquired for each element of a program, and an element whose number of executions has not reached a predetermined target value is set as an unattained element.
  • a condition to be satisfied for each feature such as the header length is extracted from the test case in which the unreached element is executed by using a statistical method or artificial intelligence. Then, by automatically generating a test case that satisfies the extracted condition, the number of executions of all the elements of the program executed at least once or more is set to the target value or more.
  • Patent Document 2 describes a technique for extracting a branch condition from a source code to be tested to an element of a program by using symbolic execution and generating a test case satisfying the condition by using a solver.
  • Patent Document 1 cannot always generate a test case that is effective in increasing the number of test executions.
  • a test case that has executed an unreached element is selected from the execution history, and a test case satisfying the characteristics extracted from the selected test case is additionally generated.
  • the extracted feature does not always match the branch condition to the unreached element in the source code, so there is no guarantee that the additionally generated test case will surely execute the unreached element.
  • a meaningless test is a test by a case that overlaps with a test case that has already been executed
  • a meaningful test is a test by a test case that has not been executed yet.
  • the test execution device is A test case generation unit that generates a test case that executes an unachieved element in which the test does not meet the test criteria, out of a plurality of elements that make up the test target program, A local variable extractor for extracting a local variable used in the program code of the unreached element, A variable value changing unit that changes the value of the local variable extracted by the local variable extracting unit when the test target program that receives the test case generated by the test case generating unit is executed.
  • the value of the local variable used in the program code of the unreached element is changed when the test target program that receives the test case that executes the unreached element is executed. As a result, it becomes possible to execute a test having different inputs for the processing of the unreached element, and it becomes possible to execute a meaningful test for the unreached element.
  • FIG. 3 is a hardware configuration diagram of the test execution device 10 according to the first embodiment.
  • FIG. FIG. 3 is a functional configuration diagram of the test execution device 10 according to the first embodiment.
  • 3 is a flowchart showing the operation of the test execution device 10 according to the first embodiment.
  • FIG. 6 is an explanatory diagram of local variable extraction processing according to the first embodiment.
  • FIG. 6 is an explanatory diagram of a breakpoint setting process according to the first embodiment.
  • FIG. 6 is an explanatory diagram of a numerical value changing process according to the first embodiment.
  • the test execution device 10 is a computer.
  • the test execution device 10 includes hardware such as a processor 11, a memory 12, a storage 13, and a communication interface 14.
  • the processor 11 is connected to other hardware via a signal line and controls these other hardware.
  • the processor 11 is an IC (Integrated Circuit) that performs processing.
  • the processor 11 is a CPU (Central Processing Unit), a DSP (Digital Signal Processor), and a GPU (Graphics Processing Unit).
  • the memory 12 is a storage device that temporarily stores data.
  • the memory 12 is, for example, an SRAM (Static Random Access Memory) or a DRAM (Dynamic Random Access Memory).
  • the storage 13 is a storage device that stores data.
  • the storage 13 is, as a specific example, a HDD (Hard Disk Drive).
  • the storage 13 includes SD (registered trademark, Secure Digital) memory card, CF (CompactFlash, registered trademark), NAND flash, flexible disk, optical disk, compact disk, Blu-ray (registered trademark) disk, DVD (Digital Versatile Disk). It may be a portable recording medium.
  • the communication interface 14 is an interface for communicating with an external device.
  • the communication interface 14 is, as a specific example, an Ethernet (registered trademark), USB (Universal Serial Bus), or HDMI (registered trademark, High-Definition Multimedia Interface) port.
  • the test execution apparatus 10 includes, as functional components, an element division unit 21, a density calculation unit 22, an unreached element identification unit 23, a symbolic execution unit 24, a test case generation unit 25, and a local variable extraction unit 26.
  • a breakpoint setting unit 27, a variable value changing unit 28, and a program executing unit 29 are provided.
  • the function of each functional component of the test execution apparatus 10 is realized by software.
  • the storage 13 stores programs that implement the functions of the functional components of the test execution apparatus 10. This program is read into the memory 12 by the processor 11 and executed by the processor 11. As a result, the function of each functional component of the test execution device 10 is realized.
  • FIG. 1 only one processor 11 is shown. However, a plurality of processors 11 may be provided, and the plurality of processors 11 may execute programs that implement respective functions in cooperation with each other.
  • the operation of the test execution device 10 according to the first embodiment will be described with reference to FIGS. 3 to 6.
  • the operation of the test execution device 10 according to the first embodiment corresponds to the test execution method according to the first embodiment.
  • the operation of the test execution device 10 according to the first embodiment corresponds to the processing of the test execution program according to the first embodiment.
  • the total test execution history 32 indicates a history of execution of the test target program. Specifically, the test total execution history 32 indicates a set of a test case and an individual execution history for each of a plurality of test cases given to the test target program 31 in fuzzing executed in the past. The individual execution history is an execution history for each element when a corresponding test case is given to the test target program 31 and executed.
  • Step S101 of FIG. 3 element division processing
  • the element dividing unit 21 reads the test target program 31 from the storage 13.
  • the element dividing unit 21 divides the test target program 31 into a plurality of elements by using conditional branches as delimiters.
  • the element dividing unit 21 writes the divided program code of each element in the memory 12.
  • the test target program 31 will be described assuming that it is in the state of the source code. That is, the program code of the test target program 31 is assumed to be the source code. However, even if the program code of the test target program 31 is not the source code but the binary code, it is possible to perform the same processing by using the emulator.
  • Step S102 of FIG. 3 step calculation process
  • the element dividing unit 21 reads the program codes of the plurality of elements divided in step S101 from the memory 12.
  • the element dividing unit 21 calculates the number of steps of the program code of the target element for each of the plurality of elements.
  • the element dividing unit 21 writes the number of steps of each of the plurality of elements in the memory 12.
  • Step S103 of FIG. 3 Execution count calculation process
  • the density calculation unit 22 calculates the number of times the target element has been executed in the fuzzing executed in the past, for each of the plurality of elements divided in step S101. Specifically, the density calculation unit 22 reads the total test execution history 32 from the storage 13. The density calculation unit 22 calculates the number of times the target element has been executed from the total test execution history 32 for each of the plurality of elements. The density calculation unit 22 writes the number of times each of the plurality of elements has been executed in the memory 12.
  • Step S104 of FIG. 3 density calculation processing
  • the density calculation unit 22 calculates the test density of the target element for each of the plurality of elements divided in step S101. Specifically, the density calculation unit 22 reads from the memory 12 the number of steps of the program code of each of the plurality of elements calculated in step S102 and the number of times each of the plurality of elements calculated in step S103 has been executed. .. Then, the density calculation unit 22 calculates the test density of the target element by dividing the number of times by the number of steps of the program code of the target element. The density calculation unit 22 writes the test density of each of the plurality of elements in the memory 12.
  • Step S105 of FIG. 3 Unachieved element identification processing
  • the unreached element specifying unit 23 specifies the unreached element 34 whose test does not satisfy the test standard among the plurality of elements divided in step S101. Specifically, the unreached element specifying unit 23 reads out the test density calculated in step S104 for the target element from the memory 12 for each of the plurality of elements. The unachieved element identifying unit 23 identifies the targeted element as the unachieved element 34 when the test density of the targeted element is less than the density indicated by the density index 33 which is the test reference.
  • the density index 33 indicates a density which is a condition for determining whether or not each program element has been executed a sufficient number of times during the test so as to be judged not to have the vulnerability.
  • the density index 33 is set according to the degree of vulnerability of the test target program 31 and the like. Here, the density index 33 is assumed to be stored in the storage 13 in advance.
  • the unreached element specifying unit 23 specifies the insufficient test number 35 indicating the number of tests necessary for making the test density of the target element of the unreached element 34 reach the density indicated by the density index 33.
  • the unreached element specifying unit 23 writes the unreached element 34 and the insufficient test number 35 in association with each other in the memory 12.
  • Step S106 of FIG. 3 non-arrival determination process
  • the unreached element specifying unit 23 determines whether or not there is an element specified as the unreached element 34 in step S105. If there is an element identified as the unreached element 34, the unreached element identification unit 23 advances the process to step S107. On the other hand, the unreached-element specifying unit 23 ends the process when there is no element specified as the unreached element 34.
  • the processing from step S107 is executed for each of the plurality of unreached elements 34.
  • the processing from step S107 may be executed only on a part of the unachieved elements 34 having a high priority among the unachieved elements 34. For example, the priority is set to be higher for the unreached element 34 having a larger number of insufficient tests.
  • Step S107 in FIG. 3 Symbolic total history acquisition process
  • the symbolic execution unit 24 reads the total symbolic execution history 36 from the storage 13.
  • the total symbolic execution history 36 includes an execution path for each execution path of the test target program 31 targeted in the past symbolic execution, a constraint condition that the test case must satisfy to execute the execution path, and It is a set with an example of one test case 37 generated by solving a constraint condition. If fuzzing is executed before execution of the processing shown in FIG. 3 and symbolic execution is also executed, the symbolic execution total history 36 is stored in the storage 13 even when the processing shown in FIG. 3 is executed for the first time.
  • step S109 the symbolic execution unit 24 performs symbolic execution and writes the obtained information in the storage 13 as the symbolic execution total history 36.
  • Symbolic execution is processing for treating an input as a symbol and extracting a path that can be executed from the program code.
  • Patent Document 2 describes that symbolic execution is performed to generate a test case.
  • Step S108 of FIG. 3 acquisition determination process
  • the symbolic execution unit 24 determines whether or not the symbolic execution total history 36 read in step S107 includes an execution route having the target unreached element as a route end.
  • the symbolic execution part 24 advances a process to step S109, when the execution path which makes a target unachieved element the path
  • the symbolic execution part 24 advances a process to step S110, when the execution route which makes a route end the target unachieved element is included.
  • Step S109 of FIG. 3 symbolic execution process
  • the symbolic execution unit 24 reads the test target program 31 from the storage 13.
  • the symbolic execution unit 24 performs symbolic execution on the execution path having the target unreached element as the path end.
  • the symbolic execution unit 24 acquires, from the result of the symbolic execution, the constraint conditions that the test case 37 for executing the execution path having the target unreached element as the path end must satisfy.
  • the symbolic execution unit 24 writes the constraint condition in the memory 12.
  • the symbolic execution unit 24 associates the execution path with the constraint condition and adds them to the total symbolic execution history 36 stored in the storage 13.
  • Step S110 of FIG. 3 Constraint condition acquisition process
  • the symbolic execution unit 24 acquires, from the symbolic execution total history 36 read in step S107, the constraint conditions that the test case 37 for executing the execution path having the target unreached element as the path end must satisfy. ..
  • the symbolic execution unit 24 writes the constraint condition in the memory 12.
  • the test case generation unit 25 generates the test cases 37 that execute the unreached elements 34 whose tests do not satisfy the test criteria among the plurality of elements that form the test target program 31 by the number of the insufficient tests 35. Specifically, the test case generation unit 25 reads from the memory 12 the constraint condition acquired in step S109 or step S110 and the insufficient test number 35 for the target unreached element 34 calculated in step S105. The test case generation unit 25 generates the test cases 37 satisfying the constraint as many times as the number of the insufficient tests 35. The test case generation unit 25 stores the generation process of the test case 37 for each constraint condition, and uses the stored generation process for the constraint condition for which the test case 37 has been generated in the past.
  • test case generation unit 25 When the number of test cases 37 that can be generated is less than the number of test cases 35, the duplication of the test cases 37 is permitted.
  • the test case generator 25 writes the test case 37 in the memory 12.
  • the test case generation unit 25 associates one test case 37 with the constraint condition and adds the test case 37 to the symbolic execution total history 36 stored in the storage 13. ..
  • the local variable extraction unit 26 extracts a local variable used in the program code of the target unreached element 34.
  • the local variable is a local variable and is used only within a limited range such as within a function.
  • the local variable extraction unit 26 writes the local variable in the memory 12.
  • Writing the local variable to the memory 12 specifically means writing the variable name of the local variable, the type, and the referenced line to the memory 12.
  • the local variable extraction unit 26 may extract only the local variable referenced in the program code of the target unreached element 34.
  • the program “SAMPLE” is the test target program 31. Since the test target program 31 is divided into a plurality of elements with the conditional branch as a delimiter, here, the processing A and the processing B are each one element. At this time, it is assumed that the process A is the unachieved element 34.
  • the local variable extraction unit 26 refers to the program code of the process A, which is the unreached element 34, and searches for the local variable called in the process A. Since the process A has a local variable “localnum”, the local variable extraction unit 26 extracts “localnum” and writes the process A and the “localnum”, which are unreached elements 34, in the memory 12.
  • Step S113 of FIG. 3 Breakpoint setting processing
  • the break point setting unit 27 sets a break point at which the execution of the process is temporarily stopped immediately before the calling point of the local variable in the program code of the unreached element 34 of the test target program 31.
  • the breakpoint setting unit 27 reads the test target program 31 from the storage 13 and generates a copy of the program code of the test target program 31.
  • the breakpoint setting unit 27 reads out the local variables extracted in step S112 from the memory 12.
  • the breakpoint setting unit 27 sets a breakpoint immediately before a local variable in the copied program code.
  • the breakpoint setting unit 27 may use the function of the debugger to set a breakpoint immediately before the local variable in the test target program 31. In this case, the breakpoint can be set without rewriting the source code of the test target program 31.
  • FIG. 5 shows an example in which break points are set for the test target program 31 shown in FIG.
  • the break point setting unit 27 adds a break point in the copied program code of the test target program 31 immediately before the location where the local variable localnum is called. Immediately before the point where the local variable localnum is called is the line or the line immediately above.
  • the position where the breakpoint is set is not limited to the line immediately above where the local variable is called, and may be a line before the line to some extent as long as the value of the local variable is not affected.
  • Step S114 of FIG. 3 test case determination processing
  • the program execution unit 29 determines whether or not the unexecuted test case 37 remains in the test case 37 generated in step S111. When the unexecuted test case 37 remains, the program execution unit 29 advances the process to step S115. On the other hand, the program execution unit 29 ends the process when there is no unexecuted test case 37.
  • Step S115 of FIG. 3 first execution process
  • the program execution unit 29 reads the unexecuted test case 37 from the memory 12.
  • the program execution unit 29 receives the read test case 37 and executes the test target program 31.
  • the program execution unit 29 suspends the processing at the breakpoint included in the test target program 31.
  • Step S116 of FIG. 3 Numerical value change processing
  • the variable value changing unit 28 reads out the same set of local variables as the target unreached element 34 from the memory 12. Then, the variable value changing unit 28 changes the value of the local variable. At this time, the variable value changing unit 28 may change the value of the local variable to a random value, change it by using four arithmetic operations, or change the maximum value and the minimum value of the local variable to 0. May be changed to such a boundary value, or may be changed so that the resource consumption amount at the time of execution becomes large by applying a genetic algorithm. Regardless of which method is used to change the value of the local variable, the variable value changing unit 28 controls the test case 37 additionally executed so that the value does not overlap.
  • variable value changing unit 28 makes an inquiry to the program executing unit 29 based on the variable name of the local variable in the target unreached element 34, and acquires the address of the storage location of the value of the local variable in the memory 12.
  • the variable value changing unit 28 changes the value stored in the acquired address.
  • the variable value changing unit 28 acquires the address “0x11111111” of the storage position in the memory 12 of the value of the localnum that is a local variable, and the variable value changing unit 28 sets the value of the address “0x11111111” to “100”.
  • INT_MAX which is the maximum value of the int type.
  • Step S117 of FIG. 3 second execution process
  • the program execution unit 29 executes the process after the breakpoint on the test target program 31. As a result, the process is executed on the target unachieved element 34 in a state where the value of the local variable is changed.
  • the program execution unit 29 When the processing of the test target program 31 is completed, the program execution unit 29 returns the processing to step S114. Then, the program execution unit 29 repeatedly executes the processing from step S115 to step S117 until the unexecuted test cases 37 are exhausted.
  • the test execution device 10 uses the local variables used in the program code of the unreached element 34 when the target program having the test case 37 that executes the unreached element 34 as an input is executed. Change the value of. As a result, it becomes possible to execute a test having different inputs with respect to the processing of the unreached element 34, and it becomes possible to execute a meaningful test for the unreached element 34.
  • test execution device 10 According to the first embodiment, generates the test case 37 from the constraint condition obtained by the symbolic execution. Therefore, the test case 37 satisfies the condition for executing the unreached element 34. Then, the test execution device 10 according to the first embodiment changes the local variable in the unreached element 34 for each test case execution, so that it is possible to test the vulnerability of the internal processing of the unreached element 34. Is. As a result, it is possible to reduce the elements for which the test is insufficient and reduce the vulnerable portion in the test target program 31.
  • the test execution device 10 since the test execution device 10 according to the first embodiment changes the local variable localnum and performs the test, the test execution device 10 also performs the test in the case where the values of the variable x and the local variable localnum are different for the process C. It is possible to carry out. That is, the variable x and the local variable localnum are linked by the function size( ).
  • the process C When the process C operates without checking the input value on the premise of the relationship between the variable x and the local variable localnum, if the value of the local variable localnum is changed immediately before entering the process C, the variable x and the local variable localnum are changed.
  • the relationship derived from the function size() of is broken. This is called a case where the values of the variable x and the local variable localnum differ from each other.
  • the process C may have a problem. This case cannot be tested by conventional fuzzing, but can be tested by the test execution device 10 according to the first embodiment.
  • the local variable extraction unit 26 may extract only the local variable referenced in the program code of the unreached element 34 of interest. This is because if all local variables in the unreached element 34 are changed, variables that are not related to the processing in the unreached element 34 are also changed, which is wasteful. Therefore, the following rules are set for the selection of local variables to be extracted. First, the candidates to be extracted are listed in rule 1, and the candidates to be extracted are narrowed down in rules 2 to 4.
  • the local variable extraction unit 26 extracts the local variable referenced in the program code of the target unreached element 34 as a change target candidate.
  • the local variable extraction unit 26 excludes the local variables referenced only in the conditional branch determination and the loop continuation determination from the change target candidates.
  • the local variable extraction unit 26 excludes the pointer variable from the change target candidates.
  • the local variable extraction unit 26 excludes the variable referenced inside the standard library function from the change target candidates.
  • the local variable extraction unit 26 extracts the variable referred to in the processing in the unreached element 34 as a change target candidate. This is because the value stored in the variable is not used in the processing in the unreached element 34 if the operation (declaration/definition/assignment/release) other than reference is only performed, and thus the variable value is changed. This is because it has no meaning as a test for the unreached element 34. For example, when the variable referred to for the element (6) of FIG. 7 is extracted, tm_yday on the right side of the assignment operator is extracted as the change target candidate. In rule 2, the local variable extraction unit 26 excludes the variables referred to only by the conditional branch determination and the loop continuation determination from the change target candidates.
  • the unreached element 34 is not tested.
  • the variable num in the element (1) in FIG. 7 is certainly referenced because it is on the right side of the comparison operator, but in the element (1) it is referenced only by the conditional branch at the end of the element.
  • Element (1) is excluded from the candidates for change.
  • the local variable extraction unit 26 excludes the pointer variable from the change target candidates. This is because if the address to be referred to is changed, a failure may occur regardless of the processing inside the unreached element 34, and the unreached element 34 cannot be tested.
  • str is a pointer variable and thus is excluded from the candidates for change.
  • the local variable extraction unit 26 excludes the local variable inside the standard library function from the change target candidates. This is intended to omit testing, assuming that standard library functions are trustworthy.
  • the break point setting unit 27 sets a break point on the line where the local variable to be changed is referenced in the target unreached element 34 or on the line immediately above.
  • the breakpoint setting unit 27 sets only the first referenced line to set a breakpoint.
  • the breakpoint setting unit 27 sets breakpoints for all of them.
  • Rule 1 will be described with reference to FIG. It is assumed that the element (6) is the unreached element 34.
  • the unreached element 34 has the local variable tm_day to be changed, the type of the local variable tm_day, and the referenced row (here, the 32nd row). .. Therefore, in order to change the value of the variable tm_day, the breakpoint setting unit 27 sets a breakpoint on the 32nd line. According to rule 2, the breakpoint setting unit 27 sets a breakpoint only immediately before the first point when the same variable is referenced at a plurality of points.
  • the breakpoint setting unit 27 changes all the variables to be changed when there are a plurality of variables to be changed. For example, if the elements of the array such as str[3] or str[5] are referred to separately, a breakpoint is set immediately before each reference in order to change all of them.
  • each functional component is realized by software.
  • each functional component may be realized by hardware. Differences between the third embodiment and the first embodiment will be described.
  • the test execution device 10 When each functional component is realized by hardware, the test execution device 10 includes an electronic circuit instead of the processor 11, the memory 12, and the storage 13.
  • the electronic circuit is a dedicated circuit that realizes the functions of each functional component, the memory 12, and the storage 13.
  • each functional constituent element may be realized by one electronic circuit, or each functional constituent element may be dispersed and realized in a plurality of electronic circuits.
  • ⁇ Modification 4> As a fourth modification, some of the functional components may be realized by hardware, and the other functional components may be realized by software.
  • test execution device 11 processor, 12 memory, 13 storage, 14 communication interface, 21 element division part, 22 density calculation part, 23 unreached element identification part, 24 symbolic execution part, 25 test case generation part, 26 local variable extraction Section, 27 break point setting section, 28 variable value changing section, 29 program execution section, 31 test target program, 32 test total execution history, 33 density index, 34 unreached element, 35 insufficient test number, 36 symbolic execution total history, 37 test cases.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

テストケース生成部（２５）は、テスト対象プログラム（３１）を構成する複数の要素のうちテストがテスト基準である密度指標（３３）を満たしていない未達要素（３４）を実行するテストケース（３７）を生成する。局所変数抽出部（２６）は、未達要素（３４）のプログラムコードで使用される局所変数を抽出する。変数値変更部（２８）は、テストケース（３７）を入力とするテスト対象プログラム（３１）の実行時に、局所変数の値を変更する。

Description

テスト実行装置、テスト実行方法及びテスト実行プログラム
　この発明は、ソフトウェアのテストを実行する技術に関する。
　ソフトウェアが持つ脆弱性を検出するテスト手法として、ファジングがある。ファジングでは、テスト対象プログラムに予測不能なテストケースを多数与え、例外処理の挙動を監視することで脆弱性を検出する。しかし、ファジングでは、大量のテストケースをテスト対象プログラムによらず選択するので、テスト対象プログラムのうちテスト中に実行されるプログラムの要素に偏りが生じる場合がある。偏りが生じた場合には、部分的にテストが不十分な要素が残ってしまう。
　特許文献１には、テストが不十分な要素についてのテストケースを生成する技術が記載されている。特許文献１に記載された技術では、プログラムの要素毎に実行履歴が取得され、実行回数が事前に定めた目標値に到達していない要素が未達要素に設定される。未達要素を実行させたテストケースから統計的手法又は人工知能を用いてヘッダ長といった特徴毎に満たすべき条件が抽出される。そして、抽出された条件を満たすテストケースを自動生成することにより、少なくとも一度以上実行されたプログラムの全要素の実行回数を目標値以上とする。
　特許文献２には、シンボリック実行を用いてテスト対象のソースコードからあるプログラムの要素への分岐条件を抽出し、ソルバを用いてその条件を満たすテストケースを生成する技術が記載されている。
特開２０１７－１６７９８４号公報 特開２０１８－５８９０号公報
　特許文献１に記載された技術では、テスト実行数を増やす上で必ずしも有効なテストケースを生成できない。特許文献１に記載された技術では、実行履歴から未達要素を実行させたことのあるテストケースを選択し、選択されたテストケースから抽出された特徴を満たすテストケースを追加生成する。しかし、抽出された特徴はソースコード中の未達要素への分岐条件と一致するとは限らないため、追加生成したテストケースが未達要素を確実に実行させる保証はない。
　また、特許文献２に記載された技術を応用して、シンボリック実行を用いて未達要素への分岐条件を抽出し、未達要素を確実に実行させるためのテストケースを生成することが考えられる。しかし、このようにテストケースを生成したとしても、単に未達要素が実行されるだけであり、未達要素内の処理で使われる変数は考慮していないため、結果として意味のないテストを実行してしまう可能性がある。ここで、意味のないテストとは、既に実施したテストケースと重複するケースによるテストであり、意味のあるテストとは、まだ実施したことがないテストケースによるテストである。
　この発明は、追加テストの際にテスト対象の要素について意味のあるテストを実行可能にすることを目的とする。
　この発明に係るテスト実行装置は、
　テスト対象プログラムを構成する複数の要素のうちテストがテスト基準を満たしていない未達要素を実行するテストケースを生成するテストケース生成部と、
　前記未達要素のプログラムコードで使用される局所変数を抽出する局所変数抽出部と、
　前記テストケース生成部によって生成された前記テストケースを入力とする前記テスト対象プログラムの実行時に、前記局所変数抽出部によって抽出された前記局所変数の値を変更する変数値変更部と
を備える。
　この発明では、未達要素を実行するテストケースを入力とするテスト対象プログラムの実行時に、未達要素のプログラムコードで使用される局所変数の値を変更する。これにより、未達要素の処理に対して入力が異なるテストを実行することが可能になり、未達要素について意味のあるテストを実行することが可能になる。
実施の形態１に係るテスト実行装置１０のハードウェア構成図。 実施の形態１に係るテスト実行装置１０の機能構成図。 実施の形態１に係るテスト実行装置１０の動作を示すフローチャート。 実施の形態１に係る局所変数抽出処理の説明図。 実施の形態１に係るブレークポイント設置処理の説明図。 実施の形態１に係る数値変更処理の説明図。 変形例１に係るテスト対象プログラム３１の例を示す図。
　実施の形態１．
　＊＊＊構成の説明＊＊＊
　図１を参照して、実施の形態１に係るテスト実行装置１０のハードウェア構成を説明する。
　テスト実行装置１０は、コンピュータである。
　テスト実行装置１０は、プロセッサ１１と、メモリ１２と、ストレージ１３と、通信インタフェース１４とのハードウェアを備える。プロセッサ１１は、信号線を介して他のハードウェアと接続され、これら他のハードウェアを制御する。
　プロセッサ１１は、プロセッシングを行うＩＣ（Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）である。プロセッサ１１は、具体例としては、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）、ＤＳＰ（Ｄｉｇｉｔａｌ　Ｓｉｇｎａｌ　Ｐｒｏｃｅｓｓｏｒ）、ＧＰＵ（Ｇｒａｐｈｉｃｓ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）である。
　メモリ１２は、データを一時的に記憶する記憶装置である。メモリ１２は、具体例としては、ＳＲＡＭ（Ｓｔａｔｉｃ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）である。
　ストレージ１３は、データを保管する記憶装置である。ストレージ１３は、具体例としては、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）である。また、ストレージ１３は、ＳＤ（登録商標，Ｓｅｃｕｒｅ　Ｄｉｇｉｔａｌ）メモリカード、ＣＦ（ＣｏｍｐａｃｔＦｌａｓｈ，登録商標）、ＮＡＮＤフラッシュ、フレキシブルディスク、光ディスク、コンパクトディスク、ブルーレイ（登録商標）ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｋ）といった可搬記録媒体であってもよい。
　通信インタフェース１４は、外部の装置と通信するためのインタフェースである。通信インタフェース１４は、具体例としては、Ｅｔｈｅｒｎｅｔ（登録商標）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ）、ＨＤＭＩ（登録商標，Ｈｉｇｈ－Ｄｅｆｉｎｉｔｉｏｎ　Ｍｕｌｔｉｍｅｄｉａ　Ｉｎｔｅｒｆａｃｅ）のポートである。
　図２を参照して、実施の形態１に係るテスト実行装置１０の機能構成を説明する。
　テスト実行装置１０は、機能構成要素として、要素分割部２１と、密度算出部２２と、未達要素特定部２３と、シンボリック実行部２４と、テストケース生成部２５と、局所変数抽出部２６と、ブレークポイント設置部２７と、変数値変更部２８と、プログラム実行部２９とを備える。テスト実行装置１０の各機能構成要素の機能はソフトウェアにより実現される。
　ストレージ１３には、テスト実行装置１０の各機能構成要素の機能を実現するプログラムが格納されている。このプログラムは、プロセッサ１１によりメモリ１２に読み込まれ、プロセッサ１１によって実行される。これにより、テスト実行装置１０の各機能構成要素の機能が実現される。
　図１では、プロセッサ１１は、１つだけ示されていた。しかし、プロセッサ１１は、複数であってもよく、複数のプロセッサ１１が、各機能を実現するプログラムを連携して実行してもよい。
　＊＊＊動作の説明＊＊＊
　図３から図６を参照して、実施の形態１に係るテスト実行装置１０の動作を説明する。
　実施の形態１に係るテスト実行装置１０の動作は、実施の形態１に係るテスト実行方法に相当する。また、実施の形態１に係るテスト実行装置１０の動作は、実施の形態１に係るテスト実行プログラムの処理に相当する。
　以下の説明では、テストの対象のプログラムであるテスト対象プログラム３１に対して、過去にファジングが実行されているものとする。そして、テスト対象プログラム３１と、過去にファジングが実行されて得られたテスト総実行履歴３２とがストレージ１３に記憶されているものとする。
　テスト総実行履歴３２は、テスト対象プログラムが実行された履歴を示す。具体的には、テスト総実行履歴３２は、過去に実行されたファジングにおいて、テスト対象プログラム３１に与えた複数のテストケースそれぞれについての、テストケースと個別実行履歴との組を示す。個別実行履歴は、対応するテストケースをテスト対象プログラム３１に与えて実行した場合における要素毎の実行履歴である。
　（図３のステップＳ１０１：要素分割処理）
　要素分割部２１は、テスト対象プログラム３１をストレージ１３から読み出す。要素分割部２１は、条件分岐を区切りとしてテスト対象プログラム３１を複数の要素に分割する。要素分割部２１は、分割された各要素のプログラムコードをメモリ１２に書き込む。
　ここでは、テスト対象プログラム３１は、ソースコードの状態であることを想定して説明する。つまり、テスト対象プログラム３１のプログラムコードは、ソースコードであることを想定している。しかし、テスト対象プログラム３１のプログラムコードは、ソースコードではなくバイナリコードであっても、エミュレータを用いることで同様に処理を行うことが可能である。
　（図３のステップＳ１０２：ステップ計算処理）
　要素分割部２１は、ステップＳ１０１で分割された複数の要素のプログラムコードをメモリ１２から読み出す。要素分割部２１は、複数の要素それぞれを対象として、対象の要素のプログラムコードのステップ数を算出する。要素分割部２１は、複数の要素それぞれのステップ数をメモリ１２に書き込む。
　（図３のステップＳ１０３：実行回数算出処理）
　密度算出部２２は、ステップＳ１０１で分割された複数の要素それぞれを対象として、過去に実行されたファジングにおいて対象の要素が実行された回数を算出する。
　具体的には、密度算出部２２は、テスト総実行履歴３２をストレージ１３から読み出す。密度算出部２２は、複数の要素それぞれを対象として、テスト総実行履歴３２から対象の要素が実行された回数を算出する。密度算出部２２は、複数の要素それぞれが実行された回数をメモリ１２に書き込む。
　（図３のステップＳ１０４：密度算出処理）
　密度算出部２２は、ステップＳ１０１で分割された複数の要素それぞれを対象として、対象の要素のテスト密度を算出する。
　具体的には、密度算出部２２は、ステップＳ１０２で算出された複数の要素それぞれのプログラムコードのステップ数と、ステップＳ１０３で算出された複数の要素それぞれが実行された回数とをメモリ１２から読み出す。そして、密度算出部２２は、対象の要素のプログラムコードのステップ数で回数を割って、対象の要素のテスト密度を算出する。密度算出部２２は、複数の要素それぞれのテスト密度をメモリ１２に書き込む。
　（図３のステップＳ１０５：未達要素特定処理）
　未達要素特定部２３は、ステップＳ１０１で分割された複数の要素のうちテストがテスト基準を満たしていない未達要素３４を特定する。
　具体的には、未達要素特定部２３は、複数の要素それぞれを対象として、対象の要素についてステップＳ１０４で算出されたテスト密度をメモリ１２から読み出す。未達要素特定部２３は、対象の要素のテスト密度が、テスト基準である密度指標３３が示す密度未満の場合に、対象の要素を未達要素３４として特定する。密度指標３３は、テスト中に各プログラム要素が脆弱性を有さないと判断される程度に十分な回数実行されたかを判定する条件となる密度を示す。密度指標３３は、テスト対象プログラム３１がどの程度の脆弱性が許容される等に応じて設定される。ここでは、密度指標３３は、事前にストレージ１３に記憶されているものとする。
　また、未達要素特定部２３は、未達要素３４について、対象の要素のテスト密度を、密度指標３３が示す密度に到達させるのに必要なテストの件数を示す不足テスト数３５を特定する。
　未達要素特定部２３は、未達要素３４と不足テスト数３５とを対応付けてメモリ１２に書き込む。
　（図３のステップＳ１０６：未達判定処理）
　未達要素特定部２３は、ステップＳ１０５で未達要素３４として特定された要素があるか否かを判定する。
　未達要素特定部２３は、未達要素３４として特定された要素がある場合には、処理をステップＳ１０７に進める。一方、未達要素特定部２３は、未達要素３４として特定された要素がない場合には、処理を終了する。
　未達要素３４が複数存在した場合、ステップＳ１０７以降の処理は、複数の未達要素３４のそれぞれを対象として実行される。なお、ステップＳ１０７以降の処理は、複数の未達要素３４のうち、優先度が高い一部の未達要素３４のみ対象として実行されてもよい。優先度は、例えば、不足テスト数の多い未達要素３４ほど高く設定される。
　（図３のステップＳ１０７：シンボリック総履歴取得処理）
　シンボリック実行部２４は、シンボリック実行総履歴３６をストレージ１３から読み出す。
　シンボリック実行総履歴３６は、過去のシンボリック実行において対象としたテスト対象プログラム３１の実行経路それぞれについての、実行経路と、その実行経路を実行させるためにテストケースが満たす必要がある制約条件と、その制約条件を解くことにより生成された１つのテストケース３７の例との組である。図３に示す処理の実行前に、ファジングが実行された際、シンボリック実行も実行されている場合には、図３に示す処理が初めて実行される際にもシンボリック実行総履歴３６がストレージ１３に記憶されている。
　なお、後述するように、ステップＳ１０９でシンボリック実行部２４はシンボリック実行を行い、得られた情報をシンボリック実行総履歴３６としてストレージ１３に書き込む。
　シンボリック実行とは、入力を記号として扱いプログラムコードから実行し得る経路を抽出する処理である。特許文献２には、シンボリック実行を行いテストケースを生成することが記載されている。
　（図３のステップＳ１０８：取得判定処理）
　シンボリック実行部２４は、ステップＳ１０７で読み出されたシンボリック実行総履歴３６に、対象の未達要素を経路端とする実行経路が含まれているか否かを判定する。
　シンボリック実行部２４は、対象の未達要素を経路端とする実行経路が含まれていない場合には、処理をステップＳ１０９に進める。一方、シンボリック実行部２４は、対象の未達要素を経路端とする実行経路が含まれている場合には、処理をステップＳ１１０に進める。
　（図３のステップＳ１０９：シンボリック実行処理）
　シンボリック実行部２４は、テスト対象プログラム３１をストレージ１３から読み出す。シンボリック実行部２４は、対象の未達要素を経路端とする実行経路についてシンボリック実行を行う。シンボリック実行部２４は、シンボリック実行を行った結果から、対象の未達要素を経路端とする実行経路を実行させるためのテストケース３７が満たす必要がある制約条件を取得する。
　シンボリック実行部２４は、制約条件をメモリ１２に書き込む。また、シンボリック実行部２４は、実行経路と、制約条件とを対応付けて、ストレージ１３に記憶されたシンボリック実行総履歴３６に追加する。
　（図３のステップＳ１１０：制約条件取得処理）
　シンボリック実行部２４は、ステップＳ１０７で読み出されたシンボリック実行総履歴３６から、対象の未達要素を経路端とする実行経路を実行させるためのテストケース３７が満たす必要がある制約条件を取得する。シンボリック実行部２４は、制約条件をメモリ１２に書き込む。
　（図３のステップＳ１１１：テストケース生成処理）
　テストケース生成部２５は、テスト対象プログラム３１を構成する複数の要素のうちテストがテスト基準を満たしていない未達要素３４を実行するテストケース３７を不足テスト数３５が示す件数だけ生成する。
　具体的には、テストケース生成部２５は、ステップＳ１０９又はステップＳ１１０で取得された制約条件と、ステップＳ１０５で算出された対象の未達要素３４についての不足テスト数３５とをメモリ１２から読み出す。テストケース生成部２５は、不足テスト数３５が示す件数だけ、制約条件を満たすテストケース３７を生成する。なお、テストケース生成部２５は、制約条件毎にテストケース３７の生成過程を記憶しておき、過去にテストケース３７を生成したことがある制約条件に対しては記憶している生成過程を用いることにより、テストケース３７の生成時間を短縮する。生成可能なテストケース３７が不足テスト数３５が示す件数よりも少ない場合には、テストケース３７の重複を認める。
　テストケース生成部２５は、テストケース３７をメモリ１２に書き込む。また、テストケース生成部２５は、制約条件がステップＳ１０９で取得された場合には、１つのテストケース３７をその制約条件と対応付けて、ストレージ１３に記憶されたシンボリック実行総履歴３６に追加する。
　（図３のステップＳ１１２：局所変数抽出処理）
　局所変数抽出部２６は、対象の未達要素３４のプログラムコードで使用される局所変数を抽出する。局所変数は、ローカル変数のことであり、関数内といった限定的な範囲でのみ使用される変数である。局所変数抽出部２６は、局所変数をメモリ１２に書き込む。局所変数をメモリ１２に書き込むとは、具体的には、局所変数の変数名と、型と、参照されている行とをメモリ１２に書き込むという意味である。
　ここで、局所変数抽出部２６は、対象の未達要素３４のプログラムコードで参照されている局所変数のみを抽出してもよい。参照されている変数とは、式における代入演算子の右辺にある変数と、比較演算子の両辺にある変数である。例えば、ａ＝ｂ；という式があった場合、変数ｂが参照されている変数である。また、ｉ＝＝ｊ；という式があった場合，変数ｉ及び変数ｊともに参照されている変数である。
　図４を参照して、実施の形態１に係る局所変数抽出処理の具体例を説明する。
　図４では、「ＳＡＭＰＬＥ」というプログラムをテスト対象プログラム３１としている。テスト対象プログラム３１は、条件分岐を区切りとして複数の要素の分割されるため、ここでは処理Ａと処理Ｂとがそれぞれ１つの要素になる。このとき、処理Ａが未達要素３４であったとする。
　局所変数抽出部２６は、未達要素３４である処理Ａのプログラムコードを参照し、処理Ａで呼び出されている局所変数を探す。処理Ａには「ｌｏｃａｌｎｕｍ」という局所変数が存在するため、局所変数抽出部２６は「ｌｏｃａｌｎｕｍ」を抽出し、未達要素３４である処理Ａと「ｌｏｃａｌｎｕｍ」とを組にしてメモリ１２に書き込む。
　（図３のステップＳ１１３：ブレークポイント設置処理）
　ブレークポイント設置部２７は、テスト対象プログラム３１のうち対象の未達要素３４のプログラムコードにおける局所変数の呼出し箇所の直前に、処理の実行を一時停止させるブレークポイントを設置する。
　具体的には、ブレークポイント設置部２７は、テスト対象プログラム３１をストレージ１３から読み出し、テスト対象プログラム３１のプログラムコードのコピーを生成する。ブレークポイント設置部２７は、ステップＳ１１２で抽出された局所変数をメモリ１２から読み出す。ブレークポイント設置部２７は、コピーされたプログラムコードにおける、局所変数の直前にブレークポイントを設置する。
　なお、ブレークポイント設置部２７は、デバッガの機能を用いて、テスト対象プログラム３１における局所変数の直前にブレークポイントを設置してもよい。この場合には、テスト対象プログラム３１のソースコードを書き換えることなく、ブレークポイントを設置することが可能である。
　図５を参照して、実施の形態１に係るブレークポイント設置処理の具体例を説明する。
　図５では、図４に示すテスト対象プログラム３１に対してブレークポイントを設置した例を示している。ブレークポイント設置部２７は、コピーされたテスト対象プログラム３１のプログラムコードにおける、局所変数であるｌｏｃａｌｎｕｍが呼び出されている箇所の直前にブレークポイントを追加する。
　局所変数であるｌｏｃａｌｎｕｍが呼び出されている箇所の直前とは、その行あるいは直ぐ上の行ということである。但し、ブレークポイントを設置する位置は、局所変数が呼び出される直ぐ上の行に限定されるわけではなく、局所変数の値に影響がないのであれば、ある程度前の行であってもよい。
　（図３のステップＳ１１４：テストケース判定処理）
　プログラム実行部２９は、ステップＳ１１１で生成されたテストケース３７に未実行のテストケース３７が残っているか否かを判定する。
　プログラム実行部２９は、未実行のテストケース３７が残っている場合には、処理をステップＳ１１５に進める。一方、プログラム実行部２９は、未実行のテストケース３７が残っていない場合には、処理を終了する。
　（図３のステップＳ１１５：第１実行処理）
　プログラム実行部２９は、未実行のテストケース３７をメモリ１２から読み出す。プログラム実行部２９は、読み出されたテストケース３７を入力として、テスト対象プログラム３１を実行する。プログラム実行部２９は、テスト対象プログラム３１に含まれるブレークポイントで処理を一時停止する。
　（図３のステップＳ１１６：数値変更処理）
　変数値変更部２８は、対象の未達要素３４と同じ組の局所変数をメモリ１２から読み出す。そして、変数値変更部２８は、局所変数の値を変更する。この際、変数値変更部２８は、局所変数の値を、ランダム値に変更してもよいし、四則演算を用いて変更してもよいし、局所変数が取り得る最大値及び最小値と０といった境界値に変更してもよいし、遺伝的アルゴリズムを適用する等して実行時のリソース消費量が大きくなるように変更してもよい。いずれの方法で局所変数の値を変更するとしても、変数値変更部２８は、追加で実行するテストケース３７において値の重複がないように制御する。
　図６を参照して、実施の形態１に係る数値変更処理の具体例を説明する。
　ブレークポイント設置部２７によって設置されたブレークポイントでテスト対象プログラム３１の処理が一時停止している。このとき、変数値変更部２８は、対象の未達要素３４における局所変数の変数名に基づきプログラム実行部２９に問合せを行い、メモリ１２における局所変数の値の格納個所のアドレスを取得する。変数値変更部２８は、取得されたアドレスに格納された値を変更する。
　図６では、変数値変更部２８は、局所変数であるｌｏｃａｌｎｕｍの値のメモリ１２における格納位置のアドレス「０ｘ１１１１１１１１」を取得し、変数値変更部２８は、アドレス「０ｘ１１１１１１１１」の値を「１００」からｉｎｔ型の最大値である「ＩＮＴ＿ＭＡＸ」に変更している。
　（図３のステップＳ１１７：第２実行処理）
　プログラム実行部２９は、テスト対象プログラム３１について、ブレークポイント以後の処理を実行する。これにより、対象の未達要素３４について、局所変数の値が変更された状態で処理が実行される。
　プログラム実行部２９は、テスト対象プログラム３１の処理が終了すると、処理をステップＳ１１４に戻す。そして、プログラム実行部２９は、未実行のテストケース３７がなくまるまで、ステップＳ１１５からステップＳ１１７の処理を繰り返し実行する。
　＊＊＊実施の形態１の効果＊＊＊
　以上のように、実施の形態１に係るテスト実行装置１０は、未達要素３４を実行するテストケース３７を入力とする対象プログラムの実行時に、未達要素３４のプログラムコードで使用される局所変数の値を変更する。これにより、未達要素３４の処理に対して入力が異なるテストを実行することが可能になり、未達要素３４について意味のあるテストを実行することが可能になる。
　また、実施の形態１に係るテスト実行装置１０は、シンボリック実行で得られた制約条件からテストケース３７を生成する。そのため、テストケース３７は未達要素３４を実行させる条件を満たしている。そして、実施の形態１に係るテスト実行装置１０は、未達要素３４内の局所変数をテストケース実行ごとに変化させるため、未達要素３４の内部の処理について脆弱性のテストを行うことが可能である。これにより、テストが不十分な要素を減らし、テスト対象プログラム３１における脆弱性を有する部分を少なくすることが可能である。
　従来のファジングでは、テスト対象プログラム３１への入力のみを変更してテストする。つまり、図４では変数ｘのみを変更してテストする。そのため、図４における処理Ｃに対して変数ｘと局所変数ｌｏｃａｌｎｕｍとの値が食い違うケースについてはテストできない。これに対して、実施の形態１に係るテスト実行装置１０は、局所変数ｌｏｃａｌｎｕｍを変更してテストを行うため、処理Ｃに対して変数ｘと局所変数ｌｏｃａｌｎｕｍとの値が食い違うケースについてもテストを実行することが可能である。
　つまり、変数ｘと局所変数ｌｏｃａｌｎｕｍとはｓｉｚｅ（）という関数で紐づけられている。処理Ｃが変数ｘと局所変数ｌｏｃａｌｎｕｍとの関係を前提として入力値をチェックすることなく動作する場合、処理Ｃに入る直前で局所変数ｌｏｃａｌｎｕｍの値が変更されると、変数ｘと局所変数ｌｏｃａｌｎｕｍとのｓｉｚｅ（）という関数に由来する関係が崩れてしまう。これを、変数ｘと局所変数ｌｏｃａｌｎｕｍとの値が食い違うケースと呼んでいる。このケースでは、処理Ｃに不具合が発生する可能性がある。このケースについて従来のファジングではテストできないが、実施の形態１に係るテスト実行装置１０ではテストすることが可能である。
　＊＊＊他の構成＊＊＊
　＜変形例１＞
　図３のステップＳ１１２の局所変数抽出処理について補足する。
　実施の形態１では、局所変数抽出部２６は、対象の未達要素３４のプログラムコードで参照されている局所変数のみを抽出してもよいと説明した。これは、未達要素３４内全ての局所変数を変更してしまうと、未達要素３４内の処理に関係のない変数まで変更するため無駄が多いためである。
　そこで、抽出対象の局所変数の選択には次のルールを設定する。まず、ルール１で抽出対象の候補が挙げられ、ルール２～ルール４で抽出対象の候補が絞り込まれていく。
（ルール１）
　局所変数抽出部２６は、対象の未達要素３４のプログラムコードで参照されている局所変数を変更対象候補として抽出する。
（ルール２）
　局所変数抽出部２６は、条件分岐判定及びループ継続判定でのみ参照されている局所変数は変更対象候補から除外する。
（ルール３）
　局所変数抽出部２６は、ポインタ変数を変更対象候補から除外する。
（ルール４）
　局所変数抽出部２６は、標準ライブラリ関数内部で参照されている変数を変更対象候補から除外する。
　ルール１では、局所変数抽出部２６は、未達要素３４内の処理で参照されている変数を変更対象候補として抽出する。なぜなら、参照以外の操作（宣言・定義・代入・解放）がなされているだけでは、未達要素３４内の処理で変数に格納されている値が使われないため、変数値を変更しても未達要素３４に対するテストとして意味がないからである。例えば、図７の要素（６）について参照されている変数を抽出すると、代入演算子の右辺にあるｔｍ＿ｙｄａｙが変更対象候補として抽出される。
　ルール２では、局所変数抽出部２６は、条件分岐判定及びループ継続判定のみで参照されている変数を変更対象候補から除外する。なぜなら、条件分岐判定で要素分割しているため条件分岐判定は必ず要素の末尾に来るので、そこで参照されている変数を変更しても未達要素３４に対するテストにならないからである。例えば、図７の要素（１）中にある変数ｎｕｍは、比較演算子の右辺にあるため確かに参照されているが、要素（１）内では要素末尾の条件分岐のみで参照されているため、要素（１）における変更対象候補から除外される。
　ルール３では、局所変数抽出部２６は、ポインタ変数を変更対象候補から除外する。な
ぜなら、参照するアドレスを変更してしまうと、未達要素３４内部の処理に関係なく不具合を発生させるおそれがあり、未達要素３４に対するテストにならないからである。例えば、図７の要素（１）では、ｓｔｒはポインタ変数なので変更対象候補から除外される。
　ルール４では、局所変数抽出部２６は、標準ライブラリ関数内部の局所変数を変更対象候補から除外する。これには、標準ライブラリ関数は信頼できるとみなしてテストを省略する意図がある。
　＜変形例２＞
　図３のステップＳ１１３のブレークポイント設置処理について補足する。
　変形例１で説明した図３のステップＳ１１２の局所変数抽出処理と同様に、無駄な変数値変更を避けるため、ブレークポイント設置処理についても次のルールを設定する。
（ルール１）
　ブレークポイント設置部２７は、変更対象の局所変数が対象の未達要素３４内で参照されている行あるいは直ぐ上の行にブレークポイントを設置する。
（ルール２）
　ブレークポイント設置部２７は、同一の変数が未達要素３４内の複数箇所で参照されている場合には、最初に参照された行のみをブレークポイントの設置対象とする。
（ルール３）
　ブレークポイント設置部２７は、変更対象の局所変数が複数存在する場合には、その全てを対象としてブレークポイントを設置する。
　ルール１について図７を例に説明する。要素（６）が未達要素３４であるとする。図３のステップＳ１１２で、この未達要素３４には変更対象の局所変数ｔｍ＿ｄａｙがあることと、局所変数ｔｍ＿ｄａｙの型及び参照されている行（ここでは３２行目とする）が得られている。そこで、変数ｔｍ＿ｄａｙの値を変更するため、ブレークポイント設置部２７は、３２行目にブレークポイントを設置する。
　ルール２では、ブレークポイント設置部２７は、同一の変数が複数箇所で参照されている場合には、最初の箇所の直前のみにブレークポイントを設置する。これは、参照される毎に値を変更してしまうと、例えば同一要素内に２つの処理があった場合に、「処理１に０を入力すると処理２で不具合が起こる」といった処理同士の関係を追えなくなるからである。
　ルール３では、ブレークポイント設置部２７は、変更対象変数が複数あった場合、全てを変更する。例えばｓｔｒ［３］又はｓｔｒ［５］といった配列の要素が別々に参照されていた場合には、それら全てを変更するためそれぞれの参照直前にブレークポイントが設置される。
　＜変形例３＞
　実施の形態１では、各機能構成要素がソフトウェアで実現された。しかし、変形例３として、各機能構成要素はハードウェアで実現されてもよい。この変形例３について、実施の形態１と異なる点を説明する。
　各機能構成要素がハードウェアで実現される場合には、テスト実行装置１０は、プロセッサ１１とメモリ１２とストレージ１３とに代えて、電子回路を備える。電子回路は、各機能構成要素と、メモリ１２と、ストレージ１３との機能とを実現する専用の回路である。
　電子回路としては、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ロジックＩＣ、ＧＡ（Ｇａｔｅ　Ａｒｒａｙ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ　Ｓｐｅｃｉｆｉｃ　Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）が想定される。
　各機能構成要素を１つの電子回路で実現してもよいし、各機能構成要素を複数の電子回路に分散させて実現してもよい。
　＜変形例４＞
　変形例４として、一部の各機能構成要素がハードウェアで実現され、他の各機能構成要素がソフトウェアで実現されてもよい。
　１０　テスト実行装置、１１　プロセッサ、１２　メモリ、１３　ストレージ、１４　通信インタフェース、２１　要素分割部、２２　密度算出部、２３　未達要素特定部、２４　シンボリック実行部、２５　テストケース生成部、２６　局所変数抽出部、２７　ブレークポイント設置部、２８　変数値変更部、２９　プログラム実行部、３１　テスト対象プログラム、３２　テスト総実行履歴、３３　密度指標、３４　未達要素、３５　不足テスト数、３６　シンボリック実行総履歴、３７　テストケース。

Claims (7)

  1. 　テスト対象プログラムを構成する複数の要素のうちテストがテスト基準を満たしていない未達要素を実行するテストケースを生成するテストケース生成部と、
    　前記未達要素のプログラムコードで使用される局所変数を抽出する局所変数抽出部と、
    　前記テストケース生成部によって生成された前記テストケースを入力とする前記テスト対象プログラムの実行時に、前記局所変数抽出部によって抽出された前記局所変数の値を変更する変数値変更部と
    を備えるテスト実行装置。
  2. 　前記テスト実行装置は、さらに、
    　前記未達要素のプログラムコードにおける前記局所変数の呼出し箇所の前に、処理の実行を一時停止させるブレークポイントを設置するブレークポイント設置部
    を備え、
    　前記変数値変更部は、前記テストケースを入力とする前記テスト対象プログラムの実行時において、前記ブレークポイントで処理の実行が停止した際に、前記局所変数の値を変更する
    請求項１に記載のテスト実行装置。
  3. 　前記テストケース生成部は、前記テスト対象プログラムをシンボリック実行して得られた前記未達要素を実行するための制約条件を満たすテストケースを生成することにより、前記未達要素を実行するテストケースを生成する
    請求項１又は２に記載のテスト実行装置。
  4. 　前記テスト実行装置は、さらに、
    　前記複数の要素それぞれを対象として、前記テスト対象プログラムが実行された履歴を示すテスト総実行履歴から対象の要素が実行された回数を算出し、前記対象の要素のプログラムコードのステップ数で前記回数を割って、前記対象の要素のテスト密度を算出する密度算出部と、
    　前記密度算出部によって算出された前記対象の要素の前記テスト密度が、前記テスト基準である密度指標が示す密度未満の場合に、前記対象の要素を前記未達要素として特定する未達要素特定部と
    を備える請求項１から３までのいずれか１項に記載のテスト実行装置。
  5. 　前記未達要素特定部は、前記対象の要素の前記テスト密度を、前記密度指標が示す密度に到達させるのに必要なテストの件数を示す不足テスト数を特定し、
    　前記テストケース生成部は、前記不足テスト数が示す件数の前記テストケースを生成する
    請求項４に記載のテスト実行装置。
  6. 　テストケース生成部が、テスト対象プログラムを構成する複数の要素のうちテストがテスト基準を満たしていない未達要素を実行するテストケースを生成し、
    　局所変数抽出部が、前記未達要素のプログラムコードで使用される局所変数を抽出し、
    　変数値変更部が、前記テストケースを入力とする前記テスト対象プログラムの実行時に、前記局所変数の値を変更するテスト実行方法。
  7. 　テスト対象プログラムを構成する複数の要素のうちテストがテスト基準を満たしていない未達要素を実行するテストケースを生成するテストケース生成処理と、
    　前記未達要素のプログラムコードで使用される局所変数を抽出する局所変数抽出処理と、
    　前記テストケース生成処理によって生成された前記テストケースを入力とする前記テスト対象プログラムの実行時に、前記局所変数抽出処理によって抽出された前記局所変数の値を変更する変数値変更処理と
    を行うテスト実行装置としてコンピュータを機能させるテスト実行プログラム。
PCT/JP2018/048499 2018-12-28 2018-12-28 テスト実行装置、テスト実行方法及びテスト実行プログラム WO2020136880A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2018/048499 WO2020136880A1 (ja) 2018-12-28 2018-12-28 テスト実行装置、テスト実行方法及びテスト実行プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2018/048499 WO2020136880A1 (ja) 2018-12-28 2018-12-28 テスト実行装置、テスト実行方法及びテスト実行プログラム

Publications (1)

Publication Number Publication Date
WO2020136880A1 true WO2020136880A1 (ja) 2020-07-02

Family

ID=71127819

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/048499 WO2020136880A1 (ja) 2018-12-28 2018-12-28 テスト実行装置、テスト実行方法及びテスト実行プログラム

Country Status (1)

Country Link
WO (1) WO2020136880A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112699054A (zh) * 2020-08-03 2021-04-23 徐州工程学院 一种软件测试用例有序生成方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06161825A (ja) * 1992-11-20 1994-06-10 Toshiba Corp ソフトウェアプログラムのテストカバレッジ計測装置
JP2012256195A (ja) * 2011-06-08 2012-12-27 Fujitsu Semiconductor Ltd デバッガプログラム及びデバッグ方法
JP2017041196A (ja) * 2015-08-21 2017-02-23 富士通株式会社 スタブ化対象判定装置、方法、及びプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06161825A (ja) * 1992-11-20 1994-06-10 Toshiba Corp ソフトウェアプログラムのテストカバレッジ計測装置
JP2012256195A (ja) * 2011-06-08 2012-12-27 Fujitsu Semiconductor Ltd デバッガプログラム及びデバッグ方法
JP2017041196A (ja) * 2015-08-21 2017-02-23 富士通株式会社 スタブ化対象判定装置、方法、及びプログラム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112699054A (zh) * 2020-08-03 2021-04-23 徐州工程学院 一种软件测试用例有序生成方法
CN112699054B (zh) * 2020-08-03 2022-02-18 徐州工程学院 一种软件测试用例有序生成方法

Similar Documents

Publication Publication Date Title
US8316448B2 (en) Automatic filter generation and generalization
US20210064512A1 (en) Selective memory tracing of program execution
US10650147B2 (en) Method and apparatus for ensuring control flow integrity
CN109635568B (zh) 一种基于静态分析和模糊测试相结合的并发漏洞检测方法
WO2018070404A1 (ja) マルウェア解析装置、マルウェア解析方法、及び、マルウェア解析プログラムが格納された記録媒体
US8650546B2 (en) Static analysis based on observed string values during execution of a computer-based software application
CN104281805A (zh) 安全保护方法和处理器
US11868465B2 (en) Binary image stack cookie protection
WO2020136880A1 (ja) テスト実行装置、テスト実行方法及びテスト実行プログラム
US9350723B2 (en) Determination and classification of defense measures in web applications
US9734458B2 (en) Predicting outcome based on input
WO2023067665A1 (ja) 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
WO2023067668A1 (ja) 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
Spruyt Building fault models for microcontrollers
US8554522B2 (en) Detection of design redundancy
CN111858307B (zh) 模糊测试方法和设备
JP7008879B2 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
KR101947737B1 (ko) 명시적 및 암시적 정보 흐름 추적 방법 및 그 장치
JP6723483B2 (ja) テストケース生成装置、テストケース生成方法およびテストケース生成プログラム
CN109213526B (zh) 用于确定处理器操作的方法及装置
WO2023067663A1 (ja) 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
WO2019142335A1 (ja) セキュリティ設計装置、セキュリティ設計方法およびセキュリティ設計プログラム
WO2023067667A1 (ja) 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
WO2020136793A1 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
CN117931540A (zh) 预留指令处理方法、装置、电子设备和存储介质

Legal Events

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

Ref document number: 18944891

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18944891

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP