这是它的一个功能.doc

这是它的一个功能!? 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”错