武汉软件测试培训
达内武汉中心

15827352908

热门课程

小技巧!关于编程中的BUG

  • 时间:2018-04-12 14:25
  • 发布:武汉软件测试培训
  • 来源:互联网

解决Bug是编程人员的天职,甚至有人这么认为:开发人员的能力可以依据他能决解Bug的复杂程度来评定。简单的Bug大多数程序员是靠臆断来解决的,但是当Bug隐藏在代码的最深处,臆断不能够解决问题的时候,或许我们就得依靠些许技巧而不是重启。

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

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

3.臆断错误信息,通过系统打印的错误堆栈信息来推测错误原因并加以解决。好吧,这里我实在讽刺大多数不精明的程序员(同时也包括我自己)在看到错误信息后,迫不及待的享受解决Bug的快感,并不仔细查看堆栈信息,往往只解决了表面问题而忽略了更深层次问题。

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的窘境,请在编写代码的时候谨记墨菲定律:任何可能出错的事情最终都会出错。这点程序上尤为明显。

更多武汉软件测试培训相关资讯,请扫描下方二维码

上一篇:谈软件测试人员的发展方向
下一篇:测试员应该如何和开发人员沟通

听说女生适合学软件测试?

软件开发和软件测试原来不一样啊!

性能测试及其未来前景

选择城市和中心
贵州省

广西省

海南省

有位老师想和您聊一聊