bug定位_快速定位bug - CSDN
精华内容
参与话题
  • BUG定位方式

    千次阅读 2018-08-24 15:38:15
    今天面试问道BUG定位方式,我的回答基本上都是些日志或者输出特定数据弹窗之类的。回去后想起似乎有个wmp什么的文件可以用来调试。特此记录 在编写代码的时候谨记墨菲定律:任何可能出错的事情最终都会出错。 定位...

    今天面试问道BUG定位方式,我的回答基本上都是些日志或者输出特定数据弹窗之类的。回去后想起似乎有个wmp什么的文件可以用来调试。特此记录

    在编写代码的时候谨记墨菲定律:任何可能出错的事情最终都会出错。

    定位策略

    常用的定位策略分为三类:

    ①原始类(brute force)

    ②回溯类(backtracking)

    ③排除类(causeeliminations)

    排除类推荐二分法

     

    定位方法

    1.日志记录

    通过输出到文件或者弹窗警告这种模式定位BUG

    2.DMP文件

    不是wmp文件是DMP文件。在任务管理器中右键进程创建存储文件生成DMP文件。然后使用Windbg调试。

    3.IDE中直接调试

    在VS、QtCreate、GDB中都能通过单步调试一步一步找到BUG点。但是这种方式有极大的限制,当时在客户那出现BUG时不好进行调试。

    展开全文
  • 三种bug定位方法

    千次阅读 2019-01-25 21:47:00
    1、定位bug产生的过程 测试用例的执行,基本上是程序运行过程bug产生的开始,若测试结果与期望结果有出入,即出现了错误征兆,定位bug过程首先要找出bug产生的原因,然后对bug进行修正。因此定位bug过程有两种可能:...

    1、定位bug产生的过程

    测试用例的执行,基本上是程序运行过程bug产生的开始,若测试结果与期望结果有出入,即出现了错误征兆,定位bug过程首先要找出bug产生的原因,然后对bug进行修正。因此定位bug过程有两种可能:一种可能是找到了bug产生原因并提给开发去纠正;另一种可能是测试过程中程序产生的bug原因不明,测试或开发人员只得做某种推测,然后再设计测试用例证实这种推测,若一次推测失败,再做第二次推测,直到发现并纠正bug。

    定位查找bug是一个相当艰苦的过程,究其原因除了开发人员心理方面的障碍外,还因为隐藏在程序中的错误具有下列特殊的性质:

    (1)错误的外部征兆远离引起错误的内部原因,对于高度耦合的程序结构此类现象更为严重;

    (2)纠正一个bug造成了另一bug现象(暂时)的消失;

    (3)某些bug征兆只是假象;

    (4)因操作时疏忽造成的某些bug征兆不易追踪;

    (5)bug是不是程序引起的;

    (6)输入条件难以精确地再构造(例如,某些实时应用的输入次序不确定);

    (7)bug征兆时有时无,此现象对嵌入式系统尤其普遍;

    (8)bug是由于把任务分布在若干台不同处理机上运行而造的。

    在软件bug定位过程中,可能遇到大大小小、形形色色的问题,随着问题的增多,测试人员的压力也随之增大,过分地紧张致使开发人员在解决一个问题的同时又引入更多的新问题。

    尽管查找bug,定位bug不是一门好学的技术(有时人们更愿意称之为艺术),但还是有若干行之有效的方法和策略,下面介绍几种bug定位方法。

    2、定位方法

    无论采用哪种定位方法,目标只有一个,即发现并排除引起错误的原因,这要求测试人员能把直观想象与系统评估很好的结合起来。

    常用的定位策略分为三类:

    ①原始类(brute force)

    ②回溯类(backtracking)

    ③排除类(causeeliminations)

    原始类定位方法是最常用也是最低效的方法,只有在万般无奈的情况下才使用它,主要思想是“通过计算机找错”。例如输出存储器、寄存器的内容,在程序安排若干输出语句等,凭借大量的现场信息,从中找到出错的线索,虽然最终也能成功,但难免要耗费大量的时间和精力。

    回溯法能成功地用于程序的排错。方法是从出现bug征兆处开始,人工地沿控制流程往回追踪,直至发现出错的根源,不幸的是程序变大后,可能的回溯路线显著增加,以致人工进行完全回溯到望而不可及。

    排除法基于归纳和演绎原理,采用“分治”的概念,首先确定所有与bug出现有关的所有数据,设想一个导致bug的原因,用这些数据证明或反驳它;或者一次列出所有可能的原因,通过测试一一排除。只要某次测试结果说明某种假设已呈现倪端,则立即精化数据,乘胜追击。

    上述每一类方法均可利用一些测试工具,开发工具。目前,调试编译器、动态调试器(“追踪器”)、测试用例自动生成器、存储器映象及交叉访问示图等到一系列工具已广为使用。然而,无论什么工具也替代不了一个开发人员在对完整的设计文档和清晰的源代码进行认真审阅和推敲之后所起的作用。此外,不应省略掉代码走查过程中最有价值的一个资源,那就是开发小组中其他成员的评价和忠告,正所谓“当事者迷,旁观者清”。

    前面有提到,修改一处老问题可能引入几处新问题,有时程序越改越乱,但若能做到每次纠错前都扪心自问三个问题,情况将大为改观:

    ①导致这个错误的原因在程序其他部分还可能存在吗?

    ②本次修改可能对程序中相关的逻辑和数据造成什么影响?引起什么问题?

    ③上次遇到的类似问题是如何排除的?为什么这次又重新出现了?

    引自http://wenku.baidu.com/view/543a89cf482fb4daa48d4b49

    展开全文
  • 定位Bug技巧总结

    万次阅读 2016-05-03 20:12:56
    虽然上面介绍了许多关于定位Bug的方法,但不得不说查找Bug总是费时而且让人头大的,为了避免陷入查找Bug的窘境,请在编写代码的时候谨记墨菲定律:任何可能出错的事情最终都会出错。这点程序上尤为明显。
    解决Bug是编程人员的天职(创造Bug算是一种天赋吧),甚至有人这么认为:开发人员的能力可以依据他能决解Bug的复杂程度来评定。简单的Bug大多数程序员是靠臆断来解决的,但是当Bug隐藏在代码的最深处,臆断不能够解决问题的时候,或许我们就得依靠些许技巧而不是重启。

    1.打印输出,在关键位置用System.out.print(); 输出即时参数或者结果(事实上我更赞同用System.err.print(); 因为那样你的输出更明显),然后来判断程序的走向是否正确无疑简单快捷粗暴,程序新手也乐此不疲的使用打印来寻找Bug,但是这种方法缺陷是显而易见的:要求程序规模不能太大,因为你很难找到合适的地方,而且往往你也不知道打印出来的参数是什么意思;不适宜多线程环境下使用,你无法确定打印的顺序;要求程序运行最好是简单有序的,而且Bug是毕现的;线上程序出问题无法及时找到问题,必须在本地加上打印进行调试;

    2.打印堆栈,通过在事发地点主动调用 new Exception().printStack(); 帮助程序员了解程序的走向。特别是当某个接口被广泛调用的时候:当程序出错,你希望找到错误的源头,那么你就可以通过打印错误堆栈来找到始作俑者。

    3.臆断错误信息,通过系统打印的错误堆栈信息来推测错误原因并加以解决。好吧,这里我实在讽刺大多数不精明的程序员(同时也包括我自己)在看到错误信息后,迫不及待的享受解决Bug的快感,并不仔细查看堆栈信息,往往只解决了表面问题而忽略了更深层次问题。因为在这里受过的挫折太多了,我不得不举两个例子来加以警告:
    情景i:《修仙》项目初期,玩家在进行某些位移操作时候服务器会报出空指针异常错误,于是我根据错误堆栈信息来到了事发地点,并且加上了判空操作并 以为解决了这个问题,事实上当回过头来仔细检查的时候发现这个错误是由于底层移动组件的报错引起的,也就是说如果没有检查,我仅仅把表面解决了等同于我吧错误隐藏的更深了,看起来表现没有错,但是底层在不停的进行错误的操作,谁也不知道最后会发生什么。
    情景ii:项目线上运行时,同事拿给我一份错误的堆栈信息,是一个ConcurrentModificationException,也就意味着我需要仔细检查一下我的迭代器,防止元素的意外添加和移除,我简单的看了下报错的行数,“那里”恰好是一个循环,于是我对这个循环做了仔细的深入的检查,并没有发现错误,于是我决定找同事聊一下,我们一起仔细的看了遍堆栈信息,尴尬的发现我找错地方了 ,由于本地有部分代码没有提交,因此本地的行数和服务日志记录的报错的行数不一致,也就是说我根本没有仔细的查看错误堆栈信息。为了避免类似的尴尬,请各位务必仔细查看错误的堆栈详情。
    此处的所谓臆断,其实我想说以前的我并不是这样的,那时候我并不了解各个异常的含义,但是我对它们很感兴趣,我会仔细阅读错误堆栈信息,找到问题所在,并且试图发现更深的问题,但不知道什么时候开始,看到异常堆栈直觉会告诉我这个异常是这么回事,代表着什么什么,一般是由于什么错误操作导致的,然后按照习惯去解决它。虽然根据经验去推测错误本身并没有错,但我想作为程序员,检查错误时的仔细态度是必不可少的。

    4.代码调试, 使用调试工具进行代码调试,可以说是很通用万能的查找Bug的手段,可以说是程序员基本功。调试没有什么还说的,只能说代码调试容易上手,但在程序中快速找到合适的地方断点才是难点。断点调试虽然好用,依然有些缺陷:不能用于线上程序;多线程环境会影响到调试的正确性。

    5.日志记录,通用的做法就是在程序中增加不同级别的日志记录。日志记录可以说是一种比较全面的寻找和解决Bug方式,根据日志记录的异常堆栈信息找出Bug所在并加以解决是一种理想的状态,当然程序中哪里加日志,按什么格式和形式追加日志(按照不同纬度,不同视角)都决定了你寻找和解决Bug的轻松程度,尤其是在多线程环境中(没错,日志可以用来记录多线程环境下那些不容易复现的Bug)。记录日志很容易,拿Java来说有很多优秀的用来记录日志的框架,如Logger4j,Slf4j等,允许使用者定制日志的格式和形式,但是阅读日志却不是那么容易。通常一个成熟线上产品的日志,每天的日志就可以达到GB级别,每一篇日志可能也是MB的文档,在这些日志中找到你想要的可能需要一些技巧:熟悉程序是很必要的,起码知道异常模块的入口和出口;放弃使用鼠标,阅读日志时用鼠标滑来滑去绝对不是理智的做法,你应该使用查找来帮助你快速定位错误和找到你所需要的,如果你不知道你需要查找些什么,参考第一点;堆栈信息的时间很重要,一般的日志都会记录时间,知道异常发生的时间也许帮助你了解很多。
    (注:日志的格式是指记录日志的模板,如:时间-线程-类-方法;记录日志的形式,如:按天记载,按账号记载。)

    6.使用分析工具,使用Java 提供的分析工具如JMC,Java Visual VM ,可以帮助你分析程序的运行状况如CPU,内存,线程等,这些工具可以用来定位不易发现的内存泄漏问题以及项目后期的优化。

    7.查看API文档和GOOGLE,查看官方的API文档可以帮助你更好更快的掌握和使用一个工具类或者框架,记得谁说过:查看官方API文档可以帮助解决80%开发中遇到的问题,剩余的20%你都可以GOOGLE到你想要的答案。

    8.如果以上方法均不能解决问题,那么更可能是你把问题想的太复杂,或许应该休息一下。

    虽然上面介绍了许多关于定位Bug的方法,但不得不说查找Bug总是费时而且让人头大的,为了避免陷入查找Bug的窘境,请在编写代码的时候谨记墨菲定律:任何可能出错的事情最终都会出错。这点程序上尤为明显。

    展开全文
  • 关于BUG定位

    2019-06-30 14:44:59
    虽然说没有无BUG的产品,但BUG的多少以及严重程度也标志着一个产品是否成熟与完善。 作为开发人员最关心的还是自己写的代码质量以及所产生BUG数量,BUG也是评定一个优秀程序员的重要指标。BUG伴随着程序员的职业生涯...

    版权声明:本文为神州灵云作者的原创文章,未经神州灵云允许不得转载。

    本文作者:Jack

    所谓好的产品我认为要具备这几点:1、对用户产生价值;2、操作简单;3、尽量不产生BUG。虽然说没有无BUG的产品,但BUG的多少以及严重程度也标志着一个产品是否成熟与完善。

    作为开发人员最关心的还是自己写的代码质量以及所产生BUG数量,BUG也是评定一个优秀程序员的重要指标。BUG伴随着程序员的职业生涯,与其相爱相杀,生产它解决它。当你在使用一个产品功能时结果不是自己所预期或者升级产品后相同的功能不能用了,那99%可能不是设计如此,而是程序员生产了一个BUG,解决它就要先定位它,找到根本原因对症下药,下面我们就以来看看怎么定位BUG。

    产品的BUG可以划分成很多种,今天我们主要分两大类来进行说明:1、前端BUG;2、后台BUG。

    一、前端BUG的定位说明
    此类BUG一般还是比较好定位和解决的,先来说一下如何定位问题。
    如何定位:

    1. 打开Chrome的“检查”->“控制台(Console)”,如果有问题可能会看到如下图的红色提示(当然并不是所有的红色提示都是错误)。
      1.1.jpg
      1.2.jpg
    2. 学会Debug,此类问题一般是排除数据的正确性以及业务逻辑而使用到的,打开浏览器的Sources,左侧为源文件包括页面、js、css等,找到目前访问的需要排障的资源文件,一般数据和逻辑业务代码会使用js代码写,此时可以在相应的位置点击左键设置断点,然后重新执行一下功能,那么程序就会从当前设置的断点执行,每执行一步可以看到当前执行的逻辑以及数据值。
      2.jpg
      \color{red}{产生原因:}
    1. 缓存导致的BUG
      这一类BUG的出现原因一般是因为升级导致的,其表现一般是界面上样式的显示问题,比如:(1)修改了功能升级以后没有按预期的显示;(2)某个功能显示有问题。
      解决:(1)清空一下浏览器缓存;(2)清除Local Storage或Session Storage或Cookies。

    2. 程序员生产的BUG
      此类问题的产生一般是程序员的粗心或者是对业务逻辑的理解不全面导致的。
      解决:定位问题以后需要具体问题提供解决方案。

    二、后台BUG的定位说明

    如果BUG是后台产生的定位起来相对就比较麻烦了,一般需要看对应的日志,从日志的信息来分析定位,相关的日志文件可大致分以下几种:(1)Tomcat日志;(2)数据库日志

    1. 如何查看Tomcat日志来定位问题
      由于程序的后台所有日志基本都输出到Tomcat中,所以导致Tomcat的日志输出比较快,如果查看方法不适当可能就会错过重要信息。一般我们先用tail -f catalina.out来实时输出日志信息(此时最好打几行空行进行区分),然后从界面进行相关功能的操作,操作完成后马上查看日志的输出,一般同时出现多行缩进比如下图肯定就是后台出现了BUG,此时前面几行是比较有用的信息,提示了问题发生在哪个类中,出现的行数等重要信息。

    知道问题产生的类和行数就可以看源码来具体进行问题的分析了。
    3.jpg
    另外如果出现多个缩进行的时候,一般是不缩进的这行以及下面几行是关键的信息。
    4.jpg
    2. 如何查看数据库日志来定位问题

    查看日志的方法和Tomcat日志顺序相同,一般如果数据库出问题的表现有这几点:
    (1) 程序连不上数据库,可能数据库配置改了;
    (2) 界面没有数据,可能数据库插入失败;
    (3) 界面操作数据查询比较慢,可能索引有问题;
    5.jpg

    解决: 对于第一个和第二个问题比较好解决,数据库提示的比较明确,对于第三个问题就需要用explain命令来进行更深入的分析了,这里就不展开讨论了。

    \color{red}{结束语:}

    以上比较浅的说明了对BUG的定位,当然最主要的还是在实际开发中尽可能的多进行完善的功能测试让BUG在初期就解决掉。
    神州灵云二维码.png

    展开全文
  • 身为测试工程师,总有一道绕不过去的坎就是定位bug,这其实是非常花费时间的。 也许有很多人不以为然,觉得无非就是发现bug后提交bug管理系统,描述操作步骤,预期结果和实际结果哪里不一致,然后...
  • 海思一名验证牛人写的验证总结,个人感觉写得还行,当然,里面一些比较偏激的观点可以不采纳。这篇文章可以作为IC初从业人员的参考文档。
  • 软件测试之BUG分析定位概述(QA如何分析定位BUG

    万次阅读 多人点赞 2016-05-30 18:11:14
    你是否遇到这样的场景?QA发现问题后找到DEV说: 不好了,你的程序出问题了! DEV(追查半小时之后): 唉,是你们测试环境配置的问题 唉,是你们数据不一致 唉,是你们**程序版本不对 ... 唉,是**产品线的问题 ...
  • 如何进行bug定位

    千次阅读 2019-10-16 15:42:04
    Web前端常用的分析定位思路: 当你遇到一个与预期输出不符的情况时: 1.是否是浏览器设置问题? 2.是否是浏览器cache的问题? 3.在其他浏览器上是否可复现? 4.用其他数据是否可以复现? 5.是否是cookie相关的...
  • 如何使用fiddler分析bug

    千次阅读 2019-01-23 19:06:32
    手机设置代理,边操作APP边查看fiddler上数据 一般提bug时候开发需要上述接口地址,以及右侧返回结果
  • 测试对bug如何分析和定位

    千次阅读 2017-09-20 08:46:11
    功能测试 bug分析
  • 测试工程师之bug定位

    万次阅读 多人点赞 2017-09-26 20:24:39
    身为测试工程师,总有一道绕不过去的坎就是定位bug,这其实是非常花费时间的。 也许有很多人不以为然,觉得无非就是发现bug后提交bug管理系统,描述操作步骤,预期结果和实际结果哪里不一致,然后继续测试...
  • 有不少的新手程序员,刚开始都是从修BUG开始做起的。 修bug有助于熟悉项目,了解大概哪些类参与了执行线路,相互调用关系又是如何,结构设计上有什么特点。 对于新手程序员而言,在复杂代码中找BUG是一个...
  • web测试中,如何判断是前端的bug还是后端的bug呢?

    万次阅读 多人点赞 2019-01-23 16:25:57
    web测试中,如何判断是前端的bug还是后端的bug呢? 通常可以利用抓包工具来进行分析。可以从三个方面进行分析:请求接口,传参,响应。 1.请求接口url是否正确 如果请求的接口url错误,为前端的bug 2.传参是否...
  • 写代码很容易出现Bug,如何快速定位BUG出现的位置和原因,这里利用利用Try Catch将异常写入Log文件。 刚开始代码出现Bug,是通过单步调试或者断点调试,比较麻烦,后来将其写入Log文件,而且几乎每次都要写这个...
  • 之前测试其他产品的时候,由于业务逻辑相对简单,bug也不多,也就很少留意到这个问题,但是现在手头的项目让我对于bug定位的问题再也无法忽略。遂查了一些资料,再加上自己的理解,输出了这篇文章,谨以记录以及相互...
  • 软件测试之bug分析定位技巧

    万次阅读 2018-03-22 10:11:58
    1、web前端Web前端就是通常说的网页。互联网公司的前端一般包含如下内容:JavaScript、ActionScript、CSS、HTML(..ML)、Flash、交互式设计、视觉设计web前端测试可能发现的...现象 测试bug定位原因归类:测试环境...
  • 如何区分前端BUG和后台BUG

    千次阅读 多人点赞 2019-07-10 10:58:41
    这里先说定位问题的要求,定位问题要向深入,前提当然是对功能、产品的流程、开发方案、开发人员非常熟悉了,以我们部门为例,定位bug至少要到下面这种程度。 首先确定是界面显示问题还是功能问题 如果是界面问题,...
  • CUDA进阶第一篇:CUDA调试

    万次阅读 2019-09-23 10:11:04
    “初学CUDA,好不容易自己写完一段cuda代码,一运行,满屏的语法bug,语法bug还好说,竟然还有逻辑bug,逻辑bug怎么改啊,wtf!!” “从别人手里接到一段CUDA代码,WTF,为什么还有bug!!还没有注释!!没有...
  • 定位BUG之日志【巧妙的日志设计】

    千次阅读 2017-07-08 14:59:07
    定位生产问题,查看日志是基本技能,必须牢牢掌握 tail -f xxx.log grep -r 'traceID' *.log 不会这些命令的,可以考虑放弃JAVA。 当框架里代码层次特别深时,定位一个问题,相关日志显示的很凌乱,...
  • 测试人员怎样定位bug原因

    万次阅读 多人点赞 2018-07-23 09:42:45
    作为测试人员,和我们最常打交道的,莫属bug。当你发现bug后,会采取什么样的行动?是直接报出来,亦或找找问题原因? 不管是我们自己找到的,亦或是开发修复后告诉我们的,知道问题之所在总是好的。在本篇文章中,...
1 2 3 4 5 ... 20
收藏数 127,999
精华内容 51,199
关键字:

bug定位