2000年11月08日 无痛错误追踪 – Painless Bug Tracking

The Joel on Software Translation Project:无痛错误追踪

From The Joel on Software Translation Project

Jump to: navigation, search

无痛错误追踪

TRS-80 Level-I BASIC只能储存两个字串变量：A$和B$。同样的我脑袋里天生就只够放两只程序臭虫(bug)。不管何时我只能记住两只。如果你要我记住第三只，先前的某一只，就会自然而然的会被遗忘在荒烟漫草的回忆中…

拥有(并使用)记录问题的数据库是优秀软件团队的标记之一。令我惊讶的是：事实上只有极少数团队有实际进行。程序人员似乎全都自认为能用脑袋或便利贴记住所有错误，这件事实在错得离谱。

如果你能专心听一下，我想要延续我前几篇文章无痛日程表和无痛规格的精神，说明一种能无痛地进行错误追踪的方法。

首先你需要一个真正的数据库。如果是两人一组在周末程序课上写些小程序，拿文字档当数据库大概还可以。不过只要规模再大一点，就要用真正的错误追踪数据库。市面上有无数的错误追踪数据库随你选买。(厚脸皮自我推销一下：我们在Fog Creek Software也写了一套，名为FogBUGZ。要我来形容的话，这是个功能强大而且使用简单的 页型产品。)

为了示范，让我们跟著臭虫走走，看著它从出生一直到某人让它解脱为止的过程。我们将要跟著大名鼎鼎的1203 臭虫。下面是错误数据库对这只虫的叙述：

以下是事情发生的经过。

程序员Mikey正为他的麦金塔软件写新的FTP用户功能。写到一半时由于觉得不爽，就写了自己的字串复制函数。想藉此教训教训公司里那些强迫要重复使用程序代码的家伙！哇哈哈！

Mikey，当你不重新使用程序代码时就会出事。而现在所出的事就是Mikey忘记把复制好的字串加零字符作结尾。不过他一直都没有注意到这个问题，因为大部份情况下，刚好都是把字串复制到已先清成零的内存里。

同一周稍后超级测试员Jill正在猛操那个程序，她把额头顶在键盘上滚来滚去或进行某些同等严荷的测试。(恰巧的是大多数优秀的测试员都叫做Jill或Gillian等等。)突然间发生了非常奇怪的事情：她测试用的ftp服务器当掉了。不要怀疑，我知道这是台Linux机器而Linux机器是不会当的(slashdot的人拜托不要嘘我)。不过这个该死的东西就是当了。而她根本没有动过服务器，她只不过用Mikey的Mac程序把文件FTP上去而已。

现在呢，由于Jill是个超级优秀的测试员，所以她会小心地把所做过的事记下来了(比如在实验手册上精确记录头在键盘上滚动的方位)。她找一台干凈的机器从头开始重复每个步骤，看吧，又发生了！Linux的ftp daemon又当了！这么一来一天内就发生两次了！ Linus(译注：创造Linux的人)注意啦。

Jill斜眼看看重现步骤清单。总共大约有20个步骤。其中有几个似乎与问题无关。做了一点实验后，Jill已经能把问题缩减到四个步骤，而且每次都能产生相同的结果。现在她已经准备好把问题发出来了。

Jill在问题追踪数据库中输入新错误。这里光是输入错误的动作就是有学问的：有好的错误 告也有不好的错误 告。

优良错误 告必备的三元素

然后主说话了，祂说「你要先取出圣撞针。然后你要数到三，不多，不少。三是你要数的数而要数的数就是三。四不是要数的数，二也不是，除非接下来要数到三。五完成不行。当数到第三个数字三时，就把你的安提阿金手榴弹投向你的敌人，那些在我眼中极其下流的人，他们必须承受」 — 圣杯传奇

写一份优良错误 告的规则很好记。每个好的错误 告都要有刚好三个东西。

1. 1. 重现的步骤，
   2. 期望看到的，以及
   3. 实际所看到的。

看起来很简单，对不对能没那么容易，身为程序员，别人丢给我的问题总会缺一两点。

如果你没告诉我要怎样重现问题，我可能根本不知道你讲的是什么。「程序当了而且在桌面留下一个臭臭的大便状物体。」讲得很好，宝贝。不过除非你告诉我你做了些什么，否则我是什么事都不会做的。现在我得承认有两种情况是很难找出重现步骤的。有时候是根本不记得或只是在转述「田野」中(field，译注：指实验室以外的环境)的错误。(顺便提一下，为什么他们要称之为「田野」呢不是像黑麦田或其他作物呢管了…)还有另一个可以不提供重现步骤的场合，就是问题时有时无并非一直出现，不过你还是应该提供重现步骤，再加个小附注标明问题不是时常出现。在这些场合下要找到问题实在是很难，不过我们还是可以试试。

如果你不指明你期望看到的，我可能不明白它为什么是个问题。开机画面上有血迹。那又怎样写这段程序时割到手指啦。你希望看到什么，你说规格上说没有血迹！现在我搞懂你为什么说它是个问题了。

第三部份。你实际上看到什么。如果你不告诉我这一点，我不会知道问题是什么。这是理所当然的。

回到我们的故事

Anyhoo。Jill把错误输进走了。在良好的错误追踪系统中，错误会自动分派给该项目的开发主管。这里隐藏了第二个概念：每个错误随时都要有一个人负责，一直到错误关闭为止。错误就像是个烫手山芋：当拿到烫手山芋时，你就得负责把它解决掉，或是把它丢给别人。

程序主管Willie看看这个错误，认为这个可能与ftp服务器有关，所以就以「不予修正」把它处理掉。毕竟他们并没有写那个ftp服务器。

问题被处理掉之后就会分派回打开的人身上。这可是个重点。不是程序人员认为没事就真的没事了。铁律是只有打开错误的人才能关闭错误。程序人员可以解决问题，意思是「嗨，我觉得弄好了」，不过要实际关闭错误并把它从清单中拿掉，最初打开的人必须确认问题真的已被修好，或是同意该问题基于某种原因不必修正。

Jill收到一封电子邮件通知她问题回来了。她看看信里开发主管Willie的说明。有些东西不太对劲。这套ftp服务器大家用好几年了都没有当。只有用Mikey的程序才会当。所以Jill重新启动该问题并说明她的想法，所以问题又回到Willie身上。这次Willie把问题指派给Mikey修正。

Mikey看看这个错误，认真的想了很久，结果完全误诊了这个问题。他修正了其他完全不相干的错，然后就说把Jill打开的问题解决掉了。

问题回到Jill身上，这次标示为「已解决 – 已修正」。Jill拿最新版软件试了她的重现步骤，看著看著Linux服务器就当了。她又重新打开问题并且直接指派回给Mikey。

Mikey被难到了，不过最后还是找到了错误的根源。(知道是什么了吗要把它当作给读者的作业。线索可是给足了！)他把问题修好后测一测，然后 –找到了！照重现步骤去做不会再让ftp服务器当掉了。他再一次标示「已修正」把问题解决掉。Jill也试了重现步骤，发现问题的确修好了，所以就把它关掉。

错误追踪的十大建议

1. 1. 好的测试员一定会试著把重现步骤减到最少步；这对必须追出问题的程序人员来说极为有用。
   2. 要记住只有一开始打开的人才能关闭该错误。其他人可以解决问题，不过只有最初看到错误的人可以真正确认所看到的错误已被修正。
   3. 要解决错误有很多种方法。FogBUGZ中可用的解决方法有fixed(已修正)，won’t fix(不予修正)，postponed(暂缓)，not repro(无法重现)，duplicate(重复的问题)，or by design(设计限制)。
   4. Not Repro表示没有人能重现该错误。程序人员在错误 告漏写重现步骤时常常会用这一项。
   5. 你需要小心追踪程序版本。每次发给测试员的软件都应该有个编译ID编 ，这样可怜的测试员才不必在根本尚未修正的版本上测试同一个问题。
   6. 如果你是个程序员，而且想尽办法都无法让测试员使用问题数据库，只要不接受用其他方法写的错误 告就可以了。如果测试员习惯用电子邮件送错误 告给你，你就把信退回去并加上以下简短讯息：「请把它放进问题数据库中。我没法子追踪电子邮件。」
   7. 如果你是个测试员，而且想尽办法都无法让程序人员使用问题数据库，只要停止向他们 告错误就好了 – 把错误直接放在数据库里并让数据库发信通知。
   8. 如果你是个程序员，而且只有部份同事在用问题数据库，只要开始在数据库里把错误分派给他们。最后他们自然会明白的。
   9. 如果你是个经理，而且似乎没人在用你花大笔费用安装的问题数据库，那就开始利用它把新功能分派给大家。因为问题数据库也是个很好的「未完成功能」数据库。
   10. 要避开在问题数据库里增加新栏位的诱惑。每个月总会有人想出个要在数据库里新增栏位的好点子。什么聪明的点子都有，比如追踪发现问题的文件；追踪有多少比例的问题是可重现的；追踪某错误发生的次数；追踪某问题发生时机器上某个DLL的版本。不要屈服在这些点子之下，这一点非常重要。如果你屈服了，输入新错误的画面最后会出现上千个栏位要输入，结果是没有人会想输入错误 告。要让问题数据库有效运作，一定得让大家都用，如果「正式」输入错误太麻烦，大家就会绕过错误数据库。

只要你在写程序(只有一个人写也一样)，如果没有一套良好的数据库列出程序中所有的问题，一定会产生品质低劣的程序代码。良好的软件团队不只会广泛使用问题数据库，其中成员还会习惯用问题数据库产生待办事项列表，并把浏览器首页设成会列出所分派到的工作，还会开始祈祷他们能把问题指派给办公室经理，叫他进多点山露汽水(Mountain Dew，译注：百事可乐的著名饮料)。

Fog Creek Software制作了一套易用的问题追踪软件，名为FogBUGZ。

这些 页的内容为表达个人意见。
All contents Copyright 1999-2002 by Joel Spolsky。All Rights Reserved。