精华内容
下载资源
问答
  • bug的生命周期图
    千次阅读
    2018-05-17 13:50:19
    

    bug的生命周期如下图:

     

    各个流程详细说明如下:

    • 创建新bug,判断其是否已经在数据库中存在同样的bug,如果存在,解其为“Duplicate”。关闭bug,流程结束。
    • 创建新bug,判断其是否已经在数据库中存在同样的bug;如果不存在,判断其是否如此设计;如果是,解其为“By Design"。关闭bug,流程结束。
    • 创建新bug,判断其是否已经在数据库中存在同样的bug;如果不存在,判断其是否如此设计;如果不是,把bug分出去。通过bug中的重现步骤,查看其是否能够重现;如果不能重现,解其为”Not Repro"。关闭bug,流程结束。
    • 创建新bug,判断其是否已经在数据库中存在同样的bug;如果不存在,判断其是否如此设计;如果不是,把bug分出去。通过bug中的重现步骤,查看其是否能够重现;如果能够重现,判断其是否需要被修在下一个版本;如果不需要修,解成“Won't Fix";如果在后面的版本修,解成“postpone”;如果是外部原因造成的不能修,解成“External”。关闭bug,流程结束。
    • 创建新bug,判断其是否已经在数据库中存在同样的bug;如果不存在,判断其是否如此设计;如果不是,把bug分出去。通过bug中的重现步骤,查看其是否能够重现;如果能够重现,判断其是否需要被修在下一个版本;如果需要修,调查bug产生的原因并修复bug;解bug为“Fixed”。在最新版本中或者bug中表明的将被修复的版本中,验证bug是否已经完全修复。如果完全修复,关闭bug,流程结束。
    • 创建新bug,判断其是否已经在数据库中存在同样的bug;如果不存在,判断其是否如此设计;如果不是,把bug分出去。通过bug中的重现步骤,查看其是否能够重现;如果能够重现,判断其是否需要被修在下一个版本;如果需要修,调查bug产生的原因并修复bug;解bug为“Fixed”。在最新版本中或者bug中表明的将被修复的版本中,验证bug是否已经完全修复。如果没有完全修复,重新激活bug;进入修复过程,修复完成重新进行验证,直至bug完全修复。关闭bug,流程结束。


    更多相关内容
  • BUG生命周期和管理

    2021-02-20 14:39:04
    BUG有着无穷的生命力,你会很悲观,认为自己已经无能为力了,这种情绪会在长时间的工作后加重。大家都厌倦重复处理相同的问题,测试人员也已经烦透了长长的BUG列表,精神压力与日俱增。低生产率和低等产品质量,耗费...
  • bug生命周期

    2018-07-27 14:43:13
    详细描述Bug生命周期,以及对生命周期的流程给予详细的介绍
  • Bug生命周期状态流程

    千次阅读 2021-08-27 15:44:52
    bug生命周期 BUG生命周期,就是一个BUG被发现到这个BUG被关闭的过程。 生命周期中缺陷状态:新建-->指派-->已解决-->待验-->关闭 发现BUG-->提交BUG-->指派BUG-->研发确认BUG--&...

    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生命周期

    千次阅读 2021-09-17 10:15:35
    bug生命周期测试人员的主要职责什么是bugbug生命周期1、发现bug2、提交bug3、指派bug4、确认缺陷5、修复BUG6、回归验证BUG7、关闭缺陷管理bug的工具首先是国内的bug管理软件:国外的bug管理软件有: 测试人员的...

    测试人员的主要职责

    测试人员最本质的工作就是寻找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生命周期

    2022-05-19 14:32:26
    测试人员最本质的工作就是寻找bug,提交bug、验证bug、推进...二、bug生命周期 生命周期中缺陷状态:新建–>指派–>已解决–>待验–>关闭 发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>

    测试人员最本质的工作就是寻找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
     

     

     

    展开全文
  • bug生命周期 1. 一个合格的bug应该包括哪几部分 发现问题的版本 出现问题的环境 错误重现的步骤 预期行为的描述 错误行为的描述 注:不要把多个bug放在一起。 2. bug生命周期 测试人员应该跟踪一个bug的整个...
  • BUG生命周期流程

    2008-11-26 15:58:37
    关于BUG管理的流程,在不同公司可以依据实际需要的不同更改.
  • bug生命周期&跟踪处理bug的定义&类型bug的等级致命错误严重错误一般错误细微错误bug的生命周期(重点)bug的跟踪管理-缺陷管理工具(重点)如何提交bug?bug的状态处理 bug的定义&类型 定义:bug是指...
  • BUG生命周期

    千次阅读 2019-06-14 10:23:16
    本篇为【从零开始学产品】系列课第1章第3节 欢迎到公众号菜单栏,获取产品经理课程更多资料 ...一什么是BUG生命周期 世界上本来没有Bug,程序员多了, 就创造出来了Bug了. 程序员为什...
  • Bug,即在测试过程中发现的问题,是测试工程师绩效最重要的考核之一,也是面试常被问到的知识领域。...Bug管理的重点,在于监控Bug生命周期,使Bug处理完整且及时,过程中需要注意一下4个方面: Bug管理要分清职责:
  • 1.3 bug生命周期 1.4 禅道的使用 2 bug的定义 软件的Bug:狭义概念是指软件程序的漏洞或缺陷,广义概念除此之外还包括测试工程师或用户所发现和剔除的软件可改进的细节或与需求文档存在差异的功能实现等。 ...
  • 三、bug级别与生命周期 四、测试执行 一、软件测试&软件开发生命周期 1. 软件测试与软件开发的对应过程 (1)需求阶段:测试人员了解需求、对需求进行分解,得出测试需求。 (2)计划阶段:根据需求编写...
  • Bug生命周期及其管理

    2011-12-23 14:15:42
    本文档记录的是Bug生命周期及其管理,供测试人员参考使用,谢谢!
  • BUG生命周期手册汇编.pdf
  • 软件测试Bug生命周期及其管理,详细的描述了软件测试bug 的流程以及在各个过程中相关人员的指责描述,并赋予图表更加清晰说明,是软件测试从业人员的很好参考
  • bug生命周期以及管理

    2020-04-09 13:41:39
    是指在Bug管理工具中,一个bug被发现到这个bug被关闭的过程,Bug生命周期被分成的阶段是(测试员)新建、(测试员)指派、(开发)接受、(开发)修复、(测试验证)关闭; bug的优先级(Priority) bug的优先级指bug必须被...
  • 一、软件测试的生命周期(软件测试的流程是什么?) 需求分析——测试计划——测试设计/开发——测试执行——测试报告 需求分析:分析需求,验证需求正确性以及合理性,细化需求,根据需求提炼测试点 测试计划:...
  • 基本定义:BUG从发现到这个bug关闭,是一个完整的生命周期。 一:从具体状态上来讲 状态有这几种: 1:new-bug被第一次发现的时候,确认是一个问题,将bug进行记录。 2:assigned-当这个bug被指派给某个开发时...
  • 还有一些可管可不管的bug,不影响使用 优先级:0,1,2...(由重到轻) 缺陷类型:功能上的,性能上的,代码上的,界面设计上的等等 二、Bug生命周期 首先测试人员提交Bug,这时Bug的状态标识为“新建”;...
  • bug生命周期和管理

    2009-07-16 09:22:48
    bug生命周期 Bug管理 软件测试中必不可少的
  • BUG生命周期流程.vsd

    2009-08-19 10:42:19
    BUG生命周期流程,自己画的,画的不好,一点点的经验总结。
  • Bug生命周期

    2021-08-10 07:47:50
    什么是Bug生命周期 ...Bug生命周期图 先来看看Bug生命周期(处理跟踪流程)图: 01提交bug 测试人员在发现bug时,首先会记录bug,即提交bug,新增的bug一般提交给技术负责人进行统一分配指派,这时bug为...
  • 1:bug生命周期,就是一个bug被发现到这个bug被关闭的过程。 生命周期中一般缺陷状态:新建、指派、已解决、待验、关闭。如果待验的bug在验证时没有解决好,我们需要重新打开(激活)->指派->已解决->待...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 75,376
精华内容 30,150
关键字:

bug的生命周期图