提高工作效率，使用Bug分类列表来更好的进行软件测试

在软件测试的工作中，做好bug分类是一件很重要的事情。它首先需要定义每个bug类别的feature，然后按着这个特征进行bug的收集，最后形成一份属于自己的bug清单。

这样的一份列表可以给那些初入测试行业的新生提供一些启发；或者为其他的测试人员提供新鲜的idea，毕竟每个人的经验/思维都可能是其他人欠缺的，三人行必有我师；这份列表在手，还可以为自己的测试工作进行完整性评估。

总而言之，有这样的一份列表总是好的，不论是互联网上获取的现成的，还是自己不断总结积累的（显然自己的更好）。

By Michael Stahl

即使是研发部门的一员，每天的工作也不是持续地创造新的产品。相信每一个在研发部门工作过的人都知道，实际上出新的工作少的可怜，更多的还是重新做着曾经做过的事情。

举个例子，你开展了个崭新的项目，内容是制造一个能够解决世界饥饿问题的嵌入式系统。最终产品必须现场升级才能解决2.0版本的臭氧层枯竭问题，所以你需要一个“固件更新”的功能。

之前没人做过这个功能吗？怎么可能没做过！任何嵌入式系统都得有这个功能。

然而这个解决世界饥饿问题的项目团队又一次面临了同样的挑战，或者说同样的错误。如果不是自己的开发团队开发出了这些“东西”，也是其他一些团队犯下了类似的错误。所以，现在我们不得不重新造轮子。

他人的经验/团队的经验/人类的经验，能够共享的话，就不必重新造轮子了。

这完完全全是多余的、低效的。应该有一种方法可以在项目之间，老手和新手之间，组织之间，甚至不同公司之间互相传递人类（开发测试人员）积累的知识——bug清单。

开始使用Bug分类法

分享测试知识/经验的一种方法是建立出bug分类的清单文档。总体思路是，定义特征类别并收集每个类别中可能的bug。

这些列表可以给有经验的测试人员提供更多哪些地方需要去测试的信息；

给没有经验的测试人员列出需要测试的项目，并提供他们可能没有意识到需要测试的产品方面（如性能和可用性方面等）的建议；

通过检查测试中是否已覆盖全部列表项，来评估测试案例列表的完整性。

下面是来自Cem Kaner，Hung Q. Nguyen和Jack Falk 的《测试计算机软件 》一书的摘录：

性能测试

Slow program 程序慢

Slow echoing 回应慢

Poor responsiveness 响应差

No type-ahead 在用户填写表单时,没有为用户提供提示或数据/输入提示

No warning that an operation will take a long time 当一个操作将需要很长时间时没有警告信息

No progress reports 没有进度报告

Problems with time-outs 超时问题

上面一部分是显而易见的需要测试的功能点，另一部分用来提醒我们测试中是否有可能错过某些点。

例如，“当一个操作将需要很长时间时没有警告信息”这个bug会触发许多验证的思路：我们产品中是否有任何功能可能要很长时间？是在什么条件下？我们是否提供进度跟踪？跟踪是否准确？

它也可以触发有关冗余功能的想法：是否有一个只需花费很短时间的操作在完成的一瞬弹出个窗口然后消失掉，让用户完全搞不清楚发生了什么。

有个有趣的事情是，列表中的一些想法有保质期。例如，输入提示功能再第一代计算机中出现时，用户输入过快就很容易超出屏幕的更新速度，但是对现在的CPU而言通常不是问题。

创建你自己的Bug分类

别人写出的bug列表的思维过程不一定与你的思维方式相同。结果是，你期望在某个类别下找到的项目出现在看起来对你并无意义的类别中。

举个例子，有人会在“绩效”这个类目下放置“没有进度报告”，但是另一个人期望在“用户体验”下看到这一项目。同时，由于列表性质的描述一般都是简洁明了（很多人写文档只为了自己能看懂就好），所以别人会觉得难以理解。

这样的后果就是，你必须把所有的（就算不是所有的，也是很大一部分）都浏览一遍，挑挑拣拣之后，再总结出适合自己项目的一套列表。

所以创建个人的列表然后共享确实是一个好主意，但是实现的过程却没有说的那么轻松……我们应该放弃么？

不。我的一个经验是，将你经常会遇到的bug总结成一个列表，因为是你自己写的，所以你的组织会高度认可它，而且它的内容对你而言是无比清晰的，这份列表的复用率就会很高。

我有一个很久以前准备好的清单，概述API测试的各个方面。无论何时，当我学习或发现一个新的API测试项目时，我将其添加到列表中。但是我不会分享这个列表，因为上文说过的原因：它是以我理解的格式写成的，不容易马上被其他人理解。所以当我分享它的时候，我需要亲自与收件人对一遍，确保他们真的懂了每一项的意思。对我而言，这份名单是非常有价值的，我也用了很多次。

这个轶事不能作为一个严格的统计调查样本，但我认为它指向一个可能的方向：bug列表很有用，尤其是你自己写出一份的时候，它会发挥更大的作用。

日积月累，这一份清单会逐渐发展，成为一个极具价值的资源。

你可以自己做，也可以小组来做，但是如果你选择后者，我建议你不仅邀请测试人员，而且还邀请开发人员和产品经理，来提供一些其他更具创意性的想法。即使你不能直接找到任何可重用的东西，也很可能触发一些新的有价值的想法。