4.app 测试和 web 测试有什么区别？
WEB 测试和 App 测试从流程上来说，没有区别。
都需要经历测试计划方案，用例设计，测试执行，缺陷管理，测试报告等相关活动。从技术上来说，WEB 测试和 APP 测试其测试类型也基本相似，都需要进行功能测试、性能测试、安全性测试、GUI 测试等测试类型。
他们的主要区别在于具体测试的细节和方法有区别，比如：性能测试，在 WEB测试只需要测试响应时间这个要素，在 App 测试中还需要考虑流量测试和耗电量测试。
兼容性测试：在 WEB 端是兼容浏览器，在 App 端兼容的是手机设备。而且相对应的兼容性测试工具也不相 同，WEB 因为是测试兼容浏览器，所以需要使用不同的浏览器进行兼容性测试（常见的是兼容 IE6，IE8，chrome，firefox）如果是手机端， 那么就需要兼容不同品牌，不同分辨率，不同 android 版本甚至不同操作系统的兼容。（常见的兼容方式是兼容市场占用率前 N 位的手机即可），有时候也可 以使用到兼容性测试工具，但 WEB 兼容性工具多用 IETester 等工具，而 App 兼容性测试会使用 Testin 这样的商业工具也可以做测试。
安装测试：WEB 测试基本上没有客户端层面的安装测试，但是 App 测试是存在客户端层面的安装测试，那么就具备相关的测试点。
还有，App 测试基于手机设备，还有一些手机设备的专项测试。如交叉事件测试，
操作类型测试，网络测试（弱网测试，网络切换）
交叉事件测试：就是在操作某个软件的时候，来电话、来短信，电量不足提示等外部事件。
操作类型测试：如横屏测试，手势测试
网络测试：包含弱网和网络切换测试。需要测试弱网所造成的用户体验，重点要考虑回退和刷新是否会造成二次提交。弱网络的模拟，据说可以用 360wifi 实现设置。
从系统架构的层面，WEB 测试只要更新了服务器端，客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是 APP 端是不能 够保证完全一致的，除非用户更新客户端。如果是 APP 下修改了服务器端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍
还有升级测试：升级测试的提醒机制，升级取消是否会影响原有功能的使用，升级后用户数据是否被清除了。
5.android 和 ios 测试区别？
App 测试中 ios 和 Android 有哪些区别呢？
1.Android 长按 home 键呼出应用列表和切换应用，然后右滑则终止应用；
2.多分辨率测试，Android 端 20 多种，ios 较少；
3.手机操作系统，Android 较多，ios 较少且不能降级，只能单向升级；新的 ios
系统中的资源库不能完全兼容低版本中的 ios 系统中的应用，低版本 ios 系统中的应用调用了新的资源库，会直接导致闪退（Crash）；
4.操作习惯：Android，Back 键是否被重写，测试点击 Back 键后的反馈是否正确；应用数据从内存移动到 SD 卡后能否正常运行等；
5.push 测试：Android：点击 home 键，程序后台运行时，此时接收到 push，点击后唤醒应用，此时是否可以正确跳转；ios，点击 home 键关闭程序和屏幕锁屏的情况（红点的显示）；
6.安装卸载测试：Android 的下载和安装的平台和工具和渠道比较多，ios 主要有 app store，iTunes 和 testflight 下载；
7.升级测试：可以被升级的必要条件：新旧版本具有相同的签名；新旧版本具有相同的包名；有一个标示符区分新旧版本（如版本号），
对于 Android 若有内置的应用需检查升级之后内置文件是否匹配（如内置的输入法）
另外：对于测试还需要注意一下几点：
1.并发（中断）测试：闹铃弹出框提示，另一个应用的启动、视频音频的播放，来电、用户正在输入等，语音、录音等的播放时强制其他正在播放的要暂停；
2.数据来源的测试：输入，选择、复制、语音输入，安装不同输入法输入等；
3.push（推送）测试：在开关机、待机状态下执行推送，消息先死及其推送跳转的正确性；应用在开发、未打开状态、应用启动且在后台运行的情况下是 push 显示和跳转是否正确；
推送消息阅读前后数字的变化是否正确；
多条推送的合集的显示和跳转是否正确；
4.分享跳转：分享后的文案是否正确；分享后跳转是否正确，显示的消息来源是否正确；
5.触屏测试：同时触摸不同的位置或者同时进行不同操作，查看客户端的处理情况，是否会 crash 等
6.app 出现 ANR，是什么原因导致的？
1.主线程执行了耗时操作，比如数据库操作或网络编程
2.其他进程（就是其他程序）占用 CPU 导致本进程得不到 CPU 时间片，比如其他进程的频繁读写操作可能会导致这个问题。
细分的话，导致 ANR 的原因有如下几点：
1.耗时的网络访问
2.大量的数据读写
3.数据库操作
4.硬件操作（比如 camera)
5.调用 thread 的 join()方法、sleep()方法、wait()方法或者等待线程锁的时
候
6.service binder 的数量达到上限
7.system server 中发生 WatchDog ANR
8.service 忙导致超时无响应
9.其他线程持有锁，导致主线程等待超时
10.其它线程终止或崩溃导致主线程一直等待。
7.App 出现 crash 原因有哪些？
为什么 App 会出现崩溃呢？百度了一下，查到和 App 崩溃相关的几个因素：内存管理错误，程序逻辑错误，设备兼容，网络因素等，如下：
1.内存管理错误：可能是可用内存过低，app 所需的内存超过设备的限制，app跑不起来导致 App crash。或是内存泄漏，程序运行的时间越长，所占用的内存越大，最终用尽全部内存，导致整个系统崩溃。亦或非授权的内存位置的使用也可能会导致 App crash。
2.程序逻辑错误：数组越界、堆栈溢出、并发操作、逻辑错误。e.g. app 新添加一个未经测试的新功能，调用了一个已释放的指针，运行的时候就会 crash。
3.设备兼容：由于设备多样性，app 在不同的设备上可能会有不同的表现。
4.网络因素：可能是网速欠佳，无法达到 app 所需的快速响应时间，导致 app crash。或者是不同网络的切换也可能会影响 app 的稳定性。
原文地址：https://blog.csdn.net/u014332275/article/details/88370889
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。