首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

我们是否应该总是重现错误以验证修复?

在开发过程中,我们通常会遇到一些错误或问题。为了确保我们修复这些问题的有效性,我们应该尽可能地重现错误。这样可以确保我们修复的问题不会再次出现,并且可以更好地理解问题的根本原因。

在重现错误时,我们可以使用测试用例或测试数据来模拟错误的情况,并使用调试工具来查看代码的执行过程。这样可以更好地理解问题的原因,并且可以更快地修复问题。

当我们修复了问题后,我们应该使用自动化测试来确保我们的修复没有引入新的问题。这样可以确保我们的代码质量和稳定性。

总之,我们应该尽可能地重现错误以验证修复,并且使用自动化测试来确保我们的修复没有引入新的问题。这样可以确保我们的代码质量和稳定性,并且可以更好地理解问题的根本原因。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

2019-05-02 如何有效提交 Bug 报告?

如果你不能重现找到的 bug,那么很有可能它实际不是个 bug。 Step 2:确认 bug 是否已报告过 一旦确定了你确实找到了个 bug,应该看看这个 bug 是否已经备案或上报了。...除了直接在 Google 搜索你发现的 bug 外,还可以浏览所用软件的 bug 页面,看看这个 bug 是否已上报过。我们使用的多数软件都会有专门查找 bug 的页面。...如果条件允许,可以帮开发者在不同环境进行测试,验证 bug 是否在不同环境下都会出现。 示例:Ubuntu-Gnome 16.04.1 版本。...每一步都应该记录下来,这样所有人都可以轻松地重现你遇到的 bug 了。 示例 1....我总是会被收到的回复惊喜到。通常我都会受到回信,并且最终开发者会修复我的 bug,或者与我解释不会(或无法)修复的原因。 坐等修复 bug 的人最后很有可能会失望。

1.1K40

2019-05-15 7个对初学者非常有用调试和故障排除技巧

正文: 在这篇文章中,我们提供了一篇关于初学者的有用调试和故障排除技巧的综合文章。 生命中有三个常数 - 死亡,税收和调试代码。在为新的吊索代码和功能编写代码时,许多程序员都会留下一堆乱七八糟的错误。...4.重现错误 任何理智的程序员或开发人员应该做的第一件事就是重现错误确定它是否明显是一个错误,并且你能够调试它。大多数时候,很多代码毛刺都无法再现; 因此,无法调试。...因此,如果您无法重现该问题,则无需进行调试。如果你不能自己重现这个bug,那就去寻求帮助吧。如果测试人员将错误编入索引,请让测试人员为您重现错误。...这最终将导致一个不同的假设,你应该稍后测试。浏览源代码查看有关系统如何工作的更多线索。你应该能够提出一些你可以测试的好假设。 6.测试你的假设 暂时不要使用调试器。在此步骤中,您需要进行单元测试。...如果你是对的,并确定了问题,你可以修复它。现在,您已经进行了单元测试以验证修复并确保它不会再次出现。尝试再次重现实际的错误确保它完全修复

48540
  • 测试面试题集-1.测试基础理论

    .如果Bug已经修复,测试人员直接关闭 ;7.如果待验的bug在验证时没有解决好,我们需要重新打开>指派>已解决>待验,循环这个过程。...中间其他状态:重新打开、拒绝、延期等;8.如果提交bug后,开发一直没有修改状态,我们会提醒开发。延期、不予修改的bug则跟开发沟通,找产品确认是否修改。 Q: 五、Bug记录包含哪些内容?...错误回归,就是在新版本中,对以前版本中出现并修复的缺陷进行再次验证,并以缺陷为核心,对相关修改的部分进行测试的方法。 Q: 八、什么是验收测试?Alpha测试和Beta测试的区别是什么?...A: 验收测试是以用户为主的测试,软件开发和QA人员也应该参加,测试一般在用户所在地进行,由用户验证软件产品是否满足了所有的需求的一系列的验收测试工作。...; 7.严重错误和主要错误的缺陷修复率必须达到100%,不允许存在功能性的错误;次要错误和一般错误的缺陷修复率必须达到85%以上,允许存在少量功能缺陷,后续版本解决;对于较小错误的缺陷修复率最好达到60%

    99310

    代码调试最佳实践

    这本书我还没有读过,但是我已经买了一本,我希望我读完后决定是否应该推荐它。...这本书中阐述的一些代码调试应该遵循的规则似乎很有道理,比如说“了解系统”,“让它失败”,“别想了,先看看”,“分而治之”,“一次只改变一件事情”,“保持审查详细记录”,“从一个新的角度看问题”,和“如果你没有修复它...快速重现bug 所有人也都同意,能够快速地重现bug是非常有用的(如果每次更改都需要3分钟来检查是否有帮助,那么迭代就太慢了)。...有了这样的错误信息,我就可以检查我是否需要修复防火墙,或者我是否由于某种原因得到了错误的IP地址。...通常我们很容易说:“好吧,你需要重现这个问题。那么先让我们进行最小化的重现,你可以开始猜测和验证你的猜测,改进你对系统的思维模式,找出问题所在,然后解决问题。

    96610

    如何写好缺陷报告「建议收藏」

    ,提示是否保存文件的对话框里“是”按钮在右边了,这就是一个defect了,因为它不符合Windows下用户的使用习惯。...b、严重Critical:操作性错误、功能遗漏、影响用户使用。 c、一般Major:UI方面的,一些小的错误,不影响使用。 d、较小Minor:建议性的问题,可以不做修改。...(5)、缺陷的状态 a、open:新提交的bug b、fixed:已修复等待测试人员验证的bug c、reopen:测试人员验证发现没有修复的bug d、closed:测试人员验证修复的bug (6)...、缺陷的频率—是指缺陷出现的概率 a、总是:可以100%重现 b、通常:出现的概率为80%–90% c、有时:出现的概率为30%–50% d、较少:出现频率比较低,2%左右 这里要注意一下缺陷的严重程度和优先级并不是一回事...重现步骤要完整简明,不要包含不必要的信息,每步尽量动词开头,例如Click XXX button to go to XXX screen. 实际结果要如实的描述发生了什么,不要包含自己的猜想。

    47830

    代码调试的最佳指南

    这本书我还没有读过,但是我已经买了一本,我希望我读完后决定是否应该推荐它。...这本书中阐述的一些代码调试应该遵循的规则似乎很有道理,比如说“了解系统”,“让它失败”,“别想了,先看看”,“分而治之”,“一次只改变一件事情”,“保持审查详细记录”,“从一个新的角度看问题”,和“如果你没有修复它...快速重现bug 所有人也都同意,能够快速地重现bug是非常有用的(如果每次更改都需要3分钟来检查是否有帮助,那么迭代就太慢了)。...有了这样的错误信息,我就可以检查我是否需要修复防火墙,或者我是否由于某种原因得到了错误的IP地址。...通常我们很容易说:“好吧,你需要重现这个问题。那么先让我们进行最小化的重现,你可以开始猜测和验证你的猜测,改进你对系统的思维模式,找出问题所在,然后解决问题。

    1.1K40

    程序员不修改bug怎么办

    我们测试人员为什么苦恼? 可能是觉得封版之前bug就应该全部解决(强迫症),也可能是觉得程序员没有理解bug的严重性,也许是bug明显违反规范,也可能是觉得缺陷肯定会影响到用户。...好的错误报告会推动问题的修正。 先等一等,在评审时看看大家反映,静制动,提供补充信息。...有的测试经理尝试用bug跟踪数据来促使程序员修改bug,比如利用数据反馈某程序员是否存在大量的bug未修改,或是否修改时间过长,或是否总是推迟修改。...是否应该推行这种制度笔者不做评论,不过笔者建议推行时需注意引导程序员的情绪,否则很容易引起某些程序员的反感,他们会在某些时候大肆放大测试员的无能,或者发表不利于测试部的言论。...除非经过测试员的验证,否则bug都不能闭环。在某些情况下,程序员会将未修复的bug置为“延期修改 ”、“非程序错误不予修改”“重复缺陷不予修改 ”,测试员需要且有义务对此提出质疑。

    1.1K70

    软件缺陷是什么以及缺陷的管理

    软件缺陷的表现形式 1、软件未达到需求规格说明书标明的功能 2、软件出现了需求规格说明书指明不会出现错误的地方 3、软件的功能超出了需求规格说明书指明的范围 4、软件出现了需求规格说明书虽未指明,而应该达到的目标...软件缺陷修复相关 并不是所有的缺陷,开发人员都会进行修复 开发人员拒绝修改的缺陷 程序员无法重现或者现象难以捕捉 --- 缺陷详细描述 没有明确的报告说明重现缺陷的步骤---缺陷报告 程序员无法读懂的缺陷报告...加强开发人员、测试人员和管理人员的协同工作,让他们更好的工作 2、 缺陷报告的注意事项 尽量确保缺陷可以重现 如果提交的缺陷无法重现,会影响开发人员的工作效率。...3、4 缺陷跟踪 新提交的缺陷为新建状态,确认有效后为打开状态,经开发人员修改后,缺陷变为已修复(待验证)状态。此时就需要测试人员对缺陷进行回归测试,验证问题是否修复。...如果问题仍然存在,则测试人员将该缺陷的状态修改为重新打开; 如果问题已经修复,则测试人员将该缺陷的状态置为关闭状态(验证通过),同时添加回测说明如“该缺陷已解决”。

    3.1K10

    软件测试之BUG的生命周期

    如果是等级越高,那么可能被修复的等级会高一些,有些公司还会根据你提的BUG数量和BUG等级来考察你的绩效。很多情况下,我们提交BUG大致的等级差不多即可,没有严格区分。...生命周期中缺陷状态:新建–>指派–>已解决–>待验–>关闭 发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG 如果待验的BUG...在验证时没有解决好,我们需要重新打开–指派—已解决—待验,循环这个过程。...如果一直未修复,提醒开发人员修改;如果已经修复等待测试环境更新后进行验证 2.已解决的BUG—-等待测试环境更新后进行验证验证通过则关闭;验证不通过则重新指派给开发 3.重复BUG—-先去查看下是否跟开发指定的...5.无法重现—-确认开发环境是否跟测试环境一致?

    81530

    性能测试案例与经验分享

    那么,我们首先要做的是验证在单用户的情况下,是否会出现响应时间变长的问题。具体做法是,将用户登录的虚拟用户脚本单独拿出来,建立一个单用户运行的性能测试场景并执行,观察用户登录的响应时间是否变慢。...如果没有变慢,则说明我们必须尝试在有压力的情况下重现这个性能问题。...为此,我们要基于用户登录的虚拟用户脚本构建并发测试的场景,但是我们并不清楚在这个场景设计中到底应该采用多少并发用户、加入多长的思考时间。...一般来说,当定位到性能“恶化”的原因并修复后,我们还会再执行一轮性能基准测试,确保系统对外发布前的性能基准测试指标没有“变坏”。...但是,具体应该增加多少机器,以及增加后系统的负载处理能力是否会线性增长,这些问题都需要通过容量规划测试进行验证。 那么,容量规划测试具体要怎么做呢?

    39410

    你不就是加了 2 行代码,为什么要用 2 天?

    我们来分析一下原因: 1、因为提交这个问题报告的人,并没有清晰描述如何重现问题。 我花了几个小时才重现了。有些开发者会立即回到报告问题的人那里,要求他提供更多的信息,然后再进行调查。...隐藏错误容易导致其他意想不到的隐患。我不希望在将来还得返工处理。 4、因为我调查了是否有其他方式可以引发同样的问题,而不仅仅是重现报告的步骤。...重现步骤是很容易让复现错误,而实际上可能是更深层次的错误原因。找到问题的确切原因,并查看所有引发问题的方法,更能提供有价值的见解。...5、因为我花了时间来验证代码中是否有其他部分可能受到类似的影响。 如果一个错误导致了 Bug,那么代码库的其他地方发生也可能有同样的错误。现在是检查的好时机。...我不想要最快速的修复方法。我想要一个未来不会造成混乱或其他问题的修复方法。 7、因为我做了更彻底的测试,并验证了它解决了所有受影响的不同代码路径的问题。 我不想依靠别人来检验我所做的是正确的。

    54420

    性能测试案例与经验分享

    那么,我们首先要做的是验证在单用户的情况下,是否会出现响应时间变长的问题。具体做法是,将用户登录的虚拟用户脚本单独拿出来,建立一个单用户运行的性能测试场景并执行,观察用户登录的响应时间是否变慢。...如果没有变慢,则说明我们必须尝试在有压力的情况下重现这个性能问题。...为此,我们要基于用户登录的虚拟用户脚本构建并发测试的场景,但是我们并不清楚在这个场景设计中到底应该采用多少并发用户、加入多长的思考时间。...一般来说,当定位到性能“恶化”的原因并修复后,我们还会再执行一轮性能基准测试,确保系统对外发布前的性能基准测试指标没有“变坏”。...但是,具体应该增加多少机器,以及增加后系统的负载处理能力是否会线性增长,这些问题都需要通过容量规划测试进行验证。 那么,容量规划测试具体要怎么做呢?

    69930

    软件测试---BUG的生命周期

    二、bug的生命周期 生命周期中缺陷状态:新建–>指派–>已解决–>待验–>关闭 发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG...Bug重现环境,bug类型,bug等级,bug的优先级以及详细的重现步骤,结果与期望等。 当然,我们在提交一个问题之前首先应该保证,这个缺陷是没有被提过的,以免造成重复缺陷单。...5、修复BUG 推迟处理   在处理问题之后,还需要进行一次判断,是否需要推迟处理,有些需求已经确认了是问题,由于其可能在极端情况下才会出现,或需要对系统架构进行改动,或其优先级非常低,所以暂时不需要对此问题进行处理...6、回归验证BUG 回归缺陷对于测试人员来说是非常重要的工作,其有三个入口两个出口。 确认非缺陷问题:对于提交的一个缺陷,开人员处理为非问题或无法重现,然后直接转交给测试人员回归。...如果非开发人员所说,是由于问题描述模糊或其它原因喂重现问题,则再次注明原因转给开发人员。 确认修复问题:对开发人员修复的问题再次进行确认,确认能过,则关闭问题。

    1.6K30

    测试思想-测试执行 缺陷提交,优先级

    至少别人不可以否认你说“问题压根不存在” 第二.是否重现 对于发现的缺陷,至少进行2-3次的重复验证。...理由: 1.判断缺陷是否重现 2.确定重现缺陷需要的最简单步骤 遇到难以重现的缺陷怎么处理? a) 停止操作,开始记录 尽量回忆之前的操作步骤、操作过程,并记录下来。包括操作环境。...说明: 提交缺陷管理系统的难重现缺陷应该有个监控周期,一般可以考虑监控2-3个版本,过期还是未重现,可以考虑关闭 第三、是否需求 缺陷是针对需求来说的,如果需求中没有相关说明,有些比较不好确定是否为缺陷的建议如下...说明: 建议类缺陷统一提交给产品负责人,好处是,一来和已固定需求分离,避免在开发周期内又新增需求,扰乱计划;二来建议类的是否作为缺陷,是否需要实现,还得产品及其他相关人员进行评审;建议组织内部应该进行约定...第四、缺陷的编写 禅道PSM的创建缺陷为例,截图所示 ? ? ?

    50530

    译 | .NET Core 基础架构进化之路(二)

    重现错误变得困难。在 dotnet/core-setup 中,一个糟糕的提交可能会破坏任何在 PR 和 CI 检查之外拉取其输出的仓库。...由于拉取请求验证时间的变化、需要对重大更改做出反应以及所需的订阅更新频率,此依赖项的更新将在每个位置不同的速率提交。...如果可能的话,我们总是努力提供一个连贯的产品。 不协调会导致哪些问题? 不协调表示可能的错误状态。例如,我们来看看 Microsoft.NETCore.App。此包表示特定的 API 层面。...这是否意味着不协调总是错误状态? 不。例如,假设图中的 Microsoft.NETCore.App 的不协调性仅表示 coreclr 中的单个更改,即单个不会爆的 JIT Bug 修复。...这在发布后期特别有价值,因为它有助于我们在查看是否进行特定更改时做出更准确的成本/收益估计。例如:我们是否有足够的时间来进行此修复并完成方案测试?

    1.4K60

    小达同学软件测试第五讲-测试技术与应用(完结)

    系统测试 什么是系统测试,系统测试测试的是整个产品系统,进行系统测试,是为了验证该系统是否符合了需求规格的定义,并找出那些不符合的地方。...功能测试一般黑盒测试进行,用到等价类划分法和边界值分析法。 错误处理测试: 软件错误等级分为:致命错误,严重错误,一般错误,轻微错误,改进建议。 描述错误分三步走,摘要,重建步骤和隔离。...重现错误: 在写文档时,记录重现错误步骤是至关重要的,只有你把步骤重现出来程序员要能足够理解,发生了什么错误,并且对程序进行修复,如果你告诉程序员这里错误了,可是不指出问题所在,程序员鸟都不鸟你!...然而重现步骤,也不是你所重现重现的,测试人员需要进行发现错误时的所有操作,必须保证操作与原先发生错误时步骤一致和测试环境一致,有可能遇见偶发性,不一定就能马上发现出来,这就需要进行重复的步骤了。...比如进行破坏性测试,重点是当破坏系统时,系统错误的状态和系统破坏程度,是否能恢复。

    44420

    Web Hacking 101 中文版 二十、漏洞报告

    重现错误的步骤 这些标准对于 Hackerone 的主要公司来说都很常见,包括雅虎,Twitter,Dropbox 等。如果你想更进一步,我建议你添加屏幕截图或视频验证(POC)。...优先级:漏洞计划必须找一些方法来为漏洞修复排序。 当你有多个具有类似影响的漏洞,但报告持续不断进入时,这非常困难,奖励计划面临严峻的挑战。 验证:在分析报告时,必须验证漏洞。...这就是为什么我们的黑客必须提供明确的指示,并解释我们发现的内容,如何重现它以及为什么它是重要的。 只是提供一个视频并不能切中它。 资源:并不是每个公司都能雇得起全职工作人员来运行奖励计划。...所以,“不要在穿越池塘之前喊‘你好’”是一个瑞典谚语,意思是你在绝对确定前不应该庆祝。 你可能猜到我为什么说这个 - 挖漏洞并不总是充满阳光和彩虹。...每一天我都检查了我是否可以再次报告。 从那以后,我发誓要提升我的 Signal ,你也应该这样! 祝挖掘顺利!

    36830

    只加两行代码,为什么要用两天?

    因为问题报告对于重现方法的描述不够明确。 有时候,我们需要耗费几个小时才能可靠地重现某些问题。遇到这种情况,有些开发人员会立即与问题上报者取得联系,要求对方提供更多详细信息。...掩盖错误很容易引发其他意料之外的副作用。我可不想在未来某个关键时刻再次被同样的错误困扰。 因为除了上报的重现步骤之外,我还调查了其他可能引发同一问题的情况。...一组重现步骤虽然能够轻松让错误再次出现,但往往不足以揭示引发错误的深层次原因。只有找到这种根源性因素,同时研究解决问题的所有可行方法,才算是真正有价值的分析洞见。...因为我花时间验证了代码的其余部分是否会受到类似问题的影响。 如果错误源自某项 bug,那么代码库内的其余位置应该也会存在相同的错误。既然有用户上报了,最好是全面检查一下。...因为在发现错误根源时,我希望最简单的方法加以解决,保证将引入副作用的风险控制在最低水平。 因为我彻底测试了这项变更,并确保其能够解决不同代码路径下的同一问题。 我不想把修复测试这种麻烦事推给其他人。

    36820

    10+年程序员总结的20+条经验教训学习

    6.所有事情所花费的时间总是比你预期的要长 特别是在编程中,即使一切进展顺利,我们也很难对功能所需的时间做出正确的预算。并且,开发软件时碰到各种意想不到的问题是非常常见的。...故障排除 9.bug总是难免的 我不喜欢那些宣称软件开发可以“一蹴而就”的高谈阔论。不论你再怎么费尽心机,bug总是难免的。最好能够做成可以快速故障排除、修复bug和部署修复的系统。...10.解决故障报告 每个开发人员都应该花时间去处理来自客户的故障报告,并修复bug。这能让你更好地理解客户的意图,明白如何使用系统,知道排除故障的难易程度,了解系统的设计情况。...11.重现问题 修复bug的第一步就是重现问题。然后你得确保修复之后,问题能够彻彻底底地消失。这样一个简单的规则可以确保你不会误将非问题当作是问题,并确保解决方案真的能够奏效。...12.修复已知错误,然后再看看有没有遗漏的地方 有时候,可能同时存在着几个不同的问题。它们之间的互相作用,可能会让你毫无头绪,束手无策。

    65070

    程序员的bug修复宝典

    5.修复bug。在明确了bug的根本原因之后,下面就需要发挥我们的聪明才智去修复这个bug了。 6.验证bug。...并不是每次我们修复完bug之后就可以万事大吉了,此时我们还需要去重现bug确保bug被真正修复。除此之外,有条件的我们还需要去验证相关场景,保证修复该bug不会引入其他bug。...在这里需要我们着重注意以下几点: 1.重复之前复现bug的步骤来验证bug是否被彻底解决。 2.验证bug修复可能改动到的相关模块是否正常,保证bug修复不引入新的bug。...提升bug信息收集的效率以及有效性可以大幅度地提升我们修复bug的效率。 那么我们应该如何建立健全的信息收集机制呢?...这个时候如果有一套自动化测试机制或者工具帮助我们验证bug的话,就可以极大地缩减我们修复bug的时间。

    68720
    领券