对于测试遇到偶现的Bug,很多软件测试工程师的做法都是尽量的复现问题的步骤,在复现的过程,有的是录制视频或者打开日志,以便复现的时候,能捕捉到,定位问题,最后如果没有,那就先把问题登记Bug管理工具,观察几个版本,看是否再现,决定是否关闭。这个算是行业通用方法。
那如果是放到Android app 偶现闪退的Bug来讲,那要应该怎么闭环呢?首先对于闪退日志的日志的捕捉,大概有几种方法:
1.通过接入第三方sdk,如友盟,bugly等,出现闪退,日志上传,可以进行查阅;
2.在被测试app的代码增加一个闪退日志捕捉,然后可以直接在app的目录下产生一个以时间戳的日志文件,到时只要闪退了,直接把这个文件附到Bug里面即可;
3.就是通过adb捕捉,不管是通过adb logcat -v time -d >d:/11.txt,然后通过日志中的fatal和包名配置定位问题日志,另外也可以通过adb logcat -b crash 直接捕捉闪退日志。
以上 90%以上公司都是这种做法,这三种方法区别,就是前两种,你脱离了公司啥也不是,第三种就是你个人能力,走到哪里都通用;
好了,说了日志的捕获以后,这只是闭环关闭闪退日志Bug的第一步,当你提交了Bug并且附上了日志以后,先重复操作10多次,看能否复现,不能复现;接下来,开发会进行问题原因定位及修复,修复完,大部分很多开发就可能是随手标注已解决或者跟你说,记得是跟你说,可能什么问题,你到时测试下。这时就存在了坑,没在Bug里面标注产生这个问题的原因,复现步骤,以及影响的范围,你就无法通过问题原因进行分析,可能影响的范围,跟开发写的影响范围进行匹配或者补充,再着偶现闪退的问题,一定要用原来的版本根据开发提供的步骤,进行复现,看是否出现这个问题,然后再用解决的版本进行复现,是否解决,这样整体通过问题的复现关闭,修改影响范围的二次确认,才可以算是正确的回归关闭了这个问题,并且所有记录都在Bug管理工具,避免了以后背锅的可能。
整体关键词,就是提交Bug带日志,知道问题的复现步骤,知道问题的原因,知道复现步骤,分析影响范围,二次确认,回归测试,关闭。一切都在Bug管理工具进行操作。
以上,整体就是关于安卓app偶现闪退关闭的闭环动作。希望对测试同行在工作中或者面试有所帮助。如对您有帮助,欢迎“”官注威信顶跃好“ 测试一般不一般~