《代码之殇》节选之Bug报告

为什么大家就不能写一份像样的Bug报告？不是说像样的报告就比蹩脚的报告冗长或者更难写，也不是说在Bug报告中为每个事物做个确切的定义是不可能的。呵呵，团队间的那些定义确实不同而且还互相矛盾。那在Bug报告中什么才是最确切的定义呢？我希望听到你的回答。

作者注：软件的每一小部分都会有成千上万的Bug，这取决于它的规模与复杂程度。有些Bug并无大碍，像“我希望关闭按钮更大一点。”有些Bug则是误解了，像“我不能为我的游戏匿称起个下作的名字。”但有些Bug就是讨厌的臭虫，无论如何都必须加以改进，像泄漏用户信息。因为Bug往往是开发团队的局外人发现的，必须等到所有问题修正为止，Bug报告才告完结——通常使用工作项目跟踪数据库，像Product Studio（微软经典的开发工具）或者Team Foundation Server。

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应被重新激活。

作者注：我第一次为我的团队制定解决方案是在10年前。回顾之前的邮件，以上定义至今仍然有效。

过犹不及

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

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

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

作者Eric Brechner，微软公司“卓越开发”部门的总监，在软件行业已经积累了20多年的经验。他从2001年开始写“HardCode”栏目，作为一种资源 提供给微软的员工。自那以后，其观点栏目在微软内部成千上万的软件开发者之间，激起了无休无止的关于最佳实践的讨论——如今。这些观点走出了微软，走向了 整个开发社区。

本文选自《代码之殇》，Eric Brechner 著，林锋译，由机械工业出版社出版。