软件工程33-测试工具：为什么不应该通过QQ-微信-邮件报Bug？

而现在正规的软件项目已经不会再用这种原始的方式来报 Bug 了，而是会借助测试工具来帮助报告和跟踪 Bug，即使你偶尔能看到有项目还在采用原始方式报 Bug，你肯定也会觉得这样做不专业。

但不知道你有没有仔细想过这个问题，为什么现在不通过 QQ/ 微信 / 邮件报 Bug，又有哪些测试工具可以帮助你更好地发现、报告和跟踪软件中的 Bug 呢？今天我们会展开讨论这个问题。

Bug 跟踪工具

我想你对与 Bug 这个词一定不陌生，它是我们软件中的缺陷或错误。这个词的诞生也很有意思。

1947 年 9 月 9 日，一只小飞蛾钻进了哈佛大学的一台计算机电路里，导致系统无法工作，操作员把飞蛾贴在计算机日志上，写下了“首个发现 Bug 的实际案例”。

（图片来源：WikiPedia《Software bug》）

虽然 Bug 的历史已经有 60 多年了，然而 Bug 跟踪工具却没有出现太久。软件项目中最早也是通过邮件、即时通讯等原始方式报告 Bug，直到 1992 年才有第一个专业的 Bug 跟踪软件GNATS。

在这之后才逐步有了像 Bugzilla、Jira、MantisBT 等专业的 Bug 跟踪工具。而现在，Bug 跟踪工具已经成为软件项目中必不可少的工具之一。

那么，Bug 跟踪工具是怎么逐步替代 QQ、邮件等方式来处理 Bug 的呢？

为什么要使用 Bug 跟踪工具？

我们在上一篇学习了软件测试相关的理论知识，软件测试的主要工作就是发现 Bug、报告 Bug 和跟踪 Bug。测试人员发现 Bug 只是第一步，还需要报告 Bug 让开发人员可以知晓和定位，并且跟踪整个 Bug 修复的过程。

用 QQ 或者邮件报 Bug 的这种方式，看起来快捷简单，但是问题很多：

• Bug 不能有效被跟踪，不知道一个 Bug 是不是已经被修复了；
• 效率很低，开发人员频繁的被这样的报 Bug 的消息打断，不得不停下手头的工作去甄别 Bug；
• 不能直观的了解当前项目的 Bug 状态，比如说：修复了多少，还有多少没有修复，近期 Bug 数量是增加了还是减少了。

不难看出，通过 QQ 等方式报告的 Bug，都是文字配合图片等信息，很难检索和分类，而 Bug 跟踪工具，采用结构化的数据来定义 Bug，每一个 Bug 都有一些关键的信息可以对 Bug 进行分类和检索。

在 Bug 跟踪工具使用中，一个基本的 Bug 信息包括：

• 标题；
• 描述（包括期望结果、实际结果和重现步骤等关键信息）；
• 优先级；
• 指派人；
• 状态（New、Open、 Rejected、Fixed 等）；
• 其他。

那这样的话，就很容易的对 Bug 进行分类和检索，比如说：

• 张三想查看所有分配给他的 Bug，那只要列出所有指派人是张三的 Bug；
• 想列出所有未解决的 Bug，只要列出所有状态不是 Close 或 Rejected 的 Bug 即可。

这样对于开发人员来说，可以直观的看到自己有哪些 Bug 需要处理，Bug 的描述信息也可以帮助重现 Bug、快速定位到 Bug 的原因；对于项目经理或者测试人员来说，可以直观的看到哪些 Bug 还没解决，及时了解项目进展。

另外，我在《12 | 流程和规范：红绿灯不是约束，而是用来提高效率》这篇文章中提到了项目中的流程和规范&#