测试过APP的人都应该发现,app崩溃是一类非常常见的问题,很多时候还是致命性的,这就要求我们测试人员要尽最大可能去找出软件当中的缺陷,减少app崩溃出现的概率,这里我将收集到的关于针对APP崩溃测试的资料以及自己的工作经验整理如下: 一.APP中BUG的直接影响:App的Bug会直接影响用户的体验.App 商店的评级.用户的忠诚度,声誉等等... 二.App崩溃是非常常见的一类bug,例如很多时候我们正在使用某个Android的APP,正在使用着突然应用就停止响应,界面上弹出“强制关闭错误”的

我们的日常生活中对移动设备越来越多的使用意味着移动App测试这个主题已成为需要考虑的一个无法避免的问题.根据最近的调查研究,用户难以容忍有bug的移动App. 移动App Bug的影响是用户体验差.App的商店评级下降.用户换用竞争对手的App,声誉和信誉损失.最后销售量减少,如果它是一个付费App的话. 移动App测试与传统台式机测试相比有一定的复杂性.这些复杂性可以被分类为: 环境(大量的设备,各种移动OSs,适应频繁OSs变化) . 设备(触摸式和非触摸式设备,有限的内存容量,电池耗电量)

1.如何追踪app崩溃率,如何解决线上闪退 当 iOS设备上的App应用闪退时,操作系统会生成一个crash日志,保存在设备上.crash日志上有很多有用的信息,比如每个正在执行线程的完整堆栈 跟踪信息和内存映像,这样就能够通过解析这些信息进而定位crash发生时的代码逻辑,从而找到App闪退的原因.通常来说,crash产生来源于两种问 题:违反iOS系统规则导致的crash和App代码逻辑BUG导致的crash,下面分别对他们进行分析. 违反iOS系统规则产生crash的三种类型: (1) 内

iOS系统app崩溃日志手动符号化步骤: 1.在桌面建立一个crash文件夹,将symbolicatecrash工具..crash文件..dSYM文件放到该文件夹中 a.如何查询symbolicatecrash路径位置? 执行命令:find /Applications/Xcode.app -name symbolicatecrash -type f 然后将symbolicatecrash复制一份    例如:Xcode7.3的symbolicatecrash路径 /Applications/Xc

我们的日常生活中对移动设备越来越多的使用意味着移动App测试这个主题已成为需要考虑的一个无法避免的问题.根据最近的调查研究,用户难以容忍有bug的移动App. 移动App Bug的影响是用户体验差.App的商店评级下降.用户换用竞争对手的App,声誉和信誉损失.最后销售量减少,如果它是一个付费App的话. 移动App测试与传统台式机测试相比有一定的复杂性.这些复杂性可以被分类为: 环境(大量的设备,各种移动OSs,适应频繁OSs变化) . 设备(触摸式和非触摸式设备,有限的内存容量,电池耗电量)

源代码获取请到github:https://github.com/DrJia/AndroidLogCollector 已经做成sdk的形式,源代码已公开,源代码看不懂的请自行google. 假设想定制适应自己app的sdk请自行fork. AndroidLogCollector android app崩溃日志收集sdk 1.0 作者:贾博士 崩溃日志收集方法: 1.LogCollector是lib包,在须要加入崩溃日志sdk的project中导入此包. 2.导入lib后,在自己的project的

每天学习一点点 编程PDF电子书.视频教程免费下载:http://www.shitanlife.com/code 最近用H5页面做了个安卓的项目,但是在H5页面中长按文字内容,会导致APP崩溃掉... 查了下资料,觉得可能是长按触发了某些默认的事件,比如长按复制.长按选中.长按打开菜单等浏览器的一些事件,于是试着禁用掉长按事件,解决. 直接引入CSS,禁止掉长按事件 *{ -webkit-touch-callout:none; /*系统默认菜单被禁用*/ -webkit-user-select:

一些通用的触发移动App崩溃的测试场景,如下: 1 验证在有不同的屏幕分辨率,操作系统和运营商的多个设备上的App行为. 2 用新发布的操作系统版本验证App的行为. 3 验证在如隧道,电梯等网络质量突然改变的环境中的App行为. 4 通过手动网络从蜂窝更改到Wi-Fi ,或反过来,验证App行为. 5 验证在没有网络的环境中的App行为. 6 验证来电/短信和设备特定的警报(如警报和通知)时的App行为. 7 通过改变设备的方向,以不同的视图模式,验证App行为. 8 验证设备内存不足时的Ap

本文来自微信开发团队yanyang的技术分享. 1.引言 相信大家都遇到过一段特殊文本可以让iOS设备所有app闪退的经历.前段时间大年初一,又出现某个印度语字符引起iOS11系统奔溃,所幸iOS版微信客户端做了保护并没有引起太大问题(字符处理这类技术问题,其实曾在Android版微信上导致过严重的用户体验危机,感兴趣的可以看看文章<微信团队披露:微信界面卡死超级bug“15....”的来龙去脉>). 一般来说,特殊字符闪退是系统漏洞引起,只要更新系统就行.但大部分用户不愿意更新系统,而苹果也

以前经常遇到APP内部异常情况下的Exception,最初是通过try catch这样的方式处理:但是APP上线后,用户在特地的情况下触发 了某些Exception,当然这些Exception从理论和正常思维上考虑是不可能存在的,查找也就无从下手.. 后来通过实现UncaughtExceptionHandler类来对异常进行捕获,并把日志记录本地,下次打开APP后发送到后台,然后这样的日志 来维护.通过这种方式,虽然可以更友好的给用户提示APP崩溃,然而这种方式只能对主线程进行捕获,非主线程的E

[原创]App崩溃率统计工具推荐 1 友盟(推荐) 友盟是一款比较成熟的工具,同时也可以展示留存,日活,事件等. 2 Bugly   腾讯的bugly统计数据也算是比较早的,可惜后续维护比较弱,功能与友盟相差太多. 3 听云   专业的性能监控工具

首先,崩溃有几种情况: 闪退 提示停止运行 无响应 ( 不同情况虽然没有严格意义上区分开引起原因,但是都有侧重.在之后的工作中,我会实时补充统计.) 1.接口返回值 ［直接原因］:app无法解析接口返回值/获取不到要获取的参数/参数类型不对 导致客户端代码报错 ［引起原因］:脏数据/网络问题导致接口超时或漏了数组元素/前后台没有统一参数类型标准/参数名错误/实体消失 ［解决办法］:在网络顺畅/不顺畅情况下抓包,对着api文档一个一个的参数对比,返回值有数组可以横向对比,可能是其中某个元素内的某个

漫谈:从APP崩溃率标准,到Monkey介绍拓展Maxim,及Jenkins自动化配置,持续集成获取崩溃日志 1.APP崩溃率标准 开发或测试app的同学,对于app崩溃肯定非常熟悉,频繁的线上崩溃属极度严重事故,肯定会给团队和个人带来KPI的低下,防患于未然就成了重中之重 1.1 常见的检测崩溃手段 业务测试,普通测试,环境版本兼容性测试,开发调试中遇到 健壮性测试:[数据状态异常.http请求状态异常.网络状态异常(网络波动).大数据.特殊场景.等等] monkey测试 友盟等线上检测工具监

前言 我们在开发App过程中,因为连接到控制台,所以遇到问题会很容易找到问题代码.但是对于线上的App出现Crash的时候,我们不可能通过这种方式,也不现实,所以我们只能通过收集Crash信息,来解决Bug.而这种收集Crash信息并且分析定位到具体代码的第三方SDK很多.但是今天我们来自己实现一下. 收集 Crash 信息 Apple提供了NSException类来帮助我们收集异常信息. NSException is used to implement exception handling a

要分析崩溃日志,首先需要保留发布时的编译出来的.xcarchive文件.这个文件包含了.DSYM文件. 我一般的做法是,发布成功后,把这个文件.xcarchive直接提交到代码版本库对应的版本分支里,这样就不会搞丢了. 这个文件在哪呢?打开XCode->菜单Window->Organizer,在编译成功的文件上右键,就能打开了. 两种比较麻烦的方法. 第一种方法: 使用dwarfdump命令 dwarfdump --uuid xx.app.dSYM     用来得到app的UUID.dwarf

获取崩溃日志的几种方法: 1.当用户抱怨闪退时,你可以要求他让设备与iTunes同步,设备与电脑上的iTunes Store同步后,会将崩溃日志保存在电脑上(路径:Mac OS X:~/Library/Logs/CrashReporter/MobileDevice/)到上述位置把崩溃日志下载下来,然后通过电子邮件发送给你:用这个方法获取崩溃日志时,你必需尽量获取用户设备生成的所有崩溃日志.因为崩溃日志越多,就越容易诊断问题所在. 2.如果你装了Xcode,也能很容易通过Xcode从你的设备上获得

android 引用:http://blog.csdn.net/caiwenfeng_for_23/article/details/41184353 package com.tan.abnormalrestart; import java.lang.Thread.UncaughtExceptionHandler; import android.app.Application; import android.content.Intent; public class AppContext exten

http://blog.csdn.net/totogo2010/article/details/39892467 要分析崩溃日志,首先需要保留发布时的编译出来的.xcarchive文件.这个文件包含了.DSYM文件. 我一般的做法是,发布成功后,把这个文件.xcarchive直接提交到代码版本库对应的版本分支里,这样就不会搞丢了. 这个文件在哪呢?打开XCode->菜单Window->Organizer,在编译成功的文件上右键,就能打开了. 两种比较麻烦的方法. 第一种方法: 使用dwarfd

常见马虎导致崩溃 1 数组越界: 2 多线程问题,在子线程刷新UI: 3 主线程无响应,主线程超过系统规定的时间没有响应,就会被watchdog杀掉: 4 野指针: 崩溃信息的收集却并没有那么简单.因为,有些崩溃日志是可以通过信号捕获到的,而很多崩溃日志却是通过信号捕获不到的. 第三方崩溃监控工具: PLCrashReporter Fabric或者Bugly 这些都是通过信号捕获崩溃日志,还有写通过信号捕捉不到的场景: 1 backgroud Task模式,App退到后台,如果在后台执行时间太长

这2天,在测APP兼容性时,遇到APP奔溃闪退的情况.将问题反馈给开发后,开发自己调试后,没有复现.由于又是远程,base地不在一块,我总不能把手机寄过去吧,那也太费事了. 所以就想到,提供明确的报错日志,让开发定位问题,岂不是就很方便了,也解决了远程的问题. 那如何抓取到Crash日志呢,我又没开发调试工具,也不可能在短时间内搭建一套开发环境.寻思答案后,最终得到了完美解决,且听细细道来. 了解Crash 我们先来简单了解下Crash:Crash,就是崩溃.anr(Application No

崩溃输出日志 2017-08-29 14:53:47.332368+0800 HuiDaiKe[2373:1135604] This application is modifying the autolayout engine from a background thread after the engine was accessed from the main thread. This can lead to engine corruption and weird crashes. Stack