APP常见崩溃原因和测试方法整理

测试过APP的人都应该发现,app崩溃是一类非常常见的问题,很多时候还是致命性的,这就要求我们测试人员要尽最大可能去找出软件当中的缺陷,减少app崩溃出现的概率,这里我将收集到的关于针对APP崩溃测试的资料以及自己的工作经验整理如下:

一、APP中BUG的直接影响:App的Bug会直接影响用户的体验、App 商店的评级、用户的忠诚度,声誉等等...

二、App崩溃是非常常见的一类bug,例如很多时候我们正在使用某个Android的APP,正在使用着突然应用就停止响应,界面上弹出“强制关闭错误”的窗口需要强制关闭应用,而iOS的APP呢则很多使用就会出现闪退的现象,这些问题,我想都是很多人所遇到的,这些都是app常见的崩溃现象。因为现在市场是andriod手机的碎片化、造成了andriod手机更加容易出现APP的崩溃,通常在网络异常时APP上还在进行数据交互,即会出现崩溃、可能的原因多种,有可能是代码中存在多余空格、程序员对该段代码的处理欠佳,未做异常处理等等;而 iOS中常见的App崩溃大多已闪退的形式出现,这些异常在最坏的情况下,不仅影响本APP的使用也可能会导致系统故障,操作系统崩溃,整个APP无法在继续使用,用户不得不卸载此APP。

三、App的测试与web端软件测试相比,所增加复杂性:

a、操作系统: 大量的设备,各种操作系统,目前使用最多的操作系统有:Android、iOS、windows、blackberry等等,它们之间的应用软件互不兼容。

b、设备:触摸式和非触摸式设备、有限的内存容量,电池耗电量,屏幕尺寸、分辨率等。

c 、网络:不同的网络和运营商,目前我国的三大运营商就有电信、联通和移动,不同的网络制式,如GSM、CDMA、3G等,在不好或无网络的情况下的App行为。

d、可用性:方向,触摸,缩放,分页和导航的局限性,各种干扰,如来电,来电短信,闹钟,和低电量警报等。

四、APP常见崩溃的原因:

设备碎片化:由于设备极具多样性,App在不同的设备上可能有表现不同。

  带宽限制:带宽不佳的网络对App所需的快速响应时间可能不够。
  网络的变化:不同网络间的切换可能会影响App的稳定性。
  内存管理:可用内存过低,或非授权的内存位置的使用可能会导致App失败。
  用户过多:连接数量过多可能会导致App崩溃。
  代码错误:没有经过测试的新功能,可能会导致App在生产环境中失败。
  第三方服务:广告或弹出屏幕可能会导致App崩溃。

五、App崩溃的测试用例设计:
  1 验证在有不同的屏幕分辨率,操作系统和运营商的多个设备上的App行为。
  2 用新发布的操作系统版本验证App的行为。
  3 验证在如隧道,电梯等网络质量突然改变的环境中的App行为。
  4 通过手动网络从蜂窝更改到Wi-Fi ,或反过来,验证App行为。
  5 验证在没有网络的环境中的App行为。
  6 验证来电/短信和设备特定的警报(如警报和通知)时的App行为。
  7 通过改变设备的方向,以不同的视图模式,验证App行为。
  8 验证设备内存不足时的App行为。
  9 通过用测试工具施加载荷验证App行为。
  10 用不同的支持语言验证App行为。
  显然,还会有更多的导致App崩溃的App特定场景。

时间: 2024-11-25 14:40:21

APP常见崩溃原因和测试方法整理的相关文章

app经常崩溃原因解析【转帖】

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

Android APP native 崩溃分析之令人困惑的 backtrace

完美无缺的代码逻辑,一定能产生完美无缺的程序吗?答案是否定的.从软件的层面来看,也许只有二进制才永远不会欺骗你. 现象 近期,业务方反馈了一个奇怪的崩溃问题,认为信息不足,无法解决. Signal: 11 (SIGSEGV), Code: 1 (SEGV_MAPERR) r0 993ff520 r1 dc3170c4 r2 00000000 r3 dabe3e08 r4 993ff520 r5 00000005 r6 00000290 r7 000007ac r8 e83253a0 r9 000

coreseek常见错误原因及解决方法

coreseek常见错误原因及解决方法 Coreseek 中文全文检索引擎 Coreseek 是一款中文全文检索/搜索软件,以GPLv2许可协议开源发布,基于Sphinx研发并独立发布,专攻中文搜索和信息处理领域,适用于行业/垂直搜索.论坛/站内搜索.数据库搜索.文档/文献检索.信息检索.数据挖掘等应用场景,用户可以免费下载使用 本文为大家整理了coreseek/sphinx中文检索引擎的常见问题和解决方法,感兴趣的同学参考下. Coreseek 是一款中文全文检索/搜索软件,以GPLv2许可协

VS2005(vs2008,vs2010)使用map文件查找程序崩溃原因

VS 2005使用map文件查找程序崩溃原因 一般程序崩溃可以通过debug,找到程序在那一行代码崩溃了,最近编一个多线程的程序,都不知道在那发生错误,多线程并发,又不好单行调试,终于找到一个比较好的方法来找原因,通过生成map文件,由于2005取消map文件生成行号信息(vc6.0下是可以生成行号信息的,不知道microsoft怎么想的,在2005上取消了),只能定位在那个函数发生崩溃.这里可以通过生成cod文件,即机器码这一文件,具体定位在那一行崩溃. 首先配置vc2005生成map文件和c

Android中app卡顿原因分析示例

在知乎回答了一个“为什么微博的app在iPhone比Android上流畅”的问题.后面部分是一个典型的动画卡顿的性能分析过程,因此帖在这里.有编程问题可以在这里交流.知乎链接. ========================================================= 我来说下我所知道的事情.我不知道iOS为什么流畅,但我知道一些Android为什么不流畅的原因. 首先,就题主所说的问题,我用iPad和小米Pad对比了一下微博滑动滚屏这件事情(2014年8月10日目前微博

托管香港服务器常见故障原因分析

1.应用服务无法正常运行 当客户把香港服务器托管后,会在服务器上运行多种应用服务,比如WWW服务.Mail服务.Ftp服务等等.提供的服务类型越多,那么出问题的可能性就越大.当出现某种服务无法启动或死机时,比如sql查询过于频繁容易导致数据库挂掉.可以通过远程重启这项服务,经过重启机器或是相关处理后即可很快恢复正常. 2.服务器硬件故障 服务器硬件可能出现问题的地方,主要有主板.内存.硬盘等方面.比如大量的读写,容易造型硬盘坏道.在排除其它可能的原因后,经技术人员检查出是服务器硬件问题,则需客户

VS2005(vs2008,vs2010 VS2012)使用map文件查找程序崩溃原因

转载http://blog.csdn.net/luxiaoyu_sdc/article/details/6458872 一般程序崩溃可以通过debug,找到程序在那一行代码崩溃了,最近编一个多线程的程序,都不知道在那发生错误,多线程并发,又不好单行调试,终于找到一个比较好的方法来找原因,通过生成map文件,由于2005取消map文件生成行号信息(vc6.0下是可以生成行号信息的,不知道microsoft怎么想的,在2005上取消了),只能定位在那个函数发生崩溃.这里可以通过生成cod文件,即机器

DELPHI XE5 UP2 无真机输出 APP并转换为IPA(实践整理)

1.在Mac上配置开发环境(具体步骤请百度)   XCODE5.1+IOS7.1SDK+COMMAND LINE TOOLS   安装PlatformAssistant   买一个真机调试账号(实际测试没有用真机,直接运行输出即可) 2.在Windows PC上配置开发环境(具体步骤请百度)   给Mac创建一个Connection Profile   给连接到Mac的iOS Device在开发系统中添加一个SDK 3.写个程序,选择IOS 设备调试模式,按F9运行.出现"没有连接真机"

Linux下利用coredump技术追查进程崩溃原因

原文链接:https://blog.csdn.net/u014585564/article/details/68063269 最近项目中出现了一个问题,服务器端程序会突然崩溃退出,我们采取了coredump技术以找到崩溃原因,即确定进程退出时正在执行的函数是哪个,其状态如何. 如果系统开启了coredump,准确的说如果当前的shell环境开启了coredump,当前shell环境下的程序崩溃退出时,会把当时进程的栈的内存状态写入core文件.使用gdb可以查看这个core文件中保存的栈的状态,