Bug修复的设计空间以及开发人员如何导航外文翻译资料

 2022-01-27 21:49:28

英语原文共 29 页,剩余内容已隐藏,支付完成后下载完整资料


Bug修复的设计空间以及开发人员如何导航

爱默生·墨菲-希尔,托马斯·齐默尔曼,克里斯蒂安·伯德和纳恰潘·纳加潘

摘要-当软件工程师修复bug时,他们可能有几个选项来解决这些bug。他们选择的修复对实践者和研究人员都有很多含义:修复期间引入其他bug的风险有多大?错误修复是否与导致错误的代码相同?变更是修复了原因还是仅仅覆盖了症状?在本文中,我们研究了对bug的替代修复,并对工程师如何选择修复bug的设计进行了实证研究。我们从Pex4Fun环境的一个激动人心的案例研究开始。然后,基于定性采访40工程师致力于各种产品,数据从6缺陷分类会议,并填写调查326年微软工程师和37开发商从其他公司,我们发现许多因素,其中许多非技术,影响错误是固定的,比如如何接近释放软件。我们还讨论了对研究和实践的影响,包括如何使错误预测和定位更加准确。

索引术语-设计概念,软件设计中的人为因素,可维护性

—————————— ——————————

  1. 介绍

当软件工程师必须使我们创建和维护的软件系统在能力和复杂性上不断增长

Social Factors

Ri sk

Management

Hardcoding

Error Surfacin g

Cause Understanding

Int er face Breakage

Refact oring

Methodology: 40 interviews, 6 triage meetings, 363 survey responses

Design Space

Data Propagation

Internal Vs Functionality

External Removal

Accuracy

Behavioral

Alternatives

Navigating Design Space

User

Behaviour

Consistency

确保这些系统正常工作。如果系统没有这样做,软件工程师就会修复导致这种意外行为的“bug”。

传统上,研究人员和实践者认为,软件中工程师永远无法修复错误的位置就是产生错误的位置。例如,Endres[2]在一项研究中做出了这样的假设,但提醒读者,

当然,最初的问题是我们如何才能阻止——我的问题是错误到底是什么。为了立即解决这个问题,我们将立即说,在这里描述的材料中,通常实际误差等于所作的修正。这并不总是很准确,因为有时真正的错误太深,因此花费的时间太长,引入新错误的风险太高,无法尝试解决真正的错误。在这种情况下,所作的纠正很可能只是补救了错误的一部分或绕过了问题。为了在分析中获得更大的准确性,我们真的不应该考虑所作的更正,而应该把原来计划的实现与实际执行的程序进行比较。然而,对于这一点,我们通常既没有手段,也没有基础材料。

尽管软件工程社区已经意识到这种假设有时是错误的,但是仍然存在

- - - - - - - - - - - - - - - - -

  • 墨菲-希尔就职于北卡罗来纳州立大学,北卡罗来纳州首府罗利27603。电子邮件:emerson@csc.ncsu.edu。

图1所示。描述错误修复程序的设计

几乎没有证据能帮助我们理解在什么情况下它是错误的。缺乏了解的后果是多方面的。让我们举几个例子。对于研究bug预测[3]和bug局部化[4]的研究人员来说,开发人员如何在过去修复bug的模型可能并不能捕获失败的真正原因,而只能捕获变通方法。对于实践者来说,当根据软件工程师修复了多少bug来评估他们时,评估可能不能准确地反映工程师对软件质量的影响。对于教育工作者来说,由于没有向未来的工程师传授决定应用哪个修复程序的上下文因素,未来的工程师可能会选择不合适的修复程序。

然而,就我们所知,还没有关于如何设计bug修复的经验研究。在这篇文章中,

  • 齐默尔曼就职于微软研究院,华盛顿州雷德蒙德98052。电子邮件:我们试图理解bug修复的设计。我们定义

tzimmer@microsoft.com。

  • 伯德就职于微软研究院,华盛顿州雷德蒙德市,邮编98052。电子邮件:cbird@microsoft.com。
  • N. Nagappan就职于微软研究院,华盛顿州雷德蒙德98052。电子邮件:nachin@microsoft.com。

错误修复的设计作为人为的想象过程

几种修复相同bug的方法,然后判断应用哪些修复。与任何软件更改一样

xxxx-xxxx / 0 x / xx美元。copy;200x IEEE 由IEEE计算机学会出版

在选择要进行什么更改时,工程师必须处理许多相互竞争的力量。这项任务并不总是那么简单。

这篇文章的早期版本是作为一篇交换意见的论文[5]出现的,它最初有一个主要的发明:bug修复设计的第一个系统特性。它分析了bug修复的设计空间,并描述了开发人员如何导航该设计空间,从而理解选择bug修复的决策(参见图1)。

    • Pex4Fun游戏的研究,激发我们的工作(第三部分)。
    • 复制我们最初对微软开发人员的调查,另外还有来自其他公司的37名开发人员(4.5节)。
    • 设计尺寸的附加说明(第5.1节)和设计导航选择(第5.2节),摘自最初的访谈。
    • 关于为什么开发人员避免重构的发现(第5.1节),他们如何破坏减少回归错误的政策,他们如何决定使用哪些分析方法来阻止挖掘错误频率,以及谁来决定要实现哪些错误修复设计(第5.2节),这些都来自我们最初的调查。
  1. 相关工作

一些研究人员已经研究了bug修复。也许最相关的研究是Leszak, Perry和Stoll关于缺陷原因的[6]研究,在该研究中,作者将bug报告按“真实缺陷位置”分类:

“真实的”位置描述了这样一个事实:有些缺陷不是通过纠正“真实的”导致错误的组件来修复的,而是通过在其他地方进行“变通”来修复的。

虽然作者收集了真实的缺陷位置,但是数据没有被分析或报告。我们的工作解释了为什么要选择一个修复而不是另一个;或者换句话说,为什么工程师会选择一个变通方案而不是在“实际位置”进行修复。

Ko和Chilana研究了100个有争议的开源bug报告,重点讨论了在开源bug修复方面的论证,比如修复的基本原理,以及当最终用户参与到[7]的辩论时,是否需要进行适当的调整。相反,我们关注的是bug修复本身的设计,而不是做出决策的过程。我们的研究还通过改进我们在修复bug时对决策过程的理解来补充这项研究,特别是对于商业软件和bug报告本身之外的决策。

Breu和他的同事在一项对600个bug报告的研究中发现,25.3%的bug报告讨论都花在了修复本身上,讨论内容包括建议、反馈请求和理解文件[8]。我们的研究通过探索bug修复的设计空间来完成这项工作。其他几位研究人员也对修复bug进行了研究。

在一次bug修复的手工检查中,Lucia和他的同事

发现一些修复程序分散在许多行代码[4]中。Bird和同事发现bug数据库中报告的bug修复与da- tabases[9]中没有报告的修复不同。Gu和他的同事调查了错误修复本身是错误来源的观点,发现错误修复大约占bug[10]的9%。Yin和他的同事研究了为什么bug是固定的incor——最近,也就是说,需要对原始补丁[11]更改后的源代码进行稍后的bug修复。Aranda和Venolia inves发现了10个封闭的bug,并调查了110名工程师关于Microsoft[12]的bug协调模式。Spinellis和他的同事试图将代码度量(如修复的bug数量)关联起来,以评估开源软件[13]的质量。Storey和同事研究了bug和代码注释[14]之间的交互作用。Anvik和他的同事调查了哪些工程师被派去修复[15]漏洞。与这些文章相反,我们的文章试图理解bug修复的不同之处,以及为什么选择一个修复而不选择另一个。

  1. 动机

有什么证据表明同一个bug可以通过多种方式修复?为了探究这个问题,并为本文的其余部分提供动力,我们转向了一个基于浏览器的学习环境,称为Pex4Fun,其中专业语法人员尝试解决编程挑战[16]。程序语法器会得到一些代码、一个带有参数和默认返回值的方法,并被要求修改程序,直到生成与谜题创建者最初创建的secret so- lution相同的输出。

尽管玩Pex4Fun并不是一个修复bug的任务,但这两种活动都是现有程序没有按照预期运行的活动,程序员的任务是修改程序表,使其符合开发人员只能逐步理解的规范。尽管Pex4Fun的环境约束比野外的bug修复少得多,但我们认为,如果Pex4Fun的解决方案存在差异,那么野外的bug修复可能存在更大的差异。

让我们来探索一个任意的Pex4Fun谜题的解决方案(图2)。在本文所使用的数据中,475名自选玩家在动脑筋解谜的同时提交了5612次尝试。共有260个不同的人成功地提交了正确的解决方案。解这个谜题的平均时间是12.25分钟。

在浏览260个提交的解决方案时,我们发现没有两个完全相同。许多在空格和注释上至少有细微的差别。然而,在许多解决方案之间也存在着重大的设计差异。

有几个解与原隐解相似,作为一个简单的代数公式:

using System;

public class Program {

public static int Puzzle(int x) {

表1方法总结

消防队的采访 面试

分流会议

调查 复制

目标

定性,

最低限度 定性的,冒失的 在

选择工程师 在一栋大楼里挑选工程师 在一个建筑

是可用的 一个错误报告

最新bug:软件、症状、原因、不止一种修复方法;如果是,详细说明

32个参与者 8人(4人8人 来自第五个产品组) 产品组

编码与 编码与

Atlas.TI Atlas.TI

定性,协同决策

量化观测

做笔记

15 - 20分钟

并观察

匿名

在沉默中

调查

协议

有限的价值

问题

因为团队

通知

定性

发现。

324年微软

反应

37个其他

反应

数据

全文共34162字,剩余内容已隐藏,支付完成后下载完整资料


资料编号:[342],资料为PDF文档或Word文档,PDF文档可免费转换为Word

原文和译文剩余内容已隐藏,您需要先支付 30元 才能查看原文和译文全部内容!立即支付

发小红书推广免费获取该资料资格。点击链接进入获取推广文案即可: Ai一键组稿 | 降AI率 | 降重复率 | 论文一键排版