你会靠谱的进行(Bug)错误报告吗？

我们知道，在软件项目中经常会有各种或大或小的Bug，更甚一点出现Error。那么如何清晰无异议的提出Bug呢？是不是经常遇到别人给你说某某地方有个Bug，然后就没有然后了...你是什么反应？或者一个功能表面上看起来都是正常的，但他说结果错了，然后呢，然后也没然后了，你去看了一下，好像都正常，没有报错什么的，这时候你是什么反应？

常见的两种提Bug的情况：

• 第一种，只说错误现象。在没有明显的错误情况下，报告错误而不说正确的结果应该是什么，没有应该正确的结果（预期结果）对比，光说错误相当于污蔑。

• 第二种，描述笼统。

• 第三种，Bug point缺乏上下文。比如说，某个页面里的一个功能按钮有bug，如果直接报告这个功能按钮，你是一下子反应不过来的，你的系统分为很多大模块，然后下面有小模块，然后下面有很多页面，这个页面里有很多功能按钮，甚至很多页面都有相同的按钮，那么到底是说哪个页面的功能按钮有Bug呢？

下图是我司禅道项目管理系统中今天分配给我的一个真实任务：

部分具体是指哪些？位置从哪调整到哪？新增的薪资模块又是什么，放哪？有没有想骂人的冲动？？ 如果不想详细表达好歹可以来一张示意图吧….

比如，张三创建了一个Bug给李四

标题：挂了

内容：我今天在玩XXXX网的时候，发现XXXX网站挂了。

这个Bug对问题的描述太过笼统，开发人员根本无从下手。李四拿到这个Bug，也是哭笑不得，试了试网站的各个页面，好像也都正常。他于是把这个Bug又推给张三，“哪里挂了？”

过了一会儿，张三回复“在我的机器上挂了”。

李四跑到张三的座位上，想看看“犯罪现场”。

张三：我刚重启了机器……

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

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

李四：这样九条浪费了两个人各一个小时的时间，最后什么进展也没有。一个好的Bug报告应该是这样的：

标题：购物网站的某个具体页面（URL），在回复中提交大于100KB的文字时会出错内容有以下几点：

环境：
在Windows XP下，使用IE7。允许Cookie。购物网的版本是1.2.40。
重现步骤：
1）用[用户名，密码]登录。这一用户在系统中是一般用户。
2）到某一产品页面（链接为：……）。
3）选中一个帖子，例如：帖子号为579。
4）回复帖子，在内容中粘贴100KB的文字内容（文本内容见附件）。
结果：网站出错，错误信息为：[略]
预期结果：网站能完成操作，或者提示用户文本内容过大。[在附件中加入100KB的文本文件]。

测试人员还可以附上其他分析，团队应该鼓励测试人员追根溯源。如果看到测试人员发来这样的Bug报告，那么开发人员就能够很快地重现这一问题，从而有效地分析和解决问题。

那么，靠谱受欢迎的Bug报告要怎么提？

软件项目管理工具通常支持多种类型的记录，“任务(Task)”和“缺陷(Bug)”是最基本的两种记录，任务=要做的事情，缺陷=意外发生的故障。当软件工程师完成了预定的任务，达到“代码完成”之后，团队的成员主要用Bug这种类型的记录来交流。在一定规模的软件项目中，一份好的错误报告，至少要满足以下几点。

1. Bug的标题，要能简要说明问题。

2. Bug的内容要写在描述中，包括：

   1. 测试的环境和准备工作。

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

   3. 实际发生的结果。

   4. （根据软件功能说明书和用户的期望）应该发生的结果。

3. 如有其他补充材料，例如相关联的Bug、输出文件、日志文件、调用堆栈的列表、截屏等，应保存在Bug对应的附件或链接中。

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

在实际生活中，在没有规范的前提下，请尽量做的规范一点，心中有佛，随处修行

文章首发于我的微信公众号，关注可获得每次最新推送

---

《构建之法》读书笔记之一