你有没有为了要更多的信息而被返回bug report的经历呢?有没有碰到过你发现的一个非常严重的错误被推迟到下一个版本才去修复的情况呢?

　　你提交的每一个bug report都是和项目组就正在测试中的软件质量问题的一种书面沟通方式。通常，你用于沟通程序错误的能力,不是体现在错误本身的内在严重程度-而是体现在确定这个错误是否需要修复。
　
　　明确你的听众

　　毋庸置疑，任何写作课都会告诉你必须了解你是为谁编写bug report。
    每份bug report至少有两个听众：必须要修复bug的程序员和决定bug命运的人或团体，这里称为裁决者。有时一个人会同时负责这两份工作，但是仍然是两个不同的听众，只是一起发生在同一个人身上罢了。
    你的第一个听众,那个必须修复bug的人需要清楚明确的步骤以重现bug，必要的信息越多越好。
    你的第二个听众，决定bug命运的裁决者需要知道如果不修复此错误的后果。这个听众需要精练的语句以抓住他们的注意力并且引发对错误的相关连问题的讨论。在使bug得以修复的过程中你的角色是使第二个听众了解不修复bug的风险远远超过修复bug可能发生的风险。
    你越了解你的听众如何工作，你就越可以根据他们的需要裁减你的bug report。

   选择一个好的标题

　　一般把用于描述错误的短句称为错误的标题或描述。这是bug report中最重要的部分。
   标题变成了一种给项目组提供检查和调查错误的方法。和数据相比，人们更容易记词语。人们更愿意记得“在windows2000下不能够安装”的错误，而不是类似“#23423”错误，而且在以后人们还会利用这些关键词搜索错误。
   编写一个好的，简明的错误标题是不容易的。和编写bug report的其他部分相比，应该多花些时间构造理想的错误标题。要确信标题是足够短以便能够在显示错误的屏幕上和由缺陷跟踪系统生成的报表中显示完全(不会折行)。标题不必是完美的语法，而应简短并一针见血。

   书写清楚，明确的步骤

　　你提交给开发人员的步骤应该提供如何产生错误的信息，这样错误就能够被发现并且修复，比如下面的例子。

　　第一种描述正确的：
    1. 运行客户端
    2. 找出一个记录
    3. 更改记录但不存盘
    4. 使数据库服务器脱机
    5. 尝试保存记录
    6. 收到一个超时的错误
    7. 退出客户端
    结果：崩溃

　　第二种描述马虎的(有很大空间让人产生误解的)： 
    使数据库服务器脱机，保存，然后退出，崩溃了。

　　第三种描述太多冗余的信息(不能够指出什么是引发错误的最关键原因)：
    1. 运行客户端
    2. 为输入新的条目查询数据库
    3. 打开一个浏览器
    4. 在yahoo.com上浏览新闻
    5. 关闭浏览器
    6. 选择一个条目
    7. 把种类从“蔬菜” 更改到“水果”
    8. 使数据库服务器脱机
    9. 尝试保存记录
    10. 收到一个超时的错误
    11. 退出客户端
    结果：崩溃

　　在这个例子中，测试人员记录在发现错误之前他所作的一切，但是他没有检查是不是每个步骤都是必要的，例如从yahoo.com阅读新闻。

　　但是如果每个步骤都是必须的，怎么办呢?如果错误只在你执行了一些看上去没有关系的步骤后出现了，那么在bug report中记录下这些步骤。你可以在那些看上去没有逻辑关系的步骤后写上“必须的步骤”，或者你可以在bug report的开始部分加上注释：“注意-这里的每一个步骤都是重现错误的必要步骤。”

　　编写清晰的步骤同样可以在验证修复过程中提供帮助，特别是在另一个测试人员做验证的时候。

　　

   本站技术原创栏目文章均为中睿原创或编译，转载请注明：文章来自中睿，本站保留追究责任的权利。