Page 164 - 《软件学报》2025年第10期
P. 164

李志强 等: SZZ  误标变更对移动      APP  即时缺陷预测性能和解释的影响                                    4561


                    本文第   1  节介绍研究背景及相关工作. 第         2  节介绍数据集的构建工作. 第       3  节描述本文实证研究的详细步骤.
                 第  4  节结合本文研究的问题和实验结果进行深入分析与总结. 第                  5  节对实验进行补充并阐述实验的有效性. 第            6
                 节对全文进行总结, 并对未来的研究工作进行展望.

                  1   背景及相关工作

                  1.1   数据集质量与  SZZ  算法
                    近年来, 数据集的质量问题受到越来越多研究人员的关注. 一些研究表明, 数据集质量问题会对缺陷预测模型
                 性能造成影响. Brid   等人  [18] 发现, 在软件开发过程中, 开发人员可能不会对修复缺陷的提交进行详细说明, 导致缺
                 陷丢失或者在导入存储库后与实际缺陷描述不符. Bachmann                等人  [19] 对文件层次的缺陷预测模型涉及的缺陷差异
                 问题进行了研究, 结果表明缺陷差异会对模型性能造成严重影响. 以上研究的数据来源于                           Bugzilla 的  ITS  系统  [18,19] ,
                 而本文的研究数据来源于         Git 版本控制系统.
                    为了探究数据噪音对文件层次以及变更层次的缺陷预测模型的影响, Kim                        等人  [20] 随机地将假阳性  (标注为有
                 缺陷但实际无缺陷) 和假阴性         (标注为无缺陷但实际有缺陷) 样本加入数据集, 结果发现数据集的错误标注样本数
                 量占比在   25%–35%  时会严重影响缺陷预测模型的性能. Antoniol 等人          [21] 和  Kochhar 等人  [22] 发现部分问题报告被
                 标注成了有缺陷, 但实际上并没有缺陷, 出现误报的情况. Herzig               等人  [23] 对  7 000  多个缺陷报告进行了人工检查,
                 他们发现缺陷报告并不会导致缺陷修复报告被误标, 但存在大部分的缺陷报告被误标的情况. 在此基础上,
                 Tantithamthavorn  等人  [24] 深入研究被错误标注的缺陷报告对文件层缺陷预测模型的影响, 他们发现错误标注的缺
                 陷报告只影响模型的召回率, 对模型的准确率无明显影响. 在实际开发过程中, 开发人员提交的一次代码变更可能
                 涉及多个方面     (例如缺陷修复和代码重构), Herzig       等人  [23] 将这种变更称为复杂的代码变更        [25] . 他们发现复杂的代
                 码变更对代码的缺陷标注工作影响并不大, 只有少部分无缺陷的文件被错误的标注为有缺陷. 因此, 复杂的代码变
                 更对缺陷预测模型不会造成显著影响. 此外, 他们进一步的研究发现, 复杂的代码变更会影响源文件                              16.6%  的相关
                 缺陷数量, 产生了数据噪音, 进而对预测文件的缺陷数量模型造成较大影响. 与此不同, 本文重点研究不同                               SZZ  算
                 法的数据标注过程中所产生的噪音对移动               APP  即时缺陷预测模型的影响, 这些噪音是由            SZZ  算法本身所造成的.
                  1.1.1    原始  SZZ (basic SZZ) 算法
                    为自动识别代码库中含有缺陷的变更, Sliwerski 等人            [12] 提出了  SZZ  算法, 称为原始  SZZ (B-SZZ). 它是一种
                 基于版本控制历史的算法, 通过分析源代码的变更历史和缺陷报告之间的关联性, 来定位可能引入缺陷的代码变
                 更. 图  1  展示了  B-SZZ  识别某款移动  APP  项目中一个缺陷的示例, 包括       4  个步骤.
                    ● 从代码提交记录中检索修复该缺陷的提交报告. 此前许多项目使用问题跟踪系统                             (issue tracking system,
                 ITS) 来存储缺陷报告, 例如     JIRA, 每个缺陷对应一个唯一标识符, 其表示为             (项目名称-缺陷标识符). 一般情况下,
                 开发人员修复缺陷以后, 会将缺陷标识符记录在更改的提交信息中. 在                      Git 版本控制系统中, B-SZZ   首先在检查变
                 更日志中是否包含缺陷关键词, 如          Step 1  中, 变更信息包含缺陷关键词: “Fix”, 表示该次变更修复了缺陷.

                    ● 识别有缺陷的代码行. B-SZZ       利用版本控制系统       (version control system, VCS) 中的  diff 命令来识别缺陷修
                 复所更改的代码行. 在      Step 2  中, B-SZZ  算法识别出的缺陷修复的代码涉及        AudioPlayerFragment.java 文件中的一
                 行  if 条件语句, 由于缺少条件导致了空指针异常, 因此            B-SZZ  算法认为该代码行存在缺陷.
                    ● 识别引入缺陷的变更. B-SZZ       算法对含有缺陷的代码行进行溯源, 识别出这些代码被首次引入的变更记录,
                 而有缺陷的代码部分可能包含很多行, 识别出的提交记录也可能包含很多个. Sliwerski 等人                      [12] 使用  VCS  的内置注
                 释命令   (例如  git blame) 来对代码历史进行溯源. 如    Step 3  所示, B-SZZ  识别出变更  292c9bf15  引入了缺陷.
                    ● 对识别出引入缺陷的变更进行过滤. B-SZZ           对引入了缺陷的变更进行筛选, 例如, 正确引入缺陷的变更应该
                 发生在缺陷修复之前, 在缺陷修复变更            05606507b  的提交日期之后所识别的引入缺陷的变更不符合现实规律, 因
                 此被去除. 变更    292c9bf15  的提交日期在缺陷修复变更        05606507b  之前, 并且引入了   05606507b  所修复的缺陷代
                 码, 所以  B-SZZ  将其识别为引入了缺陷的变更.
   159   160   161   162   163   164   165   166   167   168   169