Large-Scale Evaluation of Method-Level Bug Localization with FinerBench4BL
本文提出方法级缺陷定位评估框架 FinerBench4BL，基于 Bench4BL 半自动生成方法级仓库与 oracle，并适配现有技术；实验显示方法级技术准确率下降但调试效率提升。
2023-02-28 cs.SE
Test case prioritization using test case diversification and fault-proneness estimations
针对回归测试中测试套件规模增大导致的耗时问题，提出一种结合测试用例覆盖数据、缺陷历史和多样化的优先级排序方法，利用故障倾向性估计和聚类方案，在五个真实项目的357个版本上验证了其优于传统基于覆盖的方法。
2023-11-17 cs.SE
IncBL: Incremental Bug Localization
大量的努力已经投入到提高缺陷定位技术的有效性，而很少有人注意到，使这些工具在不断发展的软件库中更有效地运行。本文首先分析了一个经典的缺陷定位工具Buggram背后的信息检索模型，并建立了一个数学基础，说明该模型可以随着代码库或缺陷报告的发展而增量式更新。然后，我们提出了IncBL，一个工具，增量错误定位在不断发展的软件仓库。在Bugzbook数据集上对IncBL进行了评估，结果表明，与重新计算模型相比，IncBL可以显著减少平均77.79%的运行时间，同时保持相同的精度水平。我们还将IncBL实现为Github应用程序，可以轻松集成到GitHub上的开源项目中。用户也可以在本地部署和使用IncBL。IncBL的演示视频可以在https：//youtu.be/G4gMuvlJSb0上查看，源代码可以在https://github.com/soarsmu/IncBL上找到。
2021-08-13 cs.SE
PR-SZZ: How pull requests can support the tracing of defects in software repositories
SZZ算法代表了一种标准的方法来识别bug修复提交以及诱导对应提交。它构成了许多实证研究中使用的数据集的基础。自创建以来，已提出多个扩展以提高其性能。由于历史原因，相关的工作依赖于提交消息来将错误票据映射到可能相关的代码，而没有额外的数据用于跟踪这些修复引起的提交。因此，我们提出了一个更新版本的SZZ利用拉请求，这是广泛采用的今天。我们评估我们的方法相比，现有的SZZ变种进行实验和分析使用的拉请求，内部提交，合并策略。我们的结果基于6个开源项目，超过50k提交和35k拉取请求。关于bug修复提交，平均18%的bug票据可以额外映射到修复提交，导致整体F分数为0.75，提高了40个百分点。通过选择诱导提交，我们设法减少了误报，并与现有方法相比平均提高了16个百分点的精度。
2022-06-20 cs.SE
Wayback Machine: A tool to capture the evolutionary behaviour of the bug reports and their triage process in open-source software systems
问题跟踪系统（ITS）是数据驱动决策的丰富数据源。错误的不同特征，如严重性、优先级和修复时间，提供了ITS的清晰图像。然而，这些信息可能会误导。例如，花在bug上的确切时间和精力可能与实际的报告时间和修复时间有很大的不同。类似地，这些值可以是主观的，例如，严重性和优先级值是基于用户或开发者的直觉而不是基于结构化和明确定义的过程来分配的。因此，我们将探索bug依赖图的演变以及优先级和严重性级别，以探索实际的分类过程。受万维网的“Wayback Machine”概念的启发，我们的目标是重建ITS中的历史决策。因此，任何错误优先级或错误分类算法/场景可以应用在相同的环境中使用我们提出的ITS Wayback Machine。更重要的是，当采用自定义分类/优先级策略时，我们跟踪ITS中的进化指标。我们使用从三个开源项目中提取的数据测试所提出的算法的效率。我们的实证研究揭示了被忽视的进化指标-例如，过期的错误和开发人员的负载-这是通过我们提出的过去事件再生器促进。
2022-03-15 cs.SE
Automated Duplicate Bug Report Detection in Large Open Bug Repositories
Department of Computer Science University of Colorado Colorado Springs United States（计算机科学系，科罗拉多州立大学，美国）；George Mason University, Fairfax, VA, United States（乔治·马歇尔大学，弗吉尼亚州 Fairfax，美国）
本文提出基于机器学习的自动检测重复bug报告方法，通过多种技术提升准确率，应用于Eclipse开源项目数据集。
2025-04-21 cs.AI cs.SE
Bug Destiny Prediction in Large Open-Source Software Repositories through Sentiment Analysis and BERT Topic Modeling
University of Wisconsin-La Crosse（威斯康星大学拉克罗斯分校）
本研究利用Bugzilla Eclipse项目数据，结合情感分析与BERTopic主题建模，通过CNN和MLP预测Bug的解决时间、修复时间及最终状态，发现情感分析对预测Bug是否被修复尤为有效。
2025-04-22 cs.AI cs.SE
Mining Software Repair Models for Reasoning on the Search Space of Automated Program Fixing
本文通过分析软件仓库中数以千计的错误修复事务来理解错误修复的本质。然后，它将这些学习到的知识放在自动程序修复的上下文中。我们给出了大量的经验结果，在大规模和细粒度的抽象语法树差异的性质，人类的错误修复。我们建立了数学推理的搜索空间的自动修复和时间，通过应用我们的方法对14个存储库的Java软件和89,993版本事务，我们表明，并非所有的概率修复模型是等价的。
2013-11-14 cs.SE
Code Coverage Based Test Case Selection and Prioritization
回归测试的目的，是在对现有软件作出多项修订或改动后，确保软件能达到预期的功能。回归测试或可透过隐藏软件在功能性及非功能性应用方面的回归或软件错误，以证明经修订的软件的质素。事实上，测试用例集的维护是巨大的，因为它需要在大规模的测试用例上投入大量的时间和金钱。因此，最小化测试集成为减少回归测试预算的必要条件。准确地说，这篇研究论文希望提出一种创新的方法，有效地选择和优先级的测试用例，作为回报，可能会获得最大的代码平均。
2013-12-07 cs.SE
(When) Should a Software Factory be Lights-off? Benchmarking Code Review Agents on Bug Detection
Carnegie Mellon University（卡内基梅隆大学）；Microsoft（微软）；Microsoft Research（微软研究院）
该研究构建了CRBugBench基准，测试发现SOTA审查智能体在缺陷检测上有提升但复杂场景表现差，还给出了开发人员采用审查智能体的具体指导。
2026-10-12 cs.SE
Characterizing Bugs and Quality Attributes in Quantum Software: A Large-Scale Empirical Study
NIT Srinagar（印度国立技术学院斯利那加分校）
本研究通过大规模分析量子软件缺陷，揭示了全栈库和编译器的高缺陷率及自动化测试对减少缺陷的重要性。
2026-01-02 cs.SE
PreciseBugCollector: Extensible, Executable and Precise Bug-fix Collection
针对现有缺陷数据集精准度与规模难以兼顾的问题，提出基于缺陷追踪器和缺陷注入器的多语言缺陷收集方法PreciseBugCollector，已构建含百万级缺陷的大规模精准数据集，适配工业场景需求。
2024-03-09 cs.PL cs.SE
Mining Software Repositories for Expert Recommendation
Department of Computer Science, University of Colorado Colorado Springs（计算机科学系，科罗拉多州立大学）
提出一种基于问题跟踪系统历史数据，利用BERTopic和TopicMiner技术，根据缺陷报告特征对开发者经验排序，以自动化分配缺陷并辅助人类分类员的方法，并通过Top-k准确率在Eclipse和Mozilla项目上验证其有效性。
2025-04-23 cs.AI cs.SE
Cross-Ecosystem Bug Classification in Quantum Software
NIT Srinagar（印度国立技术学院斯利那加分校）
本研究对Qiskit等12个量子软件仓库的17523个缺陷开展跨生态系统比较，采用基于规则的分类框架，发现经典缺陷占比67%，所提框架在细粒度量子缺陷检测上优于机器学习基线。
2026-08-05 cs.SE
The Harmony Platform
根据维基百科，挖掘软件仓库（MSR）字段分析软件仓库中可用的丰富数据，如版本控制仓库，邮件列表存档，错误跟踪系统，问题跟踪系统等，以发现有关软件系统，项目和软件工程的有趣和可操作的信息。MSR领域受到了极大的关注，现在有了自己的研究会议：http://www.msrconf.org/。然而，进行MSR研究仍然是一个技术挑战。事实上，数据源（如版本控制系统或错误跟踪系统）是高度异构的。此外，对大量数据源执行研究在执行时间方面是非常昂贵的。令人惊讶的是，没有那么多的工具能够帮助研究人员在他们的MSR任务。这就是为什么我们创建了Harmony平台，作为协助研究人员进行MSR研究的一种手段。
2013-09-02 cs.SE
Incorporating fault-proneness estimations into coverage-based test case prioritization methods
内容：在软件程序的开发过程中，回归测试用于确保软件在更新源代码后保持正确的行为。随着测试用例数量的增加，这种回归测试随着时间的推移变得昂贵，并且为了尽快执行故障检测测试用例，对测试用例进行优先级排序是有意义的。有许多基于覆盖率的测试用例优先级（TCP）方法只使用代码覆盖率数据来确定测试用例的优先级。通过将代码单元的错误倾向性估计结合到基于覆盖率的TCP方法中，我们可以改进此类技术。目的：在本文中，我们的目标是提出一种方法，提高覆盖率为基础的TCP方法，通过考虑代码单元的故障倾向性分布。此外，我们提出的实证研究的结果表明，使用我们提出的方法显着提高了额外的策略，这是一个广泛使用的基于覆盖的TCP方法。方法：在这项研究中提出的方法使用的错误历史的软件，以引入缺陷预测方法来学习神经网络模型。然后，该模型被用来估计每个区域的源代码的故障倾向，然后将估计纳入基于覆盖率的TCP方法。我们提出的方法是一个一般的想法，可以应用到许多基于覆盖的方法，如额外的和总的TCP方法。结果如下：所提出的方法进行评估的数据集收集的开发历史的五个真实世界的项目，包括357个版本。实验表明，使用适当的错误历史可以改善基于覆盖率的TCP方法。
2020-02-16 cs.SE
Technical Debt Prioritization: State of the Art. A Systematic Literature Review
背景软件公司需要管理和重构技术债务问题。因此，有必要了解重构技术债务是否以及何时应该优先于开发功能或修复错误。Objective.本研究的目的是调查现有的知识体系在软件工程，以了解技术债务优先级的方法已被提出在研究和工业。法我们对截至2018年发表的384篇独特论文进行了系统性文献综述，遵循软件工程中应用的综合方法。我们纳入了38项主要研究。结果已经提出了不同的方法来确定技术债务的优先次序，所有这些方法都有不同的目标和不同的标准。拟议的措施只捕捉了在实践中用于定性地确定技术债务优先次序的众多因素中的一小部分。我们报告了这些因素的影响图。然而，缺乏一套经验性的、经过验证的工具。结论我们注意到，技术性的债务优先级研究是初步的，在什么是重要因素以及如何衡量这些因素方面没有达成共识。因此，我们不能认为目前的研究结论，在本文中，我们概述了必要的未来调查的不同方向。
2020-01-30 cs.SE
InferFix: End-to-End Program Repair with LLMs
软件开发的生存周期深受bug的影响：它们的引入、识别和最终的解决方案占软件成本的很大一部分。这促使软件工程研究人员和从业人员提出不同的方法来自动识别和修复软件缺陷。通过Few-Shot演示学习和指令提示，大语言模型已经适应了程序修复任务，将其视为填充任务。然而，这些模型只专注于学习从公共存储库中挖掘的未分类错误的一般错误修复模式。在本文中，我们提出了InferFix：一个基于transformer的程序修复框架与最先进的静态分析器配对，以修复关键的安全和性能错误。InferFix结合了检索器-通过对比学习目标预训练的Transformer编码器模型，其目的是搜索语义等效的错误和相应的修复;和生成器-一个大语言模型（Codex Cushman）对监督错误修复数据进行微调，并通过错误类型注释和从外部非参数存储器检索的语义相似的修复来增强提示。为了训练和评估我们的方法，我们策划了InferredBugs，这是一个新颖的、元数据丰富的bug数据集，通过对数千个Java和C#存储库的更改历史执行Infer静态分析器来提取。我们的评估表明，InferFix优于强大的LLM基线，在C#中生成修复的前1准确率为65.6%，在Java中为76.8%。我们将讨论InferFix与Infer在微软的部署，Infer提供了一个端到端的解决方案，用于检测，分类和定位错误，以及修复和验证候选补丁，集成在持续集…
2023-03-13 cs.SE
A Static Analysis Platform for Investigating Security Trends in Repositories
提出一个集成多种静态分析工具的分析平台，支持基于Git的代码仓库跨版本历史持续监控警告，并通过仪表板展示安全趋势与热点，同时可生成适用于机器学习的大规模安全警报数据库。
2023-04-04 cs.SE
Faster Configuration Performance Bug Testing with Neural Dual-level Prioritization
School of Computer Science and Engineering, University of Electronic Science and Technology of China（电子科技大学计算机科学与工程学院）；IDEAS Lab, School of Computer Science, University of Birmingham（伯明翰大学计算机学院IDEAS实验室）；Department of Computer Science, University of Exeter（埃克塞特大学计算机科学系）
针对配置性能缺陷（CPBug）测试中预言机难设置、测量成本高及配置数量多的问题，提出NDP框架，通过神经双级优先级和自动化预言机估计，实现87%的CPBug类型预测准确率及最高88.88倍的测试效率提升。
2025-04-15 cs.AI cs.SE
Self-Admitted Technical Debt in Scientific Software: Prioritization, Sentiment, and Propagation Across Artifacts
Boise State University（博伊西州立大学）；Oak Ridge National Laboratory（橡树岭国家实验室）
研究科学软件中自我承认技术债务的优先级、情感、持久性和跨工件传播，发现注释、提交和拉取请求中的SATD优先级高于问题，负面情感增加紧迫性，但移除和解决率低于开源软件平均水平。
2026-06-29 cs.SE
Lessons learned from replicating a study on information-retrieval based test case prioritization
目的：在这项研究中，我们的目标是复制基于人工制品的研究软件测试，以解决差距。我们的重点是（a）提供一个复制的一步一步的指南，反映复制人工制品为基础的测试研究时的挑战，（b）评估复制的研究有关其有效性和鲁棒性的研究结果。方法：我们复制了Kwon等人的测试用例优先级排序技术。我们使用四个程序复制了原始研究，两个来自原始研究，两个新程序。复制研究是使用Python实现的，以支持未来的复制。结果如下：确定了促进复制的各种一般因素，如：（1）文件的重要性;（2）需要原始作者的帮助;（3）维护开放源码储存库的问题（例如，关于所需的软件依赖性）;（4）脚本的可用性。我们还提出了一些针对该研究及其背景的观察结果，例如使用不同突变工具和突变体生成策略的见解。结论：我们的结论是，Kwon等人的研究是可复制的小型和中型程序，并可以自动化，以方便软件从业人员，所需的信息的可用性。
2022-04-13 cs.SE
TianoForge: An Automated Bug Triage Approach for the TianoCore UEFI Firmware Development Community
University of Colorado Colorado Springs (UCCS)（科罗拉多大学科泉分校）；Purdue University（普渡大学）
针对TianoCore UEFI固件开发社区，提出基于GPT-LLM（结合或不结合RAG）的自动化Bug分类方法TianoForge，可将平均Bug分类时间缩短99.95%，显著提升软件维护效率。
2026-08-25 cs.SE
Privacy-Preserving Methods for Bug Severity Prediction
本研究针对工业界数据共享受限问题，利用源代码度量和LLM进行方法级缺陷严重性预测，对比了集中式学习、联邦学习与合成数据生成方法，发现联邦学习与合成数据在无需共享数据时即可达到与集中训练相当的预测效果。
2025-06-28 cs.SE
Bug Analysis Towards Bug Resolution Time Prediction
Norwegian University of Science and Technology（挪威科技大学）；Technical University of Munich（慕尼黑工业大学）；University of the Bundeswehr Munich（慕尼黑联邦国防军大学）
本文基于Jira数据提出一种缺陷解决时间预测方法，并在ONAP网络项目中验证，为网络软件化项目的缺陷管理提供参考。
2024-07-30 cs.AI cs.SE
Natural Language Summarization Enables Multi-Repository Bug Localization by LLMs in Microservice Architectures
Yildiz Technical University, Dept. of Computer Eng.（Yildiz技术大学，计算机工程系）；Yildiz Technical University, Department of Computer Engineering（Yildiz技术大学，计算机工程系）
利用自然语言摘要和LLM技术，通过多仓库微服务架构实现更高效的Bug定位，显著提升定位准确率和透明度。
2025-12-05 cs.AI cs.CL cs.IR
Towards Better Summarizing Bug Reports with Crowdsourcing Elicited Attributes
近年来，在软件维护中，解决大量错误报告的需求不断增长。为了减少测试人员/开发人员阅读错误报告的时间，错误报告摘要的任务在文献中吸引了大量的研究工作。然而，没有系统的分析已经进行了属性的建设，这严重影响了监督算法的性能缺陷报告摘要。在这项研究中，我们首先进行了一项调查，以揭示现有的方法在挖掘软件仓库的属性建设。在此基础上，提出了一种从众包数据中推断新的有效属性的方法Crowd-Attribute，并开发了一个新的工具Crowdsourcing软件工程平台。利用Crowd-Attribute，我们成功地构造了11个新的属性，并提出了一个新的监督算法，称为Logistic Regression with Crowdsourced Attributes（LRCA）。为了评估LRCA的有效性，我们构建了一系列包含105，177个错误报告的大规模数据集。在包含36个人工标注错误报告的公共数据集SDS和新的大规模数据集上的实验表明，LRCA可以始终优于最先进的错误报告摘要算法。
2018-09-29 cs.SE
Developer Load Normalization Using Iterative Kuhn-Munkres Algorithm: An Optimization Triaging Approach
错误分类可以定义为将开发人员分配到错误报告的过程。bug分类小组的职责是研究开发人员的概要文件，以便在开发人员和传入的bug报告之间进行适当的匹配。因此，这一过程是问题管理系统中至关重要的一步。事实上，每天提交的bug报告数量正在逐渐增加，这影响了开发人员的工作量。因此，分类团队在分发bug时应该考虑这个因素，因为手动方法，许多开发人员都是负担。特别是，在不考虑工作负载的情况下对bug报告进行分类，不仅会影响开发人员的工作负载，还会导致未解决的bug报告数量的增加。因此，报告的bug的修复时间将相对增加。与其他专注于自动化错误分类而忽略开发人员工作量的研究人员不同，在这项工作中，我们从不同的角度处理分类过程。所提出的方法侧重于如何优化的错误修复时间规范化的开发人员在自动化系统的负载。为了评估我们的工作，我们使用了来自不同bug库的26，317个bug报告。结果表明，我们的工作优于其他系统在优化的错误总修复时间和正常化的开发人员负载。
2022-02-03 cs.SE
ZeroIn: Characterizing the Data Distributions of Commits in Software Repositories
现代软件开发是基于一系列快速增量更改，这些更改由具有不同经验和专业知识水平的开发人员对大型源代码存储库进行协作。ZeroIn项目旨在分析这些动态现象的元数据，包括关于存储库、提交和开发人员的数据，以快速准确地标记提交到达存储库时的质量。在这种情况下，本文提出了一个表征的软件开发元数据的分布数据，最好的捕捉趋势的数据集。为此，我们分析了多个数据集，包括开发人员特性的Stack Overflow和超过4.52亿个存储库的GitHub数据，其中包含1600万次提交。这种表征旨在使生成多个合成数据集成为可能，这些数据集可用于训练和测试基于机器学习的新解决方案，以提高软件的可靠性，即使它在发展。它还旨在服务于开发过程，以利用跨存储库和开发人员的聚合空间的许多关键特征向量之间的潜在相关性。本文的数据特征化旨在为ZeroIn的机器学习组件提供信息，包括应用二进制分类器来早期标记有缺陷的软件提交，以及开发基于图的学习方法来利用存储库、提交和开发人员之间的稀疏连接。
2022-04-16 cs.SE
Leveraging Models to Reduce Test Cases in Software Repositories
给定一个失败的测试用例，测试用例缩减产生一个更小的测试用例，重现失败。由于使用较小的测试用例进行重复试验和错误，此过程可能非常耗时。目前的技术通过只探索语法上有效的候选项来加速约简，但是它们仍然在语义上无效的候选项上花费大量的精力。在本文中，我们提出了一个模型引导的方法来加快测试用例的减少。该方法训练一个由句法测试用例属性驱动的语义属性模型。通过使用这个模型，我们可以跳过测试，即使是语法上有效的测试用例候选者也不太可能成功。我们评估了这个模型指导下的减少一套14个大型模糊生成的C测试案例，从两个著名的C编译器，GCC和Clang的错误存储库。我们的研究结果表明，平均精度为77%，我们可以减少14%至61%的删除试验的数量。我们观察到与最先进的技术相比，复位时间几何平均提高了30%，同时保持了相似的复位能力。
2021-03-22 cs.SE
Is this bug severe? A text-cum-graph based model for bug severity prediction
大型软件系统的存储库已经变得司空见惯。这种大规模的扩展导致了这些软件平台中各种问题的出现，包括识别（i）容易出现错误的软件包，（ii）关键错误，以及（iii）错误的严重性。其中一个重要的目标是挖掘这些bug并推荐给开发人员来解决它们。第一步是必须准确地检测错误的严重程度。在本文中，我们承担了预测在不久的将来的错误的严重性的任务。基于bug的文本描述和用户对bug的评论构建的上下文化神经模型有助于实现合理的良好性能。关于bug如何影响软件包的方式的更多信息可以以图表的形式总结出来，并与文本一起使用，以获得额外的好处。
2022-07-01 cs.IR cs.SE
SZZ Unleashed: An Open Implementation of the SZZ Algorithm -- Featuring Example Usage in a Study of Just-in-Time Bug Prediction for the Jenkins Project
许多经验性的软件工程研究依赖于关于错误的详细信息。虽然问题跟踪器通常包含有关错误何时被修复的信息，但有关错误何时被引入系统的详细信息通常不存在。作为一种补救措施，研究人员经常依赖SZZ算法作为一种启发式方法来识别引入错误的软件更改。不幸的是，正如最近的系统性文献综述所报道的那样，很少有研究人员公开他们的SZZ实现。因此，有一种风险，即研究工作被浪费，因为基于SZZ输出的新项目最初需要重新实施该方法。此外，新开发的（封闭源代码）SZZ实现还没有经过适当的测试，因此基于其输出进行研究可能会对有效性造成威胁。我们介绍SZZ Unleashed，一个用于git仓库的SZZ算法的开放实现。本文描述了我们的实现以及Jenkins项目的使用示例，并以即时错误预测的说明性研究作为结论。我们希望继续在GitHub上发展SZZ Unleashed，并热情邀请社区做出贡献。
2019-08-19 cs.SE
Improving Merge Pipeline Throughput in Continuous Integration via Pull Request Prioritization
本文提出利用历史构建数据、PR元数据和上下文信息预测构建成功率，动态优先排序可能通过的PR，以优化合并流水线顺序，显著提升持续集成吞吐量且不依赖特定构建系统。
2025-08-11 cs.SE
Utilizing Source Code Syntax Patterns to Detect Bug Inducing Commits using Machine Learning Models
本研究提出从源代码语法模式中提取特征来检测引入缺陷的提交，实验表明该方法在多种机器学习模型上提升了缺陷检测性能，并提供了更好的可解释性。
2022-12-07 cs.SE
Bug Classification in Quantum Software: A Rule-Based Framework and Its Evaluation
National Institute of Technology Srinagar（斯利那加国家技术学院）
本文提出了一种基于规则的框架，用于分类量子软件中的缺陷，通过评估发现经典缺陷占主导，量子特定缺陷占比高，且在严重性分类上仍有改进空间。
2025-06-12 cs.CY cs.DC cs.SE
DeNovoSWE: Scaling Long-Horizon Environments for Generating Entire Repositories from Scratch
Gaoling School of Artificial Intelligence, Renmin University of China（中国人民大学高瓴人工智能学院）；Independent Researcher（独立研究者）
提出DeNovoSWE数据集，通过沙盒代理工作流自动构建4818个从文档生成完整仓库的实例，采用分治与批评修复策略及难度感知轨迹过滤，微调Qwen3-30B-A3B将BeyondSWE-Doc2Repo基准得分从5.8%提升至47.2%。
2026-06-17 cs.SE
InEx-Bug: A Human Annotated Dataset of Intrinsic and Extrinsic Bugs in the NPM Ecosystem
University of British Columbia（不列颠哥伦比亚大学）
InEx-Bug数据集通过人工标注区分NPM生态系统中内在与外在bug，提供丰富的元数据用于研究缺陷特性及解决模式。
2026-02-13 cs.PL cs.SE
Analyzing the Evolution and Maintenance of Quantum Software Repositories
本研究通过挖掘GitHub上2.1万余个量子软件仓库的120万次提交，分析其演化与维护特征，揭示了增长趋势、提交类型分布及量子特有问题占比，为量子软件工程实践改进提供实证依据并开源数据集。
2025-06-06 cs.SE
G-Issue: Analyzing Lifetime and Evolution of Issue-related Artifacts from Open Source Repositories
University of Texas at El Paso（德克萨斯大学埃尔帕索分校）
提出G-Issue工具用于挖掘问题相关工件，通过对比实验和演化分析，发现其挖掘速度快但内存消耗大，并基于问题生命周期和演化可辅助优先级排序。
2026-06-23 cs.SE
Can we learn from developer mistakes? Learning to localize and repair real bugs from real bug fixes
University of Oldenburg（奥尔登堡大学）
在开源仓库中找到的真正的bug修复似乎是学习本地化和修复真正bug的完美来源。然而，由于缺乏大规模的bug修复集合，过去很难在训练较大的神经模型时有效地利用真正的bug修复。相比之下，人工bug--通过改变现有源代码产生--可以很容易地以足够的规模获得，因此在现有方法的训练中通常是首选的。尽管如此，在人工错误上训练的本地化和修复模型在面对真正的错误时通常表现不佳。这就提出了一个问题，即在真实的bug修复上训练的bug定位和修复模型在定位和修复真实的bug方面是否更有效。我们通过引入RealIT来解决这个问题，这是一种预训练和微调方法，可以有效地学习从真正的错误修复中定位和修复真正的错误。RealiT首先在传统变异算子产生的大量人工bug上进行预训练，然后在较小的一组真实bug修复上进行微调。微调不需要任何修改的学习算法，因此可以很容易地采用在各种训练场景的缺陷定位或修复（即使当真正的训练数据是稀缺的）。此外，我们发现，使用Realit对真实错误修复进行训练的经验非常强大，可以将现有模型对真实错误的本地化性能提高近一倍，同时保持甚至提高修复性能。
2022-07-01 cs.LG cs.SE
Bug Severity Prediction in Software Projects Using Supervised Machine Learning Models
Daffodil International University（达福迪尔国际大学）
本研究利用监督机器学习模型，通过Eclipse Bugzilla的历史数据预测缺陷严重性，发现集成树方法和DistilBERT在准确性上表现最佳，线性模型在召回率上更优，为自动化缺陷分拣提供了有效方法。
2026-01-09 cs.LG cs.SE
Characterizing Issue Management in Runtime Systems
本文对GitHub中34个运行时系统存储库的约118K个问题进行了实证研究，揭示了问题类型、解决率及特征对问题关闭的影响，并提出了六项改进建议。
2023-10-24 cs.SE
Engineering Pitfalls in AI Coding Tools: An Empirical Study of Bugs in Claude Code, Codex, and Gemini CLI
York University（约克大学）；Concordia University（康考迪亚大学）
本文通过分析超过3800个公开报告的bug，揭示了构建AI编码工具中的常见故障模式和工程挑战，发现功能相关bug占比超67%，主要症状包括API错误、终端问题和命令失败。
2026-03-21 cs.SE
Analyzing developer discussions on EU and US privacy legislation compliance in GitHub repositories
University of Cyprus（塞浦路斯大学）；Singapore Management University（新加坡管理大学）
借助GitHub仓库中开发者问题数据，通过挖掘分析32820个问题（部分自动、部分手动），探究开源软件开发者为遵守隐私立法所讨论的问题，构建分类法助从业者、教育界和研究界应对隐私合规。
2026-07-07 cs.SE
Bug Fix Time Optimization Using Matrix Factorization and Iterative Gale-Shaply Algorithms
缺陷分类是软件维护阶段的一项重要工作。它分配给开发人员（修复者）bug报告来修复它们。这个过程是由一个triager手动执行的，他分析开发人员的配置文件并提交错误报告，以进行适当的分配。缺陷分类过程非常耗时，因此自动化这个过程对于提高软件质量至关重要。以前的工作解决分流问题作为一个信息检索或分类问题。本文处理这个问题作为一个资源分配问题，旨在最好的分配开发人员的错误报告，减少总修复时间的新提交的错误报告，除了均匀分布的错误报告的开发人员。本文首先引入了一种基于差分进化的矩阵分解和Gale Shapely算法相结合的方法来优化总修复时间和规范开发人员的工作量。利用矩阵分解方法建立了一个推荐系统，用于Gale-Shapley算法的分配决策。差分进化提供了一组最佳的权重来构建开发人员的评分配置文件。所提出的方法在三个存储库上进行评估，Linux，Apache和Eclipse。实验结果表明，该方法在Linux、Eclipse和Apache上分别比人工分流减少了80.67%、23.61%和60.22%的漏洞修复时间。此外，开发人员的工作量是统一的。
2022-07-14 cs.IR cs.SE
Revealing Task Driven Knowledge Worker Behaviors in Open Source Software Communities
软件开发人员等知识工作者之间的协作活动是现代社会发展的基础，但深入了解他们在开放的在线社区中的行为模式是非常具有挑战性的。开源软件（OSS）存储库中大量数据的可用性（例如错误跟踪数据，电子邮件和评论）使我们能够以定量的方式调查这个问题。在本文中，我们对两个著名的OSS社区（即Eclipse和Mozilla）中与保证软件质量密切相关的在线协作活动进行了实证分析。我们的主要发现包括两个方面：（1）开发人员在两种不同的工作状态（正常和过载）下，在时间和空间上表现出两种截然相反的行为模式;（2）处理时间（包括bug修复时间和bug抛出时间）服从拉伸指数分布，而不是一般的幂律分布。我们的工作揭示了在不同任务驱动的负载条件下工作的熟练开发人员之间的在线协作活动之外的人类动力学规律，它可能是对当前人类动力学工作的重要补充。
2017-02-25 cs.SE
GIRT-Data: Sampling GitHub Issue Report Templates
GitHub的问题报告为开发人员提供了对软件开发项目的发展至关重要的宝贵信息。贡献者可以使用这些报告来执行软件工程任务，如提交bug、请求功能和协作构思。在最初版本的问题报告中，没有使用它们的标准方法。因此，问题报告的质量差别很大。为了提高问题报告的质量，GitHub引入了问题报告模板（IRT），当打开新问题时，该模板会预填充问题描述。IRT通常包含问候贡献者，描述项目指南和收集相关信息。然而，尽管这个功能在2016年推出，但只有近5%的GitHub存储库（超过10颗星）使用它。目前关于IRT的文章很少，可用的文章只考虑了少数存储库。在这项工作中，我们引入了GIRT数据，这是YAML和Markdown格式的第一个也是最大的IRT数据集。该数据集及其相应的开源爬虫工具旨在支持这一领域的研究，并鼓励更多的开发人员在其存储库中使用IRT。数据集的稳定版本包含1，084，300个存储库，其中50，032个支持IRT。数据集和爬虫程序的稳定版本可在此处获得：www.example.com
2023-03-21 cs.SE
Mining Threat Intelligence about Open-Source Projects and Libraries from Code Repository Issues and Bug Reports
University of Maryland, Baltimore County（马里兰大学巴尔的摩县分校）
开源项目和库被用于软件开发，同时也存在多个安全漏洞。第三方生态系统的使用为开发中的产品创造了一种新的攻击面。智能攻击者可以通过利用链接项目和库中存在的漏洞之一来攻击产品。在本文中，我们从公共代码存储库中报告的错误和问题中挖掘有关开源项目和库的威胁情报。我们还跟踪客户机上已安装软件的库和项目依赖关系。我们表示并存储此威胁情报，以及安全知识图谱中的软件依赖关系。然后，安全分析师和开发人员可以查询知识图谱，并在发现任何关于其产品中使用的链接库和项目的威胁情报时从知识图谱接收警报。
2018-08-09 cs.AI cs.CR cs.SE
Test case quality: an empirical study on belief and evidence
本文基于开放软件仓库开展实证研究，检验8项关于优秀测试用例特征的开发者信念，结果未发现支持证据，说明这些经验建议未必保证测试代码质量。
2023-07-12 cs.SE
Developers' Perception of GitHub Actions: A Survey Analysis
GitHub在2019年推出了“Action”，以提高工作流速度并为存储库添加自定义自动化。任何人都可以在GitHub存储库上开发用于自动化工作流的操作，其他人可以在开源时重用它们。GitHub推出了用于商业化和共享这些自动化工具的市场，目前该市场包含16，730个操作。然而，有许多Action是在本地存储库和Marketplace之外开发和分发的。到目前为止，研究界进行了挖掘研究，以了解行动，重点关注CI/CD。我们对90名Action开发人员和用户进行了调查研究，以了解使用，开发和调试Action的动机和最佳实践，以及与这些任务相关的挑战。我们发现，开发人员在选择类似的Action时，更喜欢具有验证创建者和更多星级的Action，并且在遇到bug或缺乏文档时经常切换到替代Action。60.87%的开发人员认为YAML文件的组成是Action集成的关键，具有挑战性且容易出错。他们主要检查Q\&A论坛来修复这些YAML文件的问题。最后，开发人员倾向于避免使用操作（以及自动化）来降低复杂性和安全风险，或者当操作的好处不值得为自动化设置操作的成本/工作时。
2023-03-07 cs.SE
Empirical Study on the Characteristics and Evolution of AI-usage in GitHub Repositories: Evidence from Code Comments
Missouri University of Science and Technology（密苏里科技大学）；Drexel University（德雷塞尔大学）
通过分析35,361条提及AI的GitHub代码注释及后续提交，发现开发者主要用LLM实现代码，随后频繁重构、集成和修复，AI引用从代码生成转向知识支持和代码增强。
2026-06-05 cs.SE
SWE-Bench++: A Framework for the Scalable Generation of Software Engineering Benchmarks from Open-Source Repositories
Research & Development, Turing（研发与图灵）
SWE-Bench++通过自动化生成多语言软件工程基准，提升仓库级代码生成的评估与改进
2025-12-19 cs.AI cs.CL cs.LG
WIA-SZZ: Work Item Aware SZZ
本文提出 WIA-SZZ，通过识别由缺陷引入提交与修复提交构成的“工作项”来改进 SZZ 算法，在 821 个仓库上的评估显示 F1 分数提升 2% 至 9%。
2024-11-19 cs.SE
LightSys: Lightweight and Efficient CI System for Improving Integration Speed of Software
软件的复杂性和大小的增加延长了开发人员等待代码分析和代码合并的延迟。随着软件越来越大，越来越复杂，现在越来越多的开发人员正在开发具有大型源代码存储库的软件。软件平台立即用特征更新和错误修复来更新软件包的趋势是一个重大障碍。在软件包的积极开发过程中，持续集成系统可能有助于防止软件缺陷，即使是在频繁部署和更新的情况下。在这里，我们提出了一个便携式和模块化的代码审查自动化系统，检查传入的代码更改，如代码格式和风格，性能回归，静态分析，构建和部署测试，并在合并和更改代码之前的动态分析。所提出的机制是足够轻量级的，即使对于许多开发人员来说，也可以托管在常规的台式计算机上。由此产生的成本降低允许开发人员将所提出的机制应用于许多源代码存储库。实验结果表明，该机制大大减少了开销，并提高了可用性相比，传统的机制：执行时间（6倍快），CPU使用（40%），内存消耗（1/180），和没有内存不足的发生。
2021-01-29 cs.SE
