[Paper] Bug 优先级变更预测:Apache 软件的探索性研究
发布: (2025年12月10日 GMT+8 08:59)
6 min read
原文: arXiv
Source: arXiv - 2512.09216v1
概览
本文解决了现代问题追踪中一个出人意料被忽视的问题:预测 bug 的优先级何时会在其生命周期内发生变化。通过对 32 个 Apache 项目的数据进行挖掘,作者展示了源自 bug 修复过程的特征——结合对类别不平衡的智能处理——能够以令人鼓舞的准确率预测优先级变动,为更主动的分流和资源分配打开了大门。
主要贡献
- 两阶段预测框架,将 bug 报告 与 bug 修复 阶段分离,为每个阶段训练专用模型。
- bug 修复演化特征(如评论频率、开发者活跃度、代码变更度量),捕捉 bug 上下文随时间的演变。
- 类别不平衡缓解策略(过采样 + 成本敏感学习),针对优先级变化的高度偏斜分布进行定制。
- 大规模实证评估,使用来自 32 个 Apache 项目、超过 20 万条 bug 报告的精心构建数据集,报告最高 F1 分数达 0.80。
- 跨项目分析,揭示在一个项目上训练的模型在其他项目上的迁移效果以及不同优先级层级的性能差异。
方法论
-
数据收集与标注
- 从 Apache JIRA 中提取 bug 报告,聚焦非平凡项目(如 Hadoop、Spark)。
- 根据每个 bug 的优先级字段历史,将其标记为 “优先级已变更” 或 “未变更”。
-
生命周期分段
- 报告阶段:从 bug 创建到第一次状态变更(例如 Open → In Progress)。
- 修复阶段:从第一次状态变更到 bug 被解决/关闭。
-
特征工程
- 静态属性:初始优先级、严重程度、组件、报告者声誉。
- 动态演化属性:评论数量、评论间隔时间、参与开发者数量、代码行变更量、测试覆盖率影响等。
-
处理类别不平衡
- 使用 SMOTE(合成少数类过采样技术)生成合成的“优先级变更”实例。
- 融入 成本敏感分类器,对少数类误分类施加更高惩罚。
-
模型训练与评估
- 测试了多种算法(随机森林、XGBoost、逻辑回归)。
- 采用分层 10 折交叉验证,报告 F1‑score、F1‑weighted 与 F1‑macro。
-
跨项目与优先级层级实验
- 在一个项目上训练,在另一个项目上测试,以衡量通用性。
- 分析不同优先级层级(如 P1‑Critical 与 P4‑Low)的性能表现。
结果与发现
| 阶段 | 指标 | 分数 |
|---|---|---|
| 报告阶段 | F1(二分类) | 0.798 |
| 修复阶段 | F1‑weighted | 0.712 |
| 修复阶段 | F1‑macro | 0.613 |
- bug 修复演化特征 始终优于仅使用静态属性的基线模型。
- 不平衡处理策略 为两个阶段的 F1 提升了约 6 % 的平均增益。
- 跨项目迁移:虽然在不同项目上应用模型时绝对分数会下降,但大多数配对的加权 F1 仍保持在 0.60 以上,表明具有相当的可移植性。
- 优先级层级稳健性:在 P1‑P4 各层级的预测质量相对稳定,说明该方法并未偏向高严重度的 bug。
实际意义
- 自动化分流助手:将模型集成到 JIRA 或 GitHub Issues 中,标记可能需要提升优先级的 bug,促使项目经理提前审查。
- 资源规划:团队可以预见高优先级工作量的激增,主动调整冲刺容量或分配值班工程师。
- 降低人为偏见:通过提供数据驱动的建议,系统缓解因“分流疲劳”导致的主观过度或不足的优先级分配。
- 跨项目知识共享:开源基金会可以为新项目提供预训练模型,快速实现高效的 bug 管理,无需大量本地数据收集。
局限性与未来工作
- 数据集范围:研究聚焦于 Apache 项目;在商业或规模较小、工作流不同的仓库中结果可能有所差异。
- 特征时效性:部分演化特征(如评论速度)需要实时更新,若在大规模环境下计算成本较高。
- 优先级变更粒度:二元的“变更 vs. 未变更”标签忽略了变更方向(提升或降级)及幅度。
- 未来方向:
- 拓展至 多类预测(预测具体的新优先级)。
- 探索 深度学习序列模型(如 Transformer)以捕获更丰富的时间模式。
- 开展 用户研究,评估开发者在实际使用优先级变更推荐时的交互体验。
作者
- Guangzong Cai
- Zengyang Li
- Peng Liang
- Ran Mo
- Hui Liu
- Yutao Ma
论文信息
- arXiv ID: 2512.09216v1
- 分类: cs.SE
- 发表时间: 2025 年 12 月 10 日
- PDF: Download PDF