Bug report

  Bug report应该推荐一个精确的期望结果

• 如果在一开始你就不能成功的使软件行为发生改变，那么利用文档作为一种使bug report继续有效并且有可能改变开发人员情绪的方法
• 集中精力在描述错误信息的词语和文档上。不一致的矛盾可能可以提供构思错误的线索

 

“当我点击 文件 à 打开，应用程序崩溃了，清除了我的硬盘，并且踢到了我的猫。”

 

这是一个令人信服的bug report。你可能不需要参考用户手册来解释文件à打开功能制造了骚扰你宠物的这一功能不是软件设计的功能。然而每天我们经常处理的那些普通的，严重程度低的错误不是这样的清晰，并且导致组织采取的措施同样也不清楚。

 

成为 bug 的拥护者

当你提交一个bug report的时候，你就成为了bug的拥护者－跟进bug以了解bug是否被定位这是你的工作。你写报告的方法影响着软件的行为是否会被更改，文档是否会被更改为和现实的行为相匹配，或者是错误被忽视。许多没有提倡使用精确操作过程的bug report，同样也是很容易被忽视的。思考这份简短的bug report： “当我用没有带任何参数的命令行启动软件时，我得到了一个“错误文件名”的错误，同时应用程序也中止了”。

写这个报告的测试人员是希望没有指定带参数的命令行有一个特定的默认行为吗？或是测试人员希望文档能够更好地解释为什么至少要给予命令行一个参数？或者是她只是希望要一个更好的错误信息呢？可能她并不在乎要修复成什么样，只是要一个用户清楚并且行为和文档相匹配的结果？让我们看看四种能够集中提高修改上面的bug report的机会方法。

 

请更改行为。“当我用没有带任何参数命令行启动软件时，我得到了一个“错误文件名”的错误，并且应用程序也中止了。用户手册第6页说系统将使用缺省的文件‘foo.bat’，因此我期望没有带参数的命令能够成功执行。”

 

请更改文档。“当我用没有带任何参数命令行启动软件时，我得到了一个“错误文件名”的错误，并且应用程序也中断了。用户手册没有清楚的解释命令行中必须给出关于文件名的参数。”

 

请更改错误信息。“当我用没有带任何参数命令行启动软件时，我得到了一个“错误文件名”的错误，并且应用程序也中止了。期望增加能够更好解释目前情况的错误信息，例如，‘没有指定文件名’。”

 

请更改行为和文档。“当我用没有带任何参数命令行启动软件时，我得到了一个“错误文件名”的错误，并且应用程序也中止了。这个场景没有在用户手册中提及，因为它会使用户受到打击。”

 

杠杆作用文档

试想如果他们选择忽视你认为需要修改的错误，会发生什么事呢？我有一个诀窍――我是指确保让开发人员能够重新思考错误的方法。办法就是集中精力在文档和错误信息上。

例如我最近提交了一个描述正在测试的两个不同工具在一个操作系统下的错误信息：ps和sweep（更多的信息请参考在表1中的“Getting Your Fix”部分）。这个错误看上去不能指出任何会影响系统操作的故障。尽管它会引起内部和正在使用系统的第三方开发人员产生混淆，但并不会影响那些不能访问错误程序的系统主流用户。由于在我第一次报告这个问题时，没有给文档发挥作用的机会（但是它将在之后发挥作用），因此我只是把它作为严重程度低的错误提交。

一个为在其他地方的外包供应商服务的开发人员以要求我解释为什么我看见了错误作为回复，并且以“我们不认为它是一个错误”做为结束。

我不想了解产生这个错误信息的原因－我只想它被修复！因此我使出我最得意的bug拥护手段之一。我这样回复那个开发人员，“请把这个作为是ps和sweep期望的行为记录在文档中”。

两天后，来自开发人员的回复不是文档的变更，而且为了移除错误而做的代码更改。胜利了！可能那个开发人员不想将这个古怪的行为记录在文档中。

 

刚才发生了什么事？

当然，我不是真的想要更改文档上。如果那个开发人员接受了我的吓唬并且修改了文档而不是代码，由于不可否认得已经做了改进，我将标记这个错误为已修复。然后我会在提交另外一个抱怨由于欺骗的错误影响系统可用性的bug report，或许我会报告一个改进的要求。在这一点上，我只是期望只要一会就可以修复错误，但是我知道我自己至少是尽力了。

应该提及的是如果你没有好的最终用户文档这个方法是不起作用的。我曾经花了大量的时间测试特别为开发人员编写的，详细的应用系统编程的接口（API）。和我一起工作的开发同事想用这个API文档代替功能说明，所以这个额外的动机能够使其保持准确。如果你还没有最终用户的文档，你仍然要去查找其他可能提及这个行为的文档－可能是设计文档或者是错误信息本身。

 

让他们思考

例如，我报告了一个关于开源字处理器的工具－AbiWord的＃3639错误（更多信息参考在表1中的 “Triggering Change”错误的主要描述）。在一个早前的bug report中（＃3619），我已经抱怨了AbiWord不能够导入各种类型的html文档。由于AbiWord只期望导入xhtml文件，因此它不能够导入html格式的文件，除非安装另外的插件，所以这个错误作为无效的错误被关闭了。

作为一个bug的拥护者，我应该为这个结果感到高兴吗？当然不是！我瞄准了容易产生误解的错误信息。作为一个不知道导入html插件的用户，我找到了引起混淆的错误信息：

AbiWord 不能打开 D:/foo.html 文件。它是一个假的或无效的文件。

因为这些额外的话，我提交了＃3639错误，在其中我建议将错误信息修改为（只是加了一个词）：

AbiWord 不能打开 D:/foo.html 文件。它是一个假的或无效的 xhtml 文件。

第一个回复＃3639错误的人说“这可能是一个关于用于载入文件的是html还是xhtml导入器的识别问题。”啊哈！这就是我想要的。当考虑这个令人误解的错误信息时，一些人也意识到软件不是十分的正确。我引发了超出错误信息措辞方面的讨论。

唉，但是这个错误的最终结果是因为和另一个错误－＃1406重复而被关闭。我不是很信服这是一个正确的决定，因此作为bug拥护者的－我要一直坚持到＃1406错误被关闭，因为我需要验证修复了＃1406错误也解决了我的问题。

 

提倡辩护

当你编写bug report的过程中，在你发出之前停下来想一想是否有一些文档你可以用来和现在的表现相对比。仔细的阅读错误信息。思考用户将会看到什么和应用系统将会怎么执行。如果你有好的建议的话，让开发人员清楚你想要的解决方案类型。这样你的bug report可以更高效。

如果你从开发人员那得到你不喜欢的回复（例如，“这是它的一个功能！”）时，再想想这个行为是否和已有的提示一致。你可能可以用另一种方法描述错误从而提高它被修复的机会。

 

Getting Your Fix

Triggering Change

在提交bug report时，试着杠杆作用文档和利用错误信息以使错误得到修复。 我提交了“thread exited”的错误（一些细节已经被处理了）。开发人员不认为那些严重程度低的错误是问题。当我要求开发人员在文档中警告用户可能会弹出错误时，他却选择了修复错误――这正是我要的。 概要：在杀死进程后，ps和sweep出现了“线程退出”的错误。 严重程度：低 描述：当试图重现＃385错误时，我发现ps中出现几个这样的错误：ps: read on 51844: thread exited. 我注意到在几个月前一个关于压力测试相关错误的讨论中，开发人员希望能够发现它，但我们却不能重现。现在这样非常容易重现。   1.启动foo程序并且载入此bug report中附加的数据文件 2．点击“登陆” 3．几秒钟后，清除foo程序的进程。 4．运行ps或sweep，就会看到“线程已退出”的错误   这是在抱怨“Foosry”进程。下面是在这样的一个进程从ps输出中消失并且变成一个错误之前的快照。 51844 58143 testuser release 26K Foosrv   这个错误在一会后停止出现了，一般来说少于一分钟。Taskview程序在刷新进程列表时不会发生同样的错误。这个错误看上去没有任何有害的结果。

我提交了如下的一个关于AbiWord导入html的bug report。开发人员回复说这不是一个错误因为导入html文件需要一个插件。我根据一个错误信息改变了要求。这个要求在开发人员中引起了关于审计缺陷的讨论—这是朝正确方面前进的一步！ 概要：在尝试打开html文件时，错误信息是容易引起误解的 ID：3639 严重程度：低 描述：这是由于无效被关闭的＃3619错误的后续。当我尝试用常见的FilepOpen的机制打开一个后缀名是html的文件（不是xhtml），我得到了一个错误： AbiWord cannot open D:/foo.html. It appears to be a bogus or invalid document。   我被告知在这里AbiWord只期望xhtml，但是错误信息并没有这样说。实际上，它是一个有效的html文档。对错误信息做一个小的改动就是一个大的改进： AbiWord cannot open D:/foo.html. It appears to be a bogus or invalid xhtml document.