如果你测试App，突然崩溃了，你该怎么做？
回答·46
最热
最新
- 1 首先记录崩溃的时间，版本，账号，操作步骤，（事后回想往往有遗失的因素） 2 使用工具获取日志（adb, Android studio 等） 3 分析日志和操作步骤 4 尽力复现崩溃 5 报告异常
- 测试过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端软件测试相比，所增加复杂性： 操作系统： 大量的设备，各种操作系统，目前使用最多的操作系统有：Android、iOS、windows、blackberry等等，它们之间的应用软件互不兼容。 设备：触摸式和非触摸式设备、有限的内存容量，电池耗电量，屏幕尺寸、分辨率等。 网络：不同的网络和运营商，目前我国的三大运营商就有电信、联通和移动，不同的网络制式，如GSM、CDMA、3G等，在不好或无网络的情况下的App行为。 可用性：方向，触摸，缩放，分页和导航的局限性，各种干扰，如来电，来电短信，闹钟，和低电量警报等。 四、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特定场景。
- 不管何时遇到 crash，首先第一抓 log，如果自己有分析能力，先自己定位是什么原因导致 crash，并记录问题同时知会开发。尝试当时使用场景和操作步骤进行复现，如果能复现，把复效条件告诉开发，方便其定位问题。还要关注当前测试属于什么阶段，如果在内部测试环境阶段，则内部跟踪解决闭环即可，如果再上线后遇到必现 crash，需要复盘回朔，是属于设计漏测还是执行漏测，总结经验以免再犯同样的错误。
- 跟着奔溃呗。😌😌😌
- 这个呢可以用抓包工具连接手机，做一下复现操作进行抓包定位。再一个就是看看是不是没有内存了或者是开发在更新代码
- 立刻连上adb，把日志拉出来，记录刚刚操作步骤，尽量试试能不能重现，然后把问题出现步骤以及时间点告知开发，日志发给开发。
- 1.第一时间，最快速度尽可能完整的获取对应 log，包括系统的和 app 的，或者其他特定针对性的。 2.获取 log 的同时，快速记录崩溃现象和信息。能抓图的抓图，能拍照的拍照，确认硬软件配置/版本信息…回忆崩溃前做了什么操作，是否有异常现象表现出来（比如突然花屏，白屏，闪烁，一闪而过的提示……），是否有外接装置（连接电脑？配对设备？…） 3.快速对比，和团队内其他测试确认，确认为已知崩溃，还是新出现的？ 4.根据上三步得到的信息综合，据实上报问题并与开发初步沟通（防止沟通错漏）。如为已知则正常流程处理（跟进/观察/重开/复验…） 5.根据掌握的信息，尝试复现崩溃。如能找到复现路径，第一时间与团队内及开发沟通，同时复现路径系统上报。 6.如能力允许，与开发一起解读 log，有的放矢的确认方向，查找问题。 接下来，就是日常正常步骤了。
- 链接手机，打开settings，设置debug mode，运行app，重复崩溃程序，在Android Studio或者iOS development tool中查看debugger error messages崩溃时的情况 如果不能重复崩溃程序，手机进入该app的文档，查看任何隐藏.log文件，留意error messages
- 使用 abd logcat -b all >error.log 导出错误信息 或者用 adb logcat *:E 显示到终端界面
- 1、记录操作流程 2、记录运行环境 3、获取崩溃日志 后面就是找原因，解Bug。