近来我遇到越来越多的人对我们会发布还有bug的产品大为惊讶。而让我大吃一惊的是，这些人中还有许多是软件测试人员，我本以为他们应该对此早已经有所了解。建议大家先阅读Eric Sink较早写的(但是很棒的)文章。不知道我还能对此话题有多少贡献，但我想试试。
许多bug并不值得去修复。“你这也算是测试人员吗?”，你肯定会冲我大叫，“测试人员是产品质量的捍卫者。”我可以再重复一次(如果需要的话)许多bug并不值得去修复。“让我来告诉你原因。在大多数情况下，修复bug就必须要修改代码。而修改代码需要投入资源(时间)并会引入风险。这真是很糟糕，但这却是事实。有时，如果风险和投入远超过修复bug的价值，因此我们就不会被修复这些bug。
我们决定是否修复一个bug并不是，也不应该是靠“感觉”。我喜欢用“用户痛苦”的概念来帮助我做决定。我会用三个关键因素来考虑并确定“用户痛苦”：
1、严重性—— 这个bug将产生什么影响 —— 它会让整个程序崩溃吗?它会导致用户的信息丢失吗?或者并不是那么严重?有更简单的解决方法吗?还是它仅仅是个无关紧要的问题?
2、频繁性—— 用户碰到这个问题的频率高吗?它是程序主要工作流程中的一部分?还是隐藏在一个并不常用的功能中?在最常用的那部分程序中存在的小问题很可能是需要修复的，而一些不常用到的那部分程序中存在的大问题，也许我们会放在一边。
3、对客户的影响——如果你之前准备工作做得好，你应该已经知道你的客户是谁，你的每个客户群中会有多少(或者是你希望有多少)用户。这样你就需要判断，这个问题将会影响到每位用户一，还是仅仅一部分人。如果你能追踪出客户如何使用你的产品，你就能得到更准确的数据。
以上3点因素就构成了一个公式。给上面的每一个因素都分配一个数值范围，并且用一些计算 —— 你可以直接使用加法、乘法或是基于你的应用程序以及市场因素加上权值。打个比方，我们只需要执行加法并且对每个bug赋予10分的数值范围。
Bug #1：比如它是一个会让程序崩溃的bug(10分)，它存在于程序的主要部分(10分)，它影响了80%的客户(8分)，因此这个bug的”用户痛苦“量值为28分，我们打赌我们肯定会修复它。
Bug #2：它仅仅是一个关于排列的bug(2分)，它出现在二级窗口中(2分)，这个bug所在的那部分程序只会在旧版本中被使用到(2分)。因此这个bug的“用户痛苦” 量值为6分，我们很可能不会去修复它了。
遗憾的是，很多情况并不像上面所说的那么简单。Bug #3是一个数据丢失问题(10分)，它存在于一个应用程序的某个主要部分中，却只在某些特定的情况下才出错(5分)(顺便提一下，数据是主观编造出的)。客户研究证明它很少会被使用(2分)。因此它的 “用户痛苦”量值为17分，这是一个模棱两可的数据，修与不修都可以。一方面，修复它所需要的投入可能并不值得，只要这个问题能够被理解，并且它没有任何盲点，不再理会这个bug很可能是正确的处理方法。
从另一方面来看，你必须把它和系统中的其他bug进行权衡。我们在这里应用“破窗效应(Broken Window)”—— 如果应用程序中有太多此类中等阈值的bug，产品的质量(或者最起码，从质量的感觉上)一定大受影响。你在考虑系统中每一个bug的时候，还应该结合考虑系统中其他(已知的)bug，并且以此来分析、决定哪些bug是需要被修复的而哪些则不值得被修复。
正式发布的软件中有bug的确是一件十分糟糕的事 —— 但基于我们现有的开发工具和开发语言，我们还没有找到一个更加合理的解决方法。
　补充：
写出这篇文章的时候，我想我遗漏了公式中的第四个因素：发布日期。临近发布日期时，这个因素在修复/不修复bug的决定中也起了关键作用。然而我并不确定它是否是第四个因素，也无法确定在临近发布时期时，修复一个bug所需要的 “用户痛苦”量值的阈值是多少。
最新内容请见作者的GitHub页：http://qaseven.github.io/

为什么Bugs没有被修复?相关推荐

  1. 开发工具：收集12 个顶级 Bug 跟踪工具，值得收藏！

    作者 | Eugene Stepnov 译者 | 张健欣 策划 | Tina 来源丨架构头条(ID:ArchFront) 在如今的在线世界,几乎所有的公司都面临它们产品中的 bugs,并且考虑如何管理 ...

  2. 论文阅读——Automatic Testing and Improvement of Machine Translation

    https://arxiv.org/pdf/1910.02688.pdf 机器翻译的自动测试和改进 Github:https://github.com/zysszy/TransRepair(无代码) ...

  3. OpenStack 最新版本Queens发布 中国公司贡献率排名出炉

    文章来源:OpenStack中国 2月28日,OpenStack Queens版本正式发布,这也是OpenStack自诞生以来公布的第17个版本.根据OpenStack基金会披露,为满足边缘计算,HA ...

  4. Kafka基础-流处理

    1. 什么是流处理? 首先,让我们说一下什么是数据流(也称为事件流)?它是无边界数据集的抽象说法,无边界意味着无限且不断增长,因为随着时间的推移,新数据会不断地到来. 除了无边界的特性之外,事件流模型 ...

  5. Big-man的Java篇(一)

    Big-man的Java篇(一) Java与Big-man的故事: Java是Sun(Stanford Universiy Network)公司开发出来的一套编程语言,主设计者是James Gosli ...

  6. 真 ● 禁秘技 ● 奥义 ● 终端美化

    1 概述 作为一个程序员,可以没钱,没车,没房,没老婆,没女朋友. 但是,一定要有一个漂亮骚气的终端. 没错,大骚特骚. 说什么大实话. 先来看看原生的终端: 真漂亮啊. 再看看美化过的: 这才叫终端 ...

  7. Flink分布式流式处理框架

    Flink Flink概述 数据流与流计算 Flink简介 应用场景 Flink架构 安装配置 示例演示 单词统计示例 创建Flink工程 示例代码 基本概念 DataStream和DataSet 数 ...

  8. 记一次Sonar执行失败的修复

    为什么80%的码农都做不了架构师?>>>    前提 在提高代码质量方面公司采用的是Jenkins+Sonar的方案,通过设定扫描规则对现有代码工程进行扫描.代码扫描后会产生不同级别 ...

  9. 不要只是为您的代码做些毛-用Prettier修复它

    Linting makes our lives easier because it tells us what's wrong with our code. But how can we avoid ...

最新文章

  1. 0.基于C++的图像处理算法实现、INTEL CPU上SSE加速、ARM CPU上NEON加速
  2. 转帖 开源游戏服务器调研
  3. 【20160924】GOCVHelper MFC增强算法（1）
  4. 炸弹人游戏开发系列（6）：实现碰撞检测，设置移动步长
  5. Linux——Linux C语言编程基础知识
  6. tableView练习 -- QQ好友列表
  7. 深度学习（24）随机梯度下降二: 常见函数的梯度
  8. ListBox和ComboBox绑定数据简单例子
  9. 小米首登福布斯2000榜单 排名426位！
  10. Linux内核的编译方法及如何往内核中增加程序
  11. DOS批处理不支持将UNC 路径作为当前目录的巧妙解决方案
  12. 人工手摇机械式计算机,用袖珍式计算机处理螺旋伞齿轮调整卡
  13. Jenkins的制品管理
  14. python用pandas读取excel_Python使用pandas处理Excel
  15. Python数据类型详解03
  16. 华为网络精英挑战赛初赛
  17. Flutter开发日志——初生牛犊
  18. WEBGL 2D游戏引擎研发系列 第一章 新的开始
  19. 数据库原理与应用实验指导书 实验四：数据查询
  20. 锁定计算机盘,使用U盘制作开机密码锁定引导密钥盘的三种方法_IT / computer_Professional...

热门文章

  1. 主从数据库之互为主备
  2. 论分层思想在各行各业的应用
  3. 重绘（repaint）与渲染（reflow）
  4. java中的抛出异常throws与throw
  5. 打造新型智慧城市标杆 金华跻身中国城市信息化50强
  6. javascript 设计模式（一）
  7. Codejock的使用--皮肤
  8. CRM成功实施如何化繁为简
  9. [Learn Notes] PowerShell学习笔记
  10. Mac 上 iterm2 和 VSCode 终端中的字体设置建议