15.5错误报告（Bug Report）

　　在测试中，如果发现问题，我们就得报告，在移山过程模型中，“bug”是第二个工作项类型。在这一阶段，我们就主要用bug进行交流。

　　在以前的“二人合作”一章中，有些团队成员已经互相找过bug，但是当时项目相对简单，对bug 的格式并未做严格要求。在一定规模的软件项目中，我们要求一个好的错误报告要能做到：

　　（1）bug的标题，要简明地说明问题。

　　（2）bug 的内容要写在Description中，包括：

　　a. 测试的环境和准备工作；

　　b. 测试的步骤，清楚地列出每一步做了什么；

　　c. 实际发生的结果；

　　d. （根据spec和用户的期望）应该发生的结果。

　　（3）如果需要其他补充材料，例如相关联的bug、输出文件、日志文件、调用堆栈的列表、截屏等，都要保存在bug 相应的附件或链接中。

　　（4）还可以设置bug 的严重程度（Severity）、功能区域等，这些都可在不同的字段中记录。

　　下面是九条创建的一个bug：

　　标题：挂了

　　内容：我今天在玩移山购物网的时候，发现移山网站挂了。

　　这个bug的问题在于对问题的描述不明确，让开发人员无从下手。小飞拿到这个bug，也是哭笑不得，试了试移山的各个页面，好像也都正常。他于是把这个bug又推给九条，“哪里挂了？”

　　过了一会儿，九条回复“在我的机器上是挂了”。

　　小飞跑到九条的座位上，想看看“犯罪现场”。

　　九条：我刚把机器重启动……

　　两人等到启动完毕，打开网页，发现一切正常。

　　九条：（纳闷了）昨天晚上的确是挂了。网页上还有一些错误信息。我当时正在干什么来着，好像是在留言或者在论坛上发帖子，我现在也想不清了。让我再玩玩，等着碰到了再叫你。

　　阿亨：这样九条浪费了两个人各一个小时的时间。最后什么进展也没有。一个好的bug 应该这样：

　　标题：购物网站在上传大于100K的文字的时候出错

　　内容有以下几点：

　　环境：在Windows XP下，使用IE7。允许Cookie。购物网的版本是1.2.40。

　　重现步骤：

　　（1）用[用户名，密码] 登录。这一用户在系统中是一般用户。

　　（2）到某一产品页面 （链接为：……）。

　　（3）选中一个帖子， 例如：帖子号为579。

　　（4）回复帖子，在内容中粘贴100K的文字内容（文本内容见附件）。

　　结果：

　　网站出错，错误信息为：[略]

　　预期结果：

　　网站能完成操作，或者提示用户文本内容过大。

　　[在附件中加入100KB的文本文件]。

　　如果是这样的报告，那么开发人员就能够很快地重现这一问题，从而分析和解决问题。