第二章 过程改进，没有灵丹妙药

    有些开发者恨透了Bug。他们认为有Bug说明他们的工作出错了——在Bug出现之前，他们的代码看起来那么完美。这样的开发者可称为“业余”。专业的开发者懂得，他们唯一没有发现Bug的原因是他们没注意到。

    我喜欢看到Bug。让我的客户发现它们还不如我先发现。我真正讨厌看到的是糟糕的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已被修复上所用的时间也越少。