Practitioners’ Expectations on Automated Code Comment Generation

@inproceedings{hu2022practitioners,
  title={Practitioners' expectations on automated code comment generation},
  author={Hu, Xing and Xia, Xin and Lo, David and Wan, Zhiyuan and Chen, Qiuyuan and Zimmermann, Thomas},
  booktitle={Proceedings of the 44th International Conference on Software Engineering},
  pages={1693--1705},
  year={2022}
}

0 Abstract

  • However, it is unclear whether these techniques can alleviate comment issues
    and whether practitioners appreciate this line of research.
    问题:然而,这些技术是否缓解了注释问题,以及从业者是否欣赏这一研究方向尚不清楚。

1 Introduction

  • 尽管有大量关于代码注释生成的研究,但不幸的是,很少有研究调查了从业者对注释生成研究的期望。目前尚不清楚从业者是否欣赏这一研究方向。即使他们欣赏,也不清楚他们是否会采用代码注释生成工具,什么因素影响他们的采用决策,以及他们的最低采用门槛。从业者的观点对于帮助软件工程研究人员制定满足开发人员需求的解决方案至关重要。此外,一些从业者期望与研究之间的差距尚未得到调查。
  • 为了获得从业者在代码注释生成上的期望
    • 我们首先对16位各个公司的专家进行了半结构化的采访。通过采访,我们量化了采访者在编程实践中的注释时间和问题,以及他们对自动注释生成的期望。
    • 随后我们从720个开发者的问卷调研中验证了我们的想法,这些开发者来自26个国家6个大洲。
    • 在调查之后,我们进行了对最新论文的文献回顾。然后,我们将论文中提出的技术与从业者采用的标准进行了比较。
  • 我们将探究以下4个研究问题
  • RQ1:现在代码注释实践状态是什么,问题是什么
    • 82%人会写注意,81%在读没有注释的代码时感到困惑
    • 69%和62%的人认为 注释的缺失和笼统的注释是主要问题
  • RQ2:自动化代码注释工具对从业者有用吗?
    • 80%认为值得且必要
    • 78%认为这些工具可以更好帮助他们理解源代码
  • RQ3:从业者对自动化代码注释工具的期望是什么?
    • 85%期望工具在函数级别上注释,信息包括 1)函数做了什么(功能);2)如何使用方法;3)为什么这个方法存在
    • 最需要注释的地方是复杂、棘手和非自解释的方法
    • 生成的注释的最佳长度是2-3行。生成的注释应满足附加信息量、内容充分性和简洁性
  • RQ4:当前最先进的研究在满足从业者的需求和要求之前,其接近程度如何?
    • 25篇论文,17个在函数等级生成注释
    • 然而很少文章注释 “how to use” “why a method exists” 想你洗
    • 大多数论文专注于测量生成的评论和人类撰写的评论之间的重叠N-gram,而这并不是从业者的首选
    • 没有论文评估生成的评论中额外的信息数量,这是大多数从业者期待的
  • 我们的研究旨在帮助研究人员考虑从业者的需求,以继续发展更好的代码注释生成技术,最终实现高采纳率和满意度。贡献如下
      1. 采访了16位专业人士,并对720名从业者进行了调查,解释了从业者的期望,包括了他们对注释生成重要性的看法以及他们采用或不采用这些技术的门槛和原因
      1. 我们回顾了过去10年在SE和AI顶级刊物上的论文,我们将当前的研究状态和从业者的需求进行了比较,并强调了下一步可以做什么满足从业者的需求

2 RESEARCH METHODOLOGY

  • 研究有3个阶段
    • 阶段1:与专业人士进行访谈,了解他们在代码注释方面的实践、面临的问题以及对代码注释生成技术的期望。
    • 阶段2:通过在线调查来确认和扩展基于访谈得出的关于代码注释的结论。
    • 阶段3:进行文献回顾,分析当前最先进研究在满足从业者需求和要求方面是否以及在多大程度上取得了成功。访谈和调查已获得相关机构审查委员会(IRB)的批准。

Stage 1:Interview

  • 本阶段目标理解专业人员在软件开发中的注释实践和问题,以及他们对代码注释生成的期望
  • 采访分为3部分
      1. 参与者的背景信息
      1. 开放问题:他们认为的好的或坏的代码注释
      1. 讨论他们面对与代码注释相关的的实践和问题
  • 数据分析:使用NVivo量化分析软件

Stage 2:Survey

设计

  • 调研可以分为六部分
      1. Demographics
      1. Commenting Practices
      1. Commenting Issues
      1. Tool Importance:这部分给调查对象代码注释工具直接的描述,并询问他们如何看待这类工具的重要性,具体陈述如下:
      • (i) essential:我每天都会使用这个工具来帮助软件开发或代码理解
      • (ii) worthwhile:我会使用这个工具来帮助软件开发或代码理解
      • (iii) unimportant:我不会使用这个工具
      • (iv) unwise:这个工具会损害我或我的团队的生产力。
      • 然后,我们询问了从业者关于重要性方面的问题(例如,提高开发效率和代码可读性)
      1. Practitioners’ Expectations
      • 从业者的期望,包括 偏好粒度等级
      • 期望的注释内容,注释位置,不同注释等级对应不同长度的注释
      1. Tool Adoption:询问受访者影响他们使用注释生成工具的因素,我们询问了以下因素
      • minimum Turing Test rate:自动生成的注释和人工注释的区别
      • maximum revised rate:最大修改率
      • minimum efficiency:生成注释用时
  • 最后进行自由建议实践
  • 我们也对另一些人询问了我们调查问卷的问题
      1. 调查问卷的长度是否合适
      1. 问题是否清晰
  • 对中国参与者搞了中文

参与者要求

    1. 通过IT公司的关系,获得598份回复
    1. github仓库顶尖开源仓库,向2000名潜在开发者发送链接,获得137份回复

Stage 3:Literature Review

  • 通过以下几个因素考虑技术的能力
    • 粒度等级
    • 注释什么
    • 那里注释
    • 评估指标

3 RESULTS

Finding 1:年轻从业者在读没有注释的代码时感到困惑的比例搞。软件项目中注释的质量和数量优先,很少有团队进行注释回顾
Finding 2:缺失注释和没有提供过多信息的笼统注释是最频繁的问题
Finding 3:80%受访者认为代码注释生成工具对他们有用。但这个发现不能证明大多数工具会有用,这表示代码注释生成工具不是无用的
Finding 4:方法级别的注释最被需要。小部分(28%)期望语句级别的注释
Finding 5:对于类级别的注释,功能和如何使用类是参与者期望自动化注释生成工具生成的最重要的信息。有着复杂逻辑和设计模式的类需要被好好地注释
Finding 6:对于方法级别的注释,功能,如何使用,输入和输出,设计原理是需要注释的重要信息。大部分参与者希望生成这样的信息。换句话说,注释需要从 是什么,怎么用,为什么方面来。
Finding 7:对于语句等级的注释,大多数受访则会需要包括功能和设计原理的注释。
Finding 8:在3个维度上,工具生成2-3行的注释最佳
Finding 9:大多数论文生成了描述代码片段做什么的注释(功能和实现细节),少部分描述了如何使用和它为什么存在。考虑到需要被注释的代码片段的类型,大多数研究为所有类型的代码片段生成了注释,但是在对的地方生成注释比在所有地方生成注释更重要
Finding 10:现有工具(1行)和从业者期望(2-3行)的生成注释的行数有巨大区别
Finding 11:大多数论文专注于测量生成评论和人类编写评论之间的重叠N-grams,大多数受访者所并不偏好。所有研究都忽略了从业者最重视的附加信息量(即,除了从扫描源代码中容易获取的信息之外的量)

4 DISCUSSION

4.1 Implications 影响

  • Comment completion tools
  • Identifing where to write comments
  • Describing why a code snippet exists
  • Evaluation Criterion
  • Detecting inconsistencies between comments and source code
  • Checking if the source code is self-explanatory

4.2 Threats to Validity

  • 从业者回答的问题可能不准确

5.1 Audomated Code Comment Generation

5.2 Studies on documentation practices

6 CONCLUSION AND FUTURE WORK

  • 本文我们采访了16位找专家,调研了720名从业者,关于他们在注释实践中遇到的问题,以及他们对代码注释生成工具的期望。
    • 从业者对注释生成技术研究很热情,期望工具能生成不同粒度的注释
    • 从业者期望评论生成在评论内容、评论位置、评价标准、有效性和效率等方面满足要求。
  • 我们也会比较当前研究状态中评论生成的能力与从业者对采用的期望,以识别差异。我们指出了SOTA研究的缺陷和为未来注释生成工具更好地被从业者采用的发展的路
  • 未来研究应在正确的位置生成注释而努力而不是在所有地方。此外,未来研究应该更关注从业者重视的评估指标

Practitioners’ expectations on automated fault localization

@inproceedings{kochhar2016practitioners,
  title={Practitioners' expectations on automated fault localization},
  author={Kochhar, Pavneet Singh and Xia, Xin and Lo, David and Li, Shanping},
  booktitle={Proceedings of the 25th international symposium on software testing and analysis},
  pages={165--176},
  year={2016}
}

1 INTRODUCTION

  • Despite numerous studies on fault localization, unfortunately,
    few studies have investigated the expectations of
    practitioners on research in fault localization. It is unclear
    whether practitioners appreciate this line of research. Even
    if they do, it is unclear whether they would adopt fault localization
    techniques, what factors affect their decisions to
    adopt, and what are their minimum thresholds for adoption.
    Practitioners’ perspective is important to help guide software
    engineering researchers to create solutions that matter
    to our “clients”.
    问题:尽管有大量关于故障定位的研究,但不幸的是,很少有研究调查了从业者对故障定位研究的期望。目前尚不清楚从业者是否欣赏这一研究方向。即使他们欣赏,也不清楚他们是否会采用故障定位技术,什么因素影响他们的采用决策,以及他们的最低采用门槛。从业者的观点对于帮助软件工程研究人员制定满足我们“客户”需求的解决方案至关重要。

  • 我们调查了很多从业者获得了386份回复

    • 为了获得这些从业者,我们向我们在IT公司的联系发邮件
    • 我们也想开源仓库的从业者发了邮件
  • 在我们的调研中

    • 首先收集了回复者的个人信息
    • 接下来给出 错误定位研究的概述,询问受访者他们对该领域的重要性开发
    • 以及他们根据各种因素衡量的采用门槛:调试数据的可用性、粒度级别、成功标准、成功率、可扩展性、效率、提供理由的能力以及IDE集成。
  • 随后我们进行了文献调研,与从业者采用的标准对比
    探究以下研究问题

  • RQ1:从业者重视错误定位的研究吗?

  • RQ2:在调试会话期间,从业者可用的调试数据有哪些?

  • RQ3:故障定位技术应该针对哪些粒度级别(例如,组件、类、方法、基本块、语句)进行工作?

  • RQ4:从业者何时会认为一个故障定位技术在定位错误方面是成功的?

  • RQ5: 在采用一个故障定位技术之前,该技术的可信度(可靠性)需要达到多高?

  • RQ6: 在采用一个故障定位技术之前,该技术的可扩展性需要达到多高?

  • RQ7: 在采用一个故障定位技术之前,该技术的效率需要达到多高?

  • RQ8: 一个从业者会采用一个既可信、又具可扩展性、又高效的故障定位技术吗?

  • RQ9: 除了可信度、可扩展性和效率之外,一个故障定位技术还需要满足哪些额外标准,才能让一些从业者考虑采用?

  • RQ10: 当前的研究状态与满足从业者在采用前的需求和要求之间有多接近?

  • 贡献如下:

      1. 调研了386名从业者来自30个国家以回答9个重要的研究问题,这些问题揭示了从业者的期望,包括他们对故障定位重要性的看法、他们的接受阈值以及采用或不采用这些技术的原因。
      1. 我们回顾了过去5年发表的论文,比较了当前的研究现状与从业者的需求,并强调了为满足需要接下来可以做些什么。

2 RESEARCH METHODOLOGY

  • 从业者调研
    • 参与者要求
    • 调研设计
      • Demograohics
      • Practitioners’ Expectations
      • Data Analysis
  • 文献回顾

3 PRACTITIONERS’ EXPECTATIONS

3.1 Statistics of Responses Received

3.2 Findings

  • RQ1:错误定位的重要性
    • 按照职位看效果
    • 经历越少越觉得重要
  • RQ2:可用的调试数据
    • 可用:规范,单个失败测试用例,多个失败测试用例,通过的测试用例,bug报告
    • 数学形式规范没用,70%认为文本形式有用
    • 测试用例70%认为有用,bug报告80%认为有用
  • RQ3:倾向维度:method, statement, and block
  • RQ4: 最小成功标准:98%认为不超过10个程序元素需要检查
  • RQ5:信任度
  • RQ6: 扩展性
  • RQ7:有效性
  • RQ8:采用的意愿
  • RQ9:其它因素

3.3 Respondents’ Final Comments

  • 集成到集成工具
  • 需要支持多种语言和工作流
  • 需要额外的工作来解释bug的存在

4 CURRENT STATE-OF-RESEARCH

5 DISCUSSION

5.1 Implications

  • 缺陷定位的较大的需求
  • 高的采用门槛
  • 现有技术需要在信任度(可靠性)上有大的改善
  • 在可扩展性上需要改善
  • 需要研究提供适当如何调试的理由。
  • 需要全社区的努力,将最先进的故障定位技术整合到流行的集成开发环境中。

5.2 Limitations

  • 噪音回复
  • 通用性
  • 总体期望
  • 影响采用的因素
  • 采用的意愿 vs 实际采用
  • 从业者看法,期望和活动
  • 缺陷定位的实验性研究

7 CONCLUSION AND FUTURE WORK

  • 我们发现尽管从业者对故障定位的研究充满热情,但他们的采用标准很高。从业者希望一种故障定位技术能满足一些标准,包括调试数据的可用性、粒度级别、可信度(可靠性)、可扩展性、效率、提供理由的能力以及与IDE的集成。

  • 我们还比较了当前研究中故障定位技术的能力与从业者的采用标准,并识别出了差异。这些包括需要使最先进的故障定位技术更加可信、可扩展、能够提供有洞察力的理由,并集成到流行的IDEs中。

  • 我们的研究指出了未来工作的方向,以使故障定位技术得到从业者的广泛采用。

  • 在未来,我们计划开发更接近从业者期望的工具。

  • 我们计划在未来探索这些问题,例如

    • 为什么从业者更喜欢某些较粗的粒度?
    • 为什么经验丰富的开发者对自动故障定位不那么热衷?
    • 开源和职业从业者的期望有何不同?
  • 由于将太多问题放在一个调查中会负面影响参与度和响应质量[10],因此很难在一个研究中回答所有问题。此外,页面限制阻止我们对数据进行额外的分析和报告。作为另一项未来的工作,我们计划复制和扩展我们的研究,以解决第5节中强调的局限性。

How Practitioners Perceive Automated Bug Report Management Techniques

@article{zou2018practitioners,
  title={How practitioners perceive automated bug report management techniques},
  author={Zou, Weiqin and Lo, David and Chen, Zhenyu and Xia, Xin and Feng, Yang and Xu, Baowen},
  journal={IEEE Transactions on Software Engineering},
  volume={46},
  number={8},
  pages={836--862},
  year={2018},
  publisher={IEEE}
}

1 INTRODUCTION

**问题:**大量的软件工程研究投入到自动化的错误报告管理技术中,然而,这些技术是否真的必要并且适用于理论研究之外,这个问题仍然悬而未决

贡献:

    1. 总结了2006-2017的bug报告管理技术,分为了10类
    1. 调查了327名从业者对不同类别技术加制的观点,又采访了其中的25位
    1. 我们强调了从业者对不同技术排名背后了逻辑,并未具体的技术提供了一些潜在的提升

2 RESEARCH METHODOLOGY

2.1 Literature Review

  • 论文选择
  • 论文分类
  • 开源

2.2 Survey Design

Protocol

  • 回答以下问题
    • RQ1:从业者对自动化bug报告管理技术看法
    • RQ2:哪种自动化bug报告管理技术最受欢迎
    • RQ3:从业者如何考虑哪种技术重要或不重要
      Respondent Selection
  • For industrial professionals
  • For OSS(Open Source Software) active developers
    • 除开源软件的作者外,还有报告bug的用户
      Data Analysis

2.3 Interview Design

3 RESULTS

3.1 RQ1:How Do Practitioners Perceive Automated Bug Report Management Techniques?

  • 由于很多回复者是中国人,为了防止这是潜在的威胁,我们将中国人的结果与其它集过进行了比较,差异很小,我们排除了这种威胁
  • 对参与者职位,经验等进行分组,可以进一步探究
  • finding 1:总体:大部分参与者认为bug报告管理很重要
  • finding 2:按职位:测试人员认为bug报告管理的重要程度最高,其次是项目管理人员和开发人员
  • finding 3:按经历:有经验的从业者对bug报告管理的重要性比经验少的消极
  • finding 4:按教育背景:没有显著差异
  • finding 5:按人群:职业开发者比OSS从业者认为器重要性更高

3.2 RQ2:Which Are the Highly-Rated Automated Bug Report Management Techniques That Practitioners Deem Important?

  • finding 6:大部分参与者对自动化bug报告管理技术的重要性很高,其中Bug Localization, Bug-Commit Linking 最被从业者认可
  • finding 7:B1,4,5,6相对高,8,10最低
  • finding 8
  • finding 9

3.3 RQ3:Why Do Practitioners Consider Certain Teechniques as Important or Unimportant?

  • 为了更好地理解为什么某些技术被从业者视为重要或不重要,我们对从调查受访者和采访对象收集到的答案/评论进行了主题分析。

  • 主题分析是一种旨在识别和记录文本文件内“主题”(即模式)的技术。它通常包括5个步骤:(1)阅读文档以熟悉数据,(2)为数据生成初始代码,(3)在代码中搜索潜在主题,(4)审查和精炼主题,以及(5)定义和命名最终主题。主题分析已在许多过去的软件工程研究中进行,例如[40]、[41]。

  • 本节对所有的10类技术都进行了分析

4 DISCUSSION

4.1 General Insights Across Categories

  • 从业者认为bug报告管理技术很重要
  • 对工具的采用取决于开发者对错误报告管理技术所提建议可靠性的相信程度。
  • 需要综合考虑多个数据来源来改善缺陷报告管理技术。
  • 软件工程实践是多样化的,必须更好地描述特定错误报告管理技术特别需要的背景和情境。
  • 困难的例子需要更多的注意
  • 将研究原型集成到常用工具中是值得的。

4.2 Insights on Specific Categories

4.3 Threats to Validity

Literature Review:

  • 可能错过了相关的研究,我们采取了以下措施
      1. 考虑了17各可能的期刊文献场所
      1. 选择2006年以来(该领域出现的时间)的论文
  • 分类有问题:二人一块分类
    Survey
  • 不诚实的回答。措施:
    • (1)允许我们的调查受访者匿名参与;如果参与者不留下电子邮件地址,他们将无法被追踪;他们也可以留下新的/匿名的电子邮件地址
    • (2)保证个人信息不会被传播。 如[81]说,匿名性和保密性有助于从调查受访者那里获得坦诚的回答。
  • 回答者对技术理解不充分
    • 准备了 “I don not understand ”选项
    • 准备了英语和中文两种语言
  • 参与者的自我选择,结果/发现可能会偏向于那些更有可能/愿意填写问卷的人(例如,有额外空闲时间的实践者)。
    Interview
    Thematic Analysis
  • 从业者对软件工程的总体看法,本文专注于从业者对软件工程中具体话题,也有其它的类似工作。
  • 除了探究从业者对现有技术价值观点的探究外,还有其它研究帮助研究者更好地理解软件开发和开发者行为的特点

6 CONCLUSION AND FUTURE WORK

Smart contract security: A practitioners’ perspective

@inproceedings{wan2021smart,
  title={Smart contract security: A practitioners' perspective},
  author={Wan, Zhiyuan and Xia, Xin and Lo, David and Chen, Jiachi and Luo, Xiapu and Yang, Xiaohu},
  booktitle={2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE)},
  pages={1410--1422},
  year={2021},
  organization={IEEE}
}

1 INTRODUCTION

**问题:**尽管在确保智能合约安全方面做出了许多努力,但关于软件从业者如何在实践中将安全性构建到智能合约中的信息却知之甚少。

  • 因此,我们采用了混合方法来调查从业者对智能合约安全的看法和实践。
    • 我们从与13位有智能合约开发经验的软件从业者进行半结构化访谈开始
      • 通过访谈,我们定性地调查了受访者在智能合约开发中的安全意识和实践。我们得出了智能合约开发中的6个竞争优先事项、11个安全激励因素和9个安全阻碍因素、5个从业者获取安全知识的渠道、11个安全策略以及11个影响安全工具采用的因素。
    • 进一步进行了一项探索性调查,调查对象包括来自六大洲35个国家的156名智能合约从业者,以定量验证我们在访谈中发现的安全感知和实践。
      探究问题:
      RQ1:从业者对智能合约安全的看法
      RQ2:安全如何适应智能合约的开发周期
      RQ3:区块链平台会影响从业者在智能合约安全上的观点和实践吗
  • A 软件开发中的安全实践
  • B 智能合约安全

3 METHODOLOGY

  • A Interviews
  • B Survey
    • Demographics
    • Perceptions on Smart Contract Security
    • Security Practices in Smart Contract Development
    • Factor Analysis
    • Comparison

4 RESULTS

RQ1: Perceptions on Smart Contract Security

  • Impotance of Security
  • Security Motivators
  • Security Deterrents
  • Experiencing Security Problems
  • Sources of Security Knowledge
    RQ2:Security Practices in Smart Contract Development
  • Efforts toward Security
  • Strategies to Address Smart Contract Security
  • Tools to Address Smart Contract Security
    RQ3: Influence of Blockchain Platforms on Smart Contract Security

5 DISCUSSION

  • Security Awareness and Risks of Smart Contract
  • Code Reuse and Tool Implications in Smart Contract
  • Studies across Blockchain Platforms

6 THREATS TO VALIDITY

Internal Validity

  • 采访偏差
  • 回答者噪音
    Construct Validity
  • 采访和调研的自身的问题
    Conclusion Validity
    External Validity

7 CONCLUSION

Software Documentation: The Practitioners’ Perspective

  • A crucial first step is to understand what quality means for practitioners and what information is actually needed for specific tasks.
  • 翻译:理解从业者对质量的理解和实际需要的信息
  • 我们对146名从业者进行了2个调研
      1. 他们认为的文档问题,及这些问题出现时他们的解决措施
      1. 在不同任务中都重要的文档类型
        research question
  • RQ1:什么文档问题与从业者有关
  • RQ2:哪种文档被从业者认为在不同任务中是重要的

How Practitioners Perceive Coding Proficiency

问题:什么技能影响一个人的代码熟练度?

  • 为了回答这个问题,我们调研了340位软件从业者。
  • 我们首先通过采访15名开发者,获得38种,分为9类的代码熟练技能。随后我们要求调研的参与者对这些技能进行排位,并给出他们的理由。
  • 我们的研究结果突出了21种重要的技能,我们讨论我们发现的影响
    RQ:
  • RQ1:从业者对38种派生的代码熟练技能的看法
  • RQ2:哪些时从业者认为重要的技能
  • RQ3: 为什么从业者认为某些技能重要或不重要

Practitioners’ Views on Good Software Testing Practices

问题: 尽管存在软件测试,但bug普遍存在,者引出了测试用例质量的问题,并促使我们研究什么构成了好的测试用例

贡献

    1. 我们采访和调研了许多业界和开源从业者来探究好的测试用例的特征
    1. 我们提供了6个维度29个好的测试用例的特征:测试用例内容,大小,复杂度,覆盖率,可维护性,bug检测率及其它。这些特性可以为从业者提供关于他们需要为创建测试用例考虑的因素的见解,并遵循良好的测试实践。
    1. 我们阐述了从业者对每个特性表示赞同或反对的理由,并在此过程中强调了从业者在创建测试用例时需要考虑的权衡和特殊情况。

调研RQ

  • RQ1:参与者如何排位29个测试用例特性
  • RQ2:参与者不同意这些测试用例特征的原因是什么

Trust Enhancement Issues in Program Repair

1 介绍

令人惊讶的是,无论是学术界还是工业界,关于开发者对程序修复的信任的文献或系统研究都很少。

本文中研究了如何增强开发者对自动生成的补丁的信任的问题,首先确定了与开发者对自动生成的补丁的信任相关的研究问题,分为两个类别

  • a. 开发者对自动修复技术的期望

    • RQ1:开发者对应用自动化程序修复(以下简称APR)的兴趣程度有多大,以及他们如何设想使用它?
    • RQ2:软件开发人员可以提供额外的输入来增加对生成的补丁的信任度吗?
    • RQ3:自动程序修复(Automated Program Repair,APR)产生的补丁能增加开发者的信任的证据有哪些?
  • b. 现有程序修复技术在满足开发者期望方面可能存在的不足,

    • RQ4:现有自动修复技术能否在可接受的时间范围内(0.5/1/2 小时)确定高质量补丁的位置
    • RQ5:在APR的效率上,额外的输入(例如修复位置和额外的测试案例)会带来什么影响
  • 对于a,我们在100多名专业软件开发人员中进行调查(共有35个问题),结果显示

      1. 开发人员对使用APR生成的少量(不超过10个)补丁持开放态度,但这些补丁要在可接受的时间范围内生成
      1. 开发人员愿意接受程序修复方法的标准(可以证明程序修复的正确性),同时也愿意提供额外的输入来推动APR的发展
      1. 开发人员最接受的额外输入是额外的测试用例
  • 对于b

      1. 在我们的实验中会严格要求时间不超过1小时
      1. 同时对著名的修复工具进行比较和定量分析,得出结论:搜索空间的表示在在可接受的时间范围内产生合理/正确的补丁中很重要
      1. 注意到APR可以视为微观层面的自动代码生成,通过研究APR的信任问题,我们也可以初步了解如何增强自动生成代码的信任

2 程序修复中的规范

  • 本段回顾这些规范讨论他们如何影响补丁的质量

  • 测试套件即规范 Test Suites as Specification.

    • 修复目标:通过测试组件中所有测试用例来修复程序
    • 问题:带来过拟合,因为测试套件可能不完整
  • 约束即规范 Constraints as Specification

    • 修复目标:修补程序使满足给定的约束
    • 问题:实际中不能总是可以得到约束条件;同时满足约束后的程序不一定和源程序功能相同
  • 代码样式即规范 Code Patterns as Specification

    • 问题:不能满足功能的正确性

3 调查方法

  • 调查询问35个问题,分为6类,问题包括 开放性和封闭性问题的组合,采用多项选择或5点李克特量表,问卷使用Microsoft Forms创建和部署
    • C1 APR的使用情况(RQ1):开发人员是否会使用APR,以及如何使用。
    • C2 输入/规范的可用性(RQ2):开发人员可以为APR技术提供哪些类型的输入工件。
    • C3 对信任的影响(RQ2):额外的输入将如何影响对自动生成的补丁的信任。
    • C4 解释(RQ3):开发人员期望自动生成的补丁提供哪些证据/解释。
    • C5 APR副产品的使用情况(RQ3):APR的哪些副产品对开发人员有用,例如用于手动修复错误。
    • C6 背景:参与者在软件开发过程中的角色和经验。
  • 通过两个渠道发放调查问卷 (1) Amazon Mturk,(2)向全球公司联系人放松私人链接. 随后对回复进行过滤,最终得到了103个有效的回复

4 调查结果

4.1 开发人员在APR中的参与

  • APR的接收度
    • 72%的人愿意回顾生成的补丁
    • 开发者一般解决一个bug不超过2h,这意味着APR生成补丁的时间不宜过长
    • 80%的人认为额外的工件(如测试用例)可以增加补丁的信任度,其它工件如测试套件,静态分析工具,人工对补丁的检查
  • APR的交互使用
    • 交互:大多数参与者提及低交互次数
    • 输入:测试用例>bug 报告(栈轨迹,环境细节,运行日志)
    • 输出:解释(根因),可能的其它补丁,测试报告
    • 集成:DevOps流水线,测试失败时自动生成补丁交由开发者审查,APR最重要的是节省开发者时间

4.2 额外工件的可用性和影响

  • 可用工件:软件开发人员可以提供额外的工件,如测试用例、程序断言、逻辑约束、执行日志以及相关的源代码位置。
  • 信任的影响:额外的测试用例对APR的信任有很大的影响。有自动化测试生成提升APR的信任度的可能

4.3 补丁 解释/证据

  • 补丁证据:软件开发人员希望看到补丁正确性的证据,以有效地选择补丁候选项。他们希望看到的信息包括代码覆盖率以及覆盖的输入空间比例。
  • APR的副产品:我们的结果表明,APR的副产品,如故障和修复位置以及生成的测试用例,可以帮助手动补丁验证,从而增强对APR的信任。

5 评估方法 (RQ4,5)

6 评估结果 (RQ4,5)

7 有效性威胁

调研的外部威胁

  • 调查结论不够泛化。
    • 措施:所有研究工件开源,可以重复研究
  • 开发者不参与或志愿者偏差。
    • 措施:短时间调研,提供货币补偿
  • 潜在威胁:只有15%的参与者熟悉APR,除了Facebook和Bloomberg等公司
    • 措施:为了确保参与者对APR有所了解,我们在调查表开始时添加了描述和指向示例视频的链接。
  • 开发者可能先入为主,不会使用APR
    • 措施:探究影响使用APR的因素

调研的构造有效性

  • 匿名性:鼓励提供坦诚回答
  • 控制问题:筛选非真实回答
    • 控制问题(control questions)是调查或研究中用于验证参与者回答真实性和一致性的问题
  • 定性分析编码:减少误解风险

调研的内部有效性

  • 调研者对问题的不充分理解
    • 措施:预先调研,获得反馈,调整问题
  • 参与者可能提供了多份回复

对实验结果的有效性威胁

  • 实证研究未包含全部APR工具
    • 措施:包括了主要的APR理念
  • 选用广为人知的数据集
  • 使用默认参数,模拟初学者

8 相关工作

9 结论

  • 本文研究了增强开发人员对自动生成补丁信任所涉及的问题。
    • 通过对100多名从业者的详细研究,我们探索了开发人员对自动化程序修复工具的期望和容忍度。
    • 随后,我们对现有修复工具进行了定量评估,以模拟初学者使用APR工具的经验。
  • 我们的定性和定量研究表明,需要探索以下方向以获得开发人员对补丁的信任——与修复工具的低互动、交换工件(例如生成的测试用例作为输入和修复工具的输出),以及关注抽象搜索空间表示而不仅仅是搜索算法框架。- 每个修复工具都有许多参数,我们仅使用了默认的参数设置,这些设置符合初学者的预期——我们没有探索各种参数设置。为了全面了解修复工具的能力,未来值得系统地探索大量参数设置,并尝试使用不同的超时设置。