Bug剖析

Bug剖析

• 所有的Bug报告有以下的基本要求:
• 标题。要简略。
• 指派。谁来处理这个问题。
• 重现步骤。问题再次出现的相关步骤。
• 优先级别。问题的紧迫性与重要性。
• 严重程度。问题所产生的后果。
• 解决方案。怎么解决问题。
其他很多方面对修复问题及明白其深层次原因也很有帮助,但以上基本准则简练得多。下面我们来对每条准则逐一展开讨论,消除这些疑惑。

标题及指派

标题应该简明扼要,一句话就详尽说明问题的唯一性,使Bug报告的检索及标识变得简单。“点击取消按钮,屏幕就清空了”是个差劲的标题。“关闭编辑框,清空屏幕”就是个很好的标题。后者简短得多,而且对问题的出处及发生时间提供了具体的信息。
当你要创建一份新的Bug报告时,你必须指定具体人选来解决其中问题。但是,即使你这个团队的每个人都很了解,你也不应该将一个Bug指定给其中某一位,除非你是开发团队的一员。相反,你应该将此任务交给这整个团队。通常的做法是在Bug报告中指定责任方或团队作为默认选择。默认的选择通常是“主导”或“会诊”团队。不会再有更好的了。要相信这些团队,他们会知道问题由谁来解决。
作者注:有些团队希望将所有Bug都指派给团队中的某些个人,这样可保证没有Bug被遗漏。但是,他们还是必须确认将Bug指派给“主导”或“会诊”团队以确保Bug未被遗漏。毕竟,团队外部人员并不知道软件还有其他什么功能。
作为惯例,所有Bug必须指派给能对其进行经常性检查的个人或团队。因为,大多数优先团队会每天开例会,我还是偏好将Bug指定给“主导”或“会诊”团队为默认选择。

重现步骤

没什么比一份Bug报告没有清晰的重现步骤更让人郁闷了。就像你的亲友对你说:“你知道该怎么办!”,没有给你更多解释。这让我很茫然,不知道怎么办。悲催了。
Bug重现步骤应是言简意赅——一言中的。同时要包含软件创建编号(通常是单独列出的),你的工作环境(操作系统版本、所用浏览器及其他相关的细节)以及一些先备条件(像先注册个Xboxcom金牌账号等)。
有时你不能确定Bug是怎么发生的,因为它有时是间歇性的或跟某种特定的状态相关。这种情况下,列出创建编号、运行环境及配置等信息,接着描述下当时的情况,以说明具体的Bug重现步骤无法确定。

注:我们有些内部工具,如Watson与Autobug,它们可以自动生成Bug报告。诚然,用这些工具生成Bug重现步骤有其局限性,但是它们通常仍可以提供些堆栈跟踪信息、创建编号、环境及其他相关的信息,且它们对隔离问题有帮助。

在简洁的Bug重现描述后,你必须指出什么是你希望发生的(“期望”),及事实发生了什么(“事实”)。所有的重现步骤包括这三方面——配置、期望结果及实际结果。这样当别人在看这份Bug报告时就知道到底哪里出错了及怎么重现它。
通常一张图、一段视频顶上千句文字,有很多工具可以对屏幕进行图片及视频抓取。将这些文件附到Bug报告中,这些文件就是一份能妥善修复Bug的报告与含糊不清的报告之间的区别。
作者注:如果一个问题可以用4个步骤讲清楚而你在Bug报告里却用了15个步骤,这是让人相当恼火的。不仅仅是因为4步很简单,容易理解,而且这样可以使开发者及测试者快速找到Bug。重现Bug用的时间越少,在确认Bug的原因上所花时间也越少(可能出现Bug的步骤少了),同样在确认Bug已被修复上所用的时间也越少。

优先级别

对于优先级别意义的讨论一直没完没了,这种级别的范围值通常为0~3。说实在的,你可以把时间更好地用到其他地方去。这里还是说些简单的准则,以此为基础阐明优先级别。
• 优先级别一旦设定则不宜再改,除非Bug本身角色变换了。如果级别1意味着:“在目前的冲刺阶段或里程碑期间修复”,级别2意味着:“到下一个冲刺阶段或里程碑期间再修复,”那么在每个冲刺结束时,你必须更新Bug的优先级别,这样不仅很浪费时间,而且改变了Bug的“最后一次变更时间”,这会丧失很多重要信息。
• 优先级别必须容易指定并区分。你不会想让你的团队花大量的时间争论每一个Bug的优先级别吧。它必须是显而易见的,不管是在写Bug报告或读Bug报告的时候。
• 优先级别必须易记且易操作。人们不需要问:“下一个Pri 2是什么?”,人们也不需要问哪种级别需要做什么。
基于以上三条准则,一般普遍接受以下优先级别的定义。

Pri 0 一个需引起严重关注的致命错误。不存在变通办法,是一个不可逾越的Bug 只有解决了这个问题或找到了变通办法,你才能安心 Pri
1 一个需引起严重关注的致命错误 必须在当前的冲刺阶段或里程碑期间解决 Pri 2 一个严重的错误 必须在产品发布前解决 Pri
3 一般性错误或建议 最好在产品发布前解决 Pri
0通常有碍测试、部署或其他对时间敏感的工作。你必须给开发者或团队发邮件并电话告知他们,或者直接过去跟他们谈,直到有人解决这个问题。如果有变通办法,Pri
0就必须改成Pri 1。

注:确实有开发团队对优先级别有非常多的定义。有的从Pri 1开始,而不是Pri 0;有的不遵从我在本章开始时列出的准则,或者在一个单独的区域提示Bug信息。
如果你查看另一个团队的工作项目数据库,确定你使用的是他们的定义。这些定义通常显示在工具提示上或帮助窗口中。

严重程度

严重程度比优先级别简单得多,但是它还是经常被搞混。严重程度指的是问题所产生的影响范围,不关乎“有多么严重”这样的问题。其定义是:

• 严重程度1。某问题引起系统崩溃或客户数据丢失。
• 严重程度2。某问题引起的故障阻断了后续操作。
• 严重程度3。某问题引起操作不便或界面显示不完整。
注意,严重程度与优先级别是相互独立的——换句话说,严重程度与优先级别毫无关系。优先级别1的Bug比级别2的Bug更重要,不管其严重程度如何。显示一些不合适的内容就是严重程度3但也可能是优先级别1;系统崩溃后用户强行重启就是严重程度1同时也可能是优先级别3。工程师声称一个未致系统崩溃的Bug的严重程度是1,因为严重程度很高。你完全没必要成为他戏弄的笑料。如果你这样就白痴了。

解决方案

Bug报告中最重要且经常被混淆的部分是“解决方案”——说明如何解决问题。解决了一个Bug意味着你不再关心这个问题。当Bug的发现者确认这个方案能修复这个Bug时,你也不打算再作更多的处理。
在你发布产品前,如果对一个问题需要做更多的处理,即使这不是你的团队的责任,那这个Bug还是要引起关注,并指定你团队里的一个人继续跟踪相关事宜。

以下是解决方案部分可能包含的内容:

• 意图。Bug报告描述了所需处理的细节,按预先意图进行。
• 重复。这个Bug与报告中先前指出的Bug有相同的起因及非常相似的用户体验。不要像分析一个旧Bug一样分析新Bug——不管这个新的Bug报告看起来会多精美,除非你想与Bug发现人为敌并丧失“首先发现Bug”的机会。
• 外部性。一个Bug是由你控制能力之外的原因引起的,则你可以在Bug未修复之前发布产品。如果你团队之外的人没有修复这个问题,使你的产品发布不了,那么保持对这个Bug的关注并指定你团队里的某人进行跟踪,找到其他团队中存在的问题。
• 已修复。Bug修复了。这是我最喜爱的解决方案。
• 不再发生。你不能让Bug在之前说过的创建版本及环境中再次发生。声称“在我的机子上运行没什么问题”并不代表Bug解除了——随时与Bug发现人保持沟通。
• 延期。你不想在这个版本中修复Bug。延期是偷懒者的借口,他们总说明天我会写个测试单元。真正的工程师会时刻关注这个Bug并会在Bug报告里留出一个“等待修复”专区来指出下一个改进版本,只要他们真的想修复这个问题。
• 不修复。你不再修复Bug。这是我第二种得意的解决方法——这说明你有丰富的经验判知哪些Bug不需要修复。通常是因为修复本身会带来比Bug更多的问题。
当你在解决一个Bug时,你必须在解决方案中有段描述。这段描述是很重要的。这样可使解决方案少些争论,Bug重现时就更易理解,使你与你的公司免于因为这个问题成了公众热议的话题。这在我之前的一个团队中曾发生过——我们使这个公司免于千夫所指,因为我们的解决方案中对一个出现不合适内容的Bug作了描述,以说明我们并非蓄意而为。

当一个Bug被解决,它将被自行指派给发现它的人。如果这个人不是开发团队的人员,那这个Bug必须指定给另一个团队中的人,这个人可以跟Bug发现者核实解决方案。但你不能总是指望团队外部的人能及时周到地确认解决方案。当然,如果这个解决方案不怎么令人满意,那么这个Bug应被重新激活。

过犹不及

Bug报告中还有很多其他区域。我说过用“创建”及“环境”两个区域记录Bug相关信息以及用“等待修复”区域来说明什么时候处理Bug。还有一些区域用来跟踪记录底层原因,这个Bug是怎么被发现的,Bug是在产品或服务的哪个方面发生的,潜在的安全威胁以及其他信息。

设定好Bug报告的必要条件,少则缺,多则无益。要求太多人们会怨声四起而拒绝完成Bug报告——两种极端都会对你及你的客户不利。

Bug报告要易写且易读,这样会促使他们在发现问题的时候制定清晰的Bug报告。使用一些Bug模板对于一些内容的编写是很有帮助的。对于我们在乎的工程师及客户来说,规范的Bug报告使一个问题在用户发现前消灭于萌芽状态,没有比这更好的礼物了。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/diannao/56097.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

LabVIEW提高开发效率技巧----点阵图(XY Graph)

在LabVIEW开发中,点阵图(XY Graph) 是一种强大的工具,尤其适用于需要实时展示大量数据的场景。通过使用点阵图,开发人员能够将实时数据可视化,帮助用户更直观地分析数据变化。 1. 点阵图的优势 点阵图&…

树莓派应用--AI项目实战篇来啦-17.YOLOv8目标检测-安全帽检测

1. YOLOv8介绍 YOLOv8是Ultralytics公司2023年推出的Yolo系列目标检测算法,可以用于图像分类、物体检测和实例分割等任务。YOLOv8作为YOLO系列算法的最新成员,在损失函数、Anchor机制、样本分配策略等方面进行了全面优化和创新。这些改进不仅提高了模型的…

长芯微LSPGD1系列带气嘴DIP8封装集成表压传感器完全替代松下ADP51B62替代ADP51B62,成本更低!

描述 LSPGD1是长芯微针对家电医疗等市场推出的经过校准的表压传感器系列产品。该系列产品采用高性能信号调理芯片对MEMS压阻芯体输出进行温度和压力的校准和补偿,保证性能和可靠性的同时对封装进行了集成,易于使用。LSPGD1系列集成压力传感器可选量程为…

声明式LoggerFactory.getLogger和注解@Slf4j原理区别和推荐

LoggerFactory.getLogger 和 Slf4j 注解在实现日志功能时使用的原理有一些不同,以下是它们的区别: 1. LoggerFactory.getLogger: 手动创建日志实例:使用 LoggerFactory.getLogger 方法时,开发者需要手动在类中声明并…

记一次 Flink mongoDB CDC 到Kafka遇到的问题

背景 最近在做一个数据接入的部分事情,从mongo导入到 adb,趁着做的事情聊一下Flink内部的一些机制。 首先这会拆分两个部分,一部分是从 mongo 到 Kafka,另一部分是从 Kafka 到 adb,其中遇到了一些问题,比如…

Java多线程之死锁(死锁产生条件、手写简单死锁程序、破坏死锁)(面试常有)

目录 一、死锁。 &#xff08;1&#xff09;实际生活"死锁"情景。 &#xff08;2&#xff09;程序中举例。 &#xff08;3&#xff09;死锁产生必要的条件。 <1> 互斥使用。 <2> 不可抢占。 <3> 请求和保持。 <4> 循环等待。 &#xff08;4&…

iOS 14 自定义画中画悬浮窗 Custom AVPictureInPictureController 实现方案

iOS 14&#xff0c;基于 AVPictureInPictureController&#xff0c;实现自定义画中画&#xff0c;涵盖所有功能与难点。 市面上的各种悬浮钟和提词器的原理都是基于此。 Demo源码在文末。 使用 iOS 画中画的要求&#xff1a; 真机&#xff0c;不能使用模拟器&#xff1b;iO…

starrocks-删除表字段

1、背景 之前做了个大宽表&#xff0c;将近100个字段&#xff0c;但是后来发现很多字段在实际生产上都没有用到&#xff0c;并且随着数据量的增加&#xff0c;给集群的存储以及消费任务的解析带来了比较大的压力。所以决定对字段做删除处理。 当前的表是使用routine load任务从…

微服务架构:核心组件解析与设计思考(服务发现、API网关、 配置中心、负载均衡、服务调用、服务熔断、链路追踪、消息队列、服务安全、分布式事务)

微服务架构已成为大型系统设计中不可忽视的趋势&#xff0c;它通过将单一系统拆分为多个自治的服务&#xff0c;解决了传统单体架构难以应对的复杂性和扩展性问题。然而&#xff0c;微服务架构的成功依赖于多个核心组件的协同工作&#xff0c;从服务发现到API网关&#xff0c;从…

hadoop全分布式搭建(三台虚拟机,一个主节点,两个从节点)

根据尚硅谷哔哩哔哩视频搭建&#xff1a;bilibili.com/video/BV1Qp4y1n7EN/ 安装虚拟机教程可参考&#xff1a;VMware虚拟机 安装 Centos7(linux)&#xff08;新手超详细教程&#xff09;_vmware安装centos7教程-CSDN博客 集群配置如下&#xff1a; 一、先配置一台虚拟机hadoo…

python:假的身份信息生成模块faker

前言 发现一个有趣的python模块&#xff08;faker&#xff09;&#xff0c;他支持生成多个国家语言下的假身份信息&#xff0c;包含人名、地址、邮箱、公司名、电话号码、甚至是个人简历&#xff01; 你可以拿它做一些自动化测试&#xff0c;或一些跟假数据有关的填充工作。 代…

【计算机网络 - 基础问题】每日 3 题(三十八)

✍个人博客&#xff1a;https://blog.csdn.net/Newin2020?typeblog &#x1f4e3;专栏地址&#xff1a;http://t.csdnimg.cn/fYaBd &#x1f4da;专栏简介&#xff1a;在这个专栏中&#xff0c;我将会分享 C 面试中常见的面试题给大家~ ❤️如果有收获的话&#xff0c;欢迎点赞…

【华为HCIP实战课程七】OSPF邻居关系排错MTU问题,网络工程师

一、MTU MUT默认1500,最大传输单元,一致性检测 [R3-GigabitEthernet0/0/1]mtu 1503//更改R3的MTU为1503 查看R3和SW1之间的OSPF邻居关系正常: 默认华为设备没有开启MTU一致性检测! [R3-GigabitEthernet0/0/1]ospf mtu-enable //手动开启MTU检测 [SW1-Vlanif30]ospf mtu…

PCL点云处理之求法向量

求法向量干什么&#xff1f;将点渲染成面 1、一个点垂直于一个曲线的切线叫法线 2、在点云中取一块区域&#xff0c;用最小二乘将区域中的点云拟合成一个面&#xff08;贴合在曲面上的一个切面&#xff09;在相近的区域计算出n个这样的面&#xff0c;用这个面求出法向量&#…

第十五届蓝桥杯C++B组省赛

文章目录 1.握手问题解题思路1&#xff08;组合数学&#xff09;解题思路2&#xff08;暴力枚举&#xff09; 2.小球反弹做题思路 3.好数算法思路&#xff08;暴力解法&#xff09;---不会超时 4.R格式算法思路 5.宝石组合算法思路---唯一分解定理 6.数字接龙算法思路----DFS 7…

分布式数据库的进度管理:TiDB 备份恢复工具 PiTR 的原理与实践

导读 对于一款企业级数据库产品而言&#xff0c;数据的安全性和可恢复性是至关重要的。PiTR&#xff08;Point in Time Restore&#xff09;作为 TiDB 备份工具的核心功能之一&#xff0c;提供了一种精细的数据恢复能力&#xff0c;允许用户将数据库集群恢复到过去的任意时间点…

C语言 | 第十六章 | 共用体 家庭收支软件-1

P 151 结构体定义三种形式 2023/3/15 一、创建结构体和结构体变量 方式1-先定义结构体&#xff0c;然后再创建结构体变量。 struct Stu{ char *name; //姓名 int num; //学号 int age; //年龄 char group; //所在学习小组 float score; //成绩 }; struct Stu stu1, stu2; //…

基于SpringBoot+Vue+Uniapp的植物园管理小程序系统(2024最新,源码+文档+远程部署+讲解视频等)

3. 论文参考 4. 项目运行截图 5. 技术框架 5.1 后端采用SpringBoot框架 Spring Boot 是一个用于快速开发基于 Spring 框架的应用程序的开源框架。它采用约定大于配置的理念&#xff0c;提供了一套默认的配置&#xff0c;让开发者可以更专注于业务逻辑而不是配置文件。Spring …

Spring Boot在知识管理中的应用

1系统概述 1.1 研究背景 如今互联网高速发展&#xff0c;网络遍布全球&#xff0c;通过互联网发布的消息能快而方便的传播到世界每个角落&#xff0c;并且互联网上能传播的信息也很广&#xff0c;比如文字、图片、声音、视频等。从而&#xff0c;这种种好处使得互联网成了信息传…

MySQL 之索引和查询优化

在 MySQL 数据库中&#xff0c;索引是提高查询性能的重要手段之一。而理解和应用最左前缀原则对于有效地利用索引进行查询优化至关重要。 一、索引的作用 索引是一种数据结构&#xff0c;它可以帮助数据库系统快速地定位和检索数据。通过在表的某些列上创建索引&#xff0c;数…