精华内容
下载资源
问答
  • 从标题来看大家可能会觉得晕,这里说到的可复现是指这些Bug有时出现,...能否复现这些复现的Bug成为大家关注的一个话题,最近国外的测试专家James Bach、Jonathan Kohl等对这个话题进行了一些探讨,这里把他们...
    从标题来看大家可能会觉得晕,这里说到的不可复现是指这些Bug有时出现,有时候不出现。相信大家在测试过程中肯定遇到过这种Bug,不少这种不可复现的 Bug定位起来非常困难,可能很长时间都不能得到解决。能否复现这些不可复现的Bug成为大家关注的一个话题,最近国外的测试专家James Bach、Jonathan Kohl等对这个话题进行了一些探讨,这里把他们的一些思路理出来和大家分享。
        要想复现不可复现的Bug,需要先提到一个概念就是ET(Exploring Test),也就是探索式测试,这种测试方法是由James Bach首先提出来的,在所掌握的被测对象的信息不是很充分的情况下,这是一种很有效的测试方法,如果大家感兴趣,我再整理一篇ET的文章出来。
        在给大家阐述如何复现不可复现的Bug的思路之前,先说说为什么要复现这些不可复现的Bug(废话两句^_^)。对于整个项目或者产品而言,如果这些不可复现的Bug是很严重的Bug,比如导致系统崩溃等,如果不能及时、准确的定位和解决,最终发布出来的软件到达用户手中后,一旦出现势必会影响软件已经公司在用户心中的形象,严重的会“迫使”用户选择竞争对手的产品,这些显然都是公司所不愿看到的。而对于测试人员而言,出现了这些不可复现的Bug,实际上是一次很好的锻炼和提高机会,如果只是提交缺陷报告将这个大皮球踢给开发人员,不仅丧失了一次提高测试水平的机会,还有可能破坏和开发人员之间的关系。
        废话完了,进入正题。当出现不可复现的Bug时,大家可以从以下五个方面来进行考虑:
    1、被测对象的版本信息
        我测试的到底是哪个版本,这主要是有两个作用:一是确认我测试的是正式的软件版本,如果不是就先记录下该问题,然后选择正式的版本进行测试(开发人员基于尝试的一次非正规的修改可能会导致不可复现的Bug);二是可以和其它版本进行对比,如果其它的版本没有类似的问题,就可以去对比这两个版本之间的区别。
    2、环境
        这里的环境是指出现不可复现的Bug时所对应的测试环境等,比如测试所用的计算机,如果出现不可复现的Bug,那我换一台机器是不是还会出现类似的问题,也就是说通过环境的改变来进一步搜集不可复现Bug的相关信息。
    3、模式
        这里的模式是指我对这个Bug如何出现的一个理解,先给这个Bug设定一个模式,比如是不是数据库通信中断,然后再进行测试,收集更多的信息去修改和完善这个模式,这样不断进行,最终直到Bug能完全复现为止,这个时候只要使用这个模式就可以复现出Bug了。
    4、人
         这里提到的人有两个含义:一是测试是由人来进行的,人的操作、人的思维方式会有不同,通过分析这些信息也有可能找到这些不可复现的Bug的蛛丝马迹;二是想复现不可复现的Bug,往往需要多个人之间的相互协作,比如测试人员、开发人员等,通过大家的沟通和协作就能更容易去复现了。
    5、测试工具
        通过一些debug工具或者log工具等搜集内存等信息,根据这些信息来进行分析,找出不同信息之间的共同点,比如某一块内存始终都会被改写等,通过这种方式来去复现Bug。
        上面的五个方面都是和ET的思想紧密相关的,通过不断的测试和不断的信息收集和分析,逐步的把模糊的、不确定的测试变成清晰的、确定的测试,这样就能复现那些不能复现的Bug了。考虑信息时可以从以上五个方面来进行考虑。
        相应的文章链接:
    [url]http://www.kohl.ca/blog/archives/000115.html[/url]
    [url]http://blackbox.cs.fit.edu/blog/james/archives/000197.html[/url] 




    本文转自 fish_yy 51CTO博客,原文链接:http://blog.51cto.com/tester2test/137379,如需转载请自行联系原作者
    展开全文
  • 1、首先出现难以复现的bug一定要截图提交bug 2、首先评估bug的重要程度以及对整个项目的影响,如果影响小,就记录下来,继续跟踪 3、如果对项目影响较大,范围较广,则要及时解决。 尽量复现当时bug出现的场景:环境...

    1、首先出现难以复现的bug一定要截图提交bug
    2、首先评估bug的重要程度以及对整个项目的影响,如果影响小,就记录下来,继续跟踪
    3、如果对项目影响较大,范围较广,则要及时解决。(免费领取Python自动化学习资料  工具,面试宝典面试技巧,加QQ群,785128166,群内还会大佬技术交流)
    尽量复现当时bug出现的场景:环境、数据等,跟组内其他的测试同事交流下,再多尝试几次(20次到30次)。如果还是不能复现,就把这个问题反馈给开发,让开发进行代码走查,看能不能找到原因。如果开发这也不能发现,就把问题反馈给项目经理,请项目经理组织更多开发测试同事参与解决这个问题

    展开全文
  • 难以复现的Bug 不是所有的问题都用同样的操作步骤来复现的,有的Bug概率出现甚至偶现,或者是只在测试环境里出现。 解决办法: 针对难以复现的Bug,需要保存截图或者记录log保留证据;对于只在测试环境下才会出现...
    1. 测试人员描述不清晰

    工作中也有测试人员把某些“Bug操作步骤”描述的只有自己看得懂,开发人员按照步骤复现Bug不知所云,搞错了问题所在。
    解决方法:
    修改Bug操作步骤:清晰描述、无歧义、无冗余步骤,要达到即使给一个不懂的人去重现这个Bug,也能按照你的操作步骤复现。

    1. 难以复现的Bug

    不是所有的问题都能用同样的操作步骤来复现的,有的Bug概率出现甚至偶现,或者是只在测试环境里出现。
    解决办法:
    针对难以复现的Bug,需要保存截图或者记录log保留证据;对于只在测试环境下才会出现的,找研发在测试环境进行确认。这类Bug要慎重对待,规避风险。

    1. 有争议的Bug

    有争议的Bug多发生于建议类型的Bug:与同类软件不符、易用性、美观性等类型的Bug。
    解决办法:
    这种问题是否要修改需要根据公司的项目类型进行讨论。开Bug评审会,在开发能实现的情况下说出自己的理由,改善产品。

    1. 功能性Bug

    与需求不符、与原型设计不符。有时候研发对需求没有深入了解可能会忽略或者搞错个别功能。
    解决办法:
    拿证据(需求、设计说明书)给他看,这种bug自然合情合理。
    ————————————————
    版权声明:本文为CSDN博主「JLL95」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
    原文链接:https://blog.csdn.net/Strive_0902/article/details/82775273

    展开全文
  • 严格来讲这可能是我职业生涯以来的首个悲惨经历,因为凭我的知识储备和经验,基本上任何可重现的bug都是可解的。然而这个bug却困扰了我三个月之久,它具有以下生理特征: 后台日志统计到异常,偶发、低频 报异常...

    人在江湖飘,哪能不挨刀。

    我挨了重重一bug。严格来讲这可能是我职业生涯以来的首个悲惨经历,因为凭我的知识储备和经验,基本上任何可重现的bug都是可解的。然而这个bug却困扰了我三个月之久,它具有以下生理特征:

    1. 后台日志能统计到异常,偶发、低频
    2. 报异常的用户设备不具有规律性,什么手机都有
    3. 我们自己无法复现,任何设备、任何环境都没复现
    4. 打电话回访报异常的用户,确实存在问题
    5. 客服未接到用户主动反馈这个异常

    此bug并不是js报错,而是一个业务逻辑的错误。表现是,用户提交的数据莫名缺失。场景是以下这个界面

    520134-20180315151441457-948225884.png

    当用户填满所有的空之后,提交按钮变为可用状态,数据放进一个数组中提交上来。后台有报错日志显示,用户提交上来的有些是空数组,有些是数组中缺了几项。

    问题在于,提交前是有校验的,用户不可能提交上来这种未通过校验的数据。并且还是偶发的啊,如果是逻辑写错了,那应该全部会报错,我们在测试的时候肯定会发现。

    最棘手的地方是,我们压根没重现过这个情况,找各种同事、各种手机、各种胡乱操作,一次都没重现出来。这就给调试带来很大的麻烦,只能是猜测哪里可能出问题,然后去验证。但是根本没法去验证啊。。。重现不了,又如何判断是成功fix了。

    看来能验证的手段就只剩一个:线上日志。猜问题、上线、看日志。

    这是一个痛苦的过程。界面虽然简单,这却是一个庞杂的项目。因为题型众多,抽离了很多组件,为了公用和灵活扩展,组件嵌套深度有五层之多。其架构复杂程度在我的职业生涯中也能排TOP3.

    拿题干的渲染来说,就有:公式图片转LaTeX、mathjax渲染公式、渲染公式上的空、给空编号、模拟光标、自动focus空、动态计算字体大小等诸多流程。而且下方那个键盘还是我们H5模拟的,并不是系统键盘。更别提还有校验逻辑、判分逻辑。

    前n次尝试

    看距离上一版有哪些改动,抹去有嫌疑的改动,看日志是否正常。尴尬的是,这是一次重大重构,改动的地方还特别多。于是一场盲人摸象式的远程debug行动开始了。

    一次又一次的上线、观察日志、下线。不断排除了一些相关的功能,始终未能诊断到问题所在。甚至连我很确信的地方都尝试了,还是找不到问题。前前后后尝试了二十多次吧,改到我都怀疑人生了。领导看了这些上线记录都怒了,说你这上上下下的搞鸡毛呢。我也很崩溃啊。

    看来用这个盲人摸象手段是搞不定了,我意识到了情况的严重性,暗暗感觉这可能不是轻易能解决的,吕某一定使出毕生所学,为民除害。

    第n+1次尝试

    既然有那么多的用户日志,我们自己为何重现不了?这是我一直纠结的。于是再次进行疯狂测试。

    皇天不负有心人,我竟然真的给重现出来了!操作是这样的:填好空,两个手指同时按下提交按钮和删除按钮。这样的话既通过了校验,又能在提交之前把数据给删了。

    发现这个骚操作的时候我是很兴奋的,但是会有那么多用户这么操作吗?显然不太可能。此时我又想到,提交按钮和删除按钮是挨着的,会不会是用户按提交的时候误触了删除键。这还算比较合理,毕竟用户是小学生嘛,操作不一定那么精准的。

    我兴奋不已的进行验证。在删除键和提交键之间加了“下一空”按钮(通过配置),这样用户保证不会误触了。

    上线,日志依旧。我摔啊,看来并不是误触的事。

    第n+2次尝试

    随着bug拖的时间越来越长,我的心态也有点焦躁。但思路还是聚焦在删除按钮上,毕竟这是好不容易发现能重现的。

    如何能够既点提交又点删除呢?这时候我想到了点击穿透(键盘为了响应快,使用了touchstart事件)。因为在点完提交的时候,模拟键盘会收起来,而收起的过程中删除按钮会经过提交按钮的位置。根据点击穿透的原理,如果此时派发的click事件作用到了删除按钮上,那岂不是就算点到了?

    我都有点佩服我的想象力了,黔驴技穷了啊,试吧。避免点击穿透有两种方式,阻止click事件的默认动作,或者是让元素收起的时间延迟。我选了后者。

    上线,日志依旧。我吐血。后来一想,删除按钮根本都没监听click事件啊,哪来的穿透。真是病急乱投医了。

    第n+3次尝试

    扫代码,发现一个很重的疑点。答案是个数组,是引用类型。由于复杂的组件关系,这个引用类型的数据可以被多个组件访问到。

    使用可变数据的时候有个隐患,它可能在你不知道的地方被修改。代码是vue写的,有些组件中含有watch,搞不好是意外进了哪里的watch,在点完提交的时候也会把数据给更改了。

    这个猜测我觉得是合理的,在开发阶段我就曾因为未使用immutable数据而隐隐担心过。好了,快速验证吧。在点完提交按钮的时候,我把答案数据给克隆了一份,然后再进行判分和提交的操作。这下就不担心已经拿到的数据被篡改了。

    上线,日志依旧。继续吐血。

    不过这次也缩小了嫌疑范围,看来数据不是在点完提交的时候被篡改了,而是提交上来的就有问题。匪夷所思的是,用户是如何绕过校验把数据提交上来的呢?难不成是我的校验函数有问题,这个地方把数据给改了?扫了一遍代码,无果。

    第n+4次尝试

    此时聚焦到了用户在填写答案的时候发生了什么。我像侦探一样用放大镜一遍遍看代码,然而好多天的追踪,并没有找到什么有用线索。

    直到有一天,那天阳光明媚天空飘着朵朵白云,感觉有什么好事要发生。QA在反馈群里发了一张截图,说公式解析的那个点点点一直不消失(正在解析的状态),而且空里也输不进内容去。如下图:

    520134-20180315151533727-886428437.jpg

    我敏感的神经顿时嗅到了一丝线索。题干使用了mathjax来解析公式,而mathjax在解析的过程中会按需加载一些字体文件,而且还会扫描页面节点,并生成大量的DOM节点。这对浏览器来说是个压力不小的事情,更何况是移动端。

    我马上再扫描公式处理的代码,由于有些空会在公式上出现,所以代码是在等公式渲染完后统一给空编序号,然后进行自动focus,而且自动focus的时候还会首先给答案赋值。天呐,问题该不会出现在这里吧!公式的渲染过程可能有延时,用户可能在这个时间进行点什么操作!

    首先这符合偶发这个事实,因为公式解析中出现抖动网络延迟什么的也是偶然现象。再者公司的网络快,用户的网络可能慢,这也符合我们一直未重现的事实。感觉这次很靠谱了!很多侦探电视都是这么演的啊,主人公通过别人无意的一句话联想到了线索,然后案件破解,真相大白!对对对,就是这个感觉!

    赶快在代码层面做优化,尽可能早地处理没有公式的空,有公式的地方也确保执行完后用户才能输入。

    优化完毕,回归测试,万事俱备,只等线上验证,一锤定音!

    结果......日志还有啊!啊噗!,电视里都是骗人的啊!

    等等!日志虽然还有,但好像少了耶!难道这次的优化是有作用的?虽然从理论上能解释一些作用,但还存在的日志又表示什么呢?难道造成丢答案的原因不止一个?

    第n+5次尝试

    时间一天天过去,我还是没找到什么有力线索。中陆续有一些猜测,打了一些日志点后还是无果。看着QA同事紧缩的眉头,领导关切的询问,我也越发焦虑了起来。因为我这是一个公共组件库,有其他项目在等着使用,如果我的bug解决不了,将影响其他项目的进度。

    又是阳光明媚的一天,天空飘着朵朵白云。我无意跟另一位后端同事聊到了这个话题,他随口一说:应该是超时自动提交的吧。

    什么?什么!自动提交?!我突然像被闪电击中。因为我写的这是个公共组件,同时也对外暴漏了一些API,比如提交答案就是其中一个。我提供的是答题界面的组件,但是别人项目中有倒计时的场景,超时后会调用我的提交API,把用户答案提交上去。

    如果超时的时候,用户什么也没填,那岂不是把空答案给提交上去了!!!根本没有校验函数什么事,是别人调API提交的啊。

    我哭了。难怪没用户反馈呢,时间到了自动提交空答案,他们没理由反馈啊。难怪我们自己没重现呢,一直沉浸在怎么乱点出来。就算QA同学看到了超时提交的时候,也无法意识此时是空答案。

    没错,真相就是它了,修改相关逻辑后上线,果然报错日志没了。困扰我三个月的bug终于解决了!我闭上眼睛,心里默默放了一把鞭炮。

    总结

    前前后后三个月时间,总算是找到了问题所在。其实第n+4次是解决了一些问题的,最后一次是彻底解决,我用实际行动证明了,真相不止一个。而这件沸沸扬扬的丢答案bug事件,也给了我很多启示。

    1. 做重构的时候要格外小心逻辑更改,重构后一定要跑通所有case。

    2. 排查问题的方式,这期间我使用了各种对照试验,各种源码级别的排查

    3. 使用vue做复杂项目的时候要格外注意组件的嵌套层数,少写watch,避免程序执行顺序的混乱

    4. 设计对外API时,要考虑健壮性,不光考虑传入参数的不稳定,还要考虑当前上下文的不稳定。

    转载于:https://www.cnblogs.com/lvdabao/p/8573778.html

    展开全文
  • 导致牌面会出现5个牌的bug,但是个bug呢你去配一样的牌,一样的步骤,动作,顺序都不能复现。经过大量分析,服务端是确定没有异常的,但客户端这个是怎么出现的,一时没有好办法就用了个最笨的办法,每次牌堆变更就...
  • vc++如何查找和解决bug

    2015-07-23 01:18:12
    工程有若干个dll,一般错误能复现或能单步调试问题还能解决,但现在总有异常退出问题,系统日志里看不出什么,生成dump调试,代码总在反汇编代码,看懂,调用堆栈也往往是在熟悉模块里,没法查看,请问有...
  • 分享软件bug解决经验

    2020-06-19 19:55:11
    首先关于日志记录方面,通常我们开发的软件都会记录运行日志,工作中发现很多开发人员不会打日志,对于很多关键地方没有打日志,却打... 然后关于解决问题的思路,不能指望通过复现问题来找到代码中的bug,其实所有b...
  • 无法重现的bug

    2007-05-16 10:54:00
    相信大家在测试过程中肯定遇到过这种Bug,不少这种不可复现的Bug定位起来非常困难,可能很长时间都不能得到解决。能否复现这些不可复现的Bug成为大家关注的一个话题,最近国外的测试专家James Bach、Jonathan Kohl等...
  • 解决、未解决的过滤就有问题。 现在范例里有30条数据, 其中2条是【未解决,28条是【已解决状态】 在过滤条件中勾选 【未解决】, 表格依然会显示30条数据。 将范例代码拷贝下来,将pro...
  • 相信大家在测试过程中肯定遇到过这种Bug,不少这种不可复现的Bug定位起来非常困难,可能很长时间都不能得到解决。能否复现这些不可复现的Bug成为大家关注的一个话题,最近国外的测试专家James Bach、Jonathan Kohl等...
  • 追踪bug的十条建议

    2011-07-02 17:53:54
    每个人都能解决bug,但是只有亲眼见过bug的人才能确认bug是否被修复 解决bug有很多种方法:修复、无需修复、推迟、不能复现、重复、设计问题等。 不能复现,意味着没人能重现这个bug。当bug报告缺少复现步骤时,...
  • 疫情期间去了学校,科研任务也没有那么大,一次在公众号里看到了百度课程,亲身体验过之后真是非常良心课程,而且还是免费,无论是课程中认真负责班主任,还是什么bug帮你解决的助教。论文复现营是我...
  • 程序员经常扬言,"这个 Bug能复现,我就能改"。但是又有多少 Bug 是可以必现?大部分难以解决的 Bug,都是偶现,只在特定场景下才会出现。如果是一个导致崩溃 Bug,我们可以通过搜集崩溃现场信息,例如崩溃...
  • 关于解bug的一点体会和心得

    千次阅读 2018-02-10 09:54:33
    本人并非科班出身,敢妄谈自己在编程方面有很深厚功力,这里只是结合我...这里其实有一个隐藏道理——就是如果你每次都bug复现,就说明你已经知道bug的确切产生条件了,而条件就对应了软件里分支,所以...
  • 关于,问到异常状态下的Bug处理姿势时,很多同学,是没有太清晰的思路去解答,或者去解决的 。特别是在面试的时候,很多同学,吃过亏,一份到手的Offer,毁于这一个小小的问题 。啥叫异常流程 ?比如,1)提的Bug,...
  • 不能复现:可能是版本升级导致,(联系运维、产品)是否需要需要回退到上一个安全稳定 版本 能复现:召集开发、产品、运维预估bug解决时间 解决时间短:尽快修复,尽快回归,尽快线上验证...
  • 可用官方demo复现bug。求解决这个问题。 <img alt="image" src="https://img-blog.csdnimg.cn/img_convert/60a71da5f291114695926e230bb756e8.png" /></p>该提问来源于开源项目:ecomfe/echarts-for-weixin...
  • 调了好几天 最后把代码清一清,新建了一个activity发现还是能复现 demo_my_test_activtiy.xml ``` android:layout_width="match_parent" android:layout_height="match_parent" android:orientation...
  • 你写了一堆代码,不能因为别人没有证明你代码有错误而认为自己代码没有错误。 想办法复现问题、分析问题可能情况(假设+求证)、定位问题、找到问题,这个过程往往是最费时间精力事情。解决问题主要工作...
  • 作为一名测试工程师,Bug生命周期,一定陌生 ,而且脑海里,肯定想到一张关于Bug各状态流转的流程图 。 关于,问到异常状态下的Bug处理姿势时,很多同学,是没有太清晰的思路去解答,或者去解决的 。 特别是在...
  • bug修复后查明是yarn问题,yarn不能使用https://registry.npm.taobao.org源,所以报出了该错误,yarn在安装完毕后会修改默认包使用方式为yarn,而vue提供源yarn又不支持使用,所以报错 解决方案: 将C:\Users\...
  • 目录先吐槽一下bug感性描述定位bug复现bug猜想源代码解决方案后记 先吐槽一下 最近接手一个项目,前任代码非常烂,如果骂人等于杀人,那么他知道死了多少回了。 1、项目代码是从以前几个项目中拼凑来,本身就很...
  • 昨天在写一个题目其中一块任务是:将一些字符串去重,并且按给你时候顺序输出出来,我没有想到用...小弟长时间自己思考,百度源码结论都应该是冒泡逐个遍历,但是并没能解决,还请各位老师指点一二。非常感谢!

空空如也

空空如也

1 2 3 4
收藏数 78
精华内容 31
关键字:

解决不能复现的bug