WO2014180107A1 - 一种基于测试的静态分析误报消除方法 - Google Patents
一种基于测试的静态分析误报消除方法 Download PDFInfo
- Publication number
- WO2014180107A1 WO2014180107A1 PCT/CN2013/086993 CN2013086993W WO2014180107A1 WO 2014180107 A1 WO2014180107 A1 WO 2014180107A1 CN 2013086993 W CN2013086993 W CN 2013086993W WO 2014180107 A1 WO2014180107 A1 WO 2014180107A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- execution
- program
- static analysis
- defect
- test
- Prior art date
Links
- 238000004458 analytical method Methods 0.000 title claims abstract description 110
- 230000003068 static effect Effects 0.000 title claims abstract description 90
- 238000000034 method Methods 0.000 title claims abstract description 46
- 238000012360 testing method Methods 0.000 title claims abstract description 41
- 230000008030 elimination Effects 0.000 title claims abstract description 11
- 238000003379 elimination reaction Methods 0.000 title claims abstract description 11
- 230000007547 defect Effects 0.000 claims abstract description 72
- 238000005516 engineering process Methods 0.000 claims abstract description 9
- 238000012790 confirmation Methods 0.000 claims abstract description 4
- 238000010998 test method Methods 0.000 claims description 10
- 230000037431 insertion Effects 0.000 claims description 9
- 230000014509 gene expression Effects 0.000 claims description 7
- 238000012545 processing Methods 0.000 claims description 6
- 239000000523 sample Substances 0.000 claims description 4
- 239000012634 fragment Substances 0.000 claims description 2
- 230000008685 targeting Effects 0.000 claims description 2
- 230000001960 triggered effect Effects 0.000 claims 1
- 238000007781 pre-processing Methods 0.000 description 4
- 238000004364 calculation method Methods 0.000 description 3
- 238000013522 software testing Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 2
- 230000006399 behavior Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000002950 deficient Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
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
- G06F11/3604—Software analysis for verifying properties of programs
- G06F11/3608—Software analysis for verifying properties of programs using formal methods, e.g. model checking, abstract interpretation
Definitions
- the invention relates to a technique for reducing the number of false positives in a static analysis result by using a test method, and mainly uses a dynamic test technique combining symbol execution and specific execution to verify the result of the static analysis, and realizes the judgment and elimination of the false alarm in the static analysis result of the software. It belongs to the technical field of software engineering, software testing, software dynamic and static analysis. Background technique
- Static analysis techniques typically formalize different types of software defect detection processes into specific matching problems, that is, features or patterns that match a defect in the target analysis program. Because software defects often occur on specific control flow paths, most static analysis techniques are also path-sensitive, or paths that are suspected to be defective in the results of static analysis, so static analysis techniques can not be actually run. In the case of a program, potential defects in the program are discovered, thereby avoiding additional runtime overhead. Based on the above characteristics, static analysis technology has been widely recognized in both research and industry. However, static analysis tools may sacrifice accuracy for better scalability, resulting in inaccurate modeling of many important program attributes, such as heap memory cells.
- the software testing technology actually executes the program to be tested, and it can confirm whether the software defect occurs at runtime.
- a test case that actually triggers a defect and its execution time information will be an effective way to confirm a static analysis alert.
- the results of the software test can help confirm the correctness of the static analysis results and eliminate false positives.
- Software testing requires a sufficient and high-quality set of test cases. There are many ways to generate program test inputs. Specific execution and symbolic execution are important techniques.
- Hybrid execution techniques are techniques that combine symbolic execution with specific implementation.
- the specific implementation is to use the specific variable value input into the program, the execution of the driver.
- Symbolic execution refers to the use of symbolic variables instead of specific variables. According to the relationship between variables in the program and the control flow, the symbolic expressions and symbol constraints are obtained, thereby symbolizing the program execution state. Use together.
- Hybrid execution technology is a kind of simultaneous Hybrid program testing techniques for specific execution and symbolic execution. Summary of the invention
- the object of the present invention is to provide a static analysis false alarm elimination method based on test, confirm real software defects according to runtime information, eliminate false positives in static analysis results, enhance the usability of software static analysis technology, and reduce manual confirmation. And check the time and labor costs of static analysis reports.
- the present invention first reads and parses a software report containing defect information generated by a static analysis tool, and extracts information of the target defect, including a defect occurrence point reported by the static analysis tool and a program path that may cause the defect; Static analysis alarms for specific defects, using the idea of mixed execution to perform continuous execution, symbol execution, and constraint solving.
- the runtime information is collected until the stop condition is met.
- the process use the runtime information obtained in the previous step to confirm whether the defect occurs, or to determine whether the static analysis alarm is a false alarm; iteratively perform the above steps until all static analysis alarms are processed.
- test-based static analysis false positive elimination method includes the following steps:
- Step 1 Read the static analysis result report.
- a static analysis report file saved in a metadata exchange format based on the Extensible Markup Language is read from the disk file.
- Step 2 Parse the read static analysis report to obtain a list of alarms to be verified.
- the static analysis alarm information is parsed from the static analysis report, including the suspected defect path and the specific defect occurrence point, forming a list of alarms to be verified.
- the program insertion instrument is used to insert a markup statement in the program source code, and the program statement inserted into the program is compiled and linked to the original program in synchronization with the original program.
- the work of inserting the markup statement includes:
- the instrumentation marks the memory allocation, string copy and other specific defect feature statements, collect information at runtime, and help determine whether the defect occurs.
- the program is inserted or inserted to insert an additional markup statement (called a probe) in the program on the basis of ensuring the original logical integrity of the program under test, and the feature data of the program operation is thrown by the execution of the probe.
- a probe an additional markup statement
- Targeting the path segment of the static analysis alert inserted in the program source code it is possible to calculate on the control flow graph whether each branch in the program may reach the tag path segment when it is executed.
- the control flow graph is a directed graph, and each statement in the program source code corresponds to a node in the graph, and the path between the nodes in the graph represents a control relationship between the program codes.
- the reachability analysis is an intuitive control flow graph traversal and calculation process, which can be realized by combining the control flow calculation in the process with the call graph between the processes.
- Step 5 Generate a test case using the hybrid execution test method and test the program.
- Step 51 Perform an implementation with an initial input, collecting symbolic expressions and symbol constraints in the first execution.
- Step 52 According to the branch points in the collected symbol constraints, a constraint combination on the current execution path is formed, and the specific value set satisfying all the constraints is executed according to the program path.
- Step 53 Collect program information related to a specific defect at runtime.
- Step 54 Inversely solve the constraints in the collected constraint set one by one.
- Step 55 In each round of execution or before the end of the execution, it is judged whether the current execution is overwritten to the target path segment. If a suspected defect path is executed, a temporary result is generated that triggers the runtime defect, and the result set will be used to finalize whether the static analysis alert is a true defect or false positive.
- Step 56 Using the new value obtained by the constraint solving as a new input, repeat the process of step 51) until the mixed execution stop condition is satisfied, or the upper bound of the number of test execution iterations is reached.
- the hybrid execution test method is a test method combining symbol execution and specific execution; symbol execution refers to a technique of using a symbol variable instead of a specific variable, and performing simulation test execution without performing a program.
- the technique is generally used together with the constraint satisfaction problem solving method; the specific execution means that the specific variable value is input into the program, and the normal execution of the driver is tested; the hybrid execution is a mixture of specific execution and symbolic execution of the program alternately.
- Step 6 Determine whether the static analysis alarm of the specific defect is a confirmed defect according to the result set recorded in each of the test executions covering the target path segment, and if not, consider it to be a false alarm. Report the above confirmation/false positives to eliminate the results.
- Step 7 Static test alerts that are executed cannot always be overwritten for test execution, classified as a type of alert that cannot be determined, and alerted to the developer or tester for manual processing.
- the test-based static analysis false alarm elimination method of the present invention realizes the analysis of the static analysis result report, collects and confirms the defect characteristics of the static analysis report during the test run, and eliminates the static analysis alarm error report.
- the method of the present invention has the following beneficial effects:
- test-based static analysis false alarm elimination method by collecting program information and defect characteristic information related to static analysis alarms at runtime, the test technique is used to continuously cover the suspected path segments of the static analysis alarm and The location of the target defect, thereby confirming whether a specific defect of the static analysis alarm actually occurs during operation or at the end of the run, and eliminating the false alarm, reducing the workload and time cost of manually processing the static analysis report.
- Figure 1 is a flow chart of a method for static analysis of false positives based on testing. detailed description
- a static analysis report file saved in an extensible markup language based metadata exchange format is obtained from a disk file.
- Data format based on Extensible Markup Language already has mature information search methods and query language, but different defects need to query different information in static analysis report, and the data format generated by different static analysis tools is not uniform. Knowledge of the report data format generated by the static analysis tools used, and Write a simple defect information finder to get a static analysis alert.
- the information parsed in the static analysis report should include, but is not limited to, suspected defect paths and defect occurrence points.
- Other information related to the defects are organized together as an alarm list.
- a static analysis alarm for memory leaks can be organized. It is a triple ⁇ & ⁇ >, where a represents the allocation location of the suspected leaked memory, p is the suspected defect path, and e is the suspected leak point.
- a buffer overflow alert can be organized as a triple ⁇ p, e, len>, where p is the suspected defect path, e is the static analysis giving the statement that caused the buffer overflow, and len is the length of the buffer that could cause the overflow.
- the program inserting technique is used to insert the required statement in the program source code, and the program statement inserted into the program is synchronously compiled with the original program and linked into an executable program.
- the main steps of the program insertion are:
- Program insertion 1 sequentially reads the alarm information of the list to be verified, and inserts the suspect path segment in each alarm information, that is, inserts the branch statement in the path segment into the correct position in the program;
- the instrumentation information collection statement such as memory allocation operation, string copy operation, etc.
- the instrumentation information collection statement should be inserted after the corresponding statement to collect information, so as to collect information during operation, to help determine whether the defect is occur.
- the main steps are:
- (reachability analysis 2) Invert the source code control flow graph, that is, the node is unchanged, the edge of the graph points to reverse, and the graph G' is obtained; (reachability analysis 3) on the inverse control flow graph G', A suspected path segment of a static analysis alert is used as a starting point to traverse G';
- Hybrid execution is a combination of specific execution and symbolic execution.
- specific execution is implemented when the program is executed, and symbol execution is performed synchronously by the symbol execution operation of the instrumentation in the preprocessing.
- the depth-first traversal strategy is: when the conditional constraint is negated, the condition of the top of the path condition stack is sequentially selected to be inverted, and the strategy continuously traverses all the encountered branches, and the static analysis alarm is already present.
- the path-guided traversal strategy can be further optimized. Use the hybrid execution test method to generate test cases and eliminate false positives:
- the mixed execution test performs a specific execution with an initial input, thereby collecting symbolic expressions and symbol constraints in the first execution.
- (Remove the false positive step 3) Collect program information related to a specific defect during specific execution. For example, for a buffer overflow defect, it is necessary to collect buffer information in the runtime program, including the size of the buffer, current usage, and the like; For memory allocation and release operations, collect the success of the allocation, the size and address of the memory unit, and so on.
- Step 5 Determine whether the current execution covers the target path segment during each round of execution or before the end of execution. If a suspected defect path is reached, a temporary result is generated that triggers the runtime defect, and the result set will be used to finalize whether the static analysis alert is a true defect or false positive.
Abstract
本发明给出一种基于测试的静态分析误报消除方法，能够增强软件静态分析技术的可用性，降低人工确认和检查静态分析报告的时间和人力成本。利用测试技术来在运行时收集程序信息，与静态分析报告中涉及的目标路径和目标缺陷相互印证，确认缺陷或消除误报。本发明首先读取以基于可扩展标记语言的元数据交换格式保存的静态分析报告文件，从中解析出目标缺陷的信息；对每一条特定缺陷的静态分析警报，采用混合执行的思想对程序进行持续的具体执行、符号执行以及约束求解，在这一过程中根据不同缺陷的特征建模，收集运行时信息；使用上一步获取的运行时信息确认是否发生该缺陷，或判断该静态分析警报是一个误报；迭代直到所有静态分析警报被处理完毕。
Description
技术领域
本发明涉及利用测试方法削减静态分析结果中误报数目的技术， 主要利用符号执行 和具体执行相结合的动态测试技术验证静态分析的结果， 实现对软件静态分析结果中误 报的判断和消除， 属于软件工程、 软件测试、 软件动静态分析相结合的技术领域。 背景技术
静态分析与动态分析技术都被用于在 C/C++程序中发现程序缺陷。 静态分析技术通 常将不同类型的软件缺陷检测过程形式化为特定的匹配问题， 即在目标分析程序中匹配 某种缺陷的特征或模式。 因为软件缺陷常常在特定的控制流路径上发生， 大部分的静态 分析技术同时也是路径敏感的， 或在静态分析的结果中会给出疑似发生缺陷的路径， 所 以静态分析技术能在不实际运行程序的情况下发现程序中的潜在缺陷， 从而避免额外的 运行时开销。 基于以上特性， 静态分析技术在研究界和工业界中都广受重视。 然而， 静 态分析工具可能会牺牲精确性以获得更好的扩展性， 从而导致对许多重要的程序属性建 模并不准确， 比如堆内存单元等。 另外， 由于缺少运行时信息， 静态分析工具常常报告 出大量的未经确认的警报， 而真实的内存泄漏隐藏其中。 这严重限制了实际开发中静态 分析工具的可用性， 即使是一款成熟的商用静态分析工具， 也可能在分析中等规模的程 序时报告较多的警报。 人工检查所有这些警报并从中找到真实的缺陷是一项艰巨、 沉闷 和耗时耗力的工作。
软件测试技术实际执行待测程序， 可以在运行时确认软件缺陷是否发生。 实际触发 缺陷的一个测试用例及其执行时信息将是确认静态分析警报的有效方式。 软件测试的结 果可以帮助确认静态分析结果的正确性， 从而消除其中的误报。 软件测试需要充分和高 质量的测试用例集， 生成程序测试输入的方法有很多， 具体执行和符号执行是其中重要 的技术。
混合执行技术是符号执行和具体执行结合的技术。 具体执行就是使用具体的变量值 输入到程序中， 驱动程序的执行。 符号执行指的是使用符号变量代替具体变量， 根据程 序中的变量之间相互关系及控制流， 得到符号表达式和符号约束条件， 从而将程序执行 状态符号化； 其通常与约束满足问题求解方法一同使用。 混合执行技术是一种对同时进
行具体执行和符号执行的混合程序测试技术。 发明内容
技术问题： 软件静态分析技术可以在开发早期阶段发现软件缺陷， 因而被广泛使用， 但由于静态分析结果中包含不同数量的误报， 从而降低了静态分析在实际中的可用性。 本发明的目的是提供一种基于测试的静态分析误报消除方法， 根据运行时的信息确认真 实的软件缺陷， 并消除静态分析结果中的误报， 增强软件静态分析技术的可用性， 降低 人工确认和检查静态分析报告的时间和人力成本。
技术方案： 本发明首先读取并解析静态分析工具产生的包含缺陷信息的软件报告， 从中抽取出目标缺陷的信息， 包括静态分析工具报告的缺陷发生点和可能导致缺陷的程 序路径； 对每一条特定缺陷的静态分析警报， 采用混合执行的思想对程序进行持续的具 体执行、 符号执行以及约束求解， 在这一过程中根据不同缺陷的特征建模， 收集运行时 信息， 直到停止条件满足时结束该过程； 使用上一步获取到的运行时信息确认是否发生 该缺陷， 或判断该静态分析警报是否是一个误报； 迭代执行以上步骤直到所有静态分析 警报被处理完毕。
基于测试的静态分析误报消除方法包括以下步骤：
步骤 1 : 读取静态分析结果报告。
从磁盘文件读取以基于可扩展标记语言的元数据交换格式保存的静态分析报告文 件。
步骤 2: 对读入的静态分析报告进行解析， 得到待验证警报列表。
分别从静态分析报告中解析出静态分析警报信息， 包括疑似缺陷路径和特定缺陷发 生点， 形成待验证警报列表。
步骤 3: 程序插桩
采用程序插桩技术在程序源代码中插入标记语句， 程序插桩插入的程序语句与原程 序同步编译、 链接为可执行程序。
所述插入标记语句的工作包括：
①将待验证警报列表中的警报信息标记于源代码中， 也就是标记静态分析警报的路 径片段中的分支语句和缺陷相关语句， 在其前 /后插入标记语句， 为后续步骤中计算路径 片段可达性和运行时标记路径服务。
②插桩标记符号变量和符号表达式、 约束条件， 为混合执行中的符号执行服务；
③根据不同的缺陷特征， 插桩标记内存分配， 字符串拷贝等特定缺陷的特征语句， 以运行时收集信息， 辅助判断缺陷是否发生。
所述程序插桩或者插桩是在保证被测程序原有逻辑完整性的基础上在程序中插入额 外的标记语句 （称为探针）， 通过探针的执行并抛出程序运行的特征数据， 通过对这些数 据的分析， 获得程序的控制流和数据流信息， 得到逻辑覆盖等动态信息， 实现测试。
步骤 4: 可达性分析
以在程序源代码中插入的静态分析警报的路径片段为目标， 在控制流图上计算程序 中每一个分支在执行时是否可能到达标记路径片段。
所述控制流图是一个有向图， 程序源代码中的每个语句对应图中的一个节点， 图中 节点之间的路径表示程序代码之间的控制关系。
所述可达性分析是一个直观的控制流图遍历和计算过程， 将过程内的控制流计算与 过程间的调用图结合即可实现。
步骤 5: 利用混合执行测试方法生成测试用例， 对程序进行测试。
利用混合执行测试方法生成测试用例， 在运行时验证静态分析警报是否是误报， 具 体处理过程如下：
步骤 51 ) 以一个初始输入做具体执行， 在第一次执行中收集符号表达式和符号约束 条件。
步骤 52) 根据收集到的符号约束条件中的分支点， 形成对当前执行路径的一个约束 组合， 满足所有这些约束条件的具体值集合按照此程序路径执行。
步骤 53) 在运行时收集与特定缺陷相关的程序信息。
步骤 54) 对收集到的约束条件集合中的约束条件逐一取反求解。
步骤 55) 在每一轮执行中或执行结束前， 判断是否当前执行覆盖到目标路径片段。 如果执行到疑似缺陷路径， 则生成此次运行时缺陷是否触发的一个临时结果， 此结果的 集合将用于最终确定静态分析警报是否是一个真实的缺陷或误报。
步骤 56)利用约束求解得到的新值作为新的输入， 重复步骤 51 ) 的过程， 直到满足 混合执行停止条件， 或达到测试执行迭代次数的上界。
所述混合执行测试方法是符号执行和具体执行结合的测试方法； 符号执行指的是使 用符号变量代替具体变量， 不执行程序的前提下模拟程序执行来进行相关测试分析的技
术， 一般与约束满足问题求解方法一同使用； 具体执行就是指使用具体的变量值输入到 程序中， 驱动程序的正常执行进行测试； 混合执行是一种对程序交替进行具体执行和符 号执行的混合软件程序测试技术。
步骤 6:根据测试执行中每一覆盖到目标路径片段时记录的结果集合，判断特定缺陷 的静态分析警报是否是一个得到确认的缺陷， 如果不是， 认为其是误报。 报告上述确认 / 误报消除结果。
步骤 7:对于测试执行始终无法覆盖执行到的静态分析警报，将其归为一类无法确定 的警报， 并提醒开发者或测试人员人工处理。
有益效果： 本发明所述的基于测试的静态分析误报消除方法实现了对静态分析结果 报告的解析， 对静态分析报告的缺陷特征在测试运行时加以收集和确认， 并消除静态分 析警报中的错误报告。 具体来说， 本发明所述的方法具有如下的有益效果：
( 1 ) 本发明所述的基于测试的静态分析误报消除方法中，通过在运行时收集与静态 分析警报相关的程序信息和缺陷特征信息， 利用测试技术不断覆盖静态分析警报的疑似 路径片段和目标缺陷位置， 从而在运行中或运行结束时确认静态分析警报的特定缺陷是 否真实发生， 并消除错误的警报， 降低了人工处理静态分析报告的工作量和时间成本。
(2) 结合了可达性分析和混合执行测试，形成了一套对静态分析报告的解析、插桩、 动态分析技术和结果分类系统， 通过对不同特征的软件缺陷建模， 将可以适用于消除不 同类型缺陷的静态分析报告。 附图说明
图 1是基于测试的静态分析误报消除方法流程图。 具体实施方式
下面对本发明的具体实施方式作更详细的描述。
一. 读取与解析静态分析结果报告
在具体实施中， 从磁盘文件获取以基于可扩展标记语言的元数据交换格式保存的静 态分析报告文件。 基于可扩展标记语言的数据格式已经有成熟的信息查找方法及查询语 言， 但不同缺陷需要在静态分析报告中查询不同的信息， 而不同的静态分析工具产生的 数据格式也并不统一， 需要对应地了解使用的静态分析工具生成的报告数据格式， 并编
写简单的缺陷信息查找程序获取静态分析警报。
要得到待验证的静态分析警报列表， 需要在读取静态分析报告同时做特定于缺陷类 型的数据处理和组织。 静态分析报告中解析出的信息， 应该包括并不限于疑似缺陷路径 和缺陷发生点， 对于特定的缺陷类型， 与缺陷相关的其他信息一起组织为警报列表， 比 如内存泄漏的一条静态分析警报可以组织为三元组<&^^>，其中 a表示疑似泄漏内存的 分配位置， p为疑似缺陷路径， e为疑似泄漏点。 一条缓冲区溢出警报可以组织为三元组 <p, e, len>, 其中 p为疑似缺陷路径， e为静态分析给出导致缓冲区溢出的语句， len为可 能导致溢出的缓冲区长度。
二. 程序源代码预处理
在具体实施中， 对程序的源代码做两项预处理工作： 程序插桩和控制流图可达性分 析
在具体实施中， 采用程序插桩技术在程序源代码中插入需要的语句， 程序插桩插入 的程序语句与原程序同步编译、 链接为可执行程序， 程序插桩的主要步骤为：
(程序插桩 1 )依次读取待验证列表的警报信息，对每条警报信息中的疑似路径片段 做插桩， 即将路径片段中的分支语句插入程序中的正确位置；
(程序插桩 2)对每条警报信息中的缺陷相关语句插桩，插桩的语句应该包含缺陷相 关的信息， 如内存分配位置或缓冲区溢出长度等；
(程序插桩 3 )根据程序语法插桩行为语句，以在运行时收集符号变量和符号表达式、 约束条件等；
(程序插桩 4)根据不同的缺陷特征， 插桩信息收集语句， 如内存分配操作， 字符串 拷贝操作等， 应在对应语句后插桩信息收集操作， 以便运行时收集信息， 辅助判断缺陷 是否发生。
在具体实施中， 控制流图上的可达性分析计算程序中每一个分支在执行时是否可能 到达标记路径片段， 主要步骤为：
(可达性分析 1 ) 计算源代码控制流图 G并存储；
(可达性分析 2)对源代码控制流图求反，即节点不变，图的边指向反转，得到图 G' ; (可达性分析 3 ) 在反控制流图 G'上， 以一条静态分析警报的疑似路径片段作为起 点， 对 G'做遍历；
(可达性分析 4) 在遍历过程中， 每到达一个 G的分支路径， 标记该分支路径为到
当前警报的路径片段可达；
(可达性分析 5) 不断重复 （可达性分析 3) 和 （可达性分析 4) 知道所有警报的路 径片段都完成可达性分析；
三. 采用路径指导策略的混合执行测试消除误报
混合执行是具体执行、 符号执行两种执行操作相结合的一种方法。 在具体实施中， 程序执行时即实现了具体执行，而符号执行通过预处理中插桩的符号执行操作同步进行。
在具体实施中， 深度优先的遍历策略是在对条件约束进行取反时， 依次选取路径条 件栈栈顶的条件出来进行取反， 该策略不断遍历所有遇到的分支， 在已有静态分析警报 和控制流图的可达性分析条件下， 可以进一步优化为路径指导的遍历策略。 利用混合执 行测试方法生成测试用例， 消除误报的步骤：
(消除误报步骤 1 )混合执行测试以一个初始输入做具体执行，从而在第一次执行中 收集到符号表达式和符号约束条件。
(消除误报步骤 2)根据收集到的分支点符号条件，可以形成对当前执行路径的一个 约束集合， 满足所有这些约束条件的具体值集合按照此程序路径执行。
(消除误报步骤 3)在具体执行时收集与特定缺陷相关的程序信息， 例如， 对于缓冲 区溢出缺陷， 需要收集运行时程序中的缓冲区信息， 包括缓冲区的大小， 当前使用情况 等； 对于内存分配和释放操作， 收集分配是否成功， 内存单元的大小和地址等。
(消除误报步骤 4)采用路径指导的遍历策略，根据预处理步骤中的控制流图可达性 分析， 在收集到的路径约束条件集合中， 选择到静态分析警报路径片段可达性最优的路 径分支， 进行取反求解。 由于避免了对所有分支取反求解， 减少了需要遍历的程序路径 空间。
(消除误报步骤 5)在每一轮执行中或执行结束前，判断当前执行是否覆盖到目标路 径片段。 如果执行到了疑似缺陷路径， 则生成此次运行时缺陷是否触发的一个临时结果， 此结果的集合将用于最终确定静态分析警报是否是一个真实的缺陷或误报。
(消除误报步骤 6)利用约束求解得到的新值作为新的输入，重复（消除误报步骤 1 ) 至（消除误报步骤 6)的过程， 直到满足混合执行停止条件， 或达到测试执行迭代次数的 上界。
(消除误报步骤 7)根据测试执行中每一覆盖到目标路径片段的结果集合，确认特定 缺陷是否发生， 如果覆盖到警报路径的结果集合中全部没有出发特定缺陷， 认为其是误
报。 报告上述消除结果。
(消除误报步骤 8)对于测试执行始终无法覆盖执行到的静态分析警报，将其归为 类无法确定的警报， 并提醒开发者或测试人员人工处理。
Claims
1. 一种基于测试的静态分析误报消除方法， 其特征在于该方法所包含的步骤为： 步骤 1 ) 从磁盘文件读取以基于可扩展标记语言的元数据交换格式保存的静态分析报 告文件，
步骤 2) 分别从静态分析报告中解析出静态分析警报信息， 包括疑似缺陷路径和特 定缺陷发生点， 形成待验证警报列表，
步骤 3) 采用程序插桩技术在程序源代码中插入标记语句， 程序插桩插入的程序语句 与原程序同步编译、 链接为可执行程序； 所述程序插桩或者插桩是在保证被测程序原有 逻辑完整性的基础上在程序中插入额外的标记语句， 称为探针， 通过探针的执行并抛出 程序运行的特征数据， 通过对这些数据的分析， 获得程序的控制流和数据流信息， 得到 逻辑覆盖等动态信息， 实现测试，
步骤 4) 以在程序源代码中插入的静态分析警报的路径片段为目标， 在控制流图上计 算程序中每一个分支在执行时是否可能到达标记路径片段， 所述控制流图是一个有向 图， 程序源代码中的每个语句对应图中的一个节点， 图中节点之间的路径表示程序代码 之间的控制关系，
步骤 5) 利用混合执行测试方法生成测试用例， 在运行时验证静态分析警报是否是误 报， 所述混合执行测试方法是符号执行和具体执行结合的测试方法； 符号执行指的是使 用符号变量代替具体变量， 不执行程序的前提下模拟程序执行来进行相关测试分析的技 术， 与约束满足问题求解方法一同使用； 具体执行就是指使用具体的变量值输入到程序 中， 驱动程序的正常执行进行测试； 混合执行是一种对程序交替进行具体执行和符号执 行的混合软件程序测试技术，
步骤 6: 根据测试执行中每一覆盖到目标路径片段时记录的结果集合， 判断特定缺陷 的静态分析警报是否是一个得到确认的缺陷， 如果不是， 认为其是误报， 报告上述确认 / 误报消除结果，
步骤 7: 对于测试执行始终无法覆盖执行到的静态分析警报， 将其归为一类无法确定 的警报， 并提醒开发者或测试人员人工处理。
2. 根据权利要求 1 所述的基于测试的静态分析误报消除方法， 其特征在于， 所述的 利用混合执行测试方法生成测试用例， 在运行时验证静态分析警报是否是误报， 具体处 理过程如下：
步骤 51 ) 以一个初始输入做具体执行， 在第一次执行中收集符号表达式和符号约束
条件，
步骤 52) 根据收集到的符号约束条件中的分支点， 形成对当前执行路径的一个约束 组合， 满足所有这些约束条件的具体值集合按照此程序路径执行，
步骤 53) 在运行时收集与特定缺陷相关的程序信息，
步骤 54) 对收集到的约束条件集合中的约束条件逐一取反求解，
步骤 55 ) 在每一轮执行中或执行结束前， 判断是否当前执行覆盖到目标路径片段； 如果执行到疑似缺陷路径， 则生成此次运行时缺陷是否触发的一个临时结果， 此结果的 集合将用于最终确定静态分析警报是否是一个真实的缺陷或误报，
步骤 56) 利用约束求解得到的新值作为新的输入， 重复步骤 51 ) 的过程， 直到满足 混合执行停止条件， 或达到测试执行迭代次数的上界。
3. 根据权利要求 1所述的基于测试的静态分析误报消除方法， 其特征在于， 所述插入标记语句的工作包括：
①将待验证警报列表中的警报信息标记于源代码中， 也就是标记静态分析警报的路 径片段中的分支语句和缺陷相关语句， 在其前 /后插入标记语句， 为后续步骤中计算路径 片段可达性和运行时标记路径服务，
②插桩标记符号变量和符号表达式、 约束条件， 为混合执行中的符号执行服务，
③根据不同的缺陷特征， 插桩标记内存分配， 字符串拷贝等特定缺陷的特征语句， 以运行时收集信息， 辅助判断缺陷是否发生。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310165634.8A CN103294594B (zh) | 2013-05-08 | 2013-05-08 | 一种基于测试的静态分析误报消除方法 |
| CN201310165634.8 | 2013-05-08 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2014180107A1 true WO2014180107A1 (zh) | 2014-11-13 |
Family
ID=49095512
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2013/086993 WO2014180107A1 (zh) | 2013-05-08 | 2013-11-13 | 一种基于测试的静态分析误报消除方法 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN103294594B (zh) |
| WO (1) | WO2014180107A1 (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10002064B2 (en) | 2015-09-15 | 2018-06-19 | Tata Consultancy Services Limited | Static analysis based efficient elimination of false positive |
| EP3770766A1 (de) * | 2019-07-25 | 2021-01-27 | Robert Bosch GmbH | Verfahren zum testen eines systems |
| US11314632B2 (en) | 2020-05-19 | 2022-04-26 | Tata Consultancy Services Limited | Method and system for identification and elimination of false positives from delta alarms |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103294594B (zh) * | 2013-05-08 | 2016-01-06 | 南京大学 | 一种基于测试的静态分析误报消除方法 |
| CN106033394B (zh) * | 2015-03-13 | 2019-05-17 | 北京奇虎测腾科技有限公司 | 软件源代码的分析方法及装置 |
| CN105808369B (zh) * | 2016-03-29 | 2018-11-23 | 北京系统工程研究所 | 一种基于符号执行的内存泄漏检测方法 |
| EP3285171B1 (en) | 2016-08-11 | 2021-11-24 | Tata Consultancy Services Limited | System and method for cause point analysis for effective handling of static analysis alarms |
| CN108446213B (zh) * | 2017-02-15 | 2021-08-17 | 西门子公司 | 一种静态代码质量分析方法和装置 |
| CN108897678B (zh) * | 2018-06-20 | 2021-10-15 | 中国联合网络通信集团有限公司 | 静态代码检测方法和静态代码检测系统、存储设备 |
| CN109726131B (zh) * | 2019-01-03 | 2022-04-01 | 中国联合网络通信集团有限公司 | 缺陷检测方法及缺陷检测装置 |
| CN109710538B (zh) * | 2019-01-17 | 2021-05-28 | 南京大学 | 一种用于大规模系统中状态相关缺陷的静态检测方法 |
| CN110175123A (zh) * | 2019-05-22 | 2019-08-27 | 中国石油大学(华东) | 一种基于符号表达式静态缺陷警报关联识别方法 |
| CN110515857A (zh) * | 2019-09-02 | 2019-11-29 | 华东师范大学 | 一种基于动态符号执行的测试用例生成方法 |
| CN110515856B (zh) * | 2019-09-02 | 2021-01-29 | 华东师范大学 | 一种基于动态符号执行的测试用例生成系统 |
| CN111475196B (zh) * | 2020-03-30 | 2023-12-12 | 杭州迪普信息技术有限公司 | 编译告警溯源方法、装置、电子设备及计算机可读介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102323906A (zh) * | 2011-09-08 | 2012-01-18 | 哈尔滨工程大学 | 一种基于遗传算法的mc/dc测试数据自动生成方法 |
| CN102819490A (zh) * | 2012-07-20 | 2012-12-12 | 北京邮电大学 | 一种基于给定缺陷描述信息进行软件测试的方法及系统 |
| CN103294594A (zh) * | 2013-05-08 | 2013-09-11 | 南京大学 | 一种基于测试的静态分析误报消除方法 |
-
2013
- 2013-05-08 CN CN201310165634.8A patent/CN103294594B/zh active Active
- 2013-11-13 WO PCT/CN2013/086993 patent/WO2014180107A1/zh active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102323906A (zh) * | 2011-09-08 | 2012-01-18 | 哈尔滨工程大学 | 一种基于遗传算法的mc/dc测试数据自动生成方法 |
| CN102819490A (zh) * | 2012-07-20 | 2012-12-12 | 北京邮电大学 | 一种基于给定缺陷描述信息进行软件测试的方法及系统 |
| CN103294594A (zh) * | 2013-05-08 | 2013-09-11 | 南京大学 | 一种基于测试的静态分析误报消除方法 |
Non-Patent Citations (2)
| Title |
|---|
| CUI ZHAN-QI: "Target-Directed Concolic Testing", CHINESE JOURNAL OF COMPUTERS, vol. 34, no. 6, June 2011 (2011-06-01), pages 953 - 964 * |
| YU LI-QIAN: "Combined Static and Dynamic Immutability Analysis of Java Program", CHINESE JOURNAL OF COMPUTERS, vol. 33, no. 4, April 2010 (2010-04-01), pages 736 - 745 * |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10002064B2 (en) | 2015-09-15 | 2018-06-19 | Tata Consultancy Services Limited | Static analysis based efficient elimination of false positive |
| EP3770766A1 (de) * | 2019-07-25 | 2021-01-27 | Robert Bosch GmbH | Verfahren zum testen eines systems |
| US11669438B2 (en) | 2019-07-25 | 2023-06-06 | Robert Bosch Gmbh | Method for testing a system |
| US11314632B2 (en) | 2020-05-19 | 2022-04-26 | Tata Consultancy Services Limited | Method and system for identification and elimination of false positives from delta alarms |
Also Published As
| Publication number | Publication date |
|---|---|
| CN103294594B (zh) | 2016-01-06 |
| CN103294594A (zh) | 2013-09-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2014180107A1 (zh) | 一种基于测试的静态分析误报消除方法 | |
| US7958400B2 (en) | Detecting unexpected impact of software changes using coverage analysis | |
| US7971193B2 (en) | Methods for performining cross module context-sensitive security analysis | |
| CN104536883B (zh) | 一种静态缺陷检测方法及其系统 | |
| US8645761B2 (en) | Precise fault localization | |
| US8209658B2 (en) | Method of creating signatures for classifying program failures | |
| KR20060045568A (ko) | 프로그램 계측 동안의 프로브 최적화 방법 및 시스템 | |
| US20090241096A1 (en) | Dynamic Software Tracing | |
| CN112035359A (zh) | 程序测试方法、装置、电子设备及存储介质 | |
| Eldh et al. | A framework for comparing efficiency, effectiveness and applicability of software testing techniques | |
| JP2019096292A (ja) | 自動化されたソフトウェアプログラム修復候補の選択 | |
| Xu et al. | Melton: a practical and precise memory leak detection tool for C programs | |
| Zhang et al. | Is non-parametric hypothesis testing model robust for statistical fault localization? | |
| Kelly et al. | A case study on automated fuzz target generation for large codebases | |
| Kim et al. | Automated bug neighborhood analysis for identifying incomplete bug fixes | |
| CN104536878A (zh) | 一种验证并发程序中违反原子性错误是否被正确修复的方法 | |
| Backes et al. | The CASPA Tool: Causality-Based Abstraction for Security Protocol Analysis: Tool Paper | |
| CN114676061A (zh) | 一种基于知识图谱自动化固件检测方法 | |
| Ding et al. | Detecting infeasible branches based on code patterns | |
| CN113326193A (zh) | 一种小程序测试方法及装置 | |
| CN103150254B (zh) | 基于状态依赖概率建模的软件错误定位方法 | |
| Ibrahim et al. | Finite State Machine-Model Based Testing on Website Application | |
| Jiang et al. | Program flow graph oriented analysis of coverage and time performance | |
| Wu et al. | Mantra: Mutation Testing of Hardware Design Code Based on Real Bugs | |
| CN117520199B (zh) | 基于静态符号执行的数值软件缺陷检测方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 13884229 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| WA | Withdrawal of international application | ||
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 13884229 Country of ref document: EP Kind code of ref document: A1 |