WO2022044376A1 - 不具合解析装置、プログラムおよび不具合解析方法 - Google Patents

不具合解析装置、プログラムおよび不具合解析方法 Download PDF

Info

Publication number
WO2022044376A1
WO2022044376A1 PCT/JP2021/007054 JP2021007054W WO2022044376A1 WO 2022044376 A1 WO2022044376 A1 WO 2022044376A1 JP 2021007054 W JP2021007054 W JP 2021007054W WO 2022044376 A1 WO2022044376 A1 WO 2022044376A1
Authority
WO
WIPO (PCT)
Prior art keywords
analysis
function
program
start point
execution
Prior art date
Application number
PCT/JP2021/007054
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 US18/015,266 priority Critical patent/US20230259447A1/en
Publication of WO2022044376A1 publication Critical patent/WO2022044376A1/ja

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/3636Software debugging by tracing the execution of the program
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3604Software analysis for verifying properties of programs

Definitions

  • the present invention relates to a defect analysis device, a program, and a defect analysis method that support analysis of defects in a software program.
  • test In software development, the operation of software (program, software program) that differs from the specifications or is not expected by the developer is called a defect, and it is desirable to correct all the defects before releasing the software.
  • Testing is a common method for detecting defects. In the test, the input and output that are in the specification or expected by the developer are created as test cases, and it is confirmed whether the program returns the correct output for the input. If the output is different from the input, or if an exception (failure) occurs and the program does not operate, it is determined that there is a problem (a problem has occurred). If there is a problem, the developer analyzes which part of the software performed the unexpected processing, identifies the cause, and corrects the logic of the program so that appropriate input / output is performed.
  • a large and complicated program requires many test cases. Specifically, it is not realistic because a huge amount of test cases are required to cover all statements (rows / steps), branches, branch conditions, etc. of the program.
  • test cases In a control program that calculates an output from an input, most of the inputs are processed correctly, but illegal processing may be performed under extremely rare conditions. Such defects are called non-reproducibility defects, and it is difficult to identify rare conditions in which the defects occur.
  • Patent Document 1 in a software component in which an input specification and an output specification are defined, the failure propagation at the time of failure of the software component is performed by determining which output cannot satisfy the specification for an input that violates the specification. The method of evaluation is described.
  • Patent Document 1 can evaluate the behavior of a software component when an abnormal input is given, but cannot analyze the cause of a problem that an abnormal output occurs with respect to a normal input.
  • the present invention has been made in view of such a background, and an object of the present invention is to provide a defect analysis device, a program, and a defect analysis method capable of identifying an execution path in which a defect contained in a program occurs. ..
  • the defect analysis device acquires the statement of the program in which an exception occurs from the execution log as the analysis start point when analyzing the defect of the program together with the execution log of the program.
  • An analysis start point acquisition unit an analysis end point acquisition unit that acquires a function that directly or indirectly calls a function including the analysis start point as an analysis end point, and a reverse symbol execution from the analysis start point to the analysis end point. It is equipped with a symbol execution engine that outputs the execution path.
  • the present invention it is possible to provide a defect analysis device, a program, and a defect analysis method that enable identification of an execution path in which a defect included in a program occurs.
  • the input of the defect analysis device includes the source code of the program and the execution log of the program.
  • the execution log contains the function (method) called during execution. If an exception (for example, zero increment) occurs during execution, the execution log ends with the call to the function in which the exception occurred (recording the program stop).
  • the defect analysis device sets the statement (source code line / step) of the program in which the exception occurred in the function in which the exception occurred from the execution log (for example, the gradual operation of 0 gradual calculation) as the analysis start point.
  • a function that directly or indirectly calls a function including an analysis start point by inquiring to a user (developer) is set as an analysis end point.
  • the defect analysis device executes the reverse symbol in the direction opposite to the normal program execution.
  • the defect analyzer records the execution path and path conditions.
  • the execution path is a path (arrangement of statements / lines / steps) in the program connecting the analysis end point and the analysis start point, and processing proceeds along the execution path.
  • the execution path also includes the function call.
  • the path condition is a condition of a variable in which an exception (for example, zero division) occurs. Variables include local variables within the function and input parameters of the function.
  • the defect analysis device uses the SMT solver (Satisfiability Modulo Theories Solver) to calculate the input parameter value of the function that is the analysis end point that satisfies the path condition. By performing a test with this value as an input, the user can confirm whether the modified program works properly.
  • SMT solver Stisfiability Modulo Theories Solver
  • FIG. 1 is a diagram showing an input, an output, and an overall configuration of the defect analysis device 100 according to the present embodiment.
  • the defect analysis device 100 includes a control unit 110, a storage unit 120, and an input / output unit 180.
  • the input / output unit 180 includes a user interface such as a display, a keyboard, and a mouse.
  • the input / output unit 180 may further include a communication interface and a reading / writing device for a recording medium.
  • the storage unit 120 is composed of a RAM (Random Access Memory), a ROM (Read Only Memory), an SSD (Solid State Drive), and the like.
  • the storage unit 120 stores the program 121 and the function call-related database 130 (described as the function call-related DB (Database) in FIG. 1).
  • the program 121 is a program for making the computer function as the defect analysis device 100, and includes a description of the processing procedure of the defect analysis process (see FIG. 5 described later).
  • the function call relation database 130 stores data showing a relation of which function calls which function, in other words, a call relation graph (a graph of a control flow expressing the call relation between functions). Before explaining the control unit 110, the input and the output of the defect analysis device 100 will be described.
  • the input of the defect analysis device 100 includes the source code 210, the program execution log 220, and the program specification 230.
  • the source code 210 is the source code of the function (method) that constitutes the software program to be analyzed.
  • the program specification 230 the name of the function, and the name, type, and range of the input parameter value and the return value (return value) of the function are described.
  • the program execution log 220 (execution log) includes a record of function calls during program execution.
  • the program execution log 220 may include an input parameter value at the time of calling and a return value at the time of returning from the call in addition to the name (identification information) of the called function.
  • the program execution log 220 may further include an exception that occurs during program execution. Exceptions include zero graduation and violations of the input parameter value or return value described in the program specification 230 (values outside the range of the specification).
  • the output of the defect analysis device 100 includes an execution path 240 and an input parameter value 250.
  • the execution path 240 is a path (a series of statements / lines / steps sequentially processed in the source code 210) in the program in which the problem occurs.
  • One end of the execution path 240 is a statement / line / step in which an exception (failure) related to a defect occurs, and is described as an analysis start point or simply a start point.
  • the analysis start point is, for example, a statement including a slow operation in which 0 slow calculation occurs.
  • the other end of the execution path 240 is a function that directly or indirectly calls the function including the analysis start point, and is referred to as an analysis end point or an entry point.
  • the analysis end point may be a function including the start point.
  • the input parameter value 250 is an input parameter value when a defect occurs in the function that is the entry point.
  • the control unit 110 includes a CPU (Central Processing Unit), and includes a call relationship generation unit 111, an analysis start point acquisition unit 112, an analysis end point acquisition unit 113, a symbol execution engine 114, and an SMT solver 115.
  • the call relation generation unit 111 acquires the function call relation from the source code 210 and stores it in the function call relation database 130.
  • the analysis start point acquisition unit 112 analyzes the program execution log 220 and acquires the analysis start point. Details of the procedure for acquiring the analysis start point will be described later.
  • the analysis end point acquisition unit 113 (entry point acquisition unit) acquires a function that calls a function including the analysis start point from the function call relational database 130, and displays it on the display provided in the input / output unit 180 as an entry point candidate. The user (developer) selects one or more entry points from the candidates. The analysis end point acquisition unit 113 sets the selected function as the analysis end point (entry point).
  • the symbol execution engine 114 generates an execution path 240 and a path condition.
  • the path condition is a condition of variables (local variables and input parameters) for the execution of the program to be analyzed to pass through the execution path 240. Details of the execution path 240 and the path conditions will be described later.
  • the following references describe the details of the Symbolic Concrete Backward Execution: Peter Dinges and Gul Agha, "Targeted Test Input Generation Using Symbolic Concrete Backward Execution”.
  • the SMT solver 115 (solver) generates an input parameter value 250 that satisfies the path condition.
  • the SMT solver is described in the following references: Leonardo de Moura and Nikolaj Bjorner, "Z3: An Efficient SMT Solver”.
  • FIG. 2 is a diagram for explaining an execution path and a path condition according to the present embodiment.
  • FIG. 2 includes source code 210 for three functions, function apel10, function bar20, and function foo30.
  • the function apel10 calls the function bar20
  • the function bar20 calls the function foo30.
  • the description will be continued on the assumption that the exception of 0 gradual calculation occurs in the function foo30 and the function apel10 is specified as the entry point.
  • the program execution log 220 includes the recording of the call of the function apel10, the recording of the call of the function bar20, and the recording of the call of the function foo30, and ends with the recording of the occurrence of 0 gradual calculation.
  • the analysis start point acquisition unit 112 By analyzing the program execution log 220, the analysis start point acquisition unit 112 detects that an exception of 0 gradual calculation has occurred in the function foo30. Since the line 3 of the function foo is the only statement / line including the gradual calculation operation, the analysis start point acquisition unit 112 sets the start point to the line 3 of the function foo30. That is, the analysis start point acquisition unit 112 acquires the statement of the program in which the exception has occurred from the execution log as the analysis start point.
  • a path condition is a condition / constraint that causes an exception.
  • the symbol execution engine 114 determines that the function foo30 has called the second input parameter b at 0, and searches for a statement that calls the function foo30.
  • the statement that calls the function foo30 is line 3 of the function bar20, and the symbol execution engine 114 continues the search from that line.
  • the execution path at this point is line 3 to line 1 of the function foo30 and line 3 of the function bar20.
  • the functions apel10, bar20, and foo30 have variables a, b, and c having the same name, respectively, but these are local variables of each function and are different variables.
  • the symbol execution engine 114 starts the search from line 3 of the function bar20 and reaches line 1.
  • the execution paths at this point are lines 3 to 1 of the function foo30 and lines 3 to 1 of the function bar20.
  • the symbol execution engine 114 determines that the function bar20 has called the first parameter and the second input parameter with the same value, and searches for a statement that calls the function bar20. In the case of FIG. 2, the statement that calls the function bar20 is line 3 of the function apel10, and the symbol execution engine 114 continues the search from that line.
  • the symbol execution engine 114 starts the search from line 3 of the function apel10 and reaches line 1. Since the function apel10 is the analysis end point, the search ends here.
  • the path condition includes the condition of the input parameter value of the entry point (analysis end point).
  • the symbol execution engine 114 displays the execution path on the display provided in the input / output unit 180 (outputs the execution path).
  • the user can understand under what conditions and how the process proceeds and the problem occurs in the program. As a result, you will be able to find problems and fix the program.
  • the SMT solver 115 provides an input parameter value 250 (an input value of an entry point (analysis end point) that satisfies the path condition), and the user can test the modified program using this value.
  • the symbol execution engine 114 may record each execution path and path condition. In such a case, there will be multiple execution paths and multiple path conditions. In other words, it was found that an exception occurs at the same place (analysis start point) under different conditions.
  • FIG. 3 is a configuration diagram of a screen 400 of the defect analysis device 100 according to the present embodiment.
  • the information display area 411 of the analysis start point, the information display area 412 of the analysis end point, and the information display area 413 of the analysis result are arranged in the center on the left and right of the screen 400 from the top.
  • the analysis start point acquisition unit 112 sets the analysis start point
  • the function name including the analysis start point, the number of lines of the analysis start point, the condition for generating an exception, and the like are displayed in the information display area 411 of the analysis start point. For example, when an exception of 0 gradual calculation occurs and there are a plurality of gradual calculation operations, there are a plurality of candidates for analysis start points.
  • the information display area 411 has a plurality of candidates for the analysis start point, and a message prompting the user to select one of them is displayed.
  • the user presses the "designate" button 421 and selects one analysis start point from the screen (not shown) that displays the candidates for the analysis start point.
  • the analysis start point acquisition unit 112 sets the candidate of the selected analysis start point as the analysis start point.
  • a message prompting the selection of the analysis end point is displayed in the information display area 412 of the analysis end point.
  • the user presses the "Specify" button 422 to end one or more analysis from the screen (not shown) that displays the candidates for the analysis end point (function including the start point, function that directly or indirectly calls the function).
  • Select a point a point.
  • the analysis end point acquisition unit 113 sets the selected analysis end point candidate as the analysis end point and displays it in the information display area 412. When a plurality of analysis end points are selected, a plurality of analysis end points are displayed in the information display area 412.
  • the symbol execution engine 114 searches for an execution path, and the path conditions related to the input parameters of the analysis end point and the analysis end point reached are the analysis result information display area 413. Is displayed in. If there are a plurality of analysis end points or path conditions relating to a plurality of input parameters, a plurality of analysis end points and path conditions are displayed in the information display area 413.
  • the "execution path display” button 424 is pressed, the execution path display screen 430 (see FIG. 4 described later) is displayed on the display provided in the input / output unit 180.
  • FIG. 4 is a configuration diagram of the execution path display screen 430 according to the present embodiment.
  • the source code of the function apel10, the function bar20, and the function foo30 through which the execution path passes is displayed.
  • the statements having the respective execution paths 431,432,433 are highlighted.
  • the "start point” is displayed as a comment of the program in the statement of the analysis start point
  • the "end point” is displayed in the statement of the function name of the entry point.
  • the path condition corresponding to the statement is displayed as a program comment.
  • the user By checking the execution path that shows the flow of the program and the path condition that is the condition for the problem to occur in the execution path, the user (developer) can understand the cause of the problem, and how to source it. It makes it easier to consider whether to fix the code.
  • the start point, end point, and path condition are displayed in the form of a comment of the program, but other formats may be used as long as the correspondence with the statement / line can be grasped.
  • FIG. 5 is a flowchart of the defect analysis process according to the present embodiment.
  • the control unit 110 reads the input source code 210, the program execution log 220, and the program specification 230.
  • the call relation generation unit 111 extracts the function call relation from the read source code 210 and stores it in the function call relation database 130.
  • step S13 the analysis start point acquisition unit 112 acquires and sets the analysis start point from the program execution log 220. If there are multiple candidates for the analysis start point, contact the user to obtain them (see the "Specify" button 421 in FIG. 3).
  • step S14 the analysis end point acquisition unit 113 inquires of the user to acquire and set the analysis end point (entry point).
  • step S15 the symbol execution engine 114 starts the search (reverse symbol execution) from the analysis start point. Specifically, the symbol execution engine 114 executes the symbol in the opposite direction toward the first line of the function.
  • step S16 the symbol execution engine 114 records the execution path and the path condition.
  • step S17 if the statement / line currently being searched for is the first line of the analysis end point (entry point), the symbol execution engine 114 proceeds to step S18 (step S17 ⁇ YES), and at the first line of the analysis end point. If not (step S17 ⁇ NO), the process proceeds to step S19.
  • step S18 the symbol execution engine 114 displays the result of the search (reverse symbol execution) (see the information display area 413 of the analysis result shown in FIG. 3).
  • step S19 the symbol execution engine 114 identifies the caller of the function.
  • step S20 the symbol execution engine 114 continues the search (execution of the reverse symbol toward the first line of the function) from the caller of the function, and returns to step S16. If the callers of the plurality of functions are specified in step S19, the search is continued from each caller. If the path condition is not satisfied during the search, the search is terminated.
  • the defect analysis device 100 identifies a statement / line in which an exception (failure) related to a defect occurs from the program execution log 220, and sets it as an analysis start point. If the analysis start point cannot be specified as one, the defect analysis device 100 presents a candidate for the analysis start point to the user and sets the selected candidate as the analysis start point.
  • the defect analysis device 100 searches the program from the analysis start point to the analysis end point (entry point) specified by the user in the opposite direction to the normal execution direction (execution of the reverse symbol), and the execution path 240, 431, 432, 433 and the path condition are specified and output (see FIGS. 3 and 4).
  • the user can understand under what conditions and how the processing proceeds and the problem occurs in the program. As a result, you will be able to find problems and fix the program. Further, it becomes possible to test the modified program by using the input parameter value 250 of the entry point satisfying the path condition.
  • the defect analysis device 100 obtains an input parameter value of an entry point that satisfies the path condition after the search (reverse symbol execution) is completed.
  • the defect analysis device 100 may solve the path condition or detect an exception (failure) in consideration of the range of the input parameter value and the return value described in the program specification 230.
  • FIG. 6 is a diagram for explaining an execution path and a path condition according to a modified example of the present embodiment.
  • FIG. 6 includes source code 210 for two functions, function foobar40 and function qux50.
  • the function foobar40 calls the function qux50.
  • the range of the first parameter of the function foobar40 is 1 or more and 5 or less
  • the range of the second input parameter is 0 or more and 5 or less
  • the range of the return value is 1 or more and less than 10.
  • the information display area 412 of the analysis end point shown in FIG. 7 Refer to the information display area 412 of the analysis end point shown in FIG. 7). In the following, the description will be continued on the assumption that the return value abnormality occurs in the function foobar40 and the function foobar40 is specified as the entry point.
  • the program execution log 220 includes a record of the call of the function foobar40, a record of the call of the function qux50, and a record of an exception (abnormality) relating to the return value of the function foobar40.
  • the symbol execution engine 114 searches the program in the opposite direction of normal (forward) execution until it reaches the entry point.
  • the symbol execution engine 114 starts the search from line 3 of the function foobar40 and arrives at the call of the function qux50 at line 3.
  • the execution path at this point is line 4 to line 3 of the function foobar40.
  • the symbol execution engine 114 determines that the return value of the function qux50 is 10, and searches for a statement to return to the caller of the function qux50. In the case of FIG. 6, the statements returning to the caller are line 3 and line 5.
  • the symbol execution engine 114 continues the search from each of line 3 and line 5.
  • the SMT solver 115 solves the path condition together with the input parameter specifications of the function foobar40.
  • the specifications of the input parameters are that a of the first parameter is 1 or more and 5 or less, and b of the second parameter is 0 or more and 5 or less.
  • FIG. 7 is a configuration diagram of the screen 400A of the defect analysis device 100 according to the modified example of the present embodiment.
  • the information of the entry point displayed in the information display area 412 of the analysis end point includes the specifications of the input parameter and the return value.
  • the variable value of the starting point when the function which is the entry point is called with this value is displayed.
  • the processing of the symbol execution engine 114 or the SMT solver 115 that processes the condition may be slowed down or may not be processed in some cases.
  • FIG. 8 is a flowchart (1) of the defect analysis process according to the modified example of the present embodiment.
  • FIG. 9 is a flowchart (2) of the defect analysis process according to the modified example of the present embodiment.
  • Steps S31 to S39 are the same as steps S11 to S17, S19, and S20 shown in FIG. 5, respectively.
  • step S37 if the statement / line currently being searched is the first line of the analysis end point (entry point) (step S37 ⁇ YES), the symbol execution engine 114 proceeds to step S40 described in FIG.
  • step S40 the SMT solver 115 solves the path condition and obtains the input parameter value at which the problem occurs. Specifically, the SMT solver 115 obtains an input parameter value 250 that satisfies the path condition at the entry point and the condition (specification) relating to the range of the input parameter value of the function that is the entry point. In other words, the SMT solver 115 outputs the input parameter value at the entry point that satisfies the path condition. The SMT solver 115 may output the condition of the input parameter value at the entry point satisfying the path condition.
  • step S41 the symbol execution engine 114 executes forward symbols from the entry point with the input parameter value obtained in step S40.
  • the symbol execution engine 114 records the execution path and the variable value.
  • step S43 the symbol execution engine 114 proceeds to step S44 if the statement / line currently executing the forward symbol is the analysis start point (step S43 ⁇ YES), and if it is not the analysis start point (step S43 ⁇ YES). NO) Proceed to step S45.
  • step S44 the symbol execution engine 114 displays the result of forward symbol execution (see the information display area 413 of the analysis result shown in FIG. 7).
  • step S45 the symbol execution engine 114 identifies the function to be called in the function call.
  • step S46 the symbol execution engine 114 continues the forward symbol execution with the input parameter value at the time of calling in the function to be called, and returns to step S42.
  • Exception 0 gradual calculation, input parameter value (function call with a value outside the specification) and return value (function call with a value outside the specification) contrary to the description of the program specification 230 are used. Return) was shown. Not limited to the program specification 230, the exception is the call of the library function that violates the input parameter specifications of the library function called from the program (source code 210) and the return from the call of the library function that violates the specifications of the return value of the library function. May be included.
  • the analysis start point acquisition unit 112 acquires the statement of the program in which such an exception occurs from the execution log as the analysis start point.
  • the analysis start point acquisition unit 112 detects the occurrence of an exception from the program execution log and sets the start point, but inquires of the user and makes an exception at the start point or the start point. (Path condition) may be acquired. If the program execution log does not record the occurrence of an exception, the user (developer) sets the starting point by guessing the location where the exception occurred from the last recorded function call.
  • the program execution log includes a record of function calls during program execution.
  • the record of the function call may not be included, and the information for determining the starting point such as the exception occurrence location and the exception occurrence condition may be included.
  • the program execution log may include information related to diagnosis (for example, information output by an assert in C language).
  • the analysis start point acquisition unit 112 may use a statement (assert statement) that outputs the information as a start point.
  • the present invention can take various other embodiments, and further, various changes such as omission and replacement can be made without departing from the gist of the present invention.
  • These embodiments and variations thereof are included in the scope and gist of the invention described in the present specification and the like, and are also included in the scope of the invention described in the claims and the equivalent scope thereof.

Abstract

不具合解析装置(100)は、入力にプログラム(ソースコード(210))の実行ログ(プログラム実行ログ(220))を含む。不具合解析装置(100)は、実行ログから例外が発生したプログラムのステートメントを解析開始点として取得する解析開始点取得部(112)と、解析開始点を含む関数を直接または間接に呼び出す関数を解析終了点として取得する解析終了点取得部(113)と、解析開始点から解析終了点へ逆向き記号実行を行い、実行パス(240)を出力する記号実行エンジン(114)とを備える。

Description

不具合解析装置、プログラムおよび不具合解析方法
 本発明は、ソフトウェアプログラムの不具合の解析を支援する不具合解析装置、プログラムおよび不具合解析方法に関する。
 ソフトウェア開発において、仕様書と異なる、または開発者が想定していないソフトウェア(プログラム、ソフトウェアプログラム)の動作は、不具合と呼ばれ、ソフトウェアをリリースする前に不具合を全て修正してなくすことが望ましい。不具合を検出する一般的な手法としてはテストがある。テストでは、仕様書にある、または開発者が期待する、入力と出力とをテストケースとして作成し、プログラムが入力に対して正しい出力を返すかを確認する。入力に対して出力が異なる、または、例外(故障)が発生してプログラムが動作しない場合には、不具合がある(不具合が発生した)と判断される。不具合がある場合、開発者は、ソフトウェアのどの部分で想定外の処理をしたかを解析し、原因箇所を特定して、適切な入出力を行うようにプログラムのロジックを修正する。
 巨大で複雑なプログラムでは、たくさんのテストケースが必要となる。詳しくは、プログラムの全てのステートメント(行/ステップ)、分岐、分岐条件などをカバーするには、膨大な量のテストケースが必要となり、現実的ではない。入力から出力を計算する制御プログラムにおいて、殆どの入力に対しては正しく処理するが、非常にまれな条件で不正な処理を行う場合がある。このような不具合は、非再現性不具合と呼ばれ、不具合が起きるまれな条件を特定するのが困難である。
 出荷直前に非再現性不具合が見つかると、不具合の解析に非常に時間がかかってしまい、出荷が延期されてしまうかもしれない。また、出荷後に非再現性不具合が見つかると、原因となる手がかりが少ないため、原因分析が非常に難しくなる。一定の確率で不具合が発生するならば、製品回収や製品修正のためのリコールを行わざるをえなくなる。出荷遅延や製品回収、リコールは利用者の信頼を傷付け、さらに非常に大きなコストがかかるため、できる限り避けるのが望ましい。
 特許文献1には、入力仕様と出力仕様とが定義されたソフトウェアコンポーネントにおいて、仕様に違反した入力に対してどの出力が仕様を満たせなくなるかを求めることにより、ソフトウェアコンポーネントの故障時の故障伝搬を評価する手法が記載されている。
特開2012-128727号公報
 特許文献1に記載の手法では、異常な入力を与えた場合のソフトウェアコンポーネントの挙動を評価できるが、通常の入力に対して異常な出力が起こる不具合の原因を解析することはできない。
 本発明は、このような背景を鑑みてなされたものであり、プログラムに含まれる不具合が発生する実行パスの特定を可能とする不具合解析装置、プログラムおよび不具合解析方法を提供することを課題とする。
 上記した課題を解決するため、本発明に係る不具合解析装置は、プログラムの実行ログを伴って当該プログラムの不具合を解析するに際して、前記実行ログから例外が発生したプログラムのステートメントを解析開始点として取得する解析開始点取得部と、前記解析開始点を含む関数を直接または間接に呼び出す関数を解析終了点として取得する解析終了点取得部と、前記解析開始点から前記解析終了点へ逆向き記号実行を行い、実行パスを出力する記号実行エンジンとを備える。
 本発明によれば、プログラムに含まれる不具合が発生する実行パスの特定を可能とする不具合解析装置、プログラムおよび不具合解析方法を提供することができる。
本実施形態に係る不具合解析装置の入力、出力、および全体構成を示す図である。 本実施形態に係る実行パスおよびパス条件を説明するための図である。 本実施形態に係る不具合解析装置の画面の構成図である。 本実施形態に係る実行パス表示画面の構成図である。 本実施形態に係る不具合解析処理のフローチャートである。 本実施形態の変形例に係る実行パスおよびパス条件を説明するための図である。 本実施形態の変形例に係る不具合解析装置の画面の構成図である。 本実施形態の変形例に係る不具合解析処理のフローチャート(1)である。 本実施形態の変形例に係る不具合解析処理のフローチャート(2)である。
 以下に、本発明を実施するための形態(実施形態)における不具合解析装置について説明する。不具合解析装置の入力には、プログラムのソースコードと、プログラムの実行ログとが含まれる。実行ログには、実行中に呼び出された関数(メソッド)が含まれている。実行中に例外(例えば0徐算)が発生すると、実行ログは例外が発生した関数の呼び出しで終わっている(プログラム停止を記録している)。
 不具合解析装置は、実行ログから例外が発生した関数のなかの例外が発生した(例えば0徐算の徐算演算)プログラムのステートメント(ソースコードの行/ステップ)を解析開始点と設定する。また、利用者(開発者)に問い合わせて、解析開始点を含む関数を直接または間接に呼び出す関数を、解析終了点と設定する。
 不具合解析装置は、解析開始点から解析終了点まで、通常のプログラム実行とは逆方向の逆向き記号実行を行う。逆向き記号実行の間は、不具合解析装置は、実行パスとパス条件を記録する。実行パスは、解析終了点と解析開始点とを結ぶプログラム中のパス(ステートメント/行/ステップの並び)であり、実行パスに沿って処理が進む。実行パスは、関数の呼び出しも含む。パス条件は、例外(例えば0徐算)が発生する変数の条件である。変数には、関数内のローカル変数や関数の入力パラメータが含まれる。
 実行パスやパス条件を参照することで、利用者は、どのようにして例外(不具合)が発生するかを理解することができ、不具合の修正方法を検討する材料にすることができる。結果として、不具合解析装置は、利用者の不具合の解析(分析)を支援することができる。
 不具合解析装置は、SMTソルバ(Satisfiability Modulo Theories Solver)を用いてパス条件を満足する解析終了点である関数の入力パラメータ値を算出する。この値を入力とするテストを行うことで、利用者は修正したプログラムが正しく動作するかを確認できるようになる。
≪不具合解析装置の構成≫
 図1は、本実施形態に係る不具合解析装置100の入力、出力、および全体構成を示す図である。不具合解析装置100は、制御部110、記憶部120、および入出力部180を備える。
 入出力部180は、ディスプレイやキーボード、マウスなどのユーザインターフェイスを備える。入出力部180は、さらに、通信インターフェイスや記録媒体の読み書きデバイスを備えてもよい。
 記憶部120は、RAM(Random Access Memory)やROM(Read Only Memory)、SSD(Solid State Drive)などから構成される。記憶部120には、プログラム121や関数呼び出し関係データベース130(図1では関数呼び出し関係DB(Database)と記載)が記憶される。プログラム121は、コンピュータを不具合解析装置100として機能させるためのプログラムであって、不具合解析処理(後記する図5参照)の処理手順の記述を含む。関数呼び出し関係データベース130には、どの関数がどの関数を呼び出すかの関係、換言すれば、呼び出し関係グラフ(関数間の呼び出し関係を表現する制御フローのグラフ)を示すデータが記憶される。
 制御部110を説明する前に、不具合解析装置100の入力と出力とを説明する。
≪不具合解析装置の入力≫
 不具合解析装置100の入力には、ソースコード210、プログラム実行ログ220、およびプログラム仕様230が含まれる。ソースコード210は、解析対象であるソフトウェアプログラムを構成する関数(メソッド)のソースコードである。プログラム仕様230には、関数の名前、および、関数の入力パラメータ値と返り値(戻り値)の名前と型と範囲とが記述されている。
 プログラム実行ログ220(実行ログ)は、プログラム実行中の関数呼び出しの記録を含む。プログラム実行ログ220には、呼び出された関数の名前(識別情報)の他に呼び出し時の入力パラメータ値や、呼び出しから戻るときの返り値を含んでもよい。プログラム実行ログ220は、さらにプログラム実行中に発生した例外を含んでもよい。例外としては、0徐算やプログラム仕様230に記述された入力パラメータ値または返り値の違反(仕様の範囲外の値)がある。
≪不具合解析装置の出力≫
 不具合解析装置100の出力には、実行パス240、および入力パラメータ値250が含まれる。実行パス240は、不具合が発生するプログラム中のパス(ソースコード210のなかで順次処理される一連のステートメント/行/ステップ)である。実行パス240の一端は、不具合に係る例外(故障)が発生するステートメント/行/ステップであり、解析開始点、または単に開始点と記す。解析開始点は、例えば0徐算が発生する徐算演算を含むステートメントである。実行パス240の他端は、解析開始点を含む関数を直接または間接に呼び出す関数であり、解析終了点、またはエントリポイントと記す。解析終了点は、開始点を含む関数であってもよい。
 入力パラメータ値250は、エントリポイントとなる関数の、不具合が発生するときの入力パラメータ値である。
≪不具合解析装置の制御部の構成≫
 制御部110は、CPU(Central Processing Unit)を含んで構成され、呼び出し関係生成部111、解析開始点取得部112、解析終了点取得部113、記号実行エンジン114、およびSMTソルバ115を備える。
 呼び出し関係生成部111は、ソースコード210から関数の呼び出し関係を取得して、関数呼び出し関係データベース130に格納する。
 解析開始点取得部112は、プログラム実行ログ220を解析して解析開始点を取得する。解析開始点の取得手順の詳細は後記する。
 解析終了点取得部113(エントリポイント取得部)は、解析開始点を含む関数を呼び出す関数を関数呼び出し関係データベース130から取得して、エントリポイントの候補として入出力部180に備わるディスプレイに表示する。利用者(開発者)は、候補のなかから1つまたは複数のエントリポイントを選択する。解析終了点取得部113は、選択された関数を解析終了点(エントリポイント)として設定する。
 記号実行エンジン114は、実行パス240、およびパス条件を生成する。パス条件は、解析対象のプログラムの実行が実行パス240を通るための変数(ローカル変数や入力パラメータ)の条件である。実行パス240やパス条件の詳細は後記する。以下の文献に記号実行エンジンンの詳細が記述されている: Peter Dinges and Gul Agha, "Targeted Test Input Generation Using Symbolic Concrete Backward Execution"。
 SMTソルバ115(ソルバ)は、パス条件を満たす入力パラメータ値250を生成する。以下の文献にSMTソルバが記述されている: Leonardo de Moura and Nikolaj Bjorner, "Z3: An Efficient SMT Solver"。
≪実行パスとパス条件≫
 図2は、本実施形態に係る実行パスおよびパス条件を説明するための図である。図2は、関数baz10、関数bar20、および関数foo30の3つの関数のソースコード210を含む。関数baz10は関数bar20を呼び出し、関数bar20は関数foo30を呼び出す。関数foo30で0徐算の例外が発生し、エントリポイントとして関数baz10が指定されたという前提で、説明を続ける。この場合、プログラム実行ログ220は、関数baz10の呼び出しの記録、関数bar20の呼び出しの記録、関数foo30の呼び出しの記録を含み、0徐算発生の記録で終わる。
 プログラム実行ログ220を解析することで、解析開始点取得部112は、関数foo30のなかで0徐算の例外が発生したことを検出する。関数fooの行3が、徐算演算を含む唯一のステートメント/行であるから、解析開始点取得部112は、開始点を関数foo30の行3に設定する。つまりは解析開始点取得部112は、実行ログから例外が発生したプログラムのステートメントを解析開始点として取得する。
 パス条件は、例外が発生する条件/制約である。解析開始点である関数foo30の行3におけるパス条件32は「b=0」である。
 記号実行エンジン114は、開始点から始めて、通常の(前向き)実行とは反対の方向にプログラム(ソースコード210)のなかを、エントリポイントに到達するまで探索(逆向き記号実行とも記す)する。エントリポイントが複数ある場合には、記号実行エンジン114は、何れか1つのエントリポイントに到達するまで探索する。
 図2の場合、記号実行エンジン114は、関数foo30の行3から探索を始めて、行1(先頭行)に到達する。この時点での実行パスは、関数foo30の行3~行1である。行1におけるパス条件31は「b=0」のままとなる。
 記号実行エンジン114は、関数foo30が、第2入力パラメータのbが0で呼ばれたと判断して、関数foo30を呼び出すステートメントを探索する。図2の場合、関数foo30を呼び出すステートメントは、関数bar20の行3であり、記号実行エンジン114は、当該行から探索を継続する。この行におけるパス条件22は、第2入力パラメータが0となる「a-b=0」である。この時点における実行パスは、関数foo30の行3~行1、関数bar20の行3である。また、この時点でのパス条件は、関数foo30における「b=0」、関数bar20における「a-b=0」である。なお、関数baz10、関数bar20、および関数foo30にそれぞれ同じ名前の変数a,b,cがあるが、これらはぞれぞれの関数のローカル変数であり、異なる変数である。
 記号実行エンジン114は、関数bar20の行3から探索を始めて、行1に到達する。この時点での実行パスは、関数foo30の行3~行1、関数bar20の行3~行1である。行1におけるパス条件21は「a=b」であり、パス条件22の「a-b=0」と同等である。
 記号実行エンジン114は、関数bar20が、第1パラメータと第2入力パラメータとが同じ値で呼ばれたと判断して、関数bar20を呼び出すステートメントを探索する。図2の場合、関数bar20を呼び出すステートメントは、関数baz10の行3であり、記号実行エンジン114は、当該行から探索を継続する。この行におけるパス条件12は「a=b」である。この時点における実行パスは、関数foo30の行3~行1、関数bar20の行3~行1、関数baz10の行3である。また、この時点でのパス条件は、関数foo30における「b=0」、関数bar20における「a-b=0」、関数baz10における「a=b」である。
 記号実行エンジン114は、関数baz10の行3から探索を始めて、行1に到達する。関数baz10は、解析終了点なので、探索はここで終了する。この時点での実行パスは、関数foo30の行3~行1、関数bar20の行3~行1、関数baz10の行3~行1である。また、この時点でのパス条件は、関数foo30における「b=0」、関数bar20における「a-b=0」、関数baz10における「a=b」である。
 パス条件には、エントリポイント(解析終了点)の入力パラメータ値の条件を含んでいる。SMTソルバ115は、パス条件を解いて、エントリポイントである関数baz10の、パス条件を満たす入力パラメータ値250、例えばa=0でb=0、を算出する。
 最後に、記号実行エンジン114は、実行パスを入出力部180に備わるディスプレイに表示する(実行パスを出力する)。利用者は、プログラムのなかで、どのような条件でどのように処理が進んで不具合が発生するかを理解することができる。延いては、問題点を見出し、プログラムを修正することができるようになる。SMTソルバ115は、入力パラメータ値250(パス条件を満たすエントリポイント(解析終了点)の入力値)を提供し、利用者はこの値を用いて修正したプログラムのテストができる。
 上記の説明において、関数foo30、および関数bar20の呼び出し元のステートメントはそれぞれ1つであった。複数の呼び出し元がある場合には、それぞれの呼び出し元から探索を継続する。例えば、関数bazA(不図示)が、行5でbar(d+1,d―2)と関数bar20を呼び出したとする。記号実行エンジン114は、関数bazAの行5まで探索して、パス条件を求める。この場合、関数bar20のパス条件である第1パラメータと第2パラメータとが等しいことから、「d+1=d―2」がパス条件となる。しかしながら、このような条件が成立することはないので、記号実行エンジン114は、関数bazAの行5からの探索を打ち切り、別の呼び出し元の探索を継続する。
 なお、複数の呼び出し元の探索を行い、それぞれがエントリポイントに到達した場合には、記号実行エンジン114は、それぞれの実行パスとパス条件とを記録するようにしてもよい。このような場合には、実行パスとパス条件とが、それぞれ複数あることになる。換言すれば、異なる条件で、同じ個所(解析開始点)で例外が発生することが判明したことになる。
 探索途中で条件分岐があった場合には、記号実行エンジン114は、分岐条件をパス条件に加える。例えば、関数foo30の行3が、「if (x<=y) c=a/b;」であったとする。この場合のパス条件は、「b=0」かつ「x<=y」である。
 解析終了点が複数指定されたり、関数の呼び出し元が複数あったり、条件分岐があったりする場合には、探索で辿り着く解析終了点や実行パス、パス条件が複数になる場合がある。記号実行エンジン114は、このようにして実行パスとパス条件とを算出して特定する。
≪ユーザインターフェイス≫
 図3は、本実施形態に係る不具合解析装置100の画面400の構成図である。画面400の左右における中央には上から、解析開始点の情報表示領域411、解析終了点の情報表示領域412、および解析結果の情報表示領域413が配置される。
 解析開始点取得部112が解析開始点を設定すると、解析開始点の情報表示領域411に解析開始点を含む関数名や解析開始点の行数、例外が発生する条件などが表示される。例えば、0徐算の例外が発生し徐算演算が複数ある場合には、解析開始点の候補が複数あることになる。このような場合には、情報表示領域411には、解析開始点の候補が複数あり、そのなかの1つを選択するように利用者を促すメッセージが表示される。利用者は、「指定」ボタン421を押下して、解析開始点の候補を表示する画面(不図示)から1つの解析開始点を選択する。解析開始点取得部112は、選択された解析開始点の候補を解析開始点と設定する。
 不具合解析装置100の起動直後(後記する図5記載の不具合解析処理の前)の時点では、解析終了点の情報表示領域412には、解析終了点(エントリポイント)の選択を促すメッセージが表示される。利用者は「指定」ボタン422を押下して、解析終了点の候補(開始点を含む関数、当該関数を直接または間接に呼び出す関数)を表示する画面(不図示)から1つ以上の解析終了点を選択する。解析終了点取得部113は、選択された解析終了点の候補を解析終了点と設定して、情報表示領域412に表示する。複数選択された場合には、複数の解析終了点が情報表示領域412に表示される。
 「解析開始」ボタン423が押下されると、記号実行エンジン114が、実行パスの探索を行い、辿り着いた解析終了点と解析終了点の入力パラメータに関するパス条件が、解析結果の情報表示領域413に表示される。複数の解析終了点、または、複数の入力パラメータに関するパス条件があれば、情報表示領域413には、複数の解析終了点やパス条件が表示される。「実行パス表示」ボタン424が押下されると、実行パス表示画面430(後記する図4参照)が入出力部180に備わるディスプレイに表示される。
 図4は、本実施形態に係る実行パス表示画面430の構成図である。実行パス表示画面430には、実行パスが通る関数baz10、関数bar20、および関数foo30のソースコードが表示される。関数baz10、関数bar20、および関数foo30のソースコードのなかで、それぞれの実行パス431,432,433となるステートメントは、反転表示される。また、解析開始点のステートメントには「開始点」が、エントリポイントの関数名のステートメントには「終了点」がプログラムのコメントとして表示される。さらに、ステートメントに対応してパス条件が、プログラムのコメントとして表示される。プログラムの流れを示す実行パス、および実行パスにおける不具合が発生する条件であるパス条件を確認することで、利用者(開発者)は不具合が発生する原因が理解でき、延いてはどのようにソースコードを修正するかを検討しやすくなる。
 図4では、開始点、終了点、パス条件が、プログラムのコメントの形式で表示されるが、ステートメント/行との対応が把握可能であれば、他の形式であってもよい。
≪不具合解析処理≫
 図5は、本実施形態に係る不具合解析処理のフローチャートである。
 ステップS11において制御部110は、入力であるソースコード210、プログラム実行ログ220、プログラム仕様230を読み込む。
 ステップS12において呼び出し関係生成部111は、読み込まれたソースコード210から関数の呼び出し関係を抽出して、関数呼び出し関係データベース130に格納する。
 ステップS13において解析開始点取得部112は、プログラム実行ログ220から解析開始点を取得して設定する。解析開始点の候補が複数ある場合には、利用者に問い合わせて取得する(図3記載の「指定」ボタン421参照)。
 ステップS14において解析終了点取得部113は、利用者に問い合わせて解析終了点(エントリポイント)を取得して設定する。
 ステップS15において記号実行エンジン114は、解析開始点から探索(逆向き記号実行)を開始する。詳しくは、記号実行エンジン114は関数の先頭行に向かって逆向きに記号実行を行う。
 ステップS16において記号実行エンジン114は、実行パスとパス条件を記録する。
 ステップS17において記号実行エンジン114は、現在探索しているステートメント/行が、解析終了点(エントリポイント)の先頭行であれば(ステップS17→YES)ステップS18に進み、解析終了点の先頭行でなければ(ステップS17→NO)ステップS19に進む。
 ステップS18において記号実行エンジン114は、探索(逆向き記号実行)の結果を表示する(図3記載の解析結果の情報表示領域413参照)。
 ステップS19において記号実行エンジン114は、関数の呼び出し元を特定する。
 ステップS20において記号実行エンジン114は、関数の呼び出し元から探索(関数の先頭行に向かう逆向き記号実行)を継続し、ステップS16に戻る。ステップS19において、複数の関数の呼び出し元が特定されれば、それぞれの呼び出し元から探索を継続する。また、探索途中でパス条件が成立しない条件になった場合には、探索を打ち切る。
≪不具合解析装置の特徴≫
 不具合解析装置100は、プログラム実行ログ220から不具合に係る例外(故障)が発生するステートメント/行を特定して、解析開始点として設定する。解析開始点を1つに特定できない場合には、不具合解析装置100は、利用者に解析開始点の候補を提示して、選択された候補を解析開始点として設定する。不具合解析装置100は、解析開始点から利用者が指定した解析終了点(エントリポイント)まで、プログラムのなかを通常の実行方向とは逆に探索(逆向き記号実行)して、実行パス240,431,432,433とパス条件を特定して出力する(図3、図4参照)。
 利用者は、実行パス240,431,432,433を参照することで、プログラムのなかで、どのような条件でどのように処理が進んで不具合が発生するかを理解することができる。延いては、問題点を見出し、プログラムを修正することができるようになる。さらに、パス条件を満たすエントリポイントの入力パラメータ値250を用いて修正したプログラムのテストができるようになる。
≪変形例≫
 上記した実施形態では、不具合解析装置100は、探索(逆向き記号実行)終了後に、パス条件を満足するエントリポイントの入力パラメータ値を求めている。不具合解析装置100は、プログラム仕様230に記載の入力パラメータ値や返り値の範囲まで考慮して、パス条件を解いたり、例外(故障)を検出したりするようにしてもよい。
 図6は、本実施形態の変形例に係る実行パスおよびパス条件を説明するための図である。図6は、関数foobar40、および関数qux50の2つの関数のソースコード210を含む。関数foobar40は関数qux50を呼び出す。プログラム仕様230では、関数foobar40の第1パラメータの範囲は1以上5以下であり、第2入力パラメータの範囲は0以上かつ5以下であって、返り値の範囲は1以上10未満である(後記する図7記載の解析終了点の情報表示領域412参照)。以下では、関数foobar40で返り値の異常が発生し、エントリポイントとして関数foobar40が指定されたという前提で、説明を続ける。この場合、プログラム実行ログ220は、関数foobar40の呼び出しの記録、関数qux50の呼び出しの記録、関数foobar40の返り値に係る例外(異常)の記録を含む。
 プログラム実行ログ220を解析することで、解析開始点取得部112は、関数foobar40のなかで返り値の例外が発生したことを検出する。関数foobar40の行4が、呼び出し元に返る唯一のステートメント/行であるから、解析開始点取得部112は、開始点を関数foobar40の行4に設定する。
 関数foobar40の返り値の範囲は1以上10未満であるので、解析開始点取得部112は、行4のパス条件43として、例えば「c=10」を設定する。解析開始点取得部112は、利用者に問い合わせてパス条件43を設定してもよい。
 記号実行エンジン114は、開始点から始めて、通常の(前向き)実行とは反対の方向にプログラムのなかを、エントリポイントに到達するまで探索する。
 図6の場合、記号実行エンジン114は、関数foobar40の行3から探索を始めて、行3で関数qux50の呼び出しに到達する。この時点での実行パスは、関数foobar40の行4~行3である。
 記号実行エンジン114は、関数qux50の返り値が10であると判断して、関数qux50の呼び出し元に戻るステートメントを探索する。図6の場合、呼び出し元に戻るステートメントは、行3と行5とがある。記号実行エンジン114は、行3と行5とのそれぞれから探索を継続する。
 行3におけるパス条件は「y=10」である。また、行2において行3に分岐する条件は「x<y」である。よって、実行パスが行3から行1である場合のパス条件52は、「y=10」かつ「x<y」であり、結果として「y=10」かつ「x<10」となる(図6では、「y=10 & x<10」と記載)。同様にして行5について、実行パスが行5、行3から行1である場合のパス条件53は、「x=10」かつ「y<=10」となる(図6では、「x=10 & y<=10」と記載)。
 以上により、関数qux50の行1におけるパス条件51は、「y=10 & x<10」または「x=10 & y<=10」となる(図6では、「(y=10 & x<10)|(x=10 & y<=10)」と記載)。
 記号実行エンジン114は、関数foobar40の行3に戻り、パス条件51を関数foobar40の変数に当てはめて、パス条件42は「(a-b=10 & a+b<10)|(a+b=10 & a-b<=10)」となる。記号実行エンジン114は、さらに探索を継続して、エントリポイントである関数foobar40の先頭行に到達して、パス条件41の「(a-b=10 & a+b<10)|(a+b=10 & a-b<=10)」を得る。
 SMTソルバ115は、関数foobar40の入力パラメータの仕様と合わせてパス条件を解く。入力パラメータの仕様は、第1パラメータのaが1以上5以下、第2パラメータのbが0以上5以下である。この条件と合わせてパス条件41を解いて、SMTソルバ115は、「a=5」と「b=5」を得る。続いて、記号実行エンジン114は、この値を用いてエントリポイントから解析開始点までの(順向き)記号実行を行い、最初のパス条件43である「c=10」を得る。
 図7は、本実施形態の変形例に係る不具合解析装置100の画面400Aの構成図である。以下、画面400(図3参照)との違いを説明する。
 解析終了点の情報表示領域412に表示されるエントリポイントの情報には、入力パラメータや返り値の仕様が含まれる。また、解析結果の情報表示領域413には、エントリポイントの入力パラメータ値250の他に、エントリポイントである関数をこの値で呼び出した場合の開始点の変数値が表示される。
 上記の変形例では、開始点でのパス条件43として、「c=10」と変数値が設定されているが、これに限らない。例えば、仕様上の返り値の範囲外である「c<1|c>=10」という条件を設定してもよい。但し、パス条件が数値ではなく条件であると、条件を処理する記号実行エンジン114やSMTソルバ115の処理が遅くなったり、場合によっては処理不能となったりする場合がある。
 図8は、本実施形態の変形例に係る不具合解析処理のフローチャート(1)である。図9は、本実施形態の変形例に係る不具合解析処理のフローチャート(2)である。
 ステップS31~S39は、図5記載のステップS11~S17,S19,S20とそれぞれ同様である。但し、ステップS37において、現在探索しているステートメント/行が、解析終了点(エントリポイント)の先頭行であれば(ステップS37→YES)記号実行エンジン114は、図9記載のステップS40に進む。
 ステップS40においてSMTソルバ115は、パス条件を解き、不具合が発生する入力パラメータ値を求める。詳しくは、SMTソルバ115は、エントリポイントにおけるパス条件、およびエントリポイントである関数の入力パラメータ値の範囲に係る条件(仕様)を満足する入力パラメータ値250を求める。換言すればSMTソルバ115は、パス条件を満たすエントリポイントにおける入力パラメータ値を出力する。SMTソルバ115は、パス条件を満たすエントリポイントにおける入力パラメータ値の条件を出力してもよい。
 ステップS41において記号実行エンジン114は、ステップS40で求めた入力パラメータ値でエントリポイントから順向き記号実行を行う。
 ステップS42において記号実行エンジン114は、実行パスと変数値を記録する。
 ステップS43において記号実行エンジン114は、現在の順向け記号実行をしているステートメント/行が、解析開始点ならば(ステップS43→YES)ステップS44に進み、解析開始点でなければ(ステップS43→NO)ステップS45に進む。
 ステップS44において記号実行エンジン114は、順向き記号実行の結果を表示する(図7記載の解析結果の情報表示領域413参照)。
 ステップS45において記号実行エンジン114は、関数呼び出しにおいて呼び出す関数を特定する。
 ステップS46において記号実行エンジン114は、呼び出す関数において、呼び出し時の入力パラメータ値で順向き記号実行を継続し、ステップS42に戻る。
≪変形例:例外≫
 上記の実施形態や変形例において、例外として0徐算や、プログラム仕様230の記載に反する入力パラメータ値(仕様から外れる値での関数呼び出し)と返り値(仕様から外れる値での関数呼び出しからの戻り)を示した。プログラム仕様230に限らず、プログラム(ソースコード210)から呼び出されるライブラリ関数の入力パラメータの仕様に反するライブラリ関数の呼び出しや、ライブラリ関数の返り値の仕様に反するライブラリ関数の呼び出しからの戻りを例外に含めてもよい。解析開始点取得部112は、実行ログからこのような例外が発生したプログラムのステートメントを解析開始点として取得する。
≪その他変形例≫
 以上、本発明のいくつかの実施形態について説明したが、これらの実施形態は、例示に過ぎず、本発明の技術的範囲を限定するものではない。例えば、上記した実施形態では、解析開始点取得部112は、プログラム実行ログから例外発生を検出して、開始点を設定しているが、利用者に問い合わせて、開始点や当該開始点における例外(パス条件)を取得するようにしてもよい。プログラム実行ログが例外の発生を記録していない場合には、利用者(開発者)は、最後に記録されている関数呼び出しから例外発生個所の見当をつけて開始点を設定する。
 上記した実施形態ではプログラム実行ログは、プログラム実行中の関数呼び出しの記録を含むとしている。これに対して、関数呼び出しの記録を含まず、例外発生箇所や例外発生条件など開始点を決めるための情報を含んでいてもよい。また、プログラム実行ログに診断に係る情報(例えばC言語のassertが出力する情報)が含まれていてもよい。解析開始点取得部112は、当該情報を出力したステートメント(assert文)を開始点としてもよい。
 本発明はその他の様々な実施形態を取ることが可能であり、さらに、本発明の要旨を逸脱しない範囲で、省略や置換等種々の変更を行うことができる。これら実施形態やその変形は、本明細書等に記載された発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
100 不具合解析装置
111 呼び出し関係生成部
112 解析開始点取得部
113 解析終了点取得部
114 記号実行エンジン
115 SMTソルバ(ソルバ)
210 ソースコード(プログラム)
220 プログラム実行ログ(実行ログ)
230 プログラム仕様
240 実行パス
250 入力パラメータ値
11,12,21,22,31,32,41,42,43,51,52,53 パス条件
411 情報表示領域(解析開始点の情報表示領域)
412 情報表示領域(解析終了点の情報表示領域)
413 情報表示領域(解析結果の情報表示領域)
431,432,433 実行パス

Claims (7)

  1.  プログラムの実行ログを伴って当該プログラムの不具合を解析するに際して、前記実行ログから例外が発生したプログラムのステートメントを解析開始点として取得する解析開始点取得部と、
     前記解析開始点を含む関数を直接または間接に呼び出す関数を解析終了点として取得する解析終了点取得部と、
     前記解析開始点から前記解析終了点へ逆向き記号実行を行い、実行パスを出力する記号実行エンジンと
     を備える不具合解析装置。
  2.  前記解析開始点取得部は、
     前記例外が発生したプログラムのステートメントが1つに特定できない場合に、前記例外が発生する複数のステートメントのなかから選択されたステートメントを、前記解析開始点として取得する
     ことを特徴とする請求項1に記載の不具合解析装置。
  3.  前記例外は、
     0徐算、
     前記プログラムのプログラム仕様に記載される関数の入力パラメータ値の範囲から外れる値での関数呼び出し、
     前記プログラムのプログラム仕様に記載される関数の返り値の範囲から外れる値での関数呼び出しからの戻り、
     前記プログラムが呼び出すライブラリ関数の入力パラメータ値の範囲から外れる値での関数呼び出し、および、
     前記プログラムが呼び出すライブラリ関数の返り値の範囲から外れる値での関数呼び出しからの戻り
     のなかの何れかを含む
     ことを特徴とする請求項1に記載の不具合解析装置。
  4.  ソルバをさらに備え、
     前記記号実行エンジンは、前記例外が発生する条件であるパス条件を算出し、
     前記ソルバは、前記パス条件を満たす前記解析終了点となる関数の入力パラメータ値の条件、または、前記パス条件を満たす前記解析終了点となる関数の入力パラメータ値を出力する
     ことを特徴とする請求項1に記載の不具合解析装置。
  5.  ソルバをさらに備え、
     前記記号実行エンジンは、前記例外が発生する条件であるパス条件を算出し、
     前記ソルバは、前記パス条件を満たす前記解析終了点となる関数の入力パラメータ値を出力し、
     前記記号実行エンジンは、前記ソルバが出力した入力パラメータ値での前記解析終了点の呼び出しから前記解析開始点までの順向き記号実行を行い、前記解析開始点での変数値を出力する
     ことを特徴とする請求項1に記載の不具合解析装置。
  6.  コンピュータを、請求項1~5の何れか1項の不具合解析装置として機能させるためのプログラム。
  7.  入力にプログラムの実行ログを含むプログラムの不具合解析装置の不具合解析方法であって、
     前記実行ログから例外が発生したプログラムのステートメントを解析開始点として取得するステップと、
     前記解析開始点を含む関数を直接または間接に呼び出す関数を解析終了点として取得するステップと、
     前記解析開始点から前記解析終了点へ逆向き記号実行を行い、実行パスを出力するステップと
     を実行する不具合解析方法。
PCT/JP2021/007054 2020-08-27 2021-02-25 不具合解析装置、プログラムおよび不具合解析方法 WO2022044376A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/015,266 US20230259447A1 (en) 2020-08-27 2021-02-25 Defect Analysis Apparatus, Program, and Defect Analysis Method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020-143591 2020-08-27
JP2020143591A JP2022038884A (ja) 2020-08-27 2020-08-27 不具合解析装置、プログラムおよび不具合解析方法

Publications (1)

Publication Number Publication Date
WO2022044376A1 true WO2022044376A1 (ja) 2022-03-03

Family

ID=80354854

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/007054 WO2022044376A1 (ja) 2020-08-27 2021-02-25 不具合解析装置、プログラムおよび不具合解析方法

Country Status (3)

Country Link
US (1) US20230259447A1 (ja)
JP (1) JP2022038884A (ja)
WO (1) WO2022044376A1 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016018253A (ja) * 2014-07-04 2016-02-01 富士通株式会社 ソフトウェア変更プログラム、ソフトウェア変更装置、及びソフトウェア変更方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016018253A (ja) * 2014-07-04 2016-02-01 富士通株式会社 ソフトウェア変更プログラム、ソフトウェア変更装置、及びソフトウェア変更方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CHEN, NING ET AL.: "STAR: Stack Trace Based Automatic Crash Reproduction via Symbolic Execution", IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, vol. 41, no. 2, 2015, pages 198 - 220, XP011572819, Retrieved from the Internet <URL:https://ieeexplore.ieee.org/stalnp/stamp.jsp?tp=&arnumber=6926857> [retrieved on 20210512], DOI: 10.1109/TSE.2014.2363469 *

Also Published As

Publication number Publication date
JP2022038884A (ja) 2022-03-10
US20230259447A1 (en) 2023-08-17

Similar Documents

Publication Publication Date Title
CN108388514B (zh) 接口自动化测试方法、装置、设备及计算机可读存储介质
US8015239B2 (en) Method and system to reduce false positives within an automated software-testing environment
JP5775829B2 (ja) ソフトウェアの構造可視化プログラムおよびシステム
US10445225B2 (en) Command coverage analyzer
Angerer et al. Configuration-aware change impact analysis (t)
CN113742119A (zh) 嵌入式系统的调用栈回溯方法、装置和计算机设备
Theisen et al. Risk-based attack surface approximation: how much data is enough?
US9734042B1 (en) System, method, and computer program for automated parameterized software testing
Schneid et al. Automated regression tests: a no-code approach for BPMN-based process-driven applications
US11734159B2 (en) Ranking test cases specific to changes in software code
CN111400164A (zh) 一种软件测试方法及装置
Barraood Test case quality factors
WO2022044376A1 (ja) 不具合解析装置、プログラムおよび不具合解析方法
US10417113B1 (en) System, method, and computer program for web testing and automation offline storage and analysis
Singh et al. A case study of program comprehension effort and technical debt estimations
US20080195906A1 (en) Test pattern generation apparatus and test pattern generation method
Thooriqoh et al. Selenium Framework for Web Automation Testing: A Systematic Literature Review
WO2023058609A1 (ja) 不具合解析装置及び不具合解析方法
CN114660437A (zh) 一种波形文件生成方法及装置
Zhyhulin et al. Combined method of prioritization and automation of software regression testing
KR102176133B1 (ko) 소프트웨어 테스트 케이스 자동 생성 방법 및 장치
CN109359042B (zh) 一种基于路径搜索算法的自动化测试方法
US20240143300A1 (en) Program analyzing apparatus, program analyzing method, and trace processing addition apparatus
Karnane et al. Automating root-cause analysis to reduce time to find bugs by up to 50%
Drobnjaković et al. Abstract interpretation-based data leakage static analysis

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

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

Country of ref document: EP

Kind code of ref document: A1