app 崩溃测试 （转：CSDN 我去热饭）

首先，崩溃有几种状况：

• 闪退
• 提示中止运行
• 无响应

( 不一样状况虽然没有严格意义上区分开引发缘由，可是都有侧重。在以后的工做中，我会实时补充统计。)

 

1.接口返回值

［直接缘由］：app没法解析接口返回值／获取不到要获取的参数／参数类型不对 致使客户端代码报错
［引发缘由］：脏数据／网络问题致使接口超时或漏了数组元素／先后台没有统一参数类型标准／参数名错误／实体消失 
［解决办法］：在网络顺畅/不畅状况下抓包，对着api文档一个一个的参数对比，返回值有数组能够横向对比，多是其中某个元素内的某个参数和其余元素内的这个参数有内容不一样/类型不一样／为空/不存在/规范不一样。
［测试方法］：首先要从2个角度考虑。1：后台不要返回这种脏数据，或者有脏数据要进行处理再返回给app。2：app要有必定的容错性，不能由于一个参数这么一点小事就致使崩溃（低级bug瞬间升级到致命bug）。因此要从俩边测试。1：先进行正常的接口测试，保证正常数据返回没有问题。再经过操做数据库或其余手段进行构造脏数据，测试服务器的错误处理能力。2：再利用mock或抓包工具，强行修改返回值，测试app端的容错能力。用脚本或手动把全部/特定 的参数进行更改，包括 类型/内容长度／为空／删除掉／不符合规范 等状况来测试app的容错性和成熟性。
其次网络问题也是有几率引发崩溃，就是在网络环境很恶劣 或变更频繁的状况下进行全部接口测试，保证返回值全面完整。观察接口返回是否有拉下的数组元素。由于app的超时断定 和服务器的超时断定是不统一的。可能接口超时要60秒，可是app只等待10秒钟，10秒没到就断定失败了，但这不是致使崩溃的缘由。致使崩溃的缘由在于服务器返回超时后（不是无网络，不是关掉wifi或数据流量），接口报什么http状态码，通常是502，app原则上是要对全部接口502都有对应处理和提示，但实际状况是，不少接口有提示不崩溃，更多的接口会崩溃。因此测试的时候要构造特殊环境，来让因此接口依次超时。方法能够是在抓包工具上打断点，而后不进行继续操做，挺着看app最终会不会崩溃。
实体消失问题致使崩溃，实际上是接口规范上的缘由，当由于前后操做，页面未及时刷新的状况，致使app对一个已经在后台数据库抹除的实体或关系进行访问时，后台又刚好没考虑过此状况，致使后台返回结果不可预料，app又没有抓取某种异常返回，致使崩溃。测试办法就是测试点中计划好全部这种能够操做到消失实体的状况，来进行模拟测试。或者抓包时强行更改请求实体，来达到请求一个不存在实体的场景，观察服务器如何处理并返回，app又是否会所以而崩溃。

 

2.内存问题

［直接缘由］：客户端app代码报错。
［引发缘由］：兼容很差／内存不足/内存泄露形成app开辟内存空间失败/内存泄漏。
［解决办法］：提醒用户更换手机或关掉后台其余app进程，崩溃的app要进行全面测试，定位到具体什么操做致使崩溃。
［测试方法］：先进行兼容性测试，用不一样的操做系统/手机型号／品牌／系统版本／蓝牙版本去执行一些跟写入读取有关的功能的用例。用emmagee监控app，看到各类操做后，占用的内存是否超过预期。让开发规范代码，及时释放掉占用的存储空间。手机安装不少app，而后后台都打开，而后再运行自家app，观察其是否会崩溃频繁，能够用monkey测试（虽然monkey没法代表究竟是什么缘由引发崩溃，可是能够经过 观察后台干净／后台运行过多app 这俩种状况下屡次测试，看是否由于后台运行过多app 就致使monkey崩溃几率高。而判断出大体自家app的生存能力）其余待补充。

 

3.下标越界问题

［直接缘由］：客户端app代码报错。
［引发缘由］：须要操做的元素已经消失/代码错误，超出实体数量/读取or写入本地文件或缓存时的IO错误
［解决办法］：调查引发崩溃的具体操做步骤，而后提交开发解决，前端代码容错率须要提升。
［测试方法］：边界值测试为核心思想，测试正常状况有关数量的功能用例
要进行代码review1：保证代码没有错误，循环中没有超出实体数量。2：保证代码容错性高，每一个循环都要有越界异常捕获并处理。／
要进行手动破坏性测试，1：如删除本地文件，好比app要调取本地缓存的4张图片，在app刚要调用的时候，已经选择好的时候，切换到本地文件管理中，删掉其中一个，那么app就会访问到一个不存在的文件，会引起越界等代码报错。2：破坏掉这个文件。那么app就会读取的时候发生io错误。等状况来进行测试。

 

4.渲染不及时问题

［直接缘由］：控件生成/调用受阻，致使前端app代码报错
［引发缘由］：渲染过慢，操做过快，兼容性很差
［解决办法］：让用户换手机，或慢点点，从新设计避免用户连点形成的操做过快，从新设计减轻页面加载渲染负担，异步处理
［测试方法］：对复杂／卡顿页面进行快速操做来让本不该该出如今一块儿的俩个控件出如今一块儿，或用monkey最大速度测试。待补充

 

5.权限问题

［直接缘由］：客户端未对无权限状况处理，致使代码报错
［引发缘由］：用户访问未获取到系统相关权限的功能，客户端又未对此状况进行处理
［解决办法］：修改崩溃bug，设计此状况的处理机制，如提示用户去手动开权限，或自动退出等状况。
［测试方法］：关掉app全部的系统权限，而后去访问全部系统权限相关的页面和功能。例如：相册，照相，定位，开启wifi，蓝牙，gps 等等权限。

 

6.第三方问题

［引发缘由］：第三方广告的忽然弹出／其余app分享进来和出去／各类第三方app的强行抢镜（如抢红包提醒）
［测试方法］：在各个页面，手动触发大多数app的 或 本app的外接 广告来测试。用其余主流app测试分享，或自家app分享出去再回来看是否已经被退出。忽然收到其余app的强制提醒。

 

7.系统高优先级app问题

［直接缘由］：致使自家app忽然被挂起或放置后台
［引发缘由］：忽然来电话，忽然收短信，闹钟，会议提醒系统原生app等状况
［测试方法］：在各个页面，功能运行前中后。进行接电话／短信来测试。主要测试是否会影响电话/短信，电话/短信结束后 app是否能恢复到以前的页面,仍是已经闪退被强关了。

 

8.设备视图方向问题

［直接缘由］：因横竖屏致使app崩溃
［解决方法］：重启app
［测试方法］：
1.先横，再开app
2.先竖，再开app
3.开app后，各类页面上，功能前中后，横屏／竖屏来回切换

 

9.多语言问题

［直接缘由］：各类语言致使崩溃
［测试方法］：
1.先切换成各国语言，再开app进行各类功能用例测试
2.先开app，再来回切换各国语言进行测试

 

10.其余代码错误

［直接缘由］：客户端app代码错误
［引发缘由］：各类异常操做，正常操做
［解决办法］：adb shell logcat抓日志，后台查看崩溃日志
［测试方法］：执行所有测试用例便可。

 

11.弱网问题

［直接缘由］：客户端没法解析json返回值
［引发缘由］：网络差，json串过长
［解决办法］：体型用户换更快网络，客户端对此操做增长等待时间。接口返回进行异步处理。增长翻页功能。
［测试方法］：用抓包工具模拟出弱网环境，包含丢包率，稳定性等元素。而后对接口返回值构造超长数据进行测试。