错误属性Bug重现环境
这应该是我们再现bug的一个前提，没有这个前提，我们可能无法再现问题，或者与原无着。
操作系统是一般软件运行的一大前提，基本上所有的软件都依赖于操作系统的上面，对于一个软件来说，要想在一个操作系统上运行，就必须在那个操作系统上运行操作系统环境是再现问题的重要前提，因为不同的操作系统可能存在win xp和windows7等差异，也可能存在windows7和CentOS linux等本质差异。
浏览器对于B/S系统和面向公众的互联网产品(网站、邮箱等)也是必须测试浏览器兼容性的重点之一。 在目前的浏览器市场中，各种浏览器都有基于用户的，为了使产品一般化，需要考虑这些产品的兼容性问题。
由于在不同的浏览器之间(IE、firefox、chrome、opera等)或同一系列的不同版本(ie6/ie7/ie8/ie9等)也可能存在兼容性问题，因此在这些APP应用程序中
其他(这个“其他”非常重要)如果系统发现了再现问题，就一定有其特定的前提。 在我测试过的邮箱里，还必须附上它是在测试线上，还是在网络环境中，以及再现问题的账号等。
关于c/s软件，安装某个软件后，可能还需要考虑与其他常用软件的兼容性等，比如影响本软件的安装和使用。 这些是为了再现问题而必须记述的环境。
问题类型
根据JIRA的管理系统划分，错误是一种问题，可以用于跟踪各种类型的问题(实际上，他只是将错误作为子类)。
JIRA系统默认提供的问题类型(大多数系统都可以自定义类型，从而提高灵活性。 ）
在故障：测试过程、维护过程中发现了影响系统运行的缺陷。 (这是常规测试器提交的错误(New Feature :向系统提出的新功能)。 (每个小需求都可以，大的话就相当于一个需求，放在这里是不合理的。 任务：要完成的任务。 (开发或测试任务的分配。 ) Improvement :改进了现有的系统功能。 (一般的产品经理和产品体验所做的事情)当然，不同的公司，他们的人员配置和职责也不太一样。 根据上面的分类，JIRA涵盖了项目(或产品)需要处理的任务、需求和缺陷，而不是简单的缺陷管理系统。
Bug 类型
现在缩小范围，只指我们测试人员在测试中发现的缺陷，发现产品缺陷其实是测试人员工作的主要目的。 当然，要确定问题的类型，还需要对项目(或产品)有深刻的理解。 代码缺陷还是设计缺陷有时很难区分。 当然，这一划分对开发定位问题的影响很小，但对问题类型统计很重要。
让我们来看看一般的分类。
分隔符1(```*代码错误
*设计缺陷
界面优化
*配置相关
*安装部署
性能问题*标准规格
*测试代码
*其他分类2:*功能类(function ) ) ) )。
*性能类(performance ) )
*接口类(UI ) ) )
*易用性类(usability ) )
*兼容性类(兼容性) )
*其他(else ) ``这个分类当然可以定制，我接触到的所有缺陷管理都可以定制。 既然是问题的管理，你当然可以制作和使用特定环境下的系统。 或者，我想用这个系统分配任务。 我的定制类型是前端任务、后端任务、测试任务、配置…
缺陷等级
缺陷等级的这一划分也比较灵活，可以分为3级或4级，也可以分为5级。
致命谋杀缺陷导致系统无法运行，存在导致数据泄露的安全问题。
可能会导致容易修正的异常、容易修复的故障或产品外观难以接受的缺陷。
一般来说，是指不影响产品的运转或运转，不会成为故障的原因，但对产品的外观或下一工序产生较大影响的缺陷
轻微缺陷是指可能对产品外观或下一个工序产生轻微影响的缺陷
提高用户体验的建议。 (一般来说，也建议是缺陷的一种。 这与系统的类型和需求有关)
缺陷优先级（priority）
如果问题处理者面临许多问题需要处理，则需要对问题进行优先排序。 我们使用了工作安排、操作系统有处理流程等优先顺序。
优先级划分： ```低——中——高——紧急
延迟处理——正常队列——优先级处理——紧急处理````错误的重要性和优先级是两个含义不同但相互密切相关的概念，从不同的方面描述了软件缺陷对软件质量和最终用户的影响的步骤和处理方法
一般来说，重大程序的软件缺陷具有很高的优先级。 严重程度高，说明缺陷对软件的危害性大，需要优先处理，严重程序不足
陷可能只是软件不太尽善尽美，可以稍后处理。 严重程度高优先级不一定高：如果某个严重的软件缺陷只在非常极端的条件下产生，则没有必要马上处理。
如果某一个软件缺陷，需要重新修改软件的整体架构，可能会产生更多的潜在缺陷，而且软件由于市场的压力必须尽快发布，此时即使缺陷的严重性很高，是否需要修正，需要全盘考虑。
严重程度优先级不一定低如果是软件名称或公司名称的拼写错误，虽然说其属于界面错误，严重程度不高，但其关系到软件和公司的市场开解，必须尽快修正。
缺陷状态
对于一个问题，其处理过程是一个周期，周期的不同阶段，其所处的状态也是不一样的。不同状态所对应的处理人也是不一样的。
打开： 表示问题被提交等待有人处理。重新指派 ： 问题被重新指派给某人处理。处理 ： 问题在处理中，尚未完成。固定 ： 确认此问题存在，但暂时不进行处理。回归 ： 对已经修复的问题进行回归确认。关闭 ： 问题的最后一个状态。 一个bug的生命周期下面通过一个比较完整的bug的处理流程图，更深刻的理解bug的状态以一个bug的生命周期。
提交（打开）缺陷
在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属性。Bug重现环境，bug类型，bug等级，bug的优先级以及详细的重现步骤，结果与期望等。
当然，我们在提交一个问题之前首先应该保证，这个缺陷是没有被提过的，以免造成重复缺陷单。
如果是回归不通过的缺陷，其状态又会变为打开状态。
分配（转交）缺陷
这一步不是必须的，跟项目模式有关，有些公司测试部门与开发部门独立，那么测试人员就不确定自己测试的模块是由哪位开发人员负责的，在这种情况下，测试人员统一把问题指派给项目组长或经理，由项目组长（或经理）对问题进行确认后再次分配给相应的开发人员。
有些测试人员是穿插到不同研发团队中的，所以对不同的开人发员负责的开发模块非常清楚，这个时候就可以将问题直接指派给相应的开发人员。
也有一种情况，本来此问题应该由A开发人员负责，但由于A开发人员的调离或辞职，些问题为转交给其它人员处理。“分配”强调是上级对下级；“转交”强调的是平级之间。
确认缺陷
当开发人员接到一个缺陷时，首先是对其进行分析与重现，如果对其进行分析发现不是缺陷（可能由于测试人员不了解需求）或无法对此问题进行重现，那么就需要将此问题反回给测试人员，并注明原因。如果确认为缺陷则需要对其进行处理。
推迟处理
在处理问题之后，还需要进行一次判断，是否需要推迟处理，有些需求已经确认了是问题，由于其可能在极端情况下才会出现，或需要对系统架构进行改动，或其优先级非常低，所以暂时不需要对此问题进行处理（或到下个版本进再进行修复）。
固定
对于推迟处理的问题可以暂时进行固定（“固定”为QC中的叫法。）一般固定的问题需要经过项目经理与测试经理协商后才能固定。
处理缺陷
开发人员在确认完一个问题需要处理时，那么就对其进行处理工作。（例如，redmine 是支持处理人时时更新问题处理进度的，如 已处理30% ，已处理80% 等，当然，对于短时间内可以修复的问题就没必要时时的去更新处理进度。）
回归缺陷
回归缺陷对于测试人员来说是非常重要的工作，其有三个入口两个出口。
确认非缺陷问题：对于提交的一个缺陷，开人员处理为非问题或无法重现，然后直接转交给测试人员回归。测试人员再次确认，如果真如开发人员所说，则将问题关闭。如果非开发人员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发人员。
确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则关闭问题。确认不通过，将问题再次打开并转给开发人员。
确认固定问题：有计划的对固定问题进行确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些固定问题依然存在且变得紧急，对于这类问题应该及时打开交给开发人员处理。
关闭缺陷
对于已经修复的缺陷进行关闭，这也是一个缺陷的最后一个状态。
最后，“状态”和“指派人”的对应关系如果更加细化，对项目而言是有益的： ```已关闭—>指派给修复这个bug的开发工程师。
无需解决，不是bug—>指派给提交这个bug的测试人员。
无需解决，迭代待解决—>指派给项目的产品经理。 ```