bug回归 - CSDN
精华内容
参与话题
  • 如何有效的进行bug回归

    千次阅读 2010-04-13 16:57:00
    因而bug长期以来都困扰着广大测试工程师,如何尽可能减少bug数,在测试的各个阶段都有不同的解决方案,下面以我经常犯错的bug回归阶段的bug遗漏问题说起。回归阶段的bug遗漏通常有几种原因: 1. bug回归人员对回归...

    在软件测试工作中,测试人员最大的目标就是尽可能的提升产品质量,减少bug数量。因而bug长期以来都困扰着广大测试工程师,如何尽可能减少bug数,在测试的各个阶段都有不同的解决方案,下面以我经常犯错的bug回归阶段的bug遗漏问题说起。

    回归阶段的bug遗漏通常有几种原因:

    1.       bug回归人员对回归bug所对应的功能不够熟悉,不能或没有举一反三,没有将所测功能的其他入口点遍历

    2.       用例不规范,无法建立bug和用例的对应,回归测试不完整

    3.       用例更新不及时,例如需求变更,随机测试等所发现的bug没有对应的测试用例,回归随机性很大

    4.       项目进度紧,没有时间进行更细致的回归

    5.       测试人员对bug如何修复不了解,错误评估测试回归范围

     

    针对上面所遇到的问题,我们主要从两方面思考问题解决方案:方法层面和思想层面

             从思想层面:

             思想层面的总结最终形成的是一种意识形态上的思考,适合有经验的测试工程师,那么我们可以从如下几个方面去规范我们的思想:

    1.       加强所负责模块的熟悉程度,及时梳理模块功能逻辑及各种入口。

    2.       提升对于bug回归在测试过程中重要性的理解。

    虽然一个项目下来,我们会发现bug分散于各个模块之中,但是在深入一步看的话,你会发现其实bug也是有一定聚集性的,也就是我们经常看到的某某开发工程师的产品经常出问题,某个功能出问题。在例如项目后期阶段,以点辐射开来找bug的效率应该是大于随机测试找bug的效率的。

    3.       加强项目中的文档管理,维护和更新。

    4.       加强项目风险预测和项目时间管理。

    这样项目预定的流程才能够被执行,不至于因为时间来不及而影响到测试工程师的执行心态及执行成效。

    5.       加强与开发工程师的沟通。

     

    方法层面:

    测试工程师最重要的还是实践动手能力,反映到问题总结上面,就是需要有一个切实可行的方案出来。

    针对于bug回归阶段的bug遗漏问题,我认为可以从如下几个方面

    1.       测试用例设计阶段,设计并维护一个各个功能入口的说明文档。

    其实这个文档的作用很大,一方面对于bug回归阶段的人来说,这是用于提醒的;另外一个方面,在随机测试的时候,随机程度也能有所提高,测试人员能够自己随意组合可能的路径。当然,一样一份文档也能提升文档设计人员,文档阅读人员对于模块的整体认识

    2.       Bug提交阶段,评估阻塞用例说明。

    在项目初期,尤其是版本刚提交的时候,往往会出现功能无法使用或者没有实现的问题,这时候我们提交bug并不仅仅是说明预期没有实现,更重要的是我们如何备忘这件事情,如何保证没有实现的功能在最终版中实现,那么在提交bug的时候,我们需要注明,哪些case被阻塞,该功能没有验证会影响到哪些其他模块和功能的验证等

    3.       Bug提交阶段,在bug描述中备注回归时的路径说明。

    测试工程师提交bug时是在当时的环境下的,也就是说对测试目录,前后操作及路径都非常清楚,对于其他可能的入口或者操作,测试工程师是知道的,因而在提交bug的时候,测试工程师除了提交出现bug的操作步骤之外,如果能补充一下其他可能的路径说明,一方面开发在修复bug的时候可以作为参考,另外一方面测试工程师在bug回归的时候也能够进行更全面高效的回归

    4.       bug提交完毕,对非用例内影响因素或路径更新到测试用例或者进行备忘。

    测试影响因素包括各个方面,因为测试工程师的经验,知识储备等各方面原因,测试设计往往会有一定的遗漏,这是不可避免的,在测试过程中我们往往会突然想到某个影响因素或者测试路径,这时候我们往往会去执行一下是否有问题,如果有问题,则会有bug提交,如果没有bug呢?往往我们会去继续去执行下一条case去了。实际上这种情况是对测试工程师脑力的一种浪费,不利于测试工程师经验的积累。

    我们试想如果我们将这种问题更新进用例,或者至少以某种方式,例如项目便签的方式对这些问题进行记录,当项目完成之后总结阶段,我们将这些问题拿出来,整理,分析,更新文档,更新测试知识库,那么首先我们不用去抓耳挠头想有什么可总结的东西,其次下一次用例设计时我们就可以直接思考到这个因素,而无需执行过程中突然想到了。

    5.       测试过程中,对需求变更等文档进行有效管理。

    测试过程中因为各种原因,例如需求权限,开发实现的成本,bug影响等,会导致产品需求的变更,测试工程师需要及时相应需求变更,更新测试用例并验证信需求,但是往往因为项目进度或其他原因,测试工程师没有这个时间,我们在回归的时候,如何保证这部分需求变更测试通过呢?那么一个测试整理的需求变更文档是必要的,这其中可以记录产品的原始需求变更,以及测试记录的测试要点。当项目总结阶段,再进行统一的维护,这对产品项目而言是很有效和清晰的方法。

    6.       测试管理中, bug的两阶段回归。

    其实这个想法并不成熟,仅仅作为参考。在项目过程中,开发和测试是并行的,也就是说到了一定阶段,新建bug是处于收敛而修复bug是发散的。这时候我们往往会进行bug回归,但是我们经常会发现到了上线的时候,某些bug又出现了,或者因为代码提交的问题,或者因为其他模块修改的问题或者逻辑变更的问题,但是一个问题,线上有bug!其实我一直在想,对于这些bug,我们是否可以在上线前的某段时间进行一次粗略的回归呢?

    7.       Bug回归时,尽可能与开发沟通bug原因及修改方案。

    这个在实际操作时是有困难的,因为哪些bug需要与开发沟通,开发是否有时间等都是影响因素,当然有人会提出由开发在处理bug时提交修改说明,这当然是最好的方式,但是与国内实际环境是不符的,因而我们是尽可能的与开发了解bug原因及修改方案,然后在bug跟踪系统中或者其他什么方式进行一个简明的说明,例如是初始化数据错误这样的原因,那么在后期我们进行bug分析时,就能从一个统计意义上的数据来对测试的测试设计及执行进行一个指导

    上面就是我对bug如何进行回归的一些想法,更希望大家能有一个讨论的空间。

    展开全文
  • 什么是bug? 功能不符合需求, 不正确或缺失的异常处理,不符合用户使用习惯的(要根据实际情况来), 超出用户期望的需求(画蛇添足,也不一定)   一个bug单包含哪些要素 1、所属的系统(产品) 2、发现的版本...

    什么是bug?

    功能不符合需求, 不正确或缺失的异常处理,不符合用户使用习惯的(要根据实际情况来), 超出用户期望的需求(画蛇添足,也不一定)

     

    一个bug单包含哪些要素

    1、所属的系统(产品)

    2、发现的版本(轮次)

    3、发现bug所属的模块

    4、bug提交人

    5、bug的错误类型:代码错误、界面优化、设计缺陷、配置相关、安装部署、安全相关、性能问题等(默认)

    6、bug的重现概率: 必现 大概率重现 小概率重现 极小概率重现

    7、bug的严重级别:致命 严重 一般 提示 (影响范围越大,严重级别越高)

    8、bug的优先级:高 中 低

    9、bug的标题 言简意赅说明是什么bug, 而不是把测试用例名字复制一遍

    10、bug单号 一般系统自动生成

    11、bug内容:发现的环境、 预制条件、重现步骤、预期结果、实际结果, 截图证明,bug错误说明,(当开发看到能容能够独立重现这个bug,说明写的还行)

    12:附件:测试用的数据或者出错的日志, 如果需要添加上日志

     

     

    提交bug的时候尽量把截图附上,并对截图进行标注,如果不好描述的可以录制视频, 如果是偶现bug ,把发生这个错误的错误日志,操作过程说明清楚

    毕竟字不如图,描述半天不如一张图, 图不如视频

     

     

    发现bug为什么要提单?

    1、bug容易漏掉,导致bug遗漏到客户那里

    2、把bug录入系统,给开发提供bug解决的依据,哪些bug 要优先改、哪些bug可以先不修改、

    3、把bug录入系统,方便开发定位这个bug,因为bug会记录重现步骤

    4、把bug录入系统,方便测试知道哪些bug 需要修改但是未修改,哪些bug已经修改可以回归

    5、提交bug,测试人员有成就感

    6、把bug录入系统,是研发过程改进的大数据库,根据不同维度的统计数据,发现研发过程中存在的问题

     

     

    针对第6点举例: 比如问题单过多(可能模块太复杂,分给技能不熟练的人了,可能是这个人就没有认真干活), 比如问题单回归不通过数量多(修改问题单不认真,导致延长测试周期), 比如 版本上线后线上问题多 (测试不到位,测试点覆盖不全,测试设计和用例评审不到位,或者执行的时候不认真 该打测试板子),通过这些数据我们可以优化我们的研发过程,提升团队的效率

     

     

     

    bug解决者一般填写哪些内容

     

    1、bug的解决方案有哪些:

    设计如此、 重复bug、外部原因、已解决、无法重现、延期处理、不予解决

    2、bug解决版本

    3、问题原因

    4、解决问题的方案

    5、解决方案的影响范围

    开发写这5点的目的是方便测试回归,回归时测试更有重点

     

     

    bug回归的时候应该怎么处理

    前提: 回归之前,如果这个bug涉及到代码修改,那么修改好的代码一定是部署到测试环境了

    1、阅读解决方案的内容

    2、检查问题单中的场景是否修改

    3、检查解决方案影响范围的功能是否正确

    阅读1、2、3, 测试2、3涉及到的场景,都通过时, 问题单关闭,否则问题单打回给开发,让重新修改

     

    对于不予解决或者设计如此的问题,如果不认可开发的解决方案,有疑问怎么处理?

    1、认真阅读不予解决的原因,或者这样设计是否合理

    2、如果认可原因,即可把问题单给关闭掉,如果不认可,反馈给测试领导吧

    Bug处理流程

    流程描述:

    1、测试人员发现bug 提交给开发。

    2、开发人员判断是否是bug。

    3、如果是bug,进行修改,修改完成后更改bug 状态为已解决。

    4、如果不是bug,退回给测试人员并描述退回原因,或为设计如此,或为外部原因,

    或者不能重现。

    5、开发人员修改完成的bug,由测试人员进行验证,确认修改正确,关闭bug。

    6、验证未通过的bug 重新激活,开发人员继续修改,直至验证通过,关闭bug。

    7、测试人员需要对开发人员退回的bug 进行确认。

    8、确认不是bug 关闭。

    9、如与开发人员意见不一致,认为是bug,需提交项目负责人仲裁。

    10、项目负责人确认是bug 由开发人员修改,不是bug 由测试人员关闭。

     

     

    测试处理bug单经常会遇到哪些问题

    1、bug修改不完整 ,bug打回

    2、开发说bug不是问题,  和开发沟通,不能达成一致,走给测试负责人处理

    3、测试中不停发现BUG,一些比较小的BUG还要提吗?

          当然要提,

    4、项目要着急上线, 但是还有一些bug没处理,这个时候应该怎么办?

    把这些bug的影响范围汇报上去, 至于要不要上线让领导定夺,咱们负责把bug的风险给汇报上去

     

    偶现问题如何处理

    1、出现bug后,首先截图,查看日志,把对应日志保留下来

    2、尝试重现这个bug ,思考这个bug可能产生的原因, 然后每个原因逐步验证,如果重现不出来,可以找开发帮忙 , 这个步骤是为了准确找到重现bug 的步骤, 开发修改的时候就容易多了,不然又会和开发来来回回扯皮

    3、如果实在重现不出来, 还是要提交bug 的, bug单一定要写清楚bug出现的环境, 版本、步骤, 错误截图, 对应的日志, 尽可能多的提供出现bug时的信息, 方便开发定位

     

     

    怎么和开发沟通bug

    1.把自己的Bug Report完善;有时候开发看到一些莫名其妙的Bug Report会很生气,这样首先就影响了你在他心目中的印象,要让别人改正,首先要保证自己是正确的、完善的。

    2. 对事不对人;找开发的时候应该针对具体的问题,可以用“我们的软件出现了这样的问题”,而不要说“你这里写的不对”。

    3. 摆事实;对于具体的bug,可以给开发说明一些事实,例如某个样式问题其实十分影响用户体验。

    4. 挖历史;如果以前有类似的问题,可以把那个问题,以及造成的后果给开发阐述一下。

    5. 平时跟开发拉好关系。测试立场要坚持, 该提bug还得提

    6. 把更高层的人拉进来;很多时候都是公说公有理婆说婆有理,这时候就需要一些第三方的同事来帮忙,这个人通常要是能说事的才行,例如研发总监或者项目经理,但是主要不要让人觉得狐假虎威的感觉,这招不适宜经常用。

     

    缺陷的分布特征

      缺陷往往喜欢扎堆,一个模块已经发现的缺陷比别的模块多,通常不是代表这个模块已经把缺陷暴露完了,而是意味着这个模块还存在有同样多的缺陷尚未被发现。这就是著名的二八定理:80%的缺陷出现在 20%的模块。

    如果一个模块bug较多,怎么来判断这个模块bug发现干净了? 那就是连续2轮发现的bug都很少

     

    缺陷的抗药性

    测试进行得越多,新缺陷就越难被发现

      因为之前一直使用同样的测试思路,同样的一套测试用例,没有新的突破。

       某些缺陷天然地只有在很特殊或者很极端的情况下才会被触发

    所以需要进行交叉测试、bug学习(不断在扩展我们的测试思路)、发散测试

     

    发布时并非所有的缺陷都要修复

    有一些原因,使得有些缺陷我们不修复:

    没有足够的时间

    不算真正的软件缺陷,可能这个bug是优化

    修复的风险太大

    不值得修复

     

    展开全文
  • 在作者多年的测试过程中,总结出了一套流程高质量的回归Bug的流程,这里跟大家分享下:I、bug的描述执行(必测)复制bug的描述(如没有,就复制概述),备注执行情况 (不明白的地方需要找bug提交人确认)II、测试...
    在作者多年的测试过程中,总结出了一套流程高质量的回归Bug的流程,这里跟大家分享下:

    I、bug的描述执行(必测)
    复制bug的描述(如没有,就复制概述),备注执行情况  (不明白的地方需要找bug提交人确认)

    II、测试建议执行(必测)
    复制开发测试建议,备注执行情况(不明白的地方需要找开发确认)

    III、个人发散(选测)
    需要做bug分析发散,如回归备份功能的bug,可能需要发散下备份还原功能

    IV、Fail用例再次执行(选测)
    确认是否有相关的失败用例,失败用例是否需要重新测试
    展开全文
  • 如何做好BUG回归

    千次阅读 2019-05-04 20:46:07
    BUG贯穿研发体系、测试质量衡定的始终,做好BUG回归,即能保证质量,又能提高个人测试能力。做好BUG回归,能够很大程度的避免漏测。 BUG的处理流程 回归BUG的思路 从回归BUG的思路来看,首先验证原BUG现象...

    BUG贯穿研发体系、测试质量衡定的始终,做好BUG回归,即能保证质量,又能提高个人测试能力。做好BUG回归,能够很大程度的避免漏测。

     

    BUG的处理流程

     

     

    回归BUG的思路

    从回归BUG的思路来看,首先验证原BUG现象是否仍然复现。然后需要进行BUG扩展回归,主要从哪几方面扩展呢?

    首先是开发原理。

    根据开发原理评估问题的原因、改动的方法、以及可能产生的影响。

    然后BUG扩展。

    针对BUG本身的扩展,建议从BUG描述进行断句,分析每个涉及到的模块,是否有扩展测试的必要。

    另外是一些常规的扩展测试比如:

     

    • 是否需要覆盖多个平台?

    • 是否需要覆盖手机和平板?

    • 是否需要考虑横竖屏?

    • 是否要考虑分辨率?

    • 是否要考虑多语言?

     

    举几个之前回归过bug作为示例:

     

    BUG1:文件列表中文件的创建日期显示不正确,应该显示今天、昨天、两天前的需要显示具体日期。

    回归方法:

    首先确保显示上没问题,无文案错误。

    从开发原理上讲,要考虑:

    1、今天、昨天和三天前是以什么时间为节点判断。以当前系统时间24个小时往前推算,还是服务器时间以0点为准?

    2、显示具体日期时,日期的格式具体是怎样的,是否显示年月日?年月日的顺序是怎样的?中间是用-隔开,还是\隔开呢?

    3、是否存在中文和英文的差异,甚至是多语言?因为不同语言表达日期的惯用格式是不一样的。

    3、文件的日期是怎么获取来的?如果是服务端,那万一服务端返回回来为空或者异常,列表会怎么显示?

    4、假设修改手机系统的日期了 ,今天、昨天、三天前是否会改变?

    针对BUG本身的扩展:

    1、文件列表:文件列表是否存在多个地方?改动是一处,还是多处?是否存在其他的列表也显示日期的?

    2、创建日期:创建日期和修改日期是有差别的,是否显示的和需求相符是创建日期,而非修改日期。

    其他常规的扩展:

    1、因为涉及到Android和iOS两个平台,因此需要覆盖两个平台测试。

    2、仅支持手机,因此仅测试手机即可。

    3、不支持横竖屏,因此不必扩展。

    4、低分辨率或者大字体下有没有可能超出一行,超出一行时如何处理,显示是否美观。

    5、存在英文,英文的习惯是年份在后面,是否有符合英文的阅读习惯?

    当然,涉及到需求不明确的时候,预期结果要以需求为准。

     

     

    BUG2:文件名称过长换行时,发现右侧的编辑按钮换行且和第二行标题重叠了。

     

    从开发原理上讲,还要考虑:

    1、为何之前会换行,是因为之前没对文案的长度做限制。那么修改后是以字符数作为限制,还是以相对布局的宽度来做长度限制的?

    2、右侧编辑按钮为什么会换行?因为原来标题和编辑按钮是相对布局,相对于标题的右侧进行显示。需要修改为线性布局,固定在右侧给编辑按钮一个位置。

    3、超出一行的内容如何显示,省略号还是其他?

    针对BUG本身的扩展:

    1、文件名称:中文、英文、标题、符号是否都能正常换行显示?换行的效果看起来都是美观的?英文单词中间是否会出现换行?

    2、改动布局之后的编辑按钮位置是否明显,点击触控区域是否合理?

     

    如何提高回归bug的准确性?

     

    • 测试用例设计和评审阶段,输出一份完整明确的案例。

    • 案例设计的越完整,回归BUG时可参考的案例越明确。

    • Bug提交阶段,给出明确的描述和步骤

    一方面开发重现问题时可以参考,快速分析。另一方面,大幅度提高他人熟悉和回归的效率。尤其在提交BUG时附上的截图和日志,是非常有价值的。

    • Bug修复阶段,开发和测试要积极沟通修复方案。

     

    一般来说,会要求在缺陷管理平台上开发处理bug时提交修改说明,第二,在测试回归前积极跟开发沟通问题原因、修复的方案和影响。

     

    • BUG关闭阶段,积极完善测试案例。

    展开全文
  • Bug的生命周期状态流程图

    千次阅读 2020-03-07 21:00:32
    bug的生命周期 BUG的生命周期,就是一个BUG被发现到这个BUG被关闭的过程。 生命周期中缺陷状态:...回归验证BUG–>是否通过验证–>关闭BUG 如果待验的BUG在验证时没有解决好,我们需要重新打开–指派—已解...
  • 一、定义: 测试自动化的数量过少,无法充分...2.回归测试作为系统测试的最后一个阶段,可有可无,时间不充足,不能够发现更多bug 3.测试工程师手动执行失误不可避免 4.缺乏足够测试自动化使得敏捷开发模式不能有...
  • BUG回归的一点看法

    千次阅读 2011-08-14 01:40:29
    测试人员找bug是个技术活, ...bug回归到不到位, 关系到发现bug本身有没有修复好, 同样也关系的因为修复bug而改动的代码对其他功能的影响. bug回归的几点心得: 1. 首先弄清楚bug必现的配置和操作过程.  因为
  • 1. 线上BUG来源 用户反馈 用户反馈由运营或者客服或PD童鞋进行收集,对集中反应比较多的问题反馈到项目组及相关童鞋,对体验不好的地方进行产品改进。 回归测试 每周服务端预发和上线以后,在客户端进行回归...
  • 冒烟测试和回归测试的区别

    万次阅读 2014-07-05 14:30:10
    每次新的版本出来的时候,老大就让我们冒烟
  • BUG单内容规范

    千次阅读 2018-03-09 17:33:50
    1. 字段(一个BUG拥有的所有属性)BUG编号 模块 测试用例编号 标题 描述 重现方法 恢复办法 概率类型 出现概率 缺陷等级 生命类型 状态 处理结果 优先级 指派给 提单日期 要求完成日期 开始解决日期 完成日期 关闭...
  • 一个BUG(缺陷)的生命周期

    千次阅读 2018-09-25 08:57:29
    缺陷状态   对于一个问题,其处理过程是一个周期,周期的不同阶段,其所处的状态也是不一样的。不同状态所对应的处理人也是不...回归 : 对已经修复的问题进行回归确认。Reopened : 关闭 : 问题的最后一个状态。...
  • 禅道BUG提出及处理流程规范

    千次阅读 2019-09-27 11:51:31
    禅道BUG提出及处理流程规范 版本说明 版本 作者 时间 备注 1.0 _冷冷 2019/9/27 首版本提交 目录 1 概述 1 2 目的 1 3 作用 1 4 缩略词 1 5 适用范围 1 6 BUG的定义 2 7 BUG书写规范 2 7.1 BUG书写必填...
  • 回归测试简介

    千次阅读 2016-08-16 14:50:46
    回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。 在软件开发过程当中,一旦软件代码做了修改,就有可能引入新的问题,所以这个时候就需要把已经完成了的验证用例重新...
  • 一个合格的bug应该包括哪几部分 bug的生命周期 1. 一个合格的bug应该包括哪几部分 发现问题的版本 出现问题的环境 错误重现的步骤 预期行为的描述 错误行为的描述 注:不要把多个bug放在一起。 2. bug的生命周期 ...
  • bug缺陷管理流程及等级划分

    千次阅读 2015-09-01 07:19:48
     致命(一级bug) 通常表现为:主流程无法跑通,系统无法运行,崩溃或严重资源不足,应用模块无法启动或异常退出,主要功能模块无法使用。 比如:1.内存泄漏;2.严重的数值计算错误;3.系统容易崩溃;4.功能...
  • 尽量避免bug的一些手法

    千次阅读 多人点赞 2019-11-21 14:51:56
    尽量避免bug的手法
  • 软件测试之App测试-回归测试

    千次阅读 2017-07-11 11:14:08
    回归测试1)Bug修复后且在新版本发布后需要进行回归测试。2)Bug修复后的回归测试在交付前、要进行全量用例的回归测试。
  • 回归验证

    千次阅读 2011-07-30 14:56:01
    在芯片开发过程当中,一旦RTL代码做了修改,就有可能引入新的问题,所以这个时候就需要把已经完成了的验证用例重新跑一下,...我们把这一个过程叫做回归验证(也有人叫代码回归,或者只叫回归, regress)。   一般地
  • 管理bug的JIRA系统

    万次阅读 2016-01-18 16:57:18
    在以往的项目中,使用过开源的Jenkins集成工具,IBM CQ管理bug,目前的项目使用的是JIRA。 这里主要记录如何使用JIRA。 1.登录与注册 在成功安装配置完成的界面上点击“Log in”,就会看到JIRA的登陆界面了,如图...
  • 项目在上线前,代码稳定后,测试人员一般会要求开发同学进行代码冻结,测试进行上线前的最后一次回归。 而测试人员是如何评估代码稳定可进入冻结的呢? 代码稳定有三个基本要求: 1. 需求实现完毕 2. 高...
1 2 3 4 5 ... 20
收藏数 26,125
精华内容 10,450
热门标签
关键字:

bug回归