bugzilla作为测试人员常见的测试工具，被所有人熟悉和使用着。

可是，bugzilla究竟给我们带来了些什么呢？

第一，bugzilla给了测试人员话语权。我们通过它，作为一个平等互利的角色向开发人员，官方的，正式的发出我们的成果宣言：一个bug。

第二，bugzilla给了测试人员平等权。测试人员不再是开发人员的帮手，大家是从不同的视图来看待一个产品的质量。 bugzilla是作为开发人员和测试人员交流的平台。 同时，这个交流平台也连接了项目管理，过程管理，需求人员，设计人员，销售人员，技术支持人员，和终客户，是大家能有一个平台去交换各自的想法。

第三，bugzilla使得测试人员能使用一个标准化的对象去进行信息内容的沟通。

第四，bugzilla使得测试人员能够更加迅速的了解产品的当前质量状态，从而调整各种计划和工作。

第五，bugzilla使得测试人员能够积极的参与到产品的管理过程中，对整个产品的管理提供更多的技术细节和过程参数。

对于如何使用bugzilla进行项目管理，我们不妨举几个例子：

例子一：我们在测试过程中，经常会遇到这种现象，是一个模块会突然爆发出很多bug来。难道bug真的那么多吗，其实很多时候，是因为开发人员在修改一个bug时，引起其他已经修复的bug被reopen或者导致更多的新bug。

我们如果有一个机制，去监控 近3天内，新加的bug的原因。那么，这种问题能够作为一个风险进入我们的风险管理过程。如果有相应的风险管理，那么执行。如果没有，需要加入。并且，根据实际情况，我们来判断，还有多少潜藏的bug会以这种方式出现。

例子二，我们在做测试计划的时候，很难说我们的测试各个阶段都能够很详细的制定出内容来。比如回归测试，到底哪些东西要做回归测试呢，什么样的频度，什么样的深度？

我们可以在功能测试结束前的2周，对现有的bug进行分析，依据bug的在各个模块的分布数量，优先级的加权等，来确定哪些需要重点进行回归，那些可以忽略。从而对各个模块的功能测试用例进行筛检，从而得到回归测试需要执行的规模和频度。

例子三，当一个产品被release之后，或者一个sprint结束之后，我们也可以对bug进行分析，通过bugzilla自带的很多图表，我们能够对上个阶段的产品质量有一个很直接的可视化分析，然后写出QA角度的分析报告来，提供给管理层和开发团队作为参考，从而在下一个阶段中能够更好的提高质量和效率。甚至，可以以QA的视角，去管理下个阶段的开发过程和质量保证过程。

总之，bugzilla不是仅仅作为我们QA跟开发交流的工具，还可以作为测试驱动开发的工具，可以作为产品质量衡量的工具。