WO2023058611A1 - ソフトウェア不具合分析装置及びソフトウェア不具合分析方法 - Google Patents

ソフトウェア不具合分析装置及びソフトウェア不具合分析方法 Download PDF

Info

Publication number
WO2023058611A1
WO2023058611A1 PCT/JP2022/037007 JP2022037007W WO2023058611A1 WO 2023058611 A1 WO2023058611 A1 WO 2023058611A1 JP 2022037007 W JP2022037007 W JP 2022037007W WO 2023058611 A1 WO2023058611 A1 WO 2023058611A1
Authority
WO
WIPO (PCT)
Prior art keywords
software
analysis
satisfies
function
test case
Prior art date
Application number
PCT/JP2022/037007
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 株式会社日立製作所
Publication of WO2023058611A1 publication Critical patent/WO2023058611A1/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 a software failure analysis device and a software failure analysis method.
  • test case describes the inputs and outputs (expected values) defined in the specifications or expected by the developer.
  • test cases When detecting defects, apply test cases to the target software and check whether the correct expected value is returned for the input. Here, if the output differs from the expected value for the input, or if the software itself stops operating, it is determined that the software contains a defect.
  • the method is a method of interactively repairing a software program using one or more human-generated test oracles to identify defects in the software program and, based on repair candidates, perform possible tests at the defects. automatically generating a first test to test the possible repair; generating a first query for a first test oracle based on the first test; generating a response to the first query; obtained from a human; generating a first human-provided test oracle based on the first query and the obtained response to the first query; and providing an extended first test. adding a first test oracle to the first test, augmenting a test suite to include the expanded first test, and using the augmented test suite to test the possible repair.
  • Patent Document 2 A method for automated software program repair candidate selection (see Patent Document 2) has also been proposed.
  • the method locates a defect in a software program that has been tested using a test suite, obtains a repair candidate for the defect, obtains a repair code pattern for the repair candidate, obtains a repair code pattern for the repair candidate, and performs a plurality of existing software programs. determining a number of occurrences of the repair code pattern in existing code of a program; prioritizing the repair candidate as a repair of the tested software program based on the number of occurrences of the repair code pattern; A repair action is performed on the tested software program according to the prioritization.
  • Still other steps include using a test suite to identify fault locations for faults in a software program; implementing repair candidates for the faults in the software program; extending the test suite with a plurality of test oracles based on the behavior based on the fault location, the test oracles corresponding to the fault locations; , executing the expanded test suite; and prioritizing the repair candidate as a repair of the software program based on failure rates of the plurality of test oracles for executing the expanded test suite.
  • a method including a ranking step has also been proposed (see Patent Document 3).
  • test case test suite
  • test suite test suite
  • Another problem is that it is difficult to evaluate the appropriateness of such developer's judgment. In other words, even if a decision is made by spending a lot of man-hours, if the validity is not certain, the accuracy of the automatic correction itself based on insufficient test cases cannot be expected.
  • the object of the present invention is to provide a technology that enables efficient securing of test cases necessary for automatic correction of software defects and correction support.
  • the information processing device holds, in a storage device, software test cases and information related to defect occurrence constraints in application functions of the test cases, and among the test cases, the The method is characterized by executing a process of judging a test case that satisfies a defect occurrence constraint and, as a result of the judgment, a process of outputting a notification requesting correction of the expected value of the test case that satisfies the occurrence constraint.
  • FIG. 1 is a diagram showing a configuration example of a software failure analysis device according to this embodiment;
  • FIG. It is a figure which shows the example of the generation
  • the software defect analysis apparatus 100 uses a so-called log-based APR (Automatic Program Repair) technique to identify the defect from a software execution log (including a log related to the defect). Analyze the existing test cases and add or modify the test cases necessary to fix the defect while finding the constraints that will occur.
  • log-based APR Automatic Program Repair
  • the software defect analysis device 100 uses the test cases added and corrected in this way to perform so-called test-based APR (Automatic Program Repair) to obtain corrected source code.
  • test-based APR Automatic Program Repair
  • the input of the software failure analysis device 100 includes the source code 12 of the software 11 and the execution log 13 of the software 11, as shown in FIG.
  • the execution log 13 contains functions (methods) called during execution.
  • an exception occurs during execution (e.g. division by 0)
  • the execution log 13 ends with the call to the function where the exception occurred, and the statement (source code line/step) where the exception occurred and the type of exception that occurred. (Recording program stop).
  • the software failure analysis device 100 sets the statement (source code line/step) of the software 11 including the division operation in the function in which the exception occurred as the analysis start point.
  • a function that directly or indirectly calls the function including the analysis start point is set as the analysis end point by inquiring of the user (developer).
  • the software failure analysis device 100 performs reverse symbolic execution in the direction opposite to normal software execution from the analysis start point to the analysis end point. During backward symbolic execution, software failure analyzer 100 records execution paths and path conditions.
  • An execution path is a path (a sequence of statements/lines/steps) in software that connects an analysis end point and an analysis start point, and processing proceeds along the execution path.
  • the execution path also includes function calls.
  • a path condition is a variable condition that causes an exception (for example, division by 0), that is, a defect occurrence constraint.
  • the variables mentioned above include local variables within the function and input parameters of the function.
  • the software defect analysis apparatus 100 determines the defect occurrence constraint among the test cases 20 based on the information on the defect occurrence constraint specified as described above and the test cases 20 prepared in advance regarding the functions of the software 11 described above. Determine what satisfies
  • the software defect analysis apparatus 100 outputs to the user terminal 200 a notification requesting modification of the expected value for the test case that satisfies the above-described defect occurrence constraint, and requests the developer to modify the test case. etc.
  • the software defect analysis apparatus 100 If, as a result of the determination described above, there is no test case that satisfies the defect occurrence constraint, the software defect analysis apparatus 100 generates a test case specifying inputs that satisfy the defect occurrence constraint based on the information regarding the defect occurrence constraint. Also, it outputs to the user terminal 200 a notification of a request for setting an expected value for such an input. The developer or the like who receives this sets the expected value of the test case through the user terminal 200, and completes the test case.
  • the software failure analysis device 100 uses an SMT solver (Satisfiability Modulo Theories Solver) 111 to calculate the input parameter value of the function that is the analysis end point that satisfies the path condition. By performing a test using this value as an input, it becomes possible to confirm whether the software 11 whose defect has been corrected operates correctly.
  • SMT solver Stisfiability Modulo Theories Solver
  • Other types of solvers such as SAT solvers (SATisfiability Solver) may be used in place of the SMT solver.
  • test-based APR Automatic Program Repair
  • the software defect analysis device 100 corrects a defect in the source code to be corrected, for example, based on the template for repair and the test case 20 corrected, added, etc. as described above. A predetermined correction process is executed.
  • the template described above contains instructions and the like for changing the source code 12 according to the presence of a defect in the source code 12 by executing the template.
  • the test case 20 determines whether the source code 12 behaves as specified or specified by the developer (eg, outputs an expected value for a given input).
  • Inputs to the software defect analyzer 100 include source code 12 , execution logs 13 and software specifications 14 .
  • the source code 12 is the source code of the functions (methods) that make up the software 11 to be analyzed.
  • the software specification 14 describes the names of functions, and the names, types and ranges of input parameter values and return values (return values) of the functions.
  • the execution log 13 contains records of function calls during execution of the software 11.
  • the execution log 13 may include the name (identification information) of the called function, input parameter values at the time of calling, and return values at the time of returning from the call.
  • Execution log 13 may also include exceptions that occurred during execution of software 11 . Exceptions include division by zero and violations of input parameter values or return values described in Software Specification 14 (values outside the specification range).
  • Execution paths 21 , input parameter values 22 , and test cases 20 are included in the output of the software failure analysis device 100 .
  • An execution path 21 is the path in the software (a series of statements/lines/steps processed sequentially in the source code 12) where the failure occurs.
  • One end of the execution path 21 is a statement/line/step in which an exception (failure) related to a problem occurs, and is referred to as an analysis start point, or simply a start point.
  • a parsing starting point is a statement containing a divide operation, for example, where a divide by 0 occurs.
  • the other end of the execution path 21 is a function that directly or indirectly calls the function containing the analysis start point, and is referred to as an analysis end point or entry point.
  • the analysis end point may be a function that includes the start point.
  • the input parameter value 22 is the input parameter value of the entry point function when a problem occurs.
  • the test case 20 is a test case prepared in advance regarding the functions of the source code 12, but is appropriately modified or added by the software failure analysis device 100 of this embodiment.
  • the software defect analysis device 100 shown in FIG. 2 is, for example, an information processing device arranged in the test environment 10 of the software 11, and efficiently secures test cases necessary for automatic defect correction of the software 11 and supports correction. enable Here, it is assumed that the software 11 described above is composed of source code 12 .
  • the software failure analysis device 100 may implement a user interface by itself, or may use the user terminal 200 connected via an appropriate network as the user interface.
  • the user terminal 200 is a terminal device operated by the developer of the software 1 or the like. Specifically, this user terminal 200 can be assumed to be a personal computer, a smart phone, a tablet terminal, or the like.
  • the software failure analysis device 100 and the user terminal 200 described above may be collectively referred to as a software failure analysis system.
  • the storage device 101 is composed of appropriate non-volatile storage elements such as SSDs (Solid State Drives) and hard disk drives.
  • the memory 103 is composed of a volatile memory element such as a RAM.
  • the arithmetic device 104 is a CPU that reads out the program 102 held in the storage device 101 into the memory 103 and executes it, performs overall control of the device itself, and performs various determinations, calculations, and control processing.
  • the input/output device 105 is a device that receives key inputs and voice inputs from developers and the like, and displays processed data.
  • a network interface card that connects to an appropriate network and handles communication processing with the user terminal 200 can be assumed.
  • the storage device 101 in addition to the program 102 for implementing the functions necessary for the software failure analysis apparatus 100 of this embodiment, the source code 12 of the software 11 described above, the execution log 13 of the software 11, At least software specifications 14, function call relation DB 15, and test cases 20 are stored.
  • the function call relation DB 15 stores data indicating the relation of which function calls which function, in other words, a call relation graph (a control flow graph representing the call relation between functions).
  • the program 102 includes at least a symbolic execution engine 110 and an SMT solver 111 .
  • test case that specifies the input that satisfies the occurrence constraint based on the function to output to the device 105 or the user terminal 200 , and using the function of outputting the notification of the request for setting the expected value for the above-mentioned input to the input/output device 105 and the user terminal 200, and the test case 20 that has undergone the above-described processing, the location of the failure occurrence in the software 11 is determined.
  • a function of specifying and a function of generating a repair candidate based on a repair template and test cases 20 for the defect are implemented.
  • a path condition is a variable (local variable or input parameter) condition for the execution of the analysis target software to pass through the execution path 21 . Details of the symbolic execution engine are described in the following document: Peter Dinges and Gul Agha, "Targeted Test Input Generation Using Symbolic Concrete Backward Execution".
  • the SMT solver 111 (solver) generates an input parameter value 22 that satisfies the pass condition.
  • the following document describes the SMT solver: Leonardo de Moura and Nikolaj Bjorner, "Z3: An Efficient SMT Solver”.
  • FIG. 3 shows an example of defect occurrence restrictions regarding the source code 12 of the software 11 .
  • the example shown here corresponds to a situation in which it is found in the execution log 13 that a division by 0 error has occurred in the function "Percentage".
  • the software defect analysis apparatus 100 analyzes the execution log 13 and finds that the line 10 of the function "Percentage” is a statement/line including a division operation, so the starting point is the line 10 of the function "Percentage”. set to
  • a path condition is a condition/constraint that causes an exception.
  • the symbolic execution engine 110 searches through the source code 12 in a direction opposite to normal (forward) execution until an entry point is reached (also referred to as reverse symbolic execution). If there are multiple entry points, the symbolic execution engine 110 searches until any one entry point is reached.
  • the symbolic execution engine 110 also searches for statements that call the function "Percentage". In the case of FIG. 3, the statement that calls the function "Percentage” is the function "abs max", and the symbolic execution engine 110 continues the search from that line and ends the search up to the analysis end point.
  • the execution paths and path conditions (including the input parameter value conditions of the entry point (analysis end point)) that have been found up to this point are constraints on the occurrence of defects. It should be noted that the SMT solver 111 solves the path conditions described above and calculates the input parameter values 22 of the function, which is the entry point, that satisfy the path conditions.
  • FIGS. 3 The results of identifying such occurrence constraints with respect to the source code 12 are illustrated in FIGS. Note that the constraint illustrated here assumes an environment in which the int type is a 32-bit signed integer, and the actual value varies depending on the execution environment.
  • the software defect analysis apparatus 100 acquires the defect occurrence constraint for each defect occurrence path (execution path) based on the execution log 13 related to the source code 12 by the log-based APR technology as described above (s1 ).
  • the software defect analysis device 100 acquires the test case 20 of the target function, which is the above-described defect occurrence location, from the storage device 101 (s2).
  • the software failure analysis device 100 selects one occurrence constraint obtained in s1 for the target function (s3). This selection method is not particularly limited.
  • the software failure analysis device 100 selects one of the test cases acquired in s2 (s4). This selection method is not particularly limited.
  • the software failure analysis device 100 determines whether the input value of the test case selected in s4 satisfies the generation constraint selected in s3 (s5). Specifically, as shown in FIG. 7, failure occurrence constraints C1 to C3 are compared with cases T1 to T4 of test case 20 regarding the function "abs max". The comparison in this case is the operation of verifying whether the relationship between the input value and the expected value of each test case of the function "abs max" satisfies each fault occurrence constraint.
  • the software failure analysis device 100 records the test case as a test case requiring correction (s6).
  • the software defect analysis apparatus 100 outputs to the input/output device 105 or the user terminal 200, in s6, a notification requesting the developer to output the test case T1, that is, to modify the expected value.
  • the developer operates the input/output device 105 or the user terminal 200 to input the expected value of the test case T1.
  • Software failure analysis device 100 receives this input and completes correction of test case T1.
  • the software failure analysis apparatus 100 selects the remaining test cases (that is, unprocessed test cases) among the test cases obtained in s2. (s7).
  • the software failure analysis device 100 returns the process to s4.
  • the software failure analysis apparatus 100 determines whether there is one or more test cases that satisfy the failure occurrence constraint. (s8).
  • the software failure analysis device 100 outputs to the input/output device 105 or the user terminal 200 a request for setting the expected value of the function "abs max" for the test cases T5 and T6 added here.
  • the developer operates the input/output device 105 or the user terminal 200 to input expected values for test cases T5 and T6.
  • Software failure analysis device 100 receives this input and completes addition of test cases T5 and T6.
  • the software defect analysis device 100 It is determined whether or not there are any remaining generation constraints that have not been processed among the constraints (s10).
  • the software failure analysis device 100 returns the process to s3.
  • the software failure analysis device 100 uses the test case 20 that has been corrected and added so far to perform software 11 is specified, and the defect is corrected based on the repair template and the test case 20 (s11), and the process ends.
  • Existing test-case-based automatic correction techniques may be appropriately employed for correcting this defect.
  • the arithmetic device defines an input that satisfies the occurrence constraint based on the information on the occurrence constraint. and outputting a notification requesting to set an expected value for the input.
  • the computing device acquires the statement in which the exception occurred as an analysis start point based on the execution log of the software, and directly or A process of acquiring a function to be indirectly called as an analysis end point, performing backward symbolic execution from the analysis start point toward the analysis end point to identify an execution path, and determining a path condition that is a condition for the exception to occur.
  • the calculation process and the condition of the input parameter value of the function serving as the analysis end point satisfying the path condition, or the input parameter value of the function serving as the analysis end point satisfying the path condition are stored as the generation constraint. It may be assumed that it executes a process held in the device.
  • the arithmetic unit uses the test case to specify a defect occurrence position in the software, and prepares a repair template and test case for the defect. A process of generating a repair candidate based on this may be further executed.
  • test-based APR Automatic Program Repair
  • log-based APR Automatic Program Repair
  • the information processing device if the result of the determination is that there is no test case that satisfies the occurrence constraint, the information processing device generates an input that satisfies the occurrence constraint based on the information on the occurrence constraint.
  • a defined test case may be generated, and a notification requesting the setting of expected values for the input may be output.
  • the information processing device obtains a statement in which an exception occurred as an analysis start point based on the execution log of the software, and directly obtains a function including the analysis start point.
  • a process of obtaining an indirectly called function as an analysis end point performing reverse symbolic execution from the analysis start point toward the analysis end point to identify an execution path, and a path condition that is a condition for the exception to occur and the condition of the input parameter value of the function serving as the analysis end point that satisfies the path condition, or the input parameter value of the function serving as the analysis end point that satisfies the path condition as the generation constraint. It is also possible to execute the processing held in the storage device.
  • the information processing apparatus uses the test case to identify a defect occurrence position in the software, and a template and test case for repairing the defect. Further processing may be performed to generate repair candidates based on .
  • Test environment 11 Software 12
  • Source code 13 Execution log 14
  • Function call relation DB 20 Test case 21
  • execution path 22 input parameter value 100 software failure analyzer 101 storage device 102 program 103 memory 104 arithmetic device 105 input/output device 110 symbolic execution engine 111 SMT solver 200 user terminal

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

ソフトウェア不具合分析装置及びソフトウェア不具合分析方法
　本発明は、ソフトウェア不具合分析装置及びソフトウェア不具合分析方法に関するものである。
　ソフトウェアに含まれる不具合は、完全に事前排除する事が難しい。そのため、そうしたソフトウェアから如何に効率的に、また的確に不具合を特定し、これを取り除いて修正するか、様々な検討が進められている。
　そうした不具合の検出手法としては、テストケースを用いるものが存在する。このテストケースは、仕様書で定めた或いは開発者が期待する入力及び出力（期待値）を記述したものである。
　不具合の検出に際しては、対象となるソフトウェアにテストケースを適用し、入力に対して正しい期待値を返すか確認する。ここで、入力に対して出力が期待値と異なる、或いはソフトウェア自体が動作停止するといった場合、当該ソフトウェアに不具合が含まれると判定される。
　開発者は、上述の不具合の存在を認識すれば、当該不具合の存在箇所を解析し、適切な入出力を行うように当該ソフトウェアのロジックを修正する。しかし、大規模なソフトウェアであれば、必要となるテストケースも大量となり、手間とコストからしても現実的な手法とは言い難い。
　そこで、こうした不具合修正の自動化を指向する技術が提案されている。例えば、人間が生み出した１つ以上のテストオラクルとともに、自動生成された１つ以上のテストを用いて、ソフトウェアプログラムをインタラクティブに修復する方法（特許文献１参照）が提案されている。
　この方法は、人間が生み出した１つ以上のテストオラクルを用いてソフトウェアプログラムをインタラクティブに修復する方法であって、ソフトウェアプログラム内の欠陥箇所を特定し、修復候補に基づき、前記欠陥箇所で、可能な修復を生成し、前記可能な修復をテストするよう第１テストを自動生成し、前記第１テストに基づき、第１テストオラクルのための第１クエリを生成し、前記第１クエリに対する応答を人間から取得し、前記第１クエリ及び該第１クエリに対する前記取得された応答に基づき、人間が提供した第１テストオラクルを生成し、拡張された第１テストを生成するよう、前記人間が提供した第１テストオラクルを前記第１テストに加え、前記拡張された第１テストを含むようテストスイートを増補し、前記増補されたテストスイートを用いて、前記可能な修復をテストするものである。
　また、自動化されたソフトウェアプログラム修復候補の選択のための方法（特許文献２参照）なども提案されている。
　この方法は、テストスイートを用いてテスト済みのソフトウェアプログラムにおいて欠陥の欠陥位置を特定し、前記欠陥のための修復候補を取得し、前記修復候補の修復コードパターンを取得し、複数の既存のソフトウェアプログラムの既存のコードにおける前記修復コードパターンの発生回数を決定し、前記修復コードパターンの前記発生回数に基づき、前記修復候補を、前記テスト済みソフトウェアプログラムの修復として優先順位付けし、前記修復候補の前記優先順位付けに従って、前記テスト済みソフトウェアプログラムに対して修復動作を実行するものである。
　また他にも、テストスイートを使用して、ソフトウェアプログラム内のフォールトのフォールト位置を特定するステップと、前記ソフトウェアプログラムにおいて、前記フォールトに対して修復候補を実装するステップと、前記ソフトウェアプログラムの観測された挙動に基づく複数のテストオラクルであって、前記フォールト位置に対応する複数のテストオラクルを用いて、前記テストスイートを拡張するステップと、前記の実装された修復候補を有する前記ソフトウェアプログラムに対して、前記の拡張されたテストスイートを実行するステップと、前記の拡張されたテストスイートを実行したことに対する前記複数のテストオラクルの失敗率に基づいて、前記ソフトウェアプログラムの修復として、前記修復候補を優先順位付けするステップを含む方法（特許文献３参照）なども提案されている。
特開２０１９－２９０１５号公報 特開２０１９－９６２９２号公報 特開２０１８－５５６７６号公報
　ところが従来技術においては、テストケース(テストスイート)が充分かどうか、人間(開発者)が判断しており、結局のところ相応の工数が必要となる。対象となるソフトウェアの規模が大きくなるほど、この工数は増大し、無視できないコストにつながりうる。
　また、そうした開発者の判断について、その妥当性を評価することが困難という問題もある。つまり、多大な工数をかけて行う判断であっても、その妥当性が確かなものでなければ、不十分なテストケースに基づく自動修正の精度自体も期待出来ないこととなる。
　そこで本発明の目的は、ソフトウェアの不具合自動修正に必要なテストケースの効率的な確保及び修正支援を可能とする技術を提供することにある。
　上記課題を解決する本発明のソフトウェア不具合分析装置は、ソフトウェアのテストケースと、前記テストケースの適用関数における不具合の発生制約に関する情報とを保持する記憶装置と、前記テストケースのうち前記不具合の発生制約を満たすものを判定する処理と、前記判定の結果、前記発生制約を満たすテストケースについて、その期待値の修正要求の通知を出力する処理を実行する演算装置を含むことを特徴とする。
　また、本発明のソフトウェア不具合分析方法は、情報処理装置が、ソフトウェアのテストケースと、前記テストケースの適用関数における不具合の発生制約に関する情報とを記憶装置にて保持し、前記テストケースのうち前記不具合の発生制約を満たすものを判定する処理と、前記判定の結果、前記発生制約を満たすテストケースについて、その期待値の修正要求の通知を出力する処理を実行する、ことを特徴とする。
　本発明によれば、ソフトウェアの不具合自動修正に必要なテストケースの効率的な確保及び修正支援が可能となる。
本実施形態におけるソフトウェア不具合分析技術の概要を示す図である。 本実施形態におけるソフトウェア不具合分析装置の構成例を示す図である。 本実施形態における不具合の発生制約例を示す図である。 本実施形態における不具合の発生制約例を示す図である。 本実施形態における不具合の発生制約例を示す図である。 本実施形態のソフトウェア不具合分析方法のフロー例を示す図である。 本実施形態での不具合発生制約とテストケースの比較例を示す図である。 本実施形態における出力例を示す図である。
＜概要＞
　図１で例示するように、本実施形態におけるソフトウェア不具合分析装置１００は、いわゆるログベースＡＰＲ（Ａｕｔｏｍａｔｉｃ　Ｐｒｏｇｒａｍ　Ｒｅｐａｉｒ）の技術を用いて、ソフトウェアの実行ログ（不具合に関するログが含まれる）から当該不具合が発生する制約条件を求める一方、既存のテストケースを分析し、不具合修正に必要なテストケースの追加や修正を実施する。
　また、ソフトウェア不具合分析装置は１００、こうして追加、修正がされたテストケースを用いて、いわゆるテストベースＡＰＲ（Ａｕｔｏｍａｔｉｃ　Ｐｒｏｇｒａｍ　Ｒｅｐａｉｒ）を実施し、修正ソースコードを得るものである。
　ここで、ソフトウェア不具合分析装置１００の入力には、図２で示すように、ソフトウェア１１のソースコード１２と、ソフトウェア１１の実行ログ１３とが含まれる。実行ログ１３には、実行中に呼び出された関数（メソッド）が含まれている。実行中に例外（例えば０徐算）が発生すると、実行ログ１３は例外が発生した関数の呼び出し、および例外が発生したステートメント（ソースコードの行／ステップ）と発生した例外の種類で終わっている（プログラム停止を記録している）。
　ソフトウェア不具合分析装置１００は、上述の実行ログ１３から、例外が発生した関数のなかの徐算演算を含むソフトウェア１１のステートメント（ソースコードの行／ステップ）を解析開始点と設定する。また、利用者（開発者）に問い合わせて、解析開始点を含む関数を直接または間接に呼び出す関数を、解析終了点と設定する。
　ソフトウェア不具合分析装置１００は、上述の解析開始点から解析終了点まで、通常のソフトウェア実行とは逆方向の逆向き記号実行を行う。逆向き記号実行の間は、ソフトウェア不具合分析装置１００は、実行パスとパス条件を記録する。
　実行パスは、解析終了点と解析開始点とを結ぶソフトウェア中のパス（ステートメント／行／ステップの並び）であり、実行パスに沿って処理が進む。実行パスは、関数の呼び出しも含む。パス条件は、例外（例えば０徐算）が発生する変数の条件、すなわち不具合の発生制約である。上述の変数には、関数内のローカル変数や関数の入力パラメータが含まれる。
　ソフトウェア不具合分析装置１００は、上述のように特定した不具合の発生制約に関する情報と、上述のソフトウェア１１の関数に関して予め用意しているテストケース２０とに基づいて、テストケース２０のうち不具合の発生制約を満たすものを判定する。
　また、ソフトウェア不具合分析装置１００は、この判定の結果、上述の不具合の発生制約を満たすテストケースについて、当該期待値の修正要求の通知をユーザ端末２００に出力し、当該テストケースの修正を開発者等に行わせる。
　また、ソフトウェア不具合分析装置１００は、上述の記判定の結果、不具合の発生制約を満たすテストケースが無かった場合、当該発生制約に関する情報に基づき、当該発生制約を満たす入力を規定したテストケースを生成し、また、こうした入力に対する期待値の設定要求の通知をユーザ端末２００に出力する。これを受けた開発者等は、当該テストケースの期待値についてユーザ端末２００を通じて設定し、当該テストケースを完成させる。
　なお、ソフトウェア不具合分析装置１００は、ＳＭＴソルバ（Satisfiability Modulo Theories Solver）１１１を用いてパス条件を満足する解析終了点である関数の入力パラメータ値を算出する。この値を入力とするテストを行うことで、不具合を修正したソフトウェア１１が正しく動作するかを確認できるようになる。ＳＭＴソルバに替えてＳＡＴソルバ(SATisfiability Solver)などの他の種類のソルバを用いても良い。
　また、ソフトウェアにおける不具合の修正は、既知の技術のうち、例えば、テストベースＡＰＲ（Ａｕｔｏｍａｔｉｃ　Ｐｒｏｇｒａｍ　Ｒｅｐａｉｒ）の技術を採用する。
　この技術において、ソフトウェア不具合分析装置１００は、不具合修正対象となるソースコードにおける不具合を修正すべく、例えば、修復用のテンプレートと、上述のように修正、追加等を行ったテストケース２０とに基づいた所定の修正処理を実行する。
　上述のテンプレートは、これを実行することで、ソースコード１２の不具合の存在に応じて当該ソースコード１２を変更する命令等を含むものである。一方、テストケース２０は、ソースコード１２が仕様や開発者の指定どおりの挙動（例：所定の入力に対する期待値の出力）を示すか判定するものである。
＜ソフトウェア不具合分析装置の入力＞
　ソフトウェア不具合分析装置１００の入力には、ソースコード１２、実行ログ１３、およびソフトウェア仕様１４が含まれる。
　ソースコード１２は、分析対象であるソフトウェア１１を構成する関数（メソッド）のソースコードである。ソフトウェア仕様１４には、関数の名前、および、関数の入力パラメータ値と返り値（戻り値）の名前と型と範囲とが記述されている。
　実行ログ１３は、ソフトウェア１１の実行中の関数呼び出しの記録を含む。実行ログ１３には、呼び出された関数の名前（識別情報）の他に呼び出し時の入力パラメータ値や、呼び出しから戻るときの返り値を含んでもよい。
　実行ログ１３は、さらにソフトウェア１１の実行中に発生した例外を含んでもよい。例外としては、０徐算やソフトウェア仕様１４に記述された入力パラメータ値または返り値の違反（仕様の範囲外の値）がある。
＜ソフトウェア不具合分析装置の出力＞
　ソフトウェア不具合分析装置１００の出力には、実行パス２１、入力パラメータ値２２、及びテストケース２０が含まれる。実行パス２１は、不具合が発生するソフトウェア中のパス（ソースコード１２のなかで順次処理される一連のステートメント／行／ステップ）である。
　実行パス２１の一端は、不具合に係る例外（故障）が発生するステートメント／行／ステップであり、解析開始点、または単に開始点と記す。解析開始点は、例えば０徐算が発生する徐算演算を含むステートメントである。
　実行パス２１の他端は、解析開始点を含む関数を直接または間接に呼び出す関数であり、解析終了点、またはエントリポイントと記す。解析終了点は、開始点を含む関数であってもよい。
　入力パラメータ値２２は、エントリポイントとなる関数の、不具合が発生するときの入力パラメータ値である。
　テストケース２０は、ソースコード１２の関数に関して予め用意しておいたテストケースであるが、本実施形態のソフトウェア不具合分析装置１００により、適宜に修正や追加がなされたものとなる。
＜ソフトウェア不具合分析装置の構成＞
　図２に示すソフトウェア不具合分析装置１００は、例えば、ソフトウェア１１のテスト環境１０において配置された情報処理装置であって、当該ソフトウェア１１の不具合自動修正に必要なテストケースの効率的な確保及び修正支援を可能とする。ここでは、上述のソフトウェア１１がソースコード１２で構成されているものとする。
　ソフトウェア不具合分析装置１００は、自身でユーザインターフェイスを実装するケースの他、適宜なネットワークを介して接続するユーザ端末２００をユーザインターフェイスとして利用するとしてもよい。
　この場合、ユーザ端末２００は、ソフトウェア１の開発者等が操作する端末装置となる。このユーザ端末２００は、具体的には、パーソナルコンピュータ、スマートフォン、タブレット端末、などを想定できる。
　なお、ソフトウェア不具合分析装置１００と、上述のユーザ端末２００を総称してソフトウェア不具合分析システムとしてもよい。
　このうち記憶装置１０１は、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される。
　また、メモリ１０３は、ＲＡＭなど揮発性記憶素子で構成される。
　また、演算装置１０４は、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵである。
　また、入出力装置１０５は、開発者等からのキー入力や音声入力を受け付け、また、処理データの表示を行う装置である。或いは、適宜なネットワークと接続してユーザ端末２００との通信処理を担うネットワークインターフェイスカードも想定できる。
　また、記憶装置１０１内には、本実施形態のソフトウェア不具合分析装置１００として必要な機能を実装する為のプログラム１０２に加えて、上述のソフトウェア１１のソースコード１２、当該ソフトウェア１１の実行ログ１３、ソフトウェア仕様１４、関数呼び出し関係ＤＢ１５、及びテストケース２０が少なくとも記憶されている。
　なお、関数呼び出し関係ＤＢ１５には、どの関数がどの関数を呼び出すかの関係、換言すれば、呼び出し関係グラフ（関数間の呼び出し関係を表現する制御フローのグラフ）を示すデータが記憶される。
　また、プログラム１０２は、記号実行エンジン１１０及びＳＭＴソルバ１１１を少なくとも含むものとする。
　演算装置１０４がプログラム１０２を実行することで、ソースコード１２から関数の呼び出し関係を取得して、関数呼び出し関係ＤＢ１５に格納する機能と、実行ログ１３を解析して解析開始点を取得する機能と、解析開始点を含む関数を呼び出す関数を関数呼び出し関係ＤＢ１５から取得して、エントリポイントの候補として入出力装置１０５またはユーザ端末２００に備わるディスプレイに表示する機能と、表示させたエントリポイントの候補すなわち関数に関してユーザ（開発者）が選択したものを、解析終了点（エントリポイント）として設定する機能と、ここまでの処理で得ている不具合の発生制約の情報と、記憶装置１０１で保持するテストケース２０とに基づいて、テストケース２０のうち不具合の発生制約を満たすものを判定する機能と、この判定の結果、不具合の発生制約を満たすテストケースについて、当該期待値の修正要求の通知を入出力装置１０５やユーザ端末２００に出力する機能と、上述の判定の結果、不具合の発生制約を満たすテストケースが無かった場合、当該発生制約に関する情報に基づき、当該発生制約を満たす入力を規定したテストケースを生成し、上述の入力に対する期待値の設定要求の通知を入出力装置１０５やユーザ端末２００に出力する機能と、上述の処理を経たテストケース２０を使用して、ソフトウェア１１における不具合発生位置を特定する機能と、当該不具合に対して修復用のテンプレート及びテストケース２０に基づいて修復候補を生成する機能が実装される。
　なお、記号実行エンジン１１０は、実行パス２１およびパス条件を生成する（例：特願２０２０－１４３５９１参照）。パス条件は、分析対象のソフトウェアの実行が実行パス２１を通るための変数（ローカル変数や入力パラメータ）の条件である。なお、以下の文献に記号実行エンジンンの詳細が記述されている: Peter Dinges and Gul Agha, "Targeted Test Input Generation Using Symbolic Concrete Backward Execution"。
　また、ＳＭＴソルバ１１１（ソルバ）は、パス条件を満たす入力パラメータ値２２生成する。以下の文献にＳＭＴソルバが記述されている： Leonardo de Moura and Nikolaj Bjorner, "Z3: An Efficient SMT Solver"。
＜不具合の発生制約例＞
　ソフトウェア１１のソースコード１２に関する、不具合の発生制約の例について、図３にて示す。ここで示す例では、関数「Ｐｅｒｃｅｎｔａｇｅ」で０割りの不具合が発生したことが実行ログ１３にて判明した状況に対応したものである。
　そこで、関数「Ｐｅｒｃｅｎｔａｇｅ」を起点に、上述のログベースでの不具合解析を実行すると、の不具合箇所に到達する実行パスとパス条件すなわち発生制約が３通り求まったとする。
　この場合、ソフトウェア不具合分析装置１００は、実行ログ１３を解析することで、関数「Ｐｅｒｃｅｎｔａｇｅ」の行１０が、徐算演算を含むステートメント／行であるから、開始点を関数「Ｐｅｒｃｅｎｔａｇｅ」の行１０に設定する。
　パス条件は、例外が発生する条件／制約である。解析開始点である関数「Ｐｅｒｃｅｎｔａｇｅ」の行１０におけるパス条件は「ｍａｘ＝０」である。
　記号実行エンジン１１０は、開始点から始めて、通常の（前向き）実行とは反対の方向にソースコード１２のなかを、エントリポイントに到達するまで探索（逆向き記号実行とも記す）する。エントリポイントが複数ある場合には、記号実行エンジン１１０は、何れか１つのエントリポイントに到達するまで探索する。
　また、記号実行エンジン１１０は、関数「Ｐｅｒｃｅｎｔａｇｅ」を呼び出すステートメントを探索する。図３の場合、関数「Ｐｅｒｃｅｎｔａｇｅ」を呼び出すステートメントは、関数「ａｂｓ　ｍａｘ」であり、記号実行エンジン１１０は、当該行から探索を継続し、解析終了点までで探索を終了する。ここまでの時点で判明した実行パスとパス条件（エントリポイント（解析終了点）の入力パラメータ値の条件を含んでいる）が、不具合の発生制約となる。なお、ＳＭＴソルバ１１１は、上述のパス条件を解いて、エントリポイントである関数の、パス条件を満たす入力パラメータ値２２を算出する。
　こうした発生制約の特定を、ソースコード１２に関して実行した結果、図３～図５に例示する。なお、ここで例示する制約はｉｎｔ型が３２ビット符号付き整数である環境を仮定しており、実際の値は実行環境により異なる。図３で示す発生制約は、￢（Ａ＞Ｂ）∩￢（Ｂ＞０）∩（Ｂ－Ａ＝０）、入力パラメータ値は、（ａ，ｂ）＝（０，０）となった。
　また、図４で示す発生制約は、￢（０＜Ａ）∩￢（０－Ａ＜０）∩（Ｂ＝０）、入力パラメータ値は、（ａ，ｂ）＝（－２１４７４８３６４８，０）となった。
　また、図５で示す発生制約は、￢（０＞Ｂ）∩￢（０＞０－Ｂ）∩（Ａ＝０）、入力パラメータ値は、（ａ，ｂ）＝（０，－２１４７４８３６４８）となった。
＜ソフトウェア不具合分析処理＞
　続いて、本実施形態の本実施形態のソフトウェア不具合分析方法のフロー例について、図６に基づき説明する。まず、ソフトウェア不具合分析装置１００は、ソースコード１２に関する実行ログ１３に基づき、不具合の発生パス（実行パス）毎の不具合の発生制約を、既に述べたようにログベースＡＰＲの技術により取得する（ｓ１）。
　続いて、ソフトウェア不具合分析装置１００は、上述の不具合の発生箇所たる対象関数のテストケース２０を記憶装置１０１から取得する（ｓ２）。
　また、ソフトウェア不具合分析装置１００は、当該対象関数に関してｓ１で得ている発生制約を一つ選択する（ｓ３）。この選択方法に関して特に限定しない。
　また、ソフトウェア不具合分析装置１００は、ｓ２で取得しているテストケースのうち一つを選択する（ｓ４）。この選択方法に関して特に限定しない。
　ここで、ソフトウェア不具合分析装置１００は、ｓ４で選択したテストケースの入力値は、ｓ３で選択した発生制約を満たすか判定する（ｓ５）。具体的には、図７で示すように、不具合の発生制約Ｃ１～Ｃ３と、関数「ａｂｓ　ｍａｘ」に関するテストケース２０のケースＴ１～Ｔ４をそれぞれ比較することとなる。この場合の比較は、関数「ａｂｓ　ｍａｘ」のテストケースそれぞれの入力値と期待値の関係を、不具合の発生制約それぞれが満たすか検証する動作となる。
　ｓ５の判定の結果、上述の発生制約を満たすテストケースが特定できた場合（ｓ５：Ｙｅｓ）、ソフトウェア不具合分析装置１００は、当該テストケースを要修正テストケースとして記録する（ｓ６）。
　この場合、図８の出力例に示すように、テストケースＴ１に関して、発生制約Ｃ１が条件を満たすと判定されたため（不具合が発生する、修正が必要なテストケースと判明）、ソフトウェア不具合分析装置１００は、ｓ６において、テストケースＴ１の出力すなわち期待値の修正を開発者に要求する通知を、入出力装置１０５またはユーザ端末２００に出力する。
　一方、開発者は、入出力装置１０５ないしユーザ端末２００を操作し、テストケースＴ１の期待値について入力する。ソフトウェア不具合分析装置１００は、この入力を受けてテストケースＴ１の修正を完了する。
　一方、上述の判定の結果、発生制約を満たすテストケースが特定できなかった場合（ｓ５：Ｎｏ）、ソフトウェア不具合分析装置１００は、ｓ２で得ているテストケースのうち残りのテストケース（すなわち未処理のもの）があるか判定する（ｓ７）。
　この判定の結果、残りのテストケースが存在することが判明した場合（ｓ７：Ｙｅｓ）、ソフトウェア不具合分析装置１００は処理をｓ４に戻す。
　一方、上述の判定の結果、残りのテストケースが存在しないことが判明した場合（ｓ７：Ｎｏ）、ソフトウェア不具合分析装置１００は、当該不具合の発生制約を満たすテストケースが１個以上存在したか判定する（ｓ８）。
　この判定の結果、不具合の発生制約を満たすテストケースが存在しないことが判明した場合（ｓ８：Ｎｏ）、ソフトウェア不具合分析装置１００は、図８で例示するように、当該不具合の発生制約Ｃ２、Ｃ３を満たす入力パラメータ値を入力としたテストケースＴ５、Ｔ６を追加する（ｓ９）。
　この場合、ソフトウェア不具合分析装置１００は、ｓ９において、ここで追加したテストケースＴ５、Ｔ６に関して、関数「ａｂｓ　ｍａｘ」の期待値の設定要求を、入出力装置１０５またはユーザ端末２００に出力する。
　一方、開発者は、入出力装置１０５ないしユーザ端末２００を操作し、テストケースＴ５、Ｔ６の各期待値について入力する。ソフトウェア不具合分析装置１００は、この入力を受けてテストケースＴ５、Ｔ６の追加を完了する。
　一方、上述の判定の結果、　当該不具合の発生制約を満たすテストケースが１個以上存在したことが判明した場合（ｓ８：Ｙｅｓ）、ソフトウェア不具合分析装置１００は、ｓ１で取得している不具合の発生制約のうち未処理である、残りの発生制約があるか判定する（ｓ１０）。
　この判定の結果、残りの発生制約が存在する場合（ｓ１０：Ｙｅｓ）、ソフトウェア不具合分析装置１００は、処理をｓ３に戻す。
　一方、上述の判定の結果、残りの発生制約が存在しないことが判明した場合（ｓ１０：Ｎｏ）、ソフトウェア不具合分析装置１００は、ここまで修正、追加が完了したテストケース２０を使用して、ソフトウェア１１における不具合の発生位置を特定し、この不具合に対して修復用のテンプレート及びテストケース２０に基づいて、不具合修正を実行し（ｓ１１）、処理を終了する。この不具合の修正処理については、既存のテストケースベースの自動修正技術を適宜採用すればよい。
　以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
　こうした本実施形態によれば、ソフトウェアの不具合自動修正に必要なテストケースの効率的な確保及び修正支援が可能となる。
　本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のソフトウェア不具合分析装置において、前記演算装置は、前記判定の結果、前記発生制約を満たすテストケースが無かった場合、前記発生制約に関する情報に基づき、当該発生制約を満たす入力を規定したテストケースを生成し、前記入力に対する期待値の設定要求の通知を出力するものである、としてもよい。
　これによれば、ソフトウェアの不具合修正に必要となるテストケースを不足なく確保可能となる。ひいては、ソフトウェアの不具合自動修正に必要なテストケースのより効率的な確保及び修正支援が可能となる。
　また、本実施形態のソフトウェア不具合分析装置において、前記演算装置は、前記ソフトウェアの実行ログに基づき、例外が発生したステートメントを解析開始点として取得する処理と、前記解析開始点を含む関数を直接または間接に呼び出す関数を解析終了点として取得する処理と、前記解析開始点から前記解析終了点に向けて逆向き記号実行を行って実行パスを特定し、前記例外が発生する条件であるパス条件を算出する処理と、前記パス条件を満たす前記解析終了点となる関数の入力パラメータ値の条件、または、前記パス条件を満たす前記解析終了点となる関数の入力パラメータ値を、前記発生制約として前記記憶装置に保持する処理を実行するものである、としてもよい。
　これによれば、いわゆるログベースＡＰＲ（Ａｕｔｏｍａｔｉｃ　Ｐｒｏｇｒａｍ　Ｒｅｐａｉｒ）における技術を採用し、不具合の発生制約を的確かつ効率的に特定することができる。ひいては、ソフトウェアの不具合自動修正に必要なテストケースのより効率的な確保及び修正支援が可能となる。
　また、本実施形態のソフトウェア不具合分析装置において、前記演算装置は、前記テストケースを使用して、前記ソフトウェアにおける不具合発生位置を特定する処理と、前記不具合に対して修復用のテンプレート及びテストケースに基づいて修復候補を生成する処理をさらに実行するものである、としてもよい。
　これによれば、いわゆるテストベースＡＰＲ（Ａｕｔｏｍａｔｉｃ　Ｐｒｏｇｒａｍ　Ｒｅｐａｉｒ）を上述のログベースＡＰＲ（Ａｕｔｏｍａｔｉｃ　Ｐｒｏｇｒａｍ　Ｒｅｐａｉｒ）に適用し、ソフトウェアの不具合自動修正に必要なテストケースの効率的な確保と、当該テストケースに基づくソフトウェア自動修正が可能となる。
　また、本実施形態のソフトウェア不具合分析方法において、前記情報処理装置が、前記判定の結果、前記発生制約を満たすテストケースが無かった場合、前記発生制約に関する情報に基づき、当該発生制約を満たす入力を規定したテストケースを生成し、前記入力に対する期待値の設定要求の通知を出力する、としてもよい。
　また、本実施形態のソフトウェア不具合分析方法において、前記情報処理装置が、前記ソフトウェアの実行ログに基づき、例外が発生したステートメントを解析開始点として取得する処理と、前記解析開始点を含む関数を直接または間接に呼び出す関数を解析終了点として取得する処理と、前記解析開始点から前記解析終了点に向けて逆向き記号実行を行って実行パスを特定し、前記例外が発生する条件であるパス条件を算出する処理と、前記パス条件を満たす前記解析終了点となる関数の入力パラメータ値の条件、または、前記パス条件を満たす前記解析終了点となる関数の入力パラメータ値を、前記発生制約として前記記憶装置に保持する処理を実行する、としてもよい。
　また、本実施形態のソフトウェア不具合分析方法において、前記情報処理装置が、前記テストケースを使用して、前記ソフトウェアにおける不具合発生位置を特定する処理と、前記不具合に対して修復用のテンプレート及びテストケースに基づいて修復候補を生成する処理をさらに実行する、としてもよい。
１０　テスト環境
１１　ソフトウェア
１２　ソースコード
１３　実行ログ
１４　ソフトウェア仕様
１５　関数呼び出し関係ＤＢ
２０　テストケース
２１　実行パス
２２　入力パラメータ値
１００　ソフトウェア不具合分析装置
１０１　記憶装置
１０２　プログラム
１０３　メモリ
１０４　演算装置
１０５　入出力装置
１１０　記号実行エンジン
１１１　ＳＭＴソルバ
２００　ユーザ端末

Claims (8)

  1. 　ソフトウェアのテストケースと、前記テストケースの適用関数における不具合の発生制約に関する情報とを保持する記憶装置と、
    　前記テストケースのうち前記不具合の発生制約を満たすものを判定する処理と、前記判定の結果、前記発生制約を満たすテストケースについて、その期待値の修正要求の通知を出力する処理を実行する演算装置と、
    　を含むことを特徴とするソフトウェア不具合分析装置。
  2. 　前記演算装置は、
    　前記判定の結果、前記発生制約を満たすテストケースが無かった場合、前記発生制約に関する情報に基づき、当該発生制約を満たす入力を規定したテストケースを生成し、前記入力に対する期待値の設定要求の通知を出力するものである、
    　ことを特徴とする請求項１に記載のソフトウェア不具合分析装置。
  3. 　前記演算装置は、
    　前記ソフトウェアの実行ログに基づき、例外が発生したステートメントを解析開始点として取得する処理と、前記解析開始点を含む関数を直接または間接に呼び出す関数を解析終了点として取得する処理と、前記解析開始点から前記解析終了点に向けて逆向き記号実行を行って実行パスを特定し、前記例外が発生する条件であるパス条件を算出する処理と、前記パス条件を満たす前記解析終了点となる関数の入力パラメータ値の条件、または、前記パス条件を満たす前記解析終了点となる関数の入力パラメータ値を、前記発生制約として前記記憶装置に保持する処理を実行するものである、
    　ことを特徴とする請求項１に記載のソフトウェア不具合分析装置。
  4. 　前記演算装置は、
    　前記テストケースを使用して、前記ソフトウェアにおける不具合発生位置を特定する処理と、前記不具合に対して修復用のテンプレート及びテストケースに基づいて修復候補を生成する処理をさらに実行するものである、
    　ことを特徴とする請求項１に記載のソフトウェア不具合分析装置。
  5. 　情報処理装置が、
    　ソフトウェアのテストケースと、前記テストケースの適用関数における不具合の発生制約に関する情報とを記憶装置にて保持し、
    　前記テストケースのうち前記不具合の発生制約を満たすものを判定する処理と、前記判定の結果、前記発生制約を満たすテストケースについて、その期待値の修正要求の通知を出力する処理を実行する、
    　ことを特徴とするソフトウェア不具合分析方法。
  6. 　前記情報処理装置が、
    　前記判定の結果、前記発生制約を満たすテストケースが無かった場合、前記発生制約に関する情報に基づき、当該発生制約を満たす入力を規定したテストケースを生成し、前記入力に対する期待値の設定要求の通知を出力する、
    　ことを特徴とする請求項５に記載のソフトウェア不具合分析方法。
  7. 　前記情報処理装置が、
    　前記ソフトウェアの実行ログに基づき、例外が発生したステートメントを解析開始点として取得する処理と、前記解析開始点を含む関数を直接または間接に呼び出す関数を解析終了点として取得する処理と、前記解析開始点から前記解析終了点に向けて逆向き記号実行を行って実行パスを特定し、前記例外が発生する条件であるパス条件を算出する処理と、前記パス条件を満たす前記解析終了点となる関数の入力パラメータ値の条件、または、前記パス条件を満たす前記解析終了点となる関数の入力パラメータ値を、前記発生制約として前記記憶装置に保持する処理を実行する、
    　ことを特徴とする請求項５に記載のソフトウェア不具合分析方法。
  8. 　前記情報処理装置が、
    　前記テストケースを使用して、前記ソフトウェアにおける不具合発生位置を特定する処理と、前記不具合に対して修復用のテンプレート及びテストケースに基づいて修復候補を生成する処理をさらに実行する、
    　ことを特徴とする請求項５に記載のソフトウェア不具合分析方法。
PCT/JP2022/037007 2021-10-07 2022-10-03 ソフトウェア不具合分析装置及びソフトウェア不具合分析方法 WO2023058611A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-165227 2021-10-07
JP2021165227A JP2023056111A (ja) 2021-10-07 2021-10-07 ソフトウェア不具合分析装置及びソフトウェア不具合分析方法

Publications (1)

Publication Number Publication Date
WO2023058611A1 true WO2023058611A1 (ja) 2023-04-13

Family

ID=85804286

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/037007 WO2023058611A1 (ja) 2021-10-07 2022-10-03 ソフトウェア不具合分析装置及びソフトウェア不具合分析方法

Country Status (2)

Country Link
JP (1) JP2023056111A (ja)
WO (1) WO2023058611A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009205239A (ja) * 2008-02-26 2009-09-10 Hitachi Ltd ソフトウェア検証システム
US20120159133A1 (en) * 2010-12-17 2012-06-21 Microsoft Corporation Business exception management pattern for business processes
JP2016164727A (ja) * 2015-03-06 2016-09-08 株式会社 日立産業制御ソリューションズ テストケース選択装置
US20190114436A1 (en) * 2017-10-13 2019-04-18 Korea Internet & Security Agency Method for automatically detecting security vulnerability based on hybrid fuzzing, and apparatus thereof

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009205239A (ja) * 2008-02-26 2009-09-10 Hitachi Ltd ソフトウェア検証システム
US20120159133A1 (en) * 2010-12-17 2012-06-21 Microsoft Corporation Business exception management pattern for business processes
JP2016164727A (ja) * 2015-03-06 2016-09-08 株式会社 日立産業制御ソリューションズ テストケース選択装置
US20190114436A1 (en) * 2017-10-13 2019-04-18 Korea Internet & Security Agency Method for automatically detecting security vulnerability based on hybrid fuzzing, and apparatus thereof

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CHEN NING; KIM SUNGHUN: "STAR: Stack Trace Based Automatic Crash Reproduction via Symbolic Execution", IEEE TRANSACTIONS ON SOFTWARE ENGINEERING., IEEE SERVICE CENTER, LOS ALAMITOS, CA., US, vol. 41, no. 2, 1 February 2015 (2015-02-01), US , pages 198 - 220, XP011572819, ISSN: 0098-5589, DOI: 10.1109/TSE.2014.2363469 *

Also Published As

Publication number Publication date
JP2023056111A (ja) 2023-04-19

Similar Documents

Publication Publication Date Title
US10586053B2 (en) Method for automatically detecting security vulnerability based on hybrid fuzzing, and apparatus thereof
CN106294120B (zh) 测试代码的方法、设备和计算机程序产品
CN108388514B (zh) 接口自动化测试方法、装置、设备及计算机可读存储介质
US20090319829A1 (en) Pattern extraction method and apparatus
CN111026601A (zh) Java应用系统的监控方法、装置、电子设备及存储介质
JP2018026135A (ja) 静的解析警告の効率的な運用のための原因ポイント解析のためのシステム及び方法
CN109977012B (zh) 系统的联调测试方法、装置、设备及计算机可读存储介质
US8661414B2 (en) Method and system for testing an order management system
Kadry A new proposed technique to improve software regression testing cost
JP2015011372A (ja) デバッグ支援システム、方法、プログラム及び記録媒体
CN110990289B (zh) 一种自动提交bug的方法、装置、电子设备及存储介质
CN110543429B (zh) 测试用例调试方法、装置及存储介质
EP3734460B1 (en) Probabilistic software testing via dynamic graphs
CN112148594A (zh) 一种脚本测试方法、装置、电子设备及存储介质
WO2023058611A1 (ja) ソフトウェア不具合分析装置及びソフトウェア不具合分析方法
CN112988578A (zh) 一种自动化测试方法和装置
US20080195906A1 (en) Test pattern generation apparatus and test pattern generation method
CN115034165A (zh) 一种芯片仿真验证方法、系统、设备以及存储介质
JP4957521B2 (ja) ソフトウェア部分テストシステム、それに用いる方法およびプログラム
CN111752823A (zh) 一种车载电源应用软件的测试方法、装置及设备
WO2019142266A1 (ja) テストケース生成装置、テストケース生成方法およびテストケース生成プログラム
WO2023058609A1 (ja) 不具合解析装置及び不具合解析方法
CN111198798A (zh) 服务稳定性的测量方法及装置
JP2023124531A (ja) 不具合解析装置及び不具合解析方法
US20230259447A1 (en) Defect Analysis Apparatus, Program, and Defect Analysis Method

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE