APP一般性能测试需要关注的点：
1、内存泄漏
2、CPU
3、GPU
4、启动时间
5、卡顿
6、过度绘制
7、FPS
8、电量
9、流量
10、Crash和ANR率
==========================================
APP性能测试？
APP的性能测试分为服务器端的性能和手机端的性能测试
服务器端的性能测试可以通过LoadRunner或Jmeter工具进行测试，为方便起见，可以以Jmeter工具为例子说一下App服务器端的性能测试流程。
服务端
第一步：首先，确定app的性能测试功能点，一般会选择使用比较频繁的功能做性能测试比如查询，提交数据。
第二步：根据该功能点的接口测试需求，或使用fiddler抓包，在jmeter上构造向服务器发送的请求数据，配置好相关的设置，并做好服务器的监控。(以我们实际项目为基准，本项目是搭建在linux上的，用的是nmon工具做监控)，
最后运行测试，测试完之后，收集CPU，内存等信息，集合聚合报告的内容，分析性能测试结果。
============================================
手机端
第一步：手机端的性能测试流程则比较简单，首先需要在服务器上提前安装监控工具(iTest/GT)，接着启动监控工具，监控被测应用.
第二步：接着需要清空先前的logcat日志记录，清空日志的命令是：adb logcat -c.接着来获取logcat日志：adb logcat -v time > E:sharelogcat.log.
第三步：再接着使用monkey运行被测应用：
adb shell monkey -p your.package.name -v 500 > E:sharemonkey.log
(获取app的包名和activity名称：
adb logcat -v time | findstr START
脚本中，cmp= 后面的值就是 包名)
ctrl+c 终止命令）
第四步：最后根据监控图，检查CPU，内存，流量，电量是否符合性能指标。如果不符合，就把不符合指标的报表和对应的logcat发给开发进行定位。
===========================================
APP性能测试中的问题分析：
1.cpu
cpu检测我们要分3种情况：
1.在空闲时间的消耗，基本没大应用使用cpu
2.在运行一些应用的情况下，cpu已占50%的情况下，观察应用程序占用cpu的情况
3.在高负荷的情况下看CPU的表现，我定义这个高负荷，cpu占用应是在80%以上
1.1 如何查看CPU的使用值
使用命令：adb shell dumpsys cpuinfo apk包名
GT(https://www.cnblogs.com/fanf/p/12419787.html)
（随身调）是APP的随身调试平台，是直接运行在手机上的IDTE。可以使用GT对APP进行快速的性能测试（CPU、内存、流量、电量、帧率/流畅度等）、开发日志查看、Crash日志查看、网络数据包的抓取、APP内部参数的调试、真机代码耗时统计等
=============================================
APP弱网测试
一、网络测试的一般流程
step1：首先要考虑网络正常的情况
① 各个模块的功能正常可用
② 页面元素/数据显示正常
step2：其次要考虑无网络的情况
① APP各个功能在无网络情况下是否可用
② APP各个页面之间切换是否正常
③ 发送网络请求时是否会导致闪退、卡死等异常情况
④ APP各个页面是否显示完整美观，未刷新的页面是否做了相应的提示和处理
⑤ 在无网络情况下数据是否会丢失
⑥ 无网络提示信息是否友好
step3：再次考虑弱网情况
① 弱网情况下APP是否针对请求做了超时处理
② 网络延迟的情况下，操作app进行数据同步、OTA升级是否会发生Crash、ANR等严重错误
③ 弱网情况下，APP请求回调未完成时，执行其他动作以及交互时，是否会出现APP闪退（如：驾考IOS开屏闪退）等异常。
④ 弱网情况下，原始数据是否出现丢失的情况（弱网下载时会出现丢包情况）
⑤ 弱网环境下，是否会出现请求堆积的情况
⑥ 弱网环境下，APP各个页面是否显示完整
⑦ 系统超时，提示信息是否清晰明确
⑧ 弱网情况下APP的响应时间是否在一个合理的时间范围内
⑨ 请求回调未完成--驾考科四难题攻克弹窗
⑩ 这个弹窗是服务器说了算，服务器知道该用户啥时候弹弹窗。若用户在做题页面时返回了，则该用户下次进入且在服务器缓存时间内，应该给出弹窗（产品逻辑：弹窗出现后用户必须看到才消失）
⑪ 请求堆积：水池注水排水问题
step4：最后考虑网络状态之间的转变
① 断开网络连接以后，操作APP各个功能是否正常
② 同步数据过程中，断开网络连接，APP是否出现异常情况
③ 传输数据过程中，网络由wifi切换到gprs，APP是否出现异常情况
④ 弱网环境下发送的请求是否在恢复网络以后出现重复提交的情况
==========================================================
常见BUG-APP
1、升级问题
系统升级友好提示，把升级内容等显示出来，按需要决定是否强制升级，升级做好程序自动备份，如需要可做回滚
预防方法：测试：测试升级功能，中断、暂停、继续升级后的程序正常使用
2、Android高版本软件权限问题
预防策略：1)检查App的用户授权级别，非法授权访问。2)限制或允许使用手机读取用户数据
3、app安装安全性问题
预防策略：
1）应用程序应能正确安装到设备驱动程序上
2）能够在安装设备驱动程序上找到应用程序的相应图标
3）是否包含数字签名信息
4）没有用户的允许, 应用程序不能预先设定自动启动
4、app卸载安全性问题
预防策略：1）卸载是否安全, 其安装进去的文件是否全部卸载
2）卸载用户使用过程中产生的文件是否有提示
3）其修改的配置信息是否复原
4）卸载是否影响其他软件的功能
5）卸载应该移除所有的文件
5、app数据安全性
预防策略：1）当将密码或其他的敏感数据输人到应用程序时, 其不会被储存在设备中, 同时密码也不会被解码
2）密码, 信用卡明细, 或其他的敏感数据将不被储存在它们预输人的位置上
3）应用程序读和写数据正确
4）如果数据库中重要的数据正要被重写, 应及时告知用户
6、app通讯安全性
预防策略：
1）在运行其软件过程中, 如果有来电、SMS、EMS、MMS、蓝牙、红外等通讯或充电时, 是否能暂停程序，优先处理通信, 并在处理完毕后能正常恢复软件, 继续其原来的功能
2）当创立连接时, 应用程序能够处理因为网络连接中断, 进而告诉用户连接中断的情况
3）应用程序将保持工作到通讯超时, 进而发送给用户一个错误信息指示有连接错误
4）应能处理网络异常和及时将异常情况通报用户
5）应用程序关闭或网络连接不再使用时应及时关闭) 断开
7、app人机接口安全性
预防策略：
1）返回菜单总保持可用
2）应用程序必需能够处理不可预知的用户操作, 例如错误的操作和同时按下多个键
3）声音的设置不影响应用程序的功能
8、app安装问题
预防策略：
1）软件在不同操作系统（Palm OS、Symbian、Linux、Android、iOS、Black BerryOS 6.0、Windows Phone 7）下安装是否正常
2）软件安装过程是否可以取消，点击取消后，写入的文件是否如概要设计说明处理
3）软件安装过程中意外情况的处理是否符合需求（如死机，重启，断电）
4）安装空间不足时是否有相应提示
5）安装后没有生成多余的目录结构和文件
9、app卸载问题
Ø预防策略：
1）直接删除安装文件夹卸载是否有提示信息
2）测试系统直接卸载程序是否有提示信息
3）测试卸载后文件是否全部删除所有的安装文件夹
4）卸载过程中出现的意外情况的测试（如死机、断电、重启）。
10、app导航问题
Ø预防策略：
1）按钮、对话框、列表和窗口等；或在不同的连接页面之间需要导航
2）导航与页面结构、菜单、连接页面的风格是否一致
11、app页面图形问题
Ø预防策略：
1）横向比较。各控件操作方式统一
2）自适应界面设计，内容根据窗口大小自适应
3）图片质量要高且图片尺寸在设计符合要求的情况下应尽量小
4）界面整体使用的颜色不宜过多
12、app运行问题
Ø预防策略：
1）App安装完成后的试运行，可正常打开软件
2）App打开测试，是否有加载状态进度提示
3）App打开速度测试，速度是否可观
4）App页面间的切换是否流畅，逻辑是否正确
13、app应用的前后台切换问题
Ø预防策略：
1）APP切换到后台，再回到App，检查是否停留在上一次操作界面
2）APP切换到后台，再回到App，检查功能及应用状态是否正常，IOS4和IOS5的版本的处理机制有的不一样
3）App切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候
4）手机锁屏解屏后进入App注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候
5）当App使用过程中有电话进来中断后再切换到App，功能状态是否正常
6）当杀掉App进程后，再开启App，App能否正常启动
7）出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷
8）对于有数据交换的页面，每个页面都必需要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃
14、app免登录问题
Ø预防策略：
1）App有免登录功能时，需要考虑IOS版本差异
2）考虑无网络情况时能否正常进入免登录状态
3）切换用户登录后，要校验用户登录信息及数据内容是否相应更新，确保原用户退出
4）根据MTOP的现有规则，一个帐户只允许登录一台机器。所以，需要检查一个帐户登录多台手机的情况。原手机里的用户需要被踢出，给出友好提示
5）密码更换后，检查有数据交换时是否进行了有效身份的校验
6）检查用户主动退出登录后，下次启动App，应停留在登录界面
=======================================================
app出现ANR（无响应），是什么原因导致的？
那么导致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.其它线程终止或崩溃导致主线程一直等待。
App出现crash（崩溃）原因有哪些？
为什么App会出现崩溃呢？百度了一下，查到和App崩溃相关的几个因素：内存管理错误，程序逻辑错误，设备兼容，网络因素等，如下：
1.内存管理错误：可能是可用内存过低，app所需的内存超过设备的限制，app跑不起来导致App crash。
或是内存泄露，程序运行的时间越长，所占用的内存越大，最终用尽全部内存，导致整个系统崩溃。
亦或非授权的内存位置的使用也可能会导致App crash。
2.程序逻辑错误：数组越界、堆栈溢出、并发操作、逻辑错误。
e.g. app新添加一个未经测试的新功能，调用了一个已释放的指针，运行的时候就会crash。
3.设备兼容：由于设备多样性，app在不同的设备上可能会有不同的表现。
4.网络因素：可能是网速欠佳，无法达到app所需的快速响应时间，导致app crash。或者是不同网络的切换也可能会影响app的稳定性。
测试过程中遇到app出现crash或者ANR，你会怎么处理？
可以先把日志过滤出来： adb logcat | findstr xxxxx(过滤日志信息) ，然后再搜索其中的关键字，比如：exception、crash，看看是那些方法或者异常导致了问题的发送，初步定位问题原因后，可以交给开发人员去具体查找深层原因并修复。