十一、难伺候的故障修复

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

拥有记录问题的数据库是优秀软件团队的标记之一.事实上只有极少数团队有 实际进行，这一点一直令我很惊讶.程序人员似乎全都自认能用脑袋或立可贴 记住所有错误，这件事实在错得离谱.

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

首先你需要一个真正的数据库.如果是两人一组在周末程序课上写些小程序， 拿文本文件当数据库大概还可以.不过只要规模再大一点就要用真正的错误追 踪数据库.市面上有无数的错误追踪数据库随你选买.（厚脸皮自我推销一下：

我们在Fog Creek Software也写了一套，名为FogBUGZ.要我来形容的话，这是个功能强大而且使用简单的网页型产品.）

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

1203
Bee Flogger 2.0 FTP客户端
上传档案会导致FTP服务器倾印核心(dump core)
已关闭
结束(已解决-已修正）
2 -必须修正
2.0 Alpha Build 2019
Jill 的 iMac, Mac OS 9.0, 128M RAM, 1024x768 millions of colors
11/1/2000由超级测试员Jill发现
* 启动Bee Flogger
*建立一个未命名档案，内容只有一个"a"字 *点工具栏上的FTP钮 *尝试用ftp传至你的服务器
错误：观察；ftp服务器停止响应.输入ps-augx显示ftp服务器 甚至停止执行而且根目录有核心倾印.
预期：不应当掉
11/1 /2000由Jill超级测试员指派给指派给开发主管Willie
11/2/2000 (昨天）已解决-开发主管不予修正
不是我们的程序，Jill,那只是Linux所附的proftpd.
11/2/2000 (昨天）已由超级测试员Jill重新启动(指派给开 发主管Willie)
这不对劲.我用一般ftp客户端联机都不会让proftpd当掉.可是 用我们的程序每次都会当.Ftp服务器不会自己"当"掉.
11/3/2000 (今天）己由开发主管Willie指派给裎序人贝 Mikey
,你能不能看一下这个问题？你的客户端程序可能有毛病.
11/3/2000 (Today)已解决-已由裎序人员Mikey修正
我想我把密码错传成用户名称或其他东西了...
11/3/2000 (今天）己由超级测试员Jill重新启动(指派给程 序人贝Mikey)
Build 2021还是有这个问题.
11/3/2000 (今天）已由裎序人员Mikey编辑
呃.这蛮奇怪的.让我来抓这个错.
11/3/2000 (今天）己由裎序人员Mikey编辑
我想应该是MikeyStrCpy()的问题...
11/3/2000 (今天）己解决-己由裎序人员Mikey修正
啊！
终于修好了丨
11/3/2000 (今天）已由超级测试员Jill关闭
build 2022显然修好了，所以我把这个问题关闭了.

以下是实际发生的事情.

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

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

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

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

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

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

优良错误报告必备的三元素

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

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

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

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

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