从刚工作时接触的第一个缺陷管理工具禅道，到redmine、JIRA、bugzilla ，再到现在的QC，当然还有其它种的开源的或商业的缺陷管理工具，它们的本质是一样的，是来管理缺陷的生命周期。

　　其实，你理解任意的一款工具，其它的工具也一定能无师自通。这不谈某款工具，单把它本质的一些东西抽离出来与大家分享。

　　Bug的属性

　　Bug重现环境

　　这个应该是我们重现bug的一个前提，如果没有这个前提，我们可能会无法重现问题，或者跟本无从下手。

　　操作系统

　　这个是一般软件运行的一大前提，基本上所有的软件都依赖于操作系统之上的，对于一个软件来说，要想在某个操作系统上运行，必须要对这个操作系统支持，这需要有真对性的设计与开发。对于不同的操作系统，其可能存在差异（如：win xp 与 win 7）或本质的区别（如 win 7 与 CentOS linux ），所以，操作系统环境是重现问题的一个重要前提。

　　浏览器

　　对于B/S系统，或面向大众的互联网产品（网站，邮箱等），浏览器的兼容性也是必须测试的一个重点，对于现在的浏览器市场，各式的浏览器都有其用户群，要想使产品大众化，必须考虑这些产品的兼容性问题。

　　不同的浏览器之间（IE、 firefox、chrome、opera 等），甚至同一系列不同版本（ie6/ie7/ie8/ie9等）都可能存在兼容性问题，所以，对于这类应用，浏览器环境重现bug前提条件之一。

　　其它（这个“其它”非常重要）

　　对于不同的系统发现重现问题，都会有其特定的前提，拿我测试的邮箱来说，必须要描述其是在测试线还是现网环境，而且还要附带一重现问题的帐号等。

　　对于c/s软件，可能还要考虑与其它常用软的兼容等，例如，是在安装的某款软件后，对本软件的安装和使用造成影响。这些都是重现问题的必须描述的环境。

　　问题类型

　　根据JIRA的管理系统的划分，bug 只是问题的一种，它可以用于跟踪多种不同类型的问题（其实，他只是将bug做为一子类而已）。

　　JIRA系统缺省提供的问题类型（大部分的系统都可以自定义类型的，这样增加了灵活性。）

　　● Bug ： 测试过程、维护过程发现影响系统运行的缺陷。（这是一般测试人员所提交的bug）

　　● New Feature ：  对系统提出的新功能。（单个的小需求可以，如果大的话，相当于一个需求，放到这里是不合理的。）

　　● Task ： 需要完成的一任务。（开发或测试任务指派。）

　　● Improvement ： 对现有系统功能的改进。（一般产品经理或产品体验师做的事）

　　当然，不同的公司，他们的人员定位与职责是不太相同的，按照上面的分类，JIRA不是简单的缺陷管理系统了，它涵盖一项目（或产品）所需要处理的任务、需求与缺陷。