非功能性测试是针对非功能性需求来说的。所谓非功能需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性
一、交互类性能
1.响应时间
互联网上对于用户响应时间，有一个普遍的标准，2/5/10秒原则。
- 2秒 “非常有吸引力”的用户体验
- 5秒 “比较不错”的用户体验
- 10秒 “糟糕”的用户体验
1.1 用例设计
我们通常所说的App卡、慢通常就是由于启动时间或者页面响应时间过长导致的。我们从这两个方面，结合实际的用户场景，给出了几种常用的测试场景。
测试场景 | 说明 |
App首次启动时间 | 从App启动到出现第一个可操作的页面的时间间隔 |
App非首次启动的时间 | 同上 |
App启动到首页加载出来的时间 | 从App启动到首页完全加载出来的时间间隔 |
无网络请求的页面响应时间 | 一般指从发起跳转，到页面完全加载出来的时间间隔 |
有网络请求的页面响应时间 | 同上 |
1.2 测试方法
实际性能测试中是严格录像计时的，按下到首帧响应时间。
ADB命令
说明：此命令适用应用冷启动时，只需关注TotalTime（单位：ms）
- ThisTime 表示一连串启动Activity的最后一个 Activity 的启动耗时，一般和TotalTime时间一样，除非在应用启动时开了一个透明的Activity预先处理一些事再显示出主Activity，这样将比TotalTime小
- TotalTime应用的启动时间，包括创建进程+Application初始化+Activity初始化到界面显示
- WaitTime 一般比TotalTime大点，包括系统影响的耗时
屏幕录制
1） 安装被测应用到测试机，保证手机网络畅通
2） 通过相机对准手机屏幕进行录像
3） 用手点击APP，待用户期待界面完全展示后，停止录像
4） 通过VirtualDub（或其他视频解帧）工具打开录好的视频，分别找出用户点击屏幕的时间点和完全展示的时间点，两者的差值就是APP响应时间
说明：此方法适用任何场景，但测试较为繁琐，建议手机无USB连接权限或其他测试条件不满足时使用
脚本判断
1）在发送touch事件后记录起始时间
2）当mFocusedActicity的数据中有指定activity，记录结束时间
3）两者做差就是所需时间（单位：ms）。
说明：适用任意场景，已添加在ATT工具中，自动化用例可随时调用
1.3 判断依据
1） 冷启动响应时间不超过2s
2） 安装完成首次启动时间不超过5s
3） 其他页面响应时间不超过5s
2.流畅度
流畅度测试简单来说就是Android页面绘制。Android系统每秒60HZ，也就是大约每16ms刷新一次界面。但是我们在使用过程中经常会看到页面有卡顿（丢帧）的现象，也就是说可能此时两个页面绘制的时间差超过0.1s（人眼视觉残留0.1s）
2.1 用例设计
测试项 | 测试场景 | 说明 |
过渡绘制 |
1. 新增列表页 2. 旧列表有大的改动 3. 当前加载页资源较多 4. … | 页面不能有超过70%的过渡绘制 |
帧率 | 平均FPS>=30，最小FPS>=24 |
2.2 测试方法
系统自带 – 开发者模式
路径：设置-开发者模式-GPU呈现模式分析-在屏幕上显示为条形图
判断依据：只要下方的曲线不超过绿线（16ms的阈值），都可以视之为流畅
ADB命令
1） adb shell dumpsys gfxinfo com.xdja.actoma > D:\fps.txt
2） 获取到如下数据，复制到Excel中绘制成堆积柱形图
3） 表格：
4） Draw + Prepare+Process + Execute = 完整显示一帧 ，这个时间要小于16ms才能保存每秒60帧。
二、资源类性能
1.CPU
Android性能指标cpu主要关注两点：
1） cpu总体使用率
2） 应用程序CPU占用率
1.1 用例设计
测试场景 | 说明 |
空闲状态下的应用CPU消耗情况 | 被测应用在系统资源非常空闲的情况下的占用率，比如只开一个被测应用； |
中等规格状态下的应用CPU消耗情况 | 后台已经有几个应用在运行已经并且消耗了系统的一些资源的情况下 |
满规格状态下的应用CPU消耗情况 | 从App启动到首页完全加载出来的时间间隔 |
1.2 测试方法
1.2.1 Android Studio直接查看
1.2.3 GT/iTest工具
1）选择待测应用+测试内容
1） 选择需要保存的数据
2） 查看动态图
3） 保存数据查看
1.3 判断依据
1） 前台进程不超过95%,后台进程不超过5%, 但是在系统没有前台进程时，后台进程可以超过5%
2） 应用不能持续占用CPU过高，如段时间内过高需要研发给出解释
2.内存
2.1 用例设计
测试场景 | 说明 |
内存使用率 | 应用占用系统的内存占比 |
内存抖动 | 使用过程中频繁申请释放内存 |
内存泄漏 | 内存无法正常释放 |
2.2 测试方法
2.2.1 内存占用率（工具:GT/iTest）
1） 选择被测应用
2） 查看内存占用曲线图
2.2.2 内存抖动（工具：AndroidStudio）
1） 测试机安装待测应用，连接到AndroidStudio
2） 操作应用使用场景查看内存抖动情况
2.2.3 内存泄漏
1） 测试机安装待测应用，连接到AndroidStudio
2） 在AndroidStudio选择DDMS工具
3） 选择被测应用，并操作用例场景后GC，记录Allocated、Data值
2.3 判断依据
2.3.1 内存抖动判断
如类似下图即为不通过
2.3.2 内存泄漏判断
标题2.2.3中Data值一直增长，GC后无下降行为即为不通过
3.流量
APP的网络流量消耗对于用户来说是较为敏感的，因为有可能会和钱挂钩。若APP开发时在这方面没有控制好，很有可能会给用户带来不好的体验
3.1 用例设计
测试场景 | 说明 |
IM聊天文字/表情/图片 | 频繁使用场景的流量测试 |
文件传输 | 传输过程中的流量消耗 |
后台静置待机 | 8小时后台待机流量消耗 |
Xpush相关业务场景 | - |
应用首次启动流量 |
|
3.2 测试方法（测试工具：GT/iTest）
1） 测试机安装GT、待测应用
2） 打开GT选择对应应用，后台
3） 操作对应测试场景后查看GT统计
3.3 判断依据
1） 流量消耗不能与发送内容的大小相差太多。如1M文件传送消耗1.1M流量即为通过，消耗2M流量即为不通过
2） 8小时后台流量待机不能超过1M流量
4.功耗
4.1 用例设计
测试场景 | 说明 |
安装目标APK前后台待机 | 前后台待机包括4G、3G、WIFI、无网络情况下测试 |
常见场景待机 | 执行常见场景后，功耗可恢复到待机状态 |
GPS耗电待机 | 网络正常连接情况下应用有GPS业务 |
1.2 测试方法
1.2.1 硬件测试
1） 测试机拆除电源后连接稳压电源并串联万用表
2） 按照万用表表盘操作读取时刻电流mA
3） 测试结束后保存平均电流mA
1.2.2 软件测试（测试工具：Power Tutor）
1） 打开PowerTutor软件，选择待测应用
2） 操作测试场景后，30分钟后查看平均功率并换算为mA
1.2.3 adb测试
1） 重置电池信息
adb shell dumpsys batterystats –reset
2） 测试结束后执行，保存电量信息
adb shell dumpsys batterystats > C:\Users\notordinary\Desktop\batterystats.txt
3） 从batterystats.txt筛选所需信息，搜索关键字“Estimated Power Use”
4） Computed drain即是段时间内消耗功耗mAh，如上图功耗值为：
功耗值 = 6.58mAh/测试时长
1.3 判断依据
1） 安装被测应用后，系统总耗电平均电流无明显增加
2） 被测APP不能有不合理的常驻服务，造成耗电持续偏高
3） ACE待机灭屏耗电6mA – 12mA
4） ACE待机亮屏耗电180 – 230mA