Understanding Bugs in Multi-Language Deep Learning Frameworks
Central China Normal University（华中师范大学）；Wuhan University（武汉大学）
深度学习框架（DLF）在这个智能时代扮演着越来越重要的角色，因为它们是越来越广泛的基于AI的应用程序的基础设施。同时，作为多编程语言（MPL）软件系统，DLF不可避免地遭受由使用多个程序设计语言（PL）引起的错误。因此，了解错误（特别是涉及多个PL的错误，即，MPL缺陷），为DLF开发过程中缺陷的预防、检测和解决提供了依据。为此，我们手动分析了三个MPL DLF（即MXNet、PyTorch和TensorFlow）中的1497个bug。首先，我们将这些DLF中的错误分为12种类型（例如，算法设计错误和存储器错误）。其次，我们进一步探讨了不同类型的错误对DLF开发的影响，发现部署错误和内存错误在不同方面对DLF的开发产生了最大的负面影响。第三，我们发现MXNet、PyTorch和TensorFlow中分别有28.6%、31.4%和16.0%的bug是MPL bug; Python和C/C++的PL组合在修复所有DLF中超过92%的MPL bug时使用最多。最后，在所有三个DLF中，MPL错误修复的代码更改复杂性明显大于单一编程语言（SPL）错误修复，而在PyTorch中，MPL错误修复的开放时间更长，通信复杂性也比SPL错误修复更高。这些结果为DLF中的错误管理提供了见解。
2023-03-05 cs.LG cs.SE
CITADEL: Context Similarity Based Deep Learning Framework Bug Finding
针对深度学习框架测试工具覆盖缺陷类型有限且效率低的问题，提出基于上下文相似性的Citadel方法，自动生成带预言的测试用例，有效检测出PyTorch和TensorFlow上多个现有工具无法发现的性能缺陷，触发率显著提升。
2025-10-28 cs.SE
How Often Do Single-Statement Bugs Occur? The ManySStuBs4J Dataset
程序修复是软件工程中的一个重要而又困难的问题。实现可接受性能的一种方法是关注简单bug的类，例如具有单个语句修复的bug，或者匹配一小组bug模板的bug。然而，很难估计简单错误的修复技术的召回率，因为没有关于相关错误在代码中发生频率的数据集。为了填补这一空白，我们提供了一个数据集，其中包含从1,000个流行的开源Java项目中挖掘出来的153,652个单语句错误修复更改，并通过它们是否匹配16个错误模板中的任何一个进行了注释，这些模板的灵感来自最先进的程序修复技术。在最初的分析中，我们发现大约33%的简单错误修复与模板匹配，这表明相当数量的单语句错误可以用相对较小的模板集修复。此外，我们发现模板拟合错误的出现频率约为每1，600 - 2，500行代码中出现一个错误（以项目最新版本的大小衡量）。我们希望该数据集将证明为未来的工作在程序修复和经验软件工程的研究资源。
2020-04-10 cs.PL cs.SE
What Happens When We Fuzz? Investigating OSS-Fuzz Bug History
本研究通过分析 OSS-Fuzz 的 44,102 个历史缺陷，发现模糊测试能将缺陷中位未解决时间缩短至 2 天，有效帮助项目在发布前快速修复问题。
2023-05-19 cs.SE
Feature Slice Matching for Precise Bug Detection
Renmin University of China（中国人民大学）；Institute of Software, Chinese Academy of Sciences（中国科学院软件研究所）；University of Trento（特伦托大学）
本文提出MATUS方法，通过特征切片和端到端学习精准检测Bug，发现31个Linux内核未知Bug并获得验证。
2026-01-03 cs.SE
Advaita: Bug Duplicity Detection System
Cisco Systems, Inc（思科系统公司）
bug在软件开发中很普遍。为了提高软件质量，使用错误跟踪系统对错误进行归档。报告的bug的属性包括标题、描述、项目、产品、受bug影响的组件以及bug的严重性。根据产品成熟度、代码大小和项目工程师数量，重复错误率（重复错误的百分比）在个位数（1 - 9%）到两位数（40%）之间。在Eclipse、Firefox等开源项目中，重复的bug范围在9%到39%之间。这种重复检测有助于重复数据消除。检测重复的bug有助于减少分类工作，并为开发人员节省修复问题的时间。传统的自然语言处理技术在识别句子之间的相似性方面不太准确。使用缺陷跟踪系统中存在的缺陷数据，探索了各种方法，包括几种机器学习算法，以获得一种可行的方法，该方法可以识别重复的缺陷，给定一对句子（即，相应的缺陷描述）。该方法考虑多组特征，即基本文本统计特征、语义特征和上下文特征。这些特征从标题、描述和组件中提取，并且随后用于训练分类算法。
2020-01-24 cs.AI cs.SE
On The Relation Between Outdated Docker Containers, Severity Vulnerabilities and Bugs
将软件打包到容器中正在成为在云和其他环境中部署服务时的常见做法。Docker镜像是用于构建和部署容器的最流行的容器技术之一。容器映像通常包括软件包的集合，这些软件包可能具有影响容器健康的错误和安全漏洞。我们的目标是通过分析过时的容器和安装在其中的脆弱和错误的包之间的关系来支持容器部署者。我们使用容器的技术滞后的概念作为给定容器与最新容器之间的差异，该最新容器可能具有相同包集合的最新版本。对于7，380个基于Debian Linux发行版的官方和社区Docker镜像，我们确定其中安装了哪些软件包，并测量它们在版本更新、安全漏洞和错误方面的技术滞后。我们发现，没有一个版本是没有漏洞的，因此部署者即使部署了最新的软件包也无法避免漏洞。我们为容器开发人员提供了一些关于他们可以遵循的策略的经验教训，以尽量减少漏洞的数量。我们认为，Docker容器扫描和安全管理工具应该通过添加有关其他类型错误的数据来改进其平台，并包括技术滞后的测量，以便为部署人员提供何时更新的信息。
2018-11-30 cs.PL cs.SE
GitHub-OSS Fixit: Fixing bugs at scale in a Software Engineering Course
许多研究表明，将开源项目引入软件工程（SE）课程教学的好处。然而，现有的研究有几个局限性，限制了开源项目在课堂环境中的广泛适应，包括（1）所选择的项目仅限于一个特定的项目，（2）大多数研究只调查了它对教授特定SE概念的影响，以及（3）学生可能会在他们的贡献中犯错误，导致质量差的代码。与此同时，软件公司已经成功推出了Google Summer of Code（GSoC）和FindBugs“fixit”等项目，为开源项目做出贡献。受这些项目成功的启发，我们提出了GitHub-OSS Fixit，这是一个课程项目，通过修复GitHub中报告的错误，教导学生为开源Java项目做出贡献。我们描述了我们的课程大纲，通过鼓励使用几个自动化的程序分析工具来教授学生SE概念。我们还提供了精心设计的指导，供学生参与GitHub-OSS Fixit。由于所有的讲座和实验都是在线进行的，我们认为我们的课程设计可以帮助指导未来的在线SE课程。总体而言，我们的调查结果显示，学生认为GitHub-OSS Fixit可以帮助他们提高许多技能，并应用课堂上教授的知识。总共有154名学生向24个不同的Java项目提交了214个pull request，其中59个项目被合并，82个项目被开发人员关闭。
2021-02-14 cs.SE
Imitation Game: Reproducing Deep Learning Bugs Leveraging an Intelligent Agent
Dalhousie University（达尔豪斯大学）
RepGen通过智能代理和生成-验证-改进机制，提高了深度学习bug的重现率和效率。
2026-02-26 cs.AI cs.LG cs.SE
Metamorphic Coverage
The Chinese University of Hong Kong, Shenzhen（香港中文大学（深圳））；National University of Singapore（新加坡国立大学）
研究针对变质测试中代码覆盖不准确、变异测试成本高的问题，提出变质覆盖（MC）度量。在五种变质测试方法上评估MC，发现其与错误修复位置重叠度高，比行覆盖更敏感且耗时少，用于反馈指导时比代码覆盖能多发现错误，可广泛应用于评估和改进测试。
2026-07-17 cs.SE
MUZZ: Thread-aware Grey-box Fuzzing for Effective Bug Hunting in Multithreaded Programs
灰盒模糊测试由于其轻量级的测试工具、快速的覆盖反馈和动态调整策略，已经揭示了真实世界软件中成千上万的漏洞。然而，直接将灰盒模糊应用于依赖于输入的多线程程序可能效率极低。在实践中，多线程相关的错误通常隐藏在复杂的程序流中。同时，现有的灰盒模糊技术没有强调线程交织影响多线程程序的执行状态。因此，主流的灰盒模糊器不能有效地测试多线程程序中的问题段，尽管他们可能会获得高的代码覆盖率统计。为此，我们提出MUZZ，一个新的灰盒模糊技术，在多线程程序中的错误狩猎。MUZZ拥有三种新颖的线程感知插装，即面向覆盖插装、线程上下文插装和调度干预插装。在模糊化过程中，这些工具产生运行时反馈，以强调线程交织引起的执行状态。通过利用动态种子选择和执行策略中的反馈，MUZZ保留了更多有价值的种子，这些种子在多线程上下文中暴露了错误。我们在12个真实世界的软件程序上评估MUZZ。实验表明，MUZZ在多线程相关种子生成和并发漏洞检测方面优于AFL。此外，通过针对生成的种子重放目标程序，MUZZ还揭示了更多的并发错误（例如，数据竞争，线程泄漏）比AFL。MUZZ总共检测到8个新的并发漏洞和19个新的并发错误。在撰写本文时，已为报告的问题分配了4个CVE ID。
2020-07-31 cs.SE
Learning to Generate Corrective Patches using Neural Machine Translation
Bug修复通常是一项手工密集型任务。然而，最近的工作提出了自动程序修复的想法，其目的是修复（至少是一个子集）的错误，以不同的方式，如代码突变等以下在同一行的工作自动修复错误，在本文中，我们的目标是利用过去的修复，提出修复当前/未来的错误。具体来说，我们提出了棘轮，一个纠正补丁生成系统，使用神经机器翻译。通过使用神经序列到序列模型学习过去修复中相应的预校正和后校正代码，Ratchet能够为给定的容易出错的代码查询生成修复代码。我们进行了实证研究与五个开源项目，即Ambari，骆驼，Hadoop，Jetty和Wicket，评估棘轮的有效性。我们的研究结果表明，棘轮可以生成语法有效的语句98.7%的时间，并实现F1的措施之间的0.29 - 0.83的实际修复采用的代码库。此外，我们使用20名参与者进行定性验证，看看生成的语句是否有助于纠正错误。我们的调查显示，Ratchet的输出被认为在许多情况下有助于修复错误，即使修复不是100%正确。
2019-07-04 cs.SE
HyperPUT: Generating Synthetic Faulty Programs to Challenge Bug-Finding Tools
本文提出 HyperPUT，从种子缺陷出发通过增量程序变换自动生成可扩展规模的带缺陷 C 程序，用于多方面挑战现代缺陷发现工具并支持实证评估。
2024-02-02 cs.CR cs.SE
Locating Buggy Segments in Quantum Program Debugging
本文首次针对量子程序调试提出考虑程序段位置依赖测试成本及统计测试精度-成本权衡特性的缺陷定位方法，实验证明其能有效降低以量子门执行数衡量的定位成本。
2024-01-15 cs.SE
Categorizing Bugs with Social Networks: A Case Study on Four Open Source Software Communities
ETH Zurich（苏黎世联邦理工学院）
有效的错误分类过程是成功的协作软件工程项目的重要前提。对bug进行分类可能会成为一项艰巨的任务，特别是在开源软件（OSS）项目中，有大量缺乏经验的兼职贡献者。在本文中，我们提出了一个有效的和实用的方法来识别有效的错误报告，a）指的是一个实际的软件错误，b）不是重复的，c）包含足够的信息，立即处理。我们的分类是基于九个措施，以量化的社会嵌入的bug报告者在协作网络。我们证明了它的适用性的案例研究中，使用一个全面的数据集，超过70万个错误报告，从Bugzilla安装的四个主要的OSS社区，为期十多年。对于那些表现出最低比例的有效错误报告的项目，我们发现，错误报告者在协作网络中的位置是错误报告质量的一个强有力的指标。基于这一发现，我们开发了一个自动化的分类方案，可以很容易地集成到错误跟踪平台，并分析其性能在考虑OSS社区。一个支持向量机（SVM），以确定有效的错误报告的基础上的九个措施产生了高达90.3%的准确率与38.9%的召回。有了这个，我们显着提高了在以前的案例研究中获得的结果，自动早期识别的错误，最终修复。此外，我们的研究强调了在协作软件工程中使用社会组织的定量测量的潜力。它还为将社会意识纳入支助基础设施的设计开辟了广阔的前景。
2013-02-28 cs.LG cs.SE cs.SI
A Bug or a Suggestion? An Automatic Way to Label Issues
Nanjing University（南京大学）；The Hong Kong Polytechnic University（香港理工大学）
越来越多的用户和开发人员正在使用问题跟踪系统（ITS）报告问题，包括错误，功能请求，增强建议等。然而，当在不同的ITS上报告问题时，会从用户那里收集不同的信息，这对问题分类工具在ITS中有效工作提出了相当大的挑战。此外，当涉及到分类问题时，错误通常具有更高的优先级，而现有的问题分类方法很少关注区分错误和其他非错误问题，导致错误识别的准确性不佳。在本文中，我们提出了一种基于深度学习的方法来自动识别各种ITS中的错误报告问题。该方法实现了k-NN算法来检测和纠正从ITS中提取的数据中的错误分类，并使用超过120万个标记问题的数据集来训练基于注意力的双向长短期记忆（ABLSTM）网络以识别错误报告。实验评估表明，我们的方法在区分错误和其他问题方面达到了85.6%的F-度量，显著优于实验中检查的其他基准和最先进的方法。
2019-09-03 cs.AI cs.SE
Extracting Concise Bug-Fixing Patches from Human-Written Patches in Version Control Systems
高质量、大规模的真实bug库和从实际应用中收集的简洁补丁是软件工程研究的关键。在这样的存储库中，每个真正的bug都明确地与它的修复相关联。因此，一方面，真实的错误和它们的修复可以启发用于发现、定位和修复软件错误的新方法;另一方面，真实的错误和它们的修复对于软件测试、故障定位和程序修复的方法的严格和有意义的评估是不可缺少的。为此，许多这样的储存库，例如，第4J章已经被发现了然而，这种储存库相当小，因为它们的建造涉及昂贵的人工干预。虽然错误修复代码提交以及相关的测试用例可以从版本控制系统自动检索，现有的方法还不能自动提取简明的错误修复补丁从错误修复提交，因为这样的提交往往涉及错误无关的更改。在本文中，我们提出了一个自动的方法，称为BugBuilder，提取完整和简洁的错误修复补丁从人类编写的补丁在版本控制系统。它通过检测bug修复提交中涉及的重构来排除重构，并在错误版本上重新应用检测到的重构。它枚举剩余部分的所有子集，并在测试用例上验证它们。如果没有一个子集有可能成为一个完整的bug修复补丁，则剩余部分作为一个整体被视为一个完整和简洁的bug修复补丁。对Defects 4J中809个真实bug修复提交的评估结果表明，BugBuilder成功地为40%的bug修复提交生成了完整而简洁的bug修复补丁，其准确率（99%）甚至高于人类专家。
2021-02-27 cs.SE
MultiDimEr: a multi-dimensional bug analyzEr
本文提出并实现了多维缺陷分析工具 MultiDimEr，通过分类和可视化缺陷报告维度识别技术债务，在 Ericsson 评估中成功定位缺陷热点与趋势，验证了手动属性准确性并促进根因分析。
2024-02-16 cs.SE
Analyzing Quantum Programs with LintQ: A Static Analysis Framework for Qiskit
针对现有静态检测框架难以识别量子领域特有错误的问题，本文提出量子程序静态分析框架LintQ，在7568个Qiskit程序数据集上准确率达91.0%，远超现有方法。
2024-05-16 cs.SE
Comparative analysis of real bugs in open-source Machine Learning projects -- A Registered Report
Deakin University（迪肯大学）
工作背景：机器学习（ML）系统依赖于数据来进行预测，与传统的软件系统相比，该系统增加了许多组件，例如数据处理管道，服务管道和模型训练。现有的软件维护研究已经研究了不同类型的问题，如性能和安全问题的问题报告需求和解决过程。然而，ML系统有特定的故障类别，报告ML问题需要特定于域的信息。由于ML和传统软件工程系统之间的不同特征，我们不知道报告需求在多大程度上不同，以及这些差异在多大程度上影响问题解决过程。目的：我们的目标是调查ML和非ML问题之间的解决时间分布是否存在差异，以及基于开源应用ML项目中的真实问题报告，某些类别的ML问题是否需要更长的时间来解决。我们进一步研究了ML问题和非ML问题的修复大小。方法：我们从Github提取最近活跃的应用ML项目中的问题报告、拉取请求和代码文件，并使用自动方法过滤ML和非ML问题。我们使用已知的深度学习错误分类来手动标记问题。我们在一个受控样本上测量ML和非ML问题的解决时间和修复大小，并比较每类问题的分布。
2022-09-20 cs.AI cs.SE
How good does a Defect Predictor need to be to guide Search-Based Software Testing?
缺陷预测器、静态缺陷检测器和检查代码的人员可以在通过测试发现程序中有缺陷的部分之前找到它们。诸如基于搜索的软件测试（SBST）技术之类的自动测试生成器可以使用该信息来将它们对测试用例的搜索引导到可能存在错误的代码，从而加速检测现有错误的过程。然而，这些工具或人类给出的预测往往是不精确的，这可能会误导SBST技术，并可能降低其性能。在本文中，我们研究了缺陷预测的不精确性对SBST缺陷检测有效性的影响。我们的研究发现，召回的缺陷预测，即，正确识别错误代码的概率对SBST的错误检测有效性有显著影响，且效应量较大。另一方面，精确度的影响，一个衡量假警报，是没有实际意义的一个非常小的效果大小所示。特别是，SBST技术发现7.5个错误平均减少每5%的召回（420个错误）。在结合缺陷预测和SBST的背景下，我们的建议是在牺牲精度的情况下增加缺陷预测器的召回率，同时保持至少75%的精度。考虑到缺陷预测器的不精确性，特别是低召回值，SBST技术应该被设计为搜索测试用例，这些测试用例也覆盖了程序中预测的非错误部分，同时优先考虑被预测为错误的部分。
2021-10-06 cs.SE
BugGen: A Self-Correcting Multi-Agent LLM Pipeline for Realistic RTL Bug Synthesis
Texas A\&M University（德克萨斯A&M大学）；Infineon Technologies（英飞凌科技）
BugGen提出了一种自校正多智能体LLM流水线，用于在RTL中自动生成、插入和验证真实功能缺陷，在OpenTitan上实现94%功能准确率，并显著提升验证效率与ML辅助调试性能。
2025-06-18 cs.LG cs.SE
Ammonia: An Approach for Deriving Project-specific Bug Patterns
查找和修复错误代码是一项重要且成本高昂的维护任务，而静态分析（SA）是开发人员用来执行该任务的方法之一。SA工具通过扫描开发人员的源代码以查找常见的错误模式来警告开发人员潜在的错误，从而使这些开发人员有机会在发布软件之前修复警告（潜在的错误）。通常，SA工具扫描任何软件项目常见的一般错误模式（如空指针取消引用），而不是项目特定的模式。然而，过去的研究指出，这种缺乏可定制性的严重限制问题SA。因此，在本文中，我们提出了一种称为氨的方法，它是基于静态分析整个项目的开发历史的变化，作为一种手段来识别特定于项目的错误模式。此外，我们的工具识别的错误模式不仅仅与一个开发人员或一个特定的提交有关，它们反映了整个项目，并补充了其他SA工具识别一般错误模式的警告。在这里，我们报告的应用程序，我们实现的工具和方法的四个Java项目：蚂蚁，骆驼，POI和Wicket。结果表明，我们的工具可以在这四个项目中检测到19个项目特定的错误模式。接下来，通过手动分析，我们确定这些更改模式中有六个是实际的bug，并根据这些bug模式提交了pull请求。结果，合并了五个拉取请求。
2020-03-14 cs.SE
Precise Debugging Benchmark: Is Your Model Debugging or Regenerating?
University of Southern California（南加州大学）；Microsoft（微软）；University of Wisconsin–Madison（威斯康星大学麦迪逊分校）；University of Toronto（多伦多大学）
本文提出PDB基准，评估LLM调试能力，发现前沿模型调试精度低，即使受指令引导也难以达到高精度。
2026-10-06 cs.CL cs.SE
Multi-Agent Code Verification via Information Theory
Noumenon Labs（诺默恩实验室）；Harvard University（哈佛大学）
通过信息论构建多智能体系统，有效检测代码错误，准确率达79.3%，运行效率高。
2025-12-03 cs.AI cs.MA cs.SE
An Empirical Evaluation of Locally Deployed LLMs for Bug Detection in Python Code
Independent Researcher Master of Electrical（独立研究者 电气工程硕士）
本文评估了本地部署的LLaMA 3.2和Mistral在Python bug检测中的性能，发现其准确率在43%-45%之间，但难以精确定位修复。
2026-04-25 cs.AI cs.LG cs.SE
Assurances in Software Testing: A Roadmap
作为研究人员，我们已经知道如何使测试更有效和更高效地发现bug。然而，由于模糊（即，自动化测试）在实践中越来越广泛地被采用，从业者们会问：模糊测试活动提供了什么保证不会暴露错误？在合理的剩余风险下，何时停止模糊器是安全的？模糊器应该运行多久才能达到足够的覆盖范围？现在是我们超越日益复杂的测试技术的创新，围绕测试过程的解释和量化建立一个知识体系，并制定合理的方法，以可衡量的准确性估计和推断这些数量的时候了。在我们对未来的展望中，从业者利用丰富的统计工具集来评估剩余风险，获得统计保证，并分析正在进行的模糊活动的成本效益权衡。我们提出了一个总体框架作为第一个出发点，以应对这一根本挑战，并讨论了大量的具体机会，为未来的研究。
2018-12-17 cs.SE
Back to the Future! Studying Data Cleanness in Defects4J and its Impact on Fault Localization
本文分析 Defects4J 故障触发测试的时间线与开发者知识污染，发现去除该知识后 SBFL 性能显著下降，并发布洁净缺陷数据集。
2024-08-08 cs.SE
Whence Is A Model Fair? Fixing Fairness Bugs via Propensity Score Matching
North Carolina State University（北卡罗来纳州立大学）；Cornell University（康奈尔大学）
针对训练与测试数据同源采样导致的公平性评估偏差问题，提出后处理方法 FairMatch，通过倾向得分匹配定位无偏子集并调整决策阈值，结合概率校准显著减轻剩余数据偏差且不牺牲预测性能。
2025-05-01 cs.CY cs.LG cs.SE
A Principled Framework for Safe Algorithm Updates in Automated Insulin Delivery Systems
University of California, Davis（加州大学戴维斯分校）；Trio OS-AID；Stanford University（斯坦福大学）
提出一个两部分的框架，用于分类自动化胰岛素输送（AID）算法中的错误并评估软件更新的临床等效性，通过将Trio的oref算法从JavaScript移植到Swift的案例验证，证明该框架能确保更新安全。
2026-06-15 cs.OS cs.SE
A Fine-grained Data Set and Analysis of Tangling in Bug Fixing Commits
上下文：纠结提交是对软件的更改，可以同时解决多个问题。对于对bug感兴趣的研究人员来说，纠结的提交意味着他们实际上不仅研究bug，还研究与bug研究无关的其他问题。目标：我们希望提高我们对纠缠的流行程度以及在bug修复提交中纠缠的更改类型的理解。方法：我们使用众包方法进行手动标记，以验证哪些更改有助于bug修复提交中每行的bug修复。每条线由四个参与者标记。如果至少有三个参与者同意相同的标签，我们就达成了共识。结果：我们估计，在bug修复提交的所有更改中，有17%到32%修改了源代码以修复潜在问题。然而，当我们只考虑对生产代码文件的更改时，这一比例增加到66%到87%。我们发现，大约11%的线路很难标记，导致参与者之间的积极分歧。由于确认的缠结和我们数据中的不确定性，我们估计3%到47%的数据在没有手动解开的情况下是有噪声的，这取决于用例。结论：缠结提交在bug修复中具有很高的流行率，并且可能导致数据中的大量噪声。先前的研究表明，这种噪音可能会改变结果。作为研究人员，我们应该持怀疑态度，并假设未经验证的数据可能非常嘈杂，直到证明不是这样。
2021-10-13 cs.SE
To Type or Not to Type? A Systematic Comparison of the Software Quality of JavaScript and TypeScript Applications on GitHub
本研究通过挖掘604个GitHub项目对比JS与TS的软件质量，发现TS代码质量和可理解性更优，但缺陷倾向性更高、修复时间更长，减少any类型使用可优化多数质量指标。
2022-03-21 cs.SE
A large-scale study on human-cloned changes for automated program repair
对自动程序修复的研究表明，真正的错误可以自动修复。然而，这一任务涉及的若干挑战尚未得到充分解决。作为一个例子，考虑一个基于测试套件的修复工具在程序中执行一个更改，以修复一个失败的测试用例发现的错误，但是随后同一个或另一个测试用例失败了。这可能意味着更改是对错误的部分修复，或者另一个错误已经显现。但是，修复工具会放弃更改并可能执行其他修复尝试。人们可能会想，应用的更改是否也应该应用于程序中的其他位置，以便完全修复bug。在本文中，我们感兴趣的是调查开发人员在补丁中克隆的错误修复更改的程度。我们的目标是通过在相同或相似的背景下使用相同或相似的变化来调查多位置修复的需要。为此，我们分析了来自ManySStuBs4J数据集的3，049个多块补丁，ManySStuBs4J数据集是一个单语句错误修复更改的大型数据集。我们发现，68%的多块补丁包含至少一个更改克隆组。此外，这些补丁中的大多数（70%）是严格克隆的补丁，这些补丁完全由属于一个单一的更改克隆组的更改组成。最后，大多数严格克隆的补丁（89%）包含具有相同更改的更改克隆，独立于其上下文。我们的结论是，自动化的解决方案，用于创建由相同或相似的变化组成的补丁可以修复错误是有用的。
2021-04-06 cs.SE
Employing Partial Least Squares Regression with Discriminant Analysis for Bug Prediction
本文首次将化学计量学方法偏最小二乘判别分析（PLS-DA）引入软件维护领域，利用静态源代码度量预测Java程序缺陷，实验表明该方法在无需重采样时性能优于现有技术，且训练更快、完整性指标最优。
2020-11-02 cs.SE stat.AP
What is a "bug"? On subjectivity, epistemic power, and implications for software research
本文探讨了软件研究中“bug”定义的主观性与认知权力问题，指出在缺乏完整形式化规约时，现有定义常依赖不完美的代理，并分析了这种模糊性对软件工程研究的影响。
2024-02-13 cs.HC cs.SE
SoK: From Finding to Deployment: Systematizing the OS Kernel Bug Lifecycle
University of Illinois Chicago（伊利诺伊大学芝加哥分校）；Indiana University Bloomington（印第安纳大学布鲁明顿分校）
本SoK系统化Linux内核缺陷从发现到部署的生命周期，划分五个阶段，通过测量syzbot修复缺陷揭示崩溃到补丁差距的结构性原因，指出修复技术应把复现器等产物视为输出而非前提。
2026-09-22 cs.CR cs.OS cs.SE
BLAZE: Cross-Language and Cross-Project Bug Localization via Dynamic Chunking and Hard Example Learning
David R. Cheriton School of Computer Science, University of Waterloo（滑铁卢大学戴维·R·切里顿计算机科学学院）
针对现有缺陷定位工具跨项目和多语言能力不足的问题，本文提出BLAZE方法，通过动态分块和难例学习微调GPT模型，并构建含26,321个缺陷的BEETLEBOX数据集，在三个基准上显著提升定位精度。
2025-06-22 cs.IR cs.LG cs.SE
It Takes Two to Tango: Combining Visual and Textual Information for Detecting Duplicate Video-Based Bug Reports
College of William & Mary（威廉与玛丽学院）；George Mason University（乔治梅森大学）
当bug在面向用户的应用程序中出现时，它很可能通过图形用户界面（GUI）暴露出来。鉴于视觉信息对识别和理解此类错误的重要性，用户越来越多地使用屏幕截图和屏幕记录作为向开发人员报告问题的手段。然而，当这样的信息被集中报告时，例如在众包测试期间，管理这些工件可能是一个耗时的过程。随着屏幕记录的报告变得越来越流行，开发人员可能会面临与手动识别描述重复错误的视频相关的挑战。由于其图形化的特性，屏幕记录对自动化分析提出了挑战，排除了使用当前的重复错误报告检测技术。为了克服这些挑战并帮助开发人员完成这项任务，本文介绍了Tango，这是一种重复检测技术，它通过利用视觉和文本信息来纯粹基于视频的错误报告。Tango结合了定制的计算机视觉技术、光学字符识别和文本检索。我们对Tango的多种配置进行了全面的实证评估，评估了4，860个重复检测任务，其中涉及来自6个Android应用程序的180个屏幕记录。此外，我们进行了一项用户研究，调查开发人员手动检测重复的基于视频的错误报告所需的工作量，并将其与使用Tango所需的工作量进行了比较。结果表明，Tango的最佳配置在检测重复的基于视频的错误报告方面非常有效，在83%的任务中，目标重复视频准确地排在返回结果的前2位。此外，我们的用户研究表明，平均而言，Tango可以减少开发人员60%以上的工作量，这说明了它的实用性。
2021-02-05 cs.AI cs.SE
