1.业务逻辑测试
业务逻辑测试：主要测试客户端业务能否正常完成
功能点测试：主要测试客户端功能点是否正常使用
关联性测试：主要测试客户端与PC端的交互，客户端处理完后，PC端与客户端数据一致
2.兼容性测试
针对App通常会考虑这些方面：
①操作系统版本
包括Andoird版本，安卓系统，
手机：华为、小米、oppo、魅族等主流手机，各系统需要兼容到的版本，4-5.0以上，以产品的需要适配的版本为主。
iOS版本 ，ios系统
手机：6，6s，6p，7，7P，8，8P，X
版本：ios9-11
②屏幕分辨率
android 800*480, 960*640,1280*720(720p),1920*1080(1080p),2560*1440(2k).
对于iOS,考虑最近几代机型对应的分辨率即可.
解决方案：
a.自行购买或者使用借来设备来实际验证。耗费资金，购买几台。
b.第三方云测试的解决方法。
c.整理不兼容的地方，然后去分析app总可能不兼容的代码。对技术能力的要求比较高，前期也需要花费不少的时间。
d.利用友盟等第三方统计平台获得应用对应的TOP N 的记性重点进行测试。
3.流量测试和电量测试
手机的电量及流量测试主要是为了站在用户角度思考，毕竟电量、流量消耗比较大，会影响客户的使用感受。手机端量使用是和CPU使用率成正比的。由于这个没有比较详细的规定，只能出一个通用范围。CPU使用率不能超过10%以上，流量不要超过10M以上。一般通过android手机端一些监控软件获取数据。当然也可以通过代码打点获取。
如果一些app架构设计的不好，或者代码有缺陷，就可能导致电量消耗比较高。
流量：一类是用户的操作直接导致的流量消耗；另一类是app在后台运行时的流量消耗
（一）流量的测试方法
手机抓包或者wifi代理（Fiddler， Charles）。
（二）常见的流量节省方法
①数据压缩。压缩包含接口文本数据的压缩，js文件的压缩及图片的压缩。
②不同数据格式的采用。例如采用JSON格式作为接口数据返回格式通常比XML格式要小。
③只获取必要的数据。有时候APP一页的内容非常多，而用户可能只会看一部分，过多的从后台拉去数据就是浪费，所以可以采用分屏加载或者懒加载的方式来减少流量消耗。
④缓存。可将图片，js等数据暂存起来，但由于手机存储空间有限，也需要控制整个缓存大小，并给用户提供清理缓存的选项。
手机电量测试 a.利用硬件设备：比如耗电量测试仪 b.第三方软件来检测：手机自带电量监控、360助手、GT等 c.命令方式（5.0以上版本） //初始化batterystats数据 adb shell dumpsys batterystats --reset //得到整个设备的电量消耗信息 adb shell dumpsys batterys > /storage/sdcard0/Download/b1.txt //得到指定app相关的电量消耗信息 adb shell dumpsys batterystats 包名 > /storage/sdcard0/Download/b1.txt 测试流量 流量分两种：a.操作app b.不操作app 测试方法： a.各类云测平台、DDMS的Network b.命令（模拟器不支持，某些真机不支持） ps | grep com.android.browser 获取pid cat /proc/pid/status 获取uid cat /proc/uid_stat/uid/tcp_snd 发送的流量byte cat /proc/uid_stat/uid/tcp_rcv 接受的流量byte c.android自带api long uidrx=TrafficStats.getUidRxBytes(10053); //10053表示uid d.抓包（最好用root真机练习） 通过tcpdump抓包，再通过wireshark直接读取报信息来获取流量
4.弱网络测试【fiddler工具】
移动互联网产品相比PC互联网产品，有一个特点是前者使用的网络比较多样，除了Wif之外，很多时候是在移动网络下使用的，移动网络遇到的情况又比较复杂，比如地铁、隧道、体育场等。所以网络不稳定的情况是比较容易发生的，在测试阶段尽量模拟这样的网络情况，及早发现和修复这些问题。
（一）工具： fiddler工具，原理：通过延迟发送数据或接收的数据的时间来限制网络的下载速度和上传速度，从而达到限速的效果。 方法：Rules > Performances > Simulate Modem Speeds 也许Fiddler的低速已经超出你的忍耐程度了，那么，可以使用脚本重新定义一下低速网络 1. 打开脚本编辑器：Rules > Customize Rules 2. 搜索m_SimulateModem， 3. 然后根据自己的需要修改如下语句 oSession[“request-trickle-delay” ] = “300”；（每上传1KB延迟300ms） oSession[“response-trickle-delay” ] = “150”；（每下载1KB延迟150ms） 点击Save Script后，之前勾选的Simulate Modem Speeds会被取消勾选，需要重新再勾选回来。 （二）弱网测试关注的测试点： ①响应时间，5s或者更长时间未响应时报错信息。用户能忍受的最佳响应时间是2s，对不同的网络机制是否设置不同的响应时间 ②加载图标。页面一致处于loading状态，还是有进度条告诉用户目前正在加载状态 ③异常的反馈 超时时提示
5.网络测试
①4G wifi 情况下功能正常
②无网测试，各页面功能是否受影响。缓存文件是否能正常显示，加载不出的页面是否有提示
③网络切换，app是否功能正常，是否有闪退卡死的情况
6.稳定性测试
App经常出现闪退或者卡死，影响用户体验，造成用户流失
7.安全测试
①包括安装包的安全测试（能否反编译代码、安装包是否签名，完整性校验，权限设置检查等）
②敏感信息测试（数据库，日志，配置文件），接入风控，敏感字敏感图片拦截。
③软键盘劫持（金融类APP登录页面的用户名密码输入框）、
账户安全（密码是否明文，密码传输是否加密，账户输入错误次数过多锁定，同时会话提醒， 注销机制）数据通信安全（关键数据是否散列或加密，关键连接是否使用安全通信，是否对数字证书合法性进行验证，是否校验数据合法性。
④组件安全测试。
⑤服务器端接口测试（SQL注入测试、XSS跨站脚本攻击， CSRF跨站请求伪造，越权访问等）。
8.环境相关的测试
①干扰测试。收到电话、收到短信、收到通知栏消息、无电提示框弹出、第三方安全软件告警弹出。 ②权限测试。一些用户在实际使用App的时候回有意识阻止某些功能。例如有的用户感觉让某个App访问电话本或者相册可能泄漏隐私，就在手机中设置了禁止了该App访问相册的权限。 ③边界测试 手机环境本身也有其边界情况需要在测试中覆盖。常见的场景有： 可用存储空间过少、没有SD卡/双SD卡、飞行模式、系统时间有误（晚于和早于标准时间）、第三方依赖（比如我们的App依赖第三方App，但是现在第三方App没有安装或者版本过低的测试情况）。 ④Android定位测试。用白盒方式模拟
⑤断网、断电、服务器异常等情况下，客户端能否正常处理，保证数据正常性。
9.升级测试
（一）正常的下载升级过程 ①考虑iOS和安卓的下载渠道不同。iOS的下载来自于AppStore，Android的升级来自于官网下载或者是各个渠道。 ②考虑网络的影响。2G/3G/4Gwifi下是否都能正常升级或者能够基于流量的影响进行智能下载 ③考虑中断下载和升级过程后是否会继续或者重新下载和升级。手动中断后可以继续进行相关操作 ④考虑断电和内存不足的问题。能够继续进行相关升级，对于内存有友好的提示 ⑤考虑应用权限问题。如果新版本对于应用权限有了扩展，需要进行权限确认 ⑥考虑不同机型。升级测试需要对各种机型进行覆盖测试 （二）升级后旧版本的兼容性 ①新旧版本并行时后台接口的兼容性。 ②在进行旧版本功能兼容性验证时，可以进行主要流程的测试和变更的接口影响到的功能详细验证，这样可以缩小测试范围 （三）覆盖升级后新版本的使用情况 ①除了新版本自身的新功能验证之外，要进行主要业务流程的验证。 ②在覆盖升级前，需要模拟使用旧版本的用户进行缓存数据的创建，然后进行升级，确认缓存数据升级后可以正常显示，相关功能工作正常。
在线升级测试
测试点：a.验证数字签名 b.升级后可以正常使用 c.在线跨版本升级
10.安装和卸载测试
主要针对编译后源程序生成的APK安装文件。
主要测试点：a.生成的APK文件在真机上可以安装及卸载；
b.Android手机端的通用安装工具，如：豌豆荚及91助手等工具可以正常安装及卸载程序。
11.交互性测试
客户端作为手机特性测试，包含被打扰的情况13种，来电，来短信，低电量测试等，还要注意手机端硬件上，如：待机，插拔数据线，耳机等操作不会影响客户端。
12.易用性测试
界面与交互性测试：符合android交互规范，符合用户使用习惯，操作方便简单，具有一致性。
可用性测试：用户体验好，用户操作方便，用户使用错误率低。
13.客户端侧性能测试
偏重客户端侧CPU、MEM、流量、电量以及客户端在不同网络环境下响应速度等等。
大数据的测试：主要在特定环境下，客户端一次性更新大量的数据，客户端能否正常处理，分为三种情况：
a.客户端第一次使用，更新大量数据
b.客户端在平时更新中，更新大量的数据
c.客户端已经在手机本地下载很多数据后，再次更新大量数据。
14.内存泄漏测试
OutOfMemory。
15.外网与场景测试
主要是模拟客户使用网络环境，检验客户端程序在实际网络环境中使用情况及进行业务操作。外网测试主要覆盖到wifi\3G\4G、net\wap、电信\移动\联通，所有可能的组合进行测试。
原则：a.尽可能全面覆盖用户的使用场景，测试用例中需要包含不同网络排列组合的各种可能； b.模拟信号被屏蔽时候，客户端的影响等； c.做外部场景测试，在高山、丘陵、火车上等特殊环境下进行全面测试。
16.APP性能测试分类
客户端：
a.应用测试（关注CPU、MEM、流量、GPU等）
b.ROM测试
c.其他（web页面，现在APP大多都是web页面）
服务器端：性能测试方法和WEB差不多
tips：客户端的测试其实比较推荐专用的硬件设备来，这样测出的数据更加准确，比如高速相机、功耗仪等
17.APP自动化测试分类
UI(robotium、Appium等)
接口
单元（junit、Robolectric等）
持续集成
tips：一句话，对编程要求高，逻辑性思维要求高
18.测试启动时间
a.代码里插入时间并打印Log.e
b.命令方式
adb shell
am start -W -n 包名/activity名
-W是指启动完成之后，返回启动耗时
c.秒表、高速相机
d.adb logcat
adb logcat >d:\log.txt
启动应用，待加载完成后ctrl+c停止
find "Displayed" d:\log.txt>d:\log1.txt
find "包名" d:\log1.txt>d:]log2.txt
19.代码静态扫描
代码扫描工具Lint，它能非常容易得帮米找出代码上的结构问题
具体的检察规则可以自定义（局部，全局）
lint --list 获得检查项id和简要说明
lint --show xxx 获得详细说明
jenkins：持续版本构建，与lint搭配使用
lint:检查已有规则规范
findbugs：针对java平台代码的检查
20.traceview
手机root，代码中埋点，加SD卡读写权限。通过monitor.bat打卡.trace文件。
Debug.startMethodTracing("路径"); //在oncreate方法中，开始埋点
Debug.stopMethodTracing(); //ondestroy中，结束
21.GPU
通过开发者模式-》显示GPU过度绘制
22.CPU
a.第三方工具、各类云测平台
b.dumpsys命令
adb shell dumpsys cpuinfo | grep com.android.browser > /storage/sdcard0/Download/cpu.txt
c.top命令
adb shell top | grep com.android.browser > /storage/sdcard0/Download/cpu.txt
tips：关注活动状态和静默状态下的情况
23.线上监控的方法
a.第三方的标准化的开源、商业产品，如Nagios、zabbix、Ganglia、百度统计等
b.自主研发的监控手机平台
c.APM，比如听云
d.用户反馈
app埋点监控测试：如友盟