一句话:评估双切片在回归故障排查中的适用性,并提出 INPRESS 压缩切片中的传播代码。
论文针对回归失败排查这一耗时任务,研究程序切片尤其是 dual slicing 在实际故障定位中的适用性。作者在 Defects4J 基准以及自建的 LibRench(八个大型开源客户端-库项目对,均含库升级失败)上进行实验,发现切片虽能缩小人工检查范围,但仍过大,且多数语句处理变更代码块之间的信息传播;这些语句提供必要上下文,却不直接导致失败。为此,作者提出 INPRESS,自动识别并摘要传播相关代码块,从而进一步缩小切片。评估表明,INPRESS 生成的切片平均比原始切片短 76%(平均 207 条 vs. 2,007 条执行语句),在保留必要上下文信息的同时减少了开发者需检查的信息量。
Numerous program slicing approaches aim to help developers troubleshoot regression failures - one of the most time-consuming development tasks. The main idea behind these approaches is to identify a subset of interdependent program statements relevant to the failure, minimizing the amount of code developers need to inspect. Accuracy and reduction rate achieved by slicing are the key considerations toward their applicability in practice: inspecting only the statements in a slice should be faster and more efficient than inspecting the code in full. In this paper, we report on our experiment applying one of the most recent and accurate slicing approaches, dual slicing, to the task of troubleshooting regression failures. As subjects, we use projects from the popular Defects4J benchmark and a systematically-collected set of eight large, open-source client-library project pairs with at least one library upgrade failure, which we refer to as LibRench. The results of our experiments show that the produced slices, while effective in reducing the scope of manual inspection, are still very large to be comfortably analyzed by a human. When inspecting these slices, we observe that most statements in a slice deal with the propagation of information between changed code blocks; these statements are essential for obtaining the necessary context for the changes but are not responsible for the failure directly. Motivated by this insight, we propose a novel approach, implemented in a tool named INPRESS, for further reducing the size of a slice by accurately identifying and summarizing the propagation-related code blocks. Our evaluation of INPRESS shows that it is able to produce slices that are 76% shorter than the original ones (207 vs. 2,007 execution statements, on average), thus, reducing the amount of information developers need to inspect without losing the necessary contextual information.