Academic Search Engines: Constraints, Bugs, and Recommendation
背景：学术搜索引擎（即，数字图书馆和索引器）在系统综述中发挥着越来越重要的作用，然而这些引擎似乎并不能有效地支持这样的综述，例如，研究人员在进行搜索时面临引擎的可用性问题。目的：调查可用性问题是否是错误（即，搜索引擎中的缺陷）或限制，并就如何解决这些问题向搜索引擎提供商和研究人员提供建议。方法：采用滚雪球抽样从大专研究，我们确定了一组621个二级研究软件工程。通过物理上重新尝试对所有这621项研究的搜索，我们有效地对42个搜索引擎进行了回归测试。结果：我们确定了8个引擎的13个错误，并确定了其他限制。我们提出了解决这些问题的建议。结论：学术搜索引擎的可用性与研究者的搜索需求之间仍有相当大的差距。目前尚不清楚搜索引擎开发人员是否意识到了这一差距。此外，学术界对学术搜索引擎的评价没有跟上搜索引擎提供商对这些搜索引擎的开发。因此，评估和开发之间的差距使得更难正确理解研究人员的搜索需求和搜索引擎的搜索功能之间的差距。
2022-11-01 cs.DL cs.SE
Finding Cross-rule Optimization Bugs in Datalog Engines
本文提出增量规则求值方法 IRE 及工具 Deopt，通过对比优化前后 Datalog 程序结果来检测跨规则优化缺陷，在四个成熟引擎中发现 30 个缺陷，并显著提升有效测试用例生成效率。
2024-02-20 cs.SE
Automated Conformance Testing for JavaScript Engines via Deep Compiler Fuzzing
JavaScript（JS）是一种流行的、与平台无关的程序设计语言。为了确保JS程序在不同平台上的互操作性，JS引擎的实现应该符合ECMAScript标准。然而，这样做是具有挑战性的，因为API行为有许多微妙的定义，并且定义不断发展。我们提出了COMFORT，一个新的编译器模糊框架，用于检测JS引擎的错误和行为偏离ECMAScript标准。COMFORT利用基于深度学习的语言模型的最新进展，自动生成JS测试代码。与以前的模糊器不同，COMFORT利用结构良好的ECMAScript规范自动生成测试数据以及测试程序，以暴露开发人员或手动编写的测试用例可能忽略的错误。然后，COMFORT在生成的测试用例上应用差异测试方法，以暴露标准一致性错误。我们将COMFORT应用于十个主流JS引擎。在200小时的自动化并发测试运行中，我们发现了所有测试过的JS引擎中的错误。我们已经确定了158个独特的JS引擎错误，其中129个已经得到验证，115个已经被开发人员修复。此外，21个Comfort生成的测试用例已添加到Test262，官方ECMAScript一致性测试套件。
2021-04-15 cs.PL cs.SE
Testing Database Engines via Pivoted Query Synthesis
关系数据库被广泛使用。它们由数据库管理系统（DBMS）管理，DBMS允许使用称为结构化查询语言（SQL）的特定于域的语言插入、修改和查询数据。流行的数据库管理系统已经被模糊器广泛测试，它已经成功地发现了崩溃错误。然而，查找逻辑错误的方法，例如当DBMS计算出不正确的结果集时，仍然大多没有解决。差分测试是一种有效的技术，通过比较这些系统的输出来测试支持公共语言的系统。然而，这种技术对于DBMS是无效的，因为每个DBMS通常都支持自己的SQL方言。为此，我们设计了一种新的和一般的方法，我们称之为枢轴查询合成。这种方法的核心思想是自动生成查询，我们确保它们获取特定的随机选择的行，称为pivot行。如果DBMS无法获取数据透视行，可能的原因是DBMS中存在错误。我们在三个广泛使用的成熟DBMS上测试了我们的方法，即SQLite，MySQL和PostgreSQL。在这些DBMS中，我们总共报告了123个错误，其中99个已经修复或验证，表明该方法是非常有效和通用的。我们希望我们的方法的广泛适用性和简单性将使许多DBMS的鲁棒性的改善。
2020-01-13 cs.DB cs.SE
JEST: N+1-version Differential Testing of Both JavaScript Engines and Specification
现代编程遵循持续集成（CI）和持续部署（CD）方法，而不是传统的瀑布模型。即使是现代程序设计语言的开发也使用CI/CD方法来快速提供新的语言功能并适应新的开发环境。与传统方法不同，在现代CI/CD方法中，语言规范不再是语言语义的预言机，因为规范及其实现可以共同进化。在这种情况下，规范和实现都可能有bug，保证它们的正确性是非常重要的。在本文中，我们提出了一种新的N+1版本差分测试来解决这个问题。与传统的差分测试不同，我们的方法包括三个步骤：1）根据给定的语言规范自动合成由语法和语义引导的程序，2）通过将断言注入到合成的程序以检查它们的最终程序状态来生成一致性测试，3）通过对多个实现执行一致性测试来检测规范和实现中的错误，以及4）使用统计信息定位规范上的错误。我们实现了我们的方法，通过JEST的JavaScript程序设计语言，它执行N+1版本的差异测试现代JavaScript引擎和ECMAScript，语言规范描述的语法和语义的自然语言的JavaScript。我们使用四个JavaScript引擎评估了JEST，这些引擎支持所有现代JavaScript语言功能和最新版本的ECMAScript（ES 11，2020）。JEST自动合成了1,700个程序，覆盖了ES 11的97.78%的语法和87.70%的语义。使用断言注入，它在四个引擎中检测到44个引擎错误，在ES 11中检测到27个…
2021-02-16 cs.SE
Empirical Review of Java Program Repair Tools: A Large-Scale Experiment on 2,141 Bugs and 23,551 Repair Attempts
在过去的十年中，基于测试套件的自动程序修复的研究有了显着增长。每年，新的方法和实现都会出现在主要的软件工程场所。然而，大多数这些方法都是在单一的bug基准上进行评估的，其他研究人员也很少复制这些bug。在本文中，我们提出了一个大规模的实验，使用11个Java测试套件为基础的修复工具和5个基准的错误。我们的目标是更好地了解自动程序修复工具在大量基准测试中的现状。我们的调查是指导的假设，修复工具的可修复性可能不会在不同的基准程序错误的一般化。我们发现，这11个工具1）能够为5个基准测试中21%的bug生成补丁，2）与其他基准测试相比，在Defects 4J上具有更好的性能，通过为Defects 4J中47%的bug生成补丁，而其他基准测试中的bug只有10-30%。我们的实验总共包括23，551次修复尝试，我们用来找到非补丁生成的原因。本文对这些原因进行了分析，有助于维修工具设计人员改进技术和工具。
2019-05-28 cs.SE
From Bugs to Benchmarks: A Comprehensive Survey of Software Defect Datasets
University of California, Davis（加州大学戴维斯分校）；University of Stuttgart（斯图加特大学）
本文综述了151个软件缺陷数据集，探讨了其范围、构建方法及应用，并提出未来研究方向以解决缺陷类型代表性不足的问题。
2026-02-10 cs.SE
PROMFUZZ: Leveraging LLM-Driven and Bug-Oriented Composite Analysis for Detecting Functional Bugs in Smart Contracts
本文提出 PROMFUZZ，通过 LLM 双智能体分析、双阶段不变量生成与面向缺陷的模糊测试检测智能合约功能缺陷，显著提升召回率和 F1，并发现 30 个零日缺陷。
2025-09-28 cs.CR cs.SE
Towards the Systematic Testing of Regular Expression Engines
Purdue University（普渡大学）；Stony Brook University（石溪大学）
ReTest框架通过语法感知模糊测试和元测试方法系统性测试正则表达式引擎，提升覆盖率并发现新缺陷。
2026-02-27 cs.CR cs.SE
Analyzing Performance Issues of Virtual Reality Applications
延展实境（XR）包括虚拟现实（VR）、增强现实（AR）和混合现实（MR）。XR是一种新兴技术，为用户模拟逼真的环境。XR技术已经在各种应用场景（例如，培训、教育、产品/架构设计、游戏、远程会议/旅游等）。由于在资源有限的设备中渲染实时动画的计算成本很高，并且与用户活动不断交互，XR应用程序经常面临性能瓶颈，这些瓶颈会对XR软件的用户体验产生负面影响。因此，性能优化在许多行业标准XR应用中起着至关重要的作用。即使识别传统软件中的性能瓶颈（例如，桌面应用程序）是一个广泛探讨的主题，但由于XR应用程序的不同性质，这些方法无法直接应用于XR软件。此外，在Unity和虚幻引擎等不同框架中开发的XR应用程序显示出不同的性能瓶颈模式，因此Unity项目的瓶颈模式无法应用于基于虚幻引擎（UE）的XR项目。为了填补基于虚幻引擎的XR项目在XR性能优化方面的知识空白，我们对7个UE XR项目、78个UE XR讨论问题和3个UE文档来源的性能优化进行了首次实证研究。我们的分析确定了14种类型的性能错误，包括12种与UE设置问题相关的错误和两种与CPP源代码相关的问题。为了进一步帮助开发人员根据已识别的错误模式检测性能错误，我们还开发了一个静态分析器UEPerfAnalyzer，它可以检测配置文件和源代码中的性能错误。
2022-11-03 cs.SE
scicode-lint: Detecting Methodology Bugs in Scientific Python Code with LLM-Generated Patterns
Authentic Research Partners, Princeton, NJ（真实研究伙伴，新泽西州普林斯顿）
提出scicode-lint，通过两级架构（构建时使用前沿模型生成模式，运行时使用小型本地模型执行）自动检测科学Python代码中的方法论错误，如数据泄露、交叉验证错误和缺失随机种子。
2026-06-01 cs.AI cs.LG cs.SE
Better Security Bug Report Classification via Hyperparameter Optimization
当发现安全漏洞时，应（a）~由安全软件工程师私下讨论;（b）~在安全补丁可用之前不向公众提及。软件工程师通常会向缺陷跟踪系统报告缺陷，并将其标记为安全缺陷报告（SBR）或非安全缺陷报告（NSBRs），而安全缺陷报告比非安全缺陷报告具有更高的被修复优先级。然而，可疑的安全漏洞报告经常被公开披露，因为错误标签问题（即，错误地将安全错误报告标记为非安全错误报告）。本文的目标是帮助软件开发人员更好地分类错误报告，识别安全漏洞作为安全错误报告，通过学习器和数据预处理器的参数调整。以前的工作已经应用了文本分析和机器学习学习器来分类哪些报告的错误与安全相关。我们对这一工作进行了改进，正如我们对五个开源项目的分析所示。我们将超参数优化应用于（a）学习器的控制参数;以及（b）处理目标类是所有数据的一小部分的情况的数据预处理方法。我们表明，优化的预处理器是更有用的比优化的学习者。我们还表明，从我们的方法获得的改进可以是非常大的。例如，使用与我们的基线方法最近分析的相同的数据集，我们表明，调整数据预处理可以使分类召回率提高35%至65%（中位数至最大值），并适度增加假阳性率。
2019-05-16 cs.SE
The GitHub Recent Bugs Dataset for Evaluating LLM-based Debugging Applications
针对 Defects4J 可能已进入 LLM 训练数据导致评估失真的问题，本文构建 GHRB 数据集，提供 OpenAI 截止日期后的 76 个真实 Java 缺陷。
2023-11-02 cs.SE
FuzzyFlow: Leveraging Dataflow To Find and Squash Program Optimization Bugs
本文提出FuzzyFlow框架，利用数据流程序表示捕获可复现系统状态和优化影响范围，实现快速语义等价性检查，并通过最小化测试输入算法，在真实应用中实现高达528倍的优化测试和调试加速。
2023-06-28 cs.SE
Detecting Argument-Swap Bugs Using Context-Enhanced Code Representations
Lakehead University（拉凯德湖大学）；University of Windsor（温莎大学）；Polytechnique de Montreal（蒙特利尔高等理工学院）；Queen’s University（女王大学）
本文提出BugProbe，一种无需调用到定义映射的基于学习的方法，利用上下文增强的代码表示检测Python方法调用中的参数顺序错误，在合成与真实数据集上取得高准确率并优于基线。
2026-09-17 cs.SE
Which Alert Removals are Beneficial?
Idan Amit
研究评估了警报移除对代码复杂度和虫害倾向的影响，通过三种方法发现减少复杂度的干预可降低未来虫害概率，影响约33%的Python文件。
2026-03-22 cs.LG cs.SE
Testing Database Engines via Query Plan Guidance
提出查询计划引导（QPG）方法，通过变异数据库状态生成多样查询计划，引导自动化测试发现数据库引擎逻辑错误，在SQLite、TiDB和CockroachDB中发现53个新错误，效率显著高于随机和覆盖率引导方法。
2023-12-29 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
Predicting Vulnerability In Large Codebases With Deep Code Representation
Cisco Systems（思科系统公司）
目前，当软件工程师为各种模块编写代码时，经常会引入各种类型的错误-编码，逻辑，语义和其他（其中大多数不会被编译和其他工具捕获）。其中一些bug可能会在测试的后期发现，很多时候客户会在生产代码中报告。公司不得不花费大量的资源，包括金钱和时间来寻找和修复错误，如果编码正确，这些错误本可以避免。此外，软件中隐藏的缺陷可能导致安全漏洞，从而可能使攻击者危及系统和应用程序。有趣的是，过去修复过的相同或相似的问题/错误（尽管在不同的模块中）往往会再次引入生产代码。我们开发了一个新的基于人工智能的系统，它使用从源代码创建的抽象树（AST）的深度表示以及主动反馈循环来识别和警告可能在开发本身时引起的潜在错误，即开发人员正在编写新代码（逻辑和/或函数）。这个工具与IDE集成为一个插件将在后台工作，指出现有的类似功能/代码段和这些功能中的任何相关错误。该工具将使开发人员能够在开发时就纳入建议，而不是等待UT/QA/客户提出缺陷。我们评估了我们的工具上的开源代码和思科代码库的C和C++编程语言。我们的研究结果证实，源代码的深度表示和主动反馈循环是预测代码中存在的安全性和其他漏洞的可靠方法。
2020-04-24 cs.LG cs.SE
Graph-Aware Fuzzing for Graph Database Management Systems
Tianjin University（天津大学）；Capital Normal University（首都师范大学）
针对图数据库管理系统现有测试方法不足，提出GRAF框架。通过基于级联依赖解析的图上下文感知查询生成有效多样查询，用执行状态反馈引导变异操作，提升测试效果，发现众多未知漏洞。
2026-07-07 cs.SE
