精华内容
下载资源
问答
  • 缺陷生命周期

    千次阅读 2015-12-19 09:42:00
    缺陷生命周期 (K3)根据IEEE Std 1044-1993定义的异常管理生命周期进行缺陷管理。 (K3)根据IEEE Std 1044-1993评估缺陷报告和缺陷分类以改进缺陷报告的质量。  缺陷生命周期  (K3)根据IEEE Std 1044-1993定义...
    缺陷生命周期 (K3)根据IEEE Std 1044-1993定义的异常管理生命周期进行缺陷管理。 (K3)根据IEEE Std 1044-1993评估缺陷报告和缺陷分类以改进缺陷报告的质量。

      缺陷生命周期

      (K3)根据IEEE Std 1044-1993定义的异常管理生命周期进行缺陷管理。

      (K3)根据IEEE Std 1044-1993评估缺陷报告和缺陷分类以改进缺陷报告的质量。

      和软件开发生命周期一样,缺陷也是由一系列的阶段和活动组成的,即缺陷同样具有生命周期。如图1所示,根据IEEE Std 1044-1993 中的描述,缺陷生命周期主要由四个阶段组成:识别(Recognition)、调查(Investigation)、改正(Action)、总结(Disposition)。

      图1 缺陷分类过程

      对于缺陷生命周期的每个阶段,都包括记录(Recording)、分类(Classifying)和确定影响(Identifying Impact)三个活动。缺陷生命周期的四个阶段看起来是按照顺序进行的,但是缺陷可能会在这几个阶段中进行多次迭代。下面对缺陷生命周期的每个阶段和阶段中的活动进行详细的讨论。

      1、识别

      缺陷的识别是整个缺陷生命周期的第一个阶段,它可以发生在软件开发生命周期的任何一个阶段。缺陷的识别可以由参与项目的任何利益相关者完成,例如:系统人员、开发人员、测试人员、支持人员、用户等。缺陷识别阶段的主要活动包括:

      记录:在缺陷识别阶段,需要记录缺陷的相关信息,包括发现缺陷时的支持数据信息和环境配置信息,例如:被测系统的硬件信息、软件信息、数据库信息和平台信息等。

      分类:在缺陷识别阶段,需要对缺陷相关的一些重要属性进行分类,主要包括发现缺陷时执行的项目活动(如表1所示)、引起缺陷的原因、缺陷是否可以重现、缺陷发现时的系统状态、缺陷发生时的征兆等。

      确定影响:根据缺陷发现者的经验和预期,判断缺陷可能会造成的影响,例如:缺陷的严重程度(如表2所示)、优先级,以及缺陷对成本、进度、风险、可靠性、质量等的影响。

      表1 发现缺陷时的项目活动分类

      表2 严重程度分类

      2、调查

      经过缺陷识别阶段后,需要对每个可能的缺陷进行调查。调查阶段主要是用来发现可能存在的其他问题以及相关的解决方案,解决方案包括"不采取任何行动"。缺陷调查阶段的主要活动包括:

      记录:在缺陷调查阶段,需要记录相关的数据和信息,对缺陷识别阶段记录的信息进行更新。缺陷调查阶段记录的信息包括缺陷调查者的信息、缺陷调查的计划开始时间、计划结束时间、实际开始时间、实际结束时间、调查工作量等。

      分类:在缺陷调查阶段,需要进行分类的属性包括缺陷引起的实际原因、缺陷的来源、缺陷的具体类型等。同时,对缺陷识别阶段中的分类信息,根据需要进行检查和更新。

      确定影响:根据缺陷调查阶段的分析结果,对缺陷识别阶段的影响分析进行更新。

      表3列举了调查阶段的支持数据。

      表3 调查阶段的支持数据表格

      3、改正

      根据缺陷调查阶段中得到的结果和信息,就可以采取改正措施解决引起缺陷的错误。采取的行动可能是修复缺陷,也可能是针对开发过程和测试过程的改进建议,以避免在将来的项目中重复出现相似的缺陷。针对每个缺陷的修复,需要进行相关的回归测试和再测试,避免由于缺陷的修复而影响原有的功能。缺陷改正阶段的主要活动包括:

      记录:在缺陷改正阶段,需要记录改正缺陷的相关支持数据信息,包括需要修改的条目、需要修改的模块、修改的描述、修改的负责人、计划修改开始的时间、计划修改完成的时间等。

      分类:当合适的修改计划或者活动确定以后,需要对下面的信息进行分类:缺陷修复的优先级(例如:是马上修改、延期修改还是不修改)、缺陷的解决方法(如表4所示)、缺陷修复的改正措施等。

      确定影响:对在缺陷识别阶段、缺陷调查阶段中得到的影响分析进行合适的检查,并在需要的时候进行更新。

      4、总结

      经过了上面的几个阶段后,缺陷生命周期就到了缺陷的总结阶段。总结阶段的主要活动包括:

    原文转自:http://www.uml.org.cn/Test/201405223.asp

    展开全文
  • 软件缺陷生命周期

    2012-03-10 20:47:13
    对于软件工程师,不仅要了解软件的生命周期,更要熟悉软件缺陷生命周期
  • 缺陷报告及缺陷生命周期 读者问我这个问题: “如何报告我们系统中的1000个左右的缺陷? 我有10分钟的状态通话时间。” 如果您正在使用一个遗留应用程序,而该团队由于多种原因无法保持卓越的技术,则可能会...

    缺陷报告及缺陷生命周期

    读者问我这个问题:

    “如何报告我们系统中的1000个左右的缺陷? 我有10分钟的状态通话时间。”

    如果您正在使用一个遗留应用程序,而该团队由于多种原因无法保持卓越的技术,则可能会遇到这样的问题。 如此多的缺陷,很少的时间来讨论。

    让我们来看一下状态报告问题。 您可以报告缺陷趋势:上周打开数量,关闭数量和剩余数量。 请参阅《我们还在那里吗?》中的图8 该图表(以及页面上的大多数图表)用于项目团队,而非管理层。

    当经理想要了解缺陷状态时,他们实际上想要这些问题的答案,即缺陷的影响:

    • 这个问题会影响客户对产品的看法,是否足以使他们不购买或推荐该产品?
    • 这个问题会影响我们的收入能力吗?
    • 这个问题会影响我们留住或吸引客户的能力吗?

    如果您可以将问题作为这些问题的答案,则可以在10分钟(或更短的时间内)内提供合理的状态。

    以下是这在四种情况下的工作方式:

    方案1:您有数百种错别字,屏幕不一致和普遍松懈。 您认为团队应该修复所有这些问题,甚至可能要花几个星期才能解决。 您说的是这样的:

    “我们有x个问题,这些问题本身都不是真正的问题。 但是,当我们将它们放在一起时,客户似乎会对我们不一致的外观感到担忧。 我们可以忍受吗? 也许。 我担心客户愿意成为参考客户,甚至让他们寻找其他选择。”

    方案2:您有两个可怕的问题,而且很少发生。 发生的结果是客户数据完全丢失。 您认为您不应该将产品置于这些问题附近,即使它们很少发生。 这就是你说的:

    除了许多小问题,我们还有两个大问题。 我将重点讨论问题1和2。如果客户遇到这些问题之一,他们将丢失其数据。 我们无法恢复数据。 他们会很生气。 可能的结果是这些客户的收入损失,更糟糕的是,可能的评论使其他人知道了我们的问题。”

    场景3:您和您的同伴正在向敏捷过渡。 您有构建和测试自动化债务,因为构建需要几个小时,并且没有足够的自动化测试。 您担心测试不够,即使团队将一切标记为已完成。 您可以尝试如下操作:

    “在这些领域(您的测试自动化不足的地方),我们面临未知的风险。 是的,我们将这些区域中的功能标记为已完成,并且我们不知道自己所不知道的。 未知的风险有造成问题的习惯。 (提醒他们最近一次发生的情况。)我建议我们将其作为Beta版本发布,并在接下来的两周中花费大量时间进行测试自动化的积压工作,并缩短构建时间,以便我们更快地了解实际情况。 这样,我们在获取或保留客户方面就没有问题。 而且,我们不会因数据丢失而导致潜在的客户问题,因此不会丢失该客户。”

    方案4:您的团队无法完成功能。 可能是因为您有交错的迭代 ,或者您的团队依赖其他人或团队来完成功能。 在这种情况下,您可以这样说:

    “尽管我们正在完成工作,但是我们无法完成功能,因为我们没有将必要的人员集成到我们的团队中。 (说这些人是谁。)我不是在责怪他们-我确信他们也想完成这项工作。 但是,我担心未经测试就可能发布的风险(或您看到的任何风险)。 我担心我们会失去客户,从而失去收入。 我担心我们不会获得参考帐户。 我担心我们会错过发布日期,并失去潜在的收入。”

    在每种情况下,您都已完成工作。 您解释了问题的影响。 由您的经理决定做什么。

    当您想影响人们时(这就是您使用项目状态报告所做的事情),您可以解释问题如何影响他们。 您提供了可以讨论的可能性。

    如果您想学习如何做到这一点,尤其是在敏捷转型的情况下,请加入我们的有影响力的敏捷领导者

    翻译自: https://www.javacodegeeks.com/2017/02/highlight-risks-reporting-defects.html

    缺陷报告及缺陷生命周期

    展开全文
  • 缺陷报告及缺陷生命周期 在我为“实际产品负责人”讲习班授课时,有些采购订单正难以理解缺陷的严重程度。 当然,他们希望有一个较小的故事,但要等到所有问题都得到解决之后,缺陷才能解决,团队已经决定是否需要...

    缺陷报告及缺陷生命周期

    在我为“实际产品负责人”讲习班授课时,有些采购订单正难以理解缺陷的严重程度。 当然,他们希望有一个较小的故事,但要等到所有问题都得到解决之后,缺陷才能解决,团队已经决定是否需要在烟熏测试中添加自动回归测试。

    因此,这里有三种可能的缺陷尺寸:

    1. 要求人们共同解决缺陷。 如果他们可以在一天或更短的时间内解决问题,则缺陷大小为1(或任何适合您的小故事)。
    2. 让整个团队蜂拥而至或围攻以加深缺陷。 在一天结束时,他们要么修复缺陷,要么他们足够了解就可以采取修复措施。
    3. 假设每个缺陷的大小都是1,除非团队认为它的大小更大。 当团队不得不考虑是否可以在一天内解决此问题的默认选项时,它可能会改变团队对缺陷的看法。

    当您使用这些可能性时,就会得到以下结果: 没有人一个人工作 并且, 团队在一天结束时对价值有一些想法(无论是估计还是完成的工作)

    我注意到的缺陷(尤其是来自旧产品的缺陷)的一件事是,它们通常比看起来更复杂。 当人们一起工作时,无论他们如何合作,他们都可以在进行过程中查看这些复杂性风险。

    如果团队成员一起工作以配对,蜂拥而至或暴民来解决问题,那就太好了。 如果团队成员共同努力评估缺陷的大小,他们就会开始考虑可能性和风险。

    我不知道这是否适合您。 它可能。 让我知道您的想法或您如何尝试确定缺陷的大小。 实际上,我们总是将初始缺陷修复的时间定为一天,唯一的区别是我们的处理方式。

    我要解决的问题是无法修复的缺陷修复,需要永久修复。

    翻译自: https://www.javacodegeeks.com/2016/09/three-tips-sizing-defect-fixes.html

    缺陷报告及缺陷生命周期

    展开全文
  • 缺陷生命周期定义  从一个defect被发现到这个defect被关闭这一段时间,defect可能会有以下状态:new、open、Postpone、Pending Retest、Retest、Pending Reject、Reject、Deferred、closed。(请注意这里有很多种...

    缺陷生命周期定义

      从一个defect被发现到这个defect被关闭这一段时间,defect可能会有以下状态:new、open、Postpone、Pending Retest、Retest、Pending Reject、Reject、Deferred、closed。(请注意这里有很多种状态,我们需要根据不同情况来决定怎样或者是否需要跟开发人员沟通)

    下面就对这几种状态进行以下解释:

    New:(新的)

    当某个“defect”被发现的时候(第一次),测试人员需要与项目负责人沟通以确认发现的的确是一个defect,如果被确认是一个defect,就将其记录下来,并将defect的状态设为New

    Assigned(已指派的)

    当一个defect被指认为New之后,将其将给开发人员,开发人员将确认这是否是一个defect,如果是,开发组的负责人就将这个defect指定给某位开发人员处理,并将defect的状态设定为“Assigned”

    Open(打开的)

    一旦开发人员开始处理defect的时候,他(她)就将这个defect的状态设置为“Open”,这表示开发人员正在处理这个“defect”

    Fixed(已修复的)

    当开发人员进行处理(并认为已经解决)之后,他(她)就可以将这个defect的状态设置为“Fixed”并将其提交给开发组的负责人,然后开发组的负责人将这个defect返还给测试组

    Pending   Reset(待在测试的)

    当defect被返还到测试组后,我们将defect的状态设置为“Pending   Reset”

    Reset(再测试)

    测试组的负责人将defect指定给某位测试人员进行再测试,并将defect的状态设置为“Reset”

    Closed(已关闭的)

    如果测试人员经过再次测试之后确认defect已经被解决之后,就将defect的状态设置为“Closed”

    Reopen(再次打开的)

    如果经过再次测试发现defect(指defect本身而不是包括因修复而引发的新defect)仍然存在的话,测试人员将defect再次传递给开发组,并将defect的状态设置为“Reopen”

    Pending   Reject(拒绝中)

    如果测试人员传递到开发组的defect被开发人员认为是正常行为而不是defect时,这种情况下开发人员可以拒绝,并将defect的状态设置为“Pending   Reject”

    Rejected(被拒绝的)

    测试组的负责人接到上述defect的时候,如果他(她)发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作defect的时候,开发组负责人就将这个defect的状态设置为“Rejected”

    Postponed(延期)

    有些时候,对于一些特殊的defect的测试需要搁置一段时间,事实上有很多原因可能导致这种情况的发生,比如无效的测试数据,一些特殊的无效的功能等等,在这种情况下,defect的状态就被设置为“Postponed”

    Deferred(延期的)

    有些情况一些特殊的defect显得不那么重要,同时也是可以消除的,这个时候我们可以将defect的状态设置为“Deferred”  

     

    转载于:https://www.cnblogs.com/xiaoTT/p/3900389.html

    展开全文
  • 软件测试缺陷定义,缺陷(Defect):存在于软件之中偏差,可被激活,以静态形式存在于软件内部。 故障(Fault):当缺陷被激活后,软件运行中出现的状态,可引起意外情况,若不加处理,可产生失效,是一种动态行为...
  • 缺陷生命周期管理

    2013-10-25 14:13:24
    每个软件缺陷都要经过“报告、确认、修正、验证、关闭”的过程,这些过程构成了软件缺陷生命周期。为了有效的管理软件缺陷,发包方和外包公司要使用同一个软件缺陷管理系统报告和处理缺陷。双方需要在测试计划阶段...
  • 缺陷管理--软件缺陷生命周期

    千次阅读 2013-06-14 17:54:36
    发现缺陷 开发人员检查缺陷 确认缺陷 修正缺陷 返回发现者 缺陷验证 完成 关闭缺陷
  • 缺陷状态: 激活/打开 已修正 已关闭/非激活 重新打开(对应图示验证通过否N) 推迟(对应图示的延期) 保留(对应图示无法解决) 不能重现 需要更多信息
  • 缺陷/bug的状态 New: 当你发现一个bug的时候,需要与项目负责人或者你的leader沟通以确认发现的确实是一个bug,如果被确认是一个bug后,就可以将其记录下来,并将bug的状态设为New。 Assigned 当一个bug被指认为New...
  • Introduction:引言 Bug can be defined as the abnormal behavīor of the software. No software exists without a bug. The elimination of bugs from the software depends upon the efficiency of testing...
  • BUG缺陷流程,缺陷类型,生命周期描述 (1)什么样的问题可以认定为BUG缺陷?:** (1)软件未实现需求说明书上描述的功能 ...(3)BUG缺陷生命周期是什么? 新建BUG(未解决)–>分配、转交(分配上下级
  • 缺陷生命周期

    2020-11-04 11:14:37
    缺陷生命周期 缺陷的识别 依据:需求文档,设计文档,产品原型,测试用例,都是客观的依据 同行业的类似成熟软件,和开发人员沟通,跟有经验的测试人员沟通,同行业隐性需求,都是带有主观依据。 测试人员在...
  • 软件缺陷生命周期(基本)

    千次阅读 2017-11-11 21:58:30
    一个最优化、最简单的软件缺陷生命周期的例子 1.发现缺陷-- (测试员发现缺陷并记录缺陷报告/缺陷报告交给程序员) --》打开-- (程序员修改缺陷/缺陷报告交给测试员) --》解决-- (测试员确认缺陷已修改/...
  • 软件缺陷生命周期(二)

    千次阅读 2009-11-21 10:55:00
    简单的软件缺陷生命周期:1、发现——打开:测试人员找到软件缺陷并将软件缺陷提交给开发人员;2、打开——修复:开发人员再现、修复缺陷,然后提交测试人员去验证;3、修复——关闭:测试人员验证修复过的软件,...
  • 软件生命周期 / 缺陷

    千次阅读 2020-12-27 21:42:22
    一、软件生命周期 软件开发全部过程、活动和任务的结构框架,是从可行性研究到需求分析、软件设计、编码、测试、软件发布维护的过程 软件测试的生命周期图 软件开发过程中,软件测试所做的全部工作可称为...
  • 一、缺陷的等级 (1)Blocker(崩溃)        阻碍开发或测试工作的问题; (1)造成系统崩溃、死机、死循环,导致数据库数据丢失,与数据库连接错误,主要功能丧失,基本模块...
  • 缺陷生命周期 缺陷的识别 依据:需求文档,设计文档,产品原型,测试用例,都是客观的依据 同行业的类似成熟软件,和开发人员沟通,跟有经验的测试人员沟通,同行业隐性需求,都是带有主观依据。 测试人员在识别...
  • 软件缺陷生命周期

    千次阅读 2009-11-21 10:48:00
    8.2软件缺陷生命周期与生物学的昆虫不同,软件的缺陷要经历一组非常严格的状态(参见图8-2)。在VSTS中,缺陷所允许的缺省的状态和转换依赖于你为项目所选择的过程模板。所选过程的那组规则决定了:选择可允许的...
  • 一、缺陷的概述和分类 测试职责:将发现的缺陷提交给开发修改,并回归。 概述:狭义概念是指软件程序的漏洞或缺陷,广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节,或与需求文档存在差异的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,095
精华内容 438
关键字:

缺陷生命周期