你提交的每一个 bug report 都是和项目组正在测试中的软件质量
问题的一种书面沟通方式。通常，你用于沟通程序错误的能力不是体现
在错误本身的内在严重程度,而是体现在确定这个错误是否需要修复。
你可能会想， “ 等等！我讨厌写作，我并不擅长写作。怎么样才
能够通过编写 bug report 来决定错误的命运呢？ ” 它要吸引大家相
信错误是为他们说话的,任何一个头脑正常的人都应该主动地查看一个
特定的错误是足够可怕的以致要被修复。
我们需要有效的和软件开发人员、项目组进行沟通,因为编
写bug report不是用有趣的词语编写流畅散文，也不是用优秀的语
法和拼写的方法。它是有关仅用能够表达你观点的词语明白地表述错
误的方法。太多地话将会使你的观点陷入茫然无措中。太少地话又会
使他人用自己的假设去填补隔阂。如果你不是很确信是什么样的错误，
那么不管你的 bug report 写得怎么好，也没有人知道那是什么样的
错误。
每份 bug report 至少有两个听众：
1、决定错误命运的人或团体（项目经理等）
2、必须要修复错误的人（开发人员）
你的第一个听众（项目经理）：他需要知道如果不修复此错误
的后果。这个听众需要精练的语句以抓住他们的注意力并且引发对错
误的相关连问题的讨论。在使错误得以修复的过程中你的角色是帮助
项目经理了解不修复错误的风险远远超过修复错误可能发生的风险。
选择一个好的标题
好的 ： 超时后在退出时崩溃了
太长的 ： 在数据库不可用后你又保存记录的更改 , 然后从文件菜单
中选择退出时程序崩溃了
不足够的信息 ： 程序崩溃了
太模糊 ： 当数据库离线时出现问题
你的第二个听众（开发人员）：他们需要清楚，BUG明确的步骤以
重现错误，信息越多越好。开发人员需要了解我们操作了什么和我们看
见了什么的准确信息。
正确的： 马虎的（容易使人产生误解）
1 ．运行客户端 使数据库服务器脱机，保存，然后退
2 ．找出一个记录 出，崩溃了。
3 ．更改记录但不存盘
4 ．使数据库服务器脱机
5 ．尝试保存记录
6 ．收到一个超时的错误
7 ．退出客户端
结果：崩溃
太多冗余的信息（不能够指出什么是引发错误的最关键原因）
1 ．运行客户端
2 ．为输入新的条目查询数据库
3 ．打开一个浏览器
4 ．在 yahoo.com 上浏览新闻
5 ．关闭浏览器
6 ．选择一个条目
7 ．把种类从 “ 蔬菜 ” 更改到 “ 水果 ”
8 ．使数据库服务器脱机
9 ．尝试保存记录
10 ．收到一个超时的错误
11 ．退出客户端
结果：崩溃
