bug的生命周期

BUG的生命周期，就是一个BUG被发现到这个BUG被关闭的过程。

生命周期中缺陷状态：新建-->指派-->已解决-->待验-->关闭

发现BUG-->提交BUG-->指派BUG-->研发确认BUG-->研发去修复BUG-->回归验证BUG-->是否通过验证-->关闭BUG

如果待验的BUG在验证时没有解决好，我们需要重新打开--指派—已解决—待验，循环这个过程。

中间其他状态：拒绝、延期等

BUG的处理流程图（生命周期图）

状态处理

1.已经指派的BUG---已经指派给开发的，应随时关注并进行跟踪自己所提BUG的状态变化！如果一直未修复，提醒开发人员修改；如果已经修复等待测试环境更新后进行验证

2.已解决的BUG----等待测试环境更新后进行验证，验证通过则关闭；验证不通过则重新指派给开发

3.重复BUG----先去查看下是否跟开发指定的BUG或者，自己在BUG系统内看到的BUG重复？如果确定重复则关闭；如果不重复，说明原因，重新打开指派给开发。

4.不是缺陷----确认开发环境是否和测试环境一致，如果如开发所说不是缺陷则进行关闭；如果确认是缺陷跟开发沟通，沟通未达一致找产品/反馈老大确认，确认是BUG注明情况并再次指派给开发。

5.无法重现----确认开发环境是否跟测试环境一致？包括操作步骤，浏览器、环境、特定账号等，如果多个版本验证之后，如开发所说重现不了，依据BUG的严重程度跟产品，开发一起确认关闭；如果找到重现原因，注明清楚并再次指派给开发。

6.不予解决---找产品经理进行确认。确认不予解决进行关闭；确认需要解决请备注原因并打开指派给开发

7.设计如此---找产品经理进行确认。确认设计如此进行关闭；确认是问题，备注原因重现指派给开发。

8.延期修改---请看下BUG严重程度，是否影响当前版本发布？与产品经理进行确认。不予延期请根据情况重新打开并将情况进行备注说明；确定延期则做好记录，后续版本进行关注。

开发同学注意事项：

开发人员应在BUG系统中，备注好以下信息：

已修改BUG应在该BUG的注释处，备注修改方案及信息，以备以后出现类似的问题时，可以快速的找到原因

设计如此（不是缺陷）、不予解决、延期解决的BUG、无法重现的BUG，应备注处理的原因，节省沟通的时间，以及，如果后续有相同问题时，可以快速查找到原因

重复BUG注明重复BUGID

测试人员的主要职责

测试人员最本质的工作就是寻找bug，提交bug、验证bug、推进bug的解决，直至软件达到发布的标准，提高软件的质量，及研发的工作效率和质量。

什么是bug

软件的BUG,狭义方面可以理解为是是指软件程序的漏洞或缺陷，广义方面除找到程序的之外之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。即测试的介入可以从需求分析开始，跟踪开发流程。

bug的生命周期

二、bug的生命周期
生命周期中缺陷状态：新建–>指派–>已解决–>待验–>关闭
发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG

1、发现bug

a.按照测试用例进行操作，发现和测试用例的预期结果不一致的,都可以被称之为Bug。
b.测试用例不可能穷尽，总有超出你预料之外的因素,或者是神操作出现的bug。
c.成本问题，没有充足的时间编写测试用例，发现的bug

2、提交bug

在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属性、Bug重现环境，bug类型，bug等级，bug的优先级以及详细的重现步骤，结果与期望等。
当然，我们在提交一个问题之前首先应该保证，这个缺陷是没有被提过的，以免造成重复缺陷单。

3、指派bug

这一步不是必须的，跟项目模式有关，有些公司测试部门与开发部门独立，那么测试人员就不确定自己测试的模块是由哪位开发人员负责的，在这种情况下，测试人员统一把问题指派给项目组长或经理，由项目组长（或经理）对问题进行确认后再次分配给相应的开发人员。

有些测试人员是穿插到不同研发团队中的，所以对不同的开人发员负责的开发模块非常清楚，这个时候就可以将问题直接指派给相应的开发人员。

也有一种情况，本来此问题应该由A开发人员负责，但由于A开发人员的调离或辞职，些问题为转交给其它人员处理。“分配”强调是上级对下级；“转交”强调的是平级之间。

4、确认缺陷

当开发人员接到一个缺陷时，首先是对其进行分析与重现，如果对其进行分析发现不是缺陷（可能由于测试人员不了解需求）或无法对此问题进行重现，那么就需要将此问题反回给测试人员，并注明原因。如果确认为缺陷则需要对其进行处理。

5、修复BUG

推迟处理
　　在处理问题之后，还需要进行一次判断，是否需要推迟处理，有些需求已经确认了是问题，由于其可能在极端情况下才会出现，或需要对系统架构进行改动，或其优先级非常低，所以暂时不需要对此问题进行处理（或到下个版本进再进行修复）。

固定：
　　对于推迟处理的问题可以暂时进行固定（“固定”为QC中的叫法。）一般固定的问题需要经过项目经理与测试经理协商后才能固定。

处理缺陷：
　　开发人员在确认完一个问题需要处理时，那么就对其进行处理工作。（例如，redmine 是支持处理人时时更新问题处理进度的，如 已处理30% ，已处理80% 等，当然，对于短时间内可以修复的问题就没必要时时的去更新处理进度。）

6、回归验证BUG

回归缺陷对于测试人员来说是非常重要的工作，其有三个入口两个出口。

确认非缺陷问题：对于提交的一个缺陷，开人员处理为非问题或无法重现，然后直接转交给测试人员回归。测试人员再次确认，如果真如开发人员所说，则将问题关闭。如果非开发人员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发人员。

确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则关闭问题。确认不通过，将问题再次打开并转给开发人员。

确认固定问题：有计划的对固定问题进行确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些固定问题依然存在且变得紧急，对于这类问题应该及时打开交给开发人员处理。

7、关闭缺陷

对于已经修复的缺陷进行关闭，这也是一个缺陷的最后一个状态。
在做接口测试的时候可以使用国产的接口测试和接口文档生成工具apipost

管理bug的工具

Bug会导致软件在运行时发生意料不到的故障，给企业带来损失，而软件测试的过程简单来说就是围绕bug进行的质量保证工作。为了提高测试工作效率，同时能够更高效的管理bug、提交bug、解决bug，合理的使用一些bug管理软件是非常有必要的。

首先是国内的bug管理软件：

禅道

禅道是第一款国产开源项目管理软件。它的核心管理思想基于敏捷方法scrum，内置了产品管理和项目管理，同时又根据国内研发现状补充了测试管理、计划管理、发布管理、文档管理、事务管理等功能。在一个软件中就可以将软件研发中的需求、任务、bug、用例、计划、发布等要素有序的跟踪管理起来，完整地覆盖了项目管理的核心流程。

禅道使用自主开发的zentaophp框架开发，内置了完整的扩展机制，用户可以非常方便的对禅道进行彻底的二次开发。禅道还为每一个页面提供了json接口的api，方便其他语言来调用交互。内置多语言支持，多风格支持，搜索功能，统计功能等实用功能。

Tracup

Tracup 是一款轻量级的团队协同平台，提供简洁、高效的 Bug 追踪，轻量、便捷的项目管理，安全、稳定的数据保障，完美地将 Bug管理与团队协作结合在一起。

无论是修改Bug，还是新增一个功能， Tracup 都可以提供一个理想的工作云平台。便捷团队协作，轻量的项目管理， 完备的问题系统，大容量的文件存储，让用户工作更方便。

Bugtags

Bugtags是新一代的、专为移动测试而生的缺陷发现及管理工具。致力于改善移动 app 的测试流程，连接发现缺陷与提交缺陷之间的用户体验，提高测试及解决缺陷的效率。帮助测试人员高效的进行 app 测试及 bug 的跟踪和管理。

移动 app 集成 bugtags SDK 后，测试用户就可以直接在 app 里所见即所得的提交 bug，SDK 会自动截屏、收集 app 运行时数据，如：设备信息，控制台数据，用户的操作步骤等，开发人员在 bugtags 云端高效的跟踪及管理 bug。

Bugtags 与其它 bug 管理系统相比，最大的区别在于：

Bugtags 是专为移动开发而设计的，不是简单将以前面向 Web 及桌面应用的 bug 管理系统进行的改进或升级，而是完全以移动 app 开发及测试的视角重新设计的 bug 管理系统。

Bugtags 不需要布署，云端注册即可使用，简单便捷。

国外的bug管理软件有：

Bugzilla

Bugzilla 是 Mozilla 公司提供的一款开源的免费 Bug 追踪系统，它可以管理软件开发中缺陷的提交（new），修复（resolve），关闭（close）等整个生命周期。用来管理软件开发，建立完善的 Bug 跟踪体系。

JIRA

JIRA是一个缺陷跟踪管理系统，开发者是 Atlassian。JIRA 这个名字并不是一个缩写，而是截取自“Gojira” 。JIRA被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA中配置灵活、功能全面、部署简单、扩展丰富，其超过150项特性得到了全球115个国家超过19,000家客户的认可。

WebIssues

WebIssues是一个采用客户机/服务器模式的团队协作工具和问题跟踪系统，可以支持小规模的开发团队。它可以被用来存储，共享和跟踪问题的各种属性，注释和文件附件。很容易安装和使用，高度可定制。服务器可安装在任何支持PHP和MySQL或PostgreSQL的主机上，客户端可以是视窗或Linux的桌面。

Bugify

Bugify是一个非常简单的bug跟踪管理系统，并且功能非常强大。它的主要功能有：问题优先级，搜索过滤，邮件通知，标签，问题链接，键盘快捷键，Mardown格式化，最突出的功能就是支持无限种其他语言。

测试人员最本质的工作就是寻找bug，提交bug、验证bug、推进bug的解决，直至软件达到发布的标准，提高软件的质量，及研发的工作效率和质量。
一、什么是bug

软件的BUG,狭义概念是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。
二、bug的生命周期

生命周期中缺陷状态：新建–>指派–>已解决–>待验–>关闭

发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG

1、发现bug

1）按照测试用例进行操作，发现和测试用例的预期结果不一致的,都可以被称之为Bug。

2）测试用例不可能穷尽，总有超出你预料之外的因素,或者是神操作出现的bug。

3）成本问题，没有充足的时间编写测试用例，发现的bug

2、提交bug

在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属性。Bug重现环境，bug类型，bug等级，bug的优先级以及详细的重现步骤，结果与期望等。

当然，我们在提交一个问题之前首先应该保证，这个缺陷是没有被提过的，以免造成重复缺陷单。

3、指派bug

这一步不是必须的，跟项目模式有关，有些公司测试部门与开发部门独立，那么测试人员就不确定自己测试的模块是由哪位开发人员负责的，在这种情况下，测试人员统一把问题指派给项目组长或经理，由项目组长（或经理）对问题进行确认后再次分配给相应的开发人员。

有些测试人员是穿插到不同研发团队中的，所以对不同的开人发员负责的开发模块非常清楚，这个时候就可以将问题直接指派给相应的开发人员。

也有一种情况，本来此问题应该由A开发人员负责，但由于A开发人员的调离或辞职，些问题为转交给其它人员处理。“分配”强调是上级对下级；“转交”强调的是平级之间。

4、确认缺陷

当开发人员接到一个缺陷时，首先是对其进行分析与重现，如果对其进行分析发现不是缺陷（可能由于测试人员不了解需求）或无法对此问题进行重现，那么就需要将此问题反回给测试人员，并注明原因。如果确认为缺陷则需要对其进行处理。

5、修复BUG

推迟处理
在处理问题之后，还需要进行一次判断，是否需要推迟处理，有些需求已经确认了是问题，由于其可能在极端情况下才会出现，或需要对系统架构进行改动，或其优先级非常低，所以暂时不需要对此问题进行处理（或到下个版本进再进行修复）。

固定
对于推迟处理的问题可以暂时进行固定（“固定”为QC中的叫法。）一般固定的问题需要经过项目经理与测试经理协商后才能固定。

处理缺陷
开发人员在确认完一个问题需要处理时，那么就对其进行处理工作。（例如，redmine 是支持处理人时时更新问题处理进度的，如 已处理30% ，已处理80% 等，当然，对于短时间内可以修复的问题就没必要时时的去更新处理进度。）

6、回归验证BUG

回归缺陷对于测试人员来说是非常重要的工作，其有三个入口两个出口。

确认非缺陷问题：对于提交的一个缺陷，开人员处理为非问题或无法重现，然后直接转交给测试人员回归。测试人员再次确认，如果真如开发人员所说，则将问题关闭。如果非开发人员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发人员。

确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则关闭问题。确认不通过，将问题再次打开并转给开发人员。

确认固定问题：有计划的对固定问题进行确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些固定问题依然存在且变得紧急，对于这类问题应该及时打开交给开发人员处理。

7、关闭缺陷

对于已经修复的缺陷进行关闭，这也是一个缺陷的最后一个状态。

在做接口测试的时候可以使用国产的接口测试和接口文档生成工具apipost