对于测试遇到偶现的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偶现闪退关闭的闭环动作。希望对测试同行在工作中或者面试有所帮助。如对您有帮助，欢迎""官注威信顶跃好" 测试一般不一般~