APP测试
一、APP测试点
1、移动App测试与传统台式机测试相比有一定的复杂性。这些复杂性可以被分类为：
环境（大量的设备，各种移动OSs，适应频繁OSs变化） 。
设备（触摸式和非触摸式设备，有限的内存容量，电池耗电量） 。
网络（不同的网络和运营商，在不好或无网络的情况下的App行为，离线支持） 。
可用性（方向，触摸，多触摸，缩放，分页和导航的局限性，各种干扰，如来电，来电短信，闹钟，和低电量警报） 。
2、移动App崩溃原因【一些崩溃原因（排名不分先后）】：
1、设备碎片化：由于设备极具多样性，App在不同的设备上可能有表现不同。
2、带宽限制：带宽不佳的网络对App所需的快速响应时间可能不够。
3、网络的变化：不同网络间的切换可能会影响App的稳定性。
4、内存管理：可用内存过低，或非授权的内存位置的使用可能会导致App失败。
5、用户过多：连接数量过多可能会导致App崩溃。
6、代码错误：没有经过测试的新功能，可能会导致App在生产环境中失败。
7、第三方服务：广告或弹出屏幕可能会导致App崩溃。
3、一些通用的触发移动App崩溃的测试场景：
1 验证在有不同的屏幕分辨率，操作系统和运营商的多个设备上的App行为。
2 用新发布的操作系统版本验证App的行为。
3 验证在如隧道，电梯等网络质量突然改变的环境中的App行为。
4 通过手动网络从蜂窝更改到Wi-Fi ，或反过来，验证App行为。
5 验证在没有网络的环境中的App行为。
6 验证来电/短信和设备特定的警报（如警报和通知）时的App行为。
7 通过改变设备的方向，以不同的视图模式，验证App行为。
8 验证设备内存不足时的App行为。
9 通过用测试工具施加载荷验证App行为。
10 用不同的支持语言验证App行为。
二、Android性能
Android 性能测试跟 pc 性能测试一样分为客户端及服务器，但在客户端上的性能测试分为 2 类：一类为 rom 版本的性能测，一类为应用的性能测试
1）针对 rom 版本的性能测试，一般关注功耗。不过 rom 版本的功耗测试跟应用的功耗测试会有所差异，当然只是用例设计方面的差异，工具仍然采用安捷伦电源仪进行
2）对于应用性能测试，包括很多测试项，如启动时间、内存、CPU、GPU、功耗、流量等。
对于启动时间、内存、cpu 测试大家一般都使用外部提供的第三方工具来辅助测试，如GT、安测试等、这些工具的原理都是基于调用 android 底层的一些 api 来获取到测试所用到的值，当然我们也可以使用 android 本身提供的一套 adb 即可完成上述测试。
对于 GPU、功耗、等测试来说，用第三方工具测试得到的数值一般都不是很准确，这个时候我们需要引入硬件来进行测试了，GPU 可以采用高速相机来进行测试，功耗可以使用万用表或安捷伦电源仪来进行测试
1、启动时间
关于应用的启动时间的测试分为三类：
1. 首次启动 --应用首次启动所花费的时间
2. 非首次启动 --应用非首次启动所花费的时间
3. 应用界面切换--应用界面内切换所花费的时间
1.1软件测试的方法做启动时间的测试一般我们分为2类，一类为使用软件来测试，一类为使用硬件来测试。
可以使用 android 提供的 DisplayManager 来获取 activity 的启动时间
●通过日志过滤关键字 Displayed 来过滤所有 activity 所打印的日志。通过 adb logcat>/address/logcat.txt 然后使用 find “Displayed” /address/logcat.txt>/newaddress/fl.txt
●通过 activity 名来过滤获取所测应用 find “ActivityName” /newaddress/fl.txt>/newaddress/last.txt
●通过计算 activity 的时间之和即可
除了 DisplayManager 的打印时间方法，还有通过 am 获取启动时间。
1.2硬件的测试方法
1）测试准备：
1、手机处于“开发者模式”。
2、点击设置--开发人员选项--找到“窗口缩放、过渡动画缩放、动画程序时长调整”三个选项，分别关闭动画。
2）测试方法和步骤：
主要通过手机录像来实现，具体操作步骤及注意事项如下：
1、用两部手机测试，A手机安装正确的版本作为测试机，B手机用来拍照，
2、将测试手机整个屏幕置于录像视野内，以便在数帧时候观察屏幕变化状态；
3、测试过程中如果出现录像模糊的情况，应等待清晰后再开始进行点击屏幕的操作；
录制视频的手机进行如下设置：
1、点击更多
2、选择慢动作效果进行视频录制
3、点击左下角倍数设置按钮，模式设置为8X（240帧/秒，也可以选其他模式）
a、首次启动时间测试方法：
1、安装好apk后，设置-应用管理-相关apk-清空缓存-强行停止；
2、点击桌面应用图标，启动应用；
3、待应用程序完全加载后，重复步骤1、2；
4、共测试4组，求平均值。
b、非首次启动时间测试方法：
1、点击home键，点击桌面应用图标，启动应用，应用完全启动后点击back键退出应用；
2、点击桌面应用图标，启动应用；
3、界面完全展开后，点击back键，然后重复步骤2；
4、共测试4组，求平均值。
c、数帧方法和注意事项
将视频在VirtualDub.exe这一工具中打开，（鼠标右键可以调节区域大小）按键盘上的→向右箭头，观察视频变化，记录手指离开图标的前一帧的时间，如图可以看出手指离开了图标，按一下键盘上←向左箭头，记录时间。 记录下起始时间，单位是ms。当界面完全展开时，记录下此刻时间，记为终止时间。
起始时间和终止时间的判断规则如下：
1、起始时间：手机离开图标的前一帧作为应用启动的起始时间；
2、终止时间：一般认为是应用界面在手机屏幕上全部清晰显示的时刻；如果页面需要加载，考虑到网速问题，这时候大体框架出现即可记为终止时间。
3、另外我们选择数据的时候要选择时间差相差较小的五组数据来计算平均值获得应用的平均响应时间。
2、内存
移动端关注的是内存消耗，这个测试目标是为了让应用不占用过多的系统资源且及时释放内存，保障整个系统的稳定性。关于内存测试在这里我们需要引入几个概念，
内存消耗测试主要是测试应用在正常使用过程中占有的系统资源，确保应用不会占用过多的系统内存且能及时释放，以保障整个系统性能的稳定性。
VSS：Virtual Set Size 虚拟耗用内存（包含共享库占用的内存），对内存真实消耗的作用很小；
RSS：Resident Set Size 实际使用物理内存（包含共享库占用的内存），共享库是当前进程独占时，RSS=PSS；
PSS：Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存），各进程PSS总和才是真实的内存占用；
USS：Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）。怀疑某个程序有内存泄露可以查看这个值是否一直有增加
一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS
空闲状态：指打开应用后，点击home键让应用后台运行，此时应用处于的状态叫做空闲。
中等规格：指的是对应用的操作时间的间隔长短不一，中等规格时间较长，
满规格：指的是对应用的操作时间的间隔长短不一，满规格时间较短，
存在很多测试子项，如下清单所示
1.空闲状态下的应用内存消耗情况
2.中等规格状态下的应用内存消耗情况
3.满规格状态下的应用内存消耗情况
4.应用内存峰值情况
5.应用内存泄露情况
6.应用是否常驻内存
7.压力测试后的内存使用情况
adb 查看单个内存占用量 （均不需要root权限）
单个应用的最大内存限制
adb shell "getprop | grep heapgrowthlimit"
应用启动后分配的初始内存
adb shell "getprop|grep dalvik.vm.heapstartsize"
单个java虚拟机的最大内存限制
adb shell "getprop|grep dalvik.vm.heapsize"
现在关于android内存测试的方法基本分为几类，
1.使用 android 本身提供的 ActivityManager.MemoryInfo() 方法获得，此类第三方工具有如网易的Emmagee、安测试、腾讯的GT等
2.使用 android 提供的 adb shell dumpsys meminfo |grep packagename >/address/mem.txt 来获取
3.使用 android 提供的 procrank
这里我们详解一下 procrank 方法（批处理，需要root权限）
首先去google获取procrank、procmem、libpagemap.so 三个文件 .
然后push文件，执行 adb push procrank /system/xbin adb push procmem /system/xbinadb push libpagemap.so /system/lib
赋权 adb shell chmod 6755 /system/xbin/procrank adb shell chmod 6755 /system/xbin/procmemadb shell chmod 6755 /system/lib/libpagemap.so ,
在开启工具记录 adb shell procrank |grep packagename >/address/procrank.txt
剩下的就是整理测试数据了
关于内存泄露方面的测试，可以通过几个方面来测试
1.通过monkey压力测试记录内存使用情况，分析数据曲线图及日志情况
2.通过eclipse上的mat+heap来分析存在内存泄露方面的节点
Android应用内存泄露leakcanary工具定位分析
Android应用内存泄露MAT工具定位分析
3、CPU
CPU跟内存一样，存在一些测试子项，如下清单所示
1.空闲状态下的应用CPU消耗情况
2.中等规格状态下的应用CPU消耗情况
3.满规格状态下的应用CPU消耗情况
4.应用CPU峰值情况
CPU的测试方法分为几类
1.使用android提供的adb shell dumpsys cpuinfo |grep packagename >/address/cpu.txt来获取
2.使用top命令 adb shell top |grep packagename>/address/cpu.txt 来获取
两种方法直接区别在于，top是持续监控状态，而dumpsys cpuinfo获取的实时CPU占用率数据
4、GPU性能
人类大脑与眼睛对一个画面的连贯性感知其实是有一个界限的，譬如我们看电影会觉得画面很自然连贯（帧率为24fps），用手机当然也需要感知屏幕操作的连贯性（尤其是动画过度），所以Android索性就把达到这种流畅的帧率规定为60fps。60帧/秒换算一下就是16ms/帧；因此我们应尽量保证每次在16ms内处理完所有的CPU与GPU计算、绘制、渲染等操作，否则会造成丢帧卡顿问题。GPU在移动端性能测试领域都知晓，但对于应用的GPU该如何来测试呢，我们先引入几个名词：
1过度绘制：是指界面显示的 activity 套接了多层而导致。
2帧率：是指屏幕刷新率。
3帧方差：是指屏幕刷新帧间隔方差
GPU的测试目前业界使用的均为硬件来进行，软件测试的数据相较硬件差异较大。对于GPU 的测试主要包括以下几个测试子项
1界面过度绘制
2屏幕滑动帧速率
3屏幕滑动平滑度
过度绘制
1严格模式操作步骤：
1、【设置】-【开发者选项】-【启用严格模式】；
2、待测应用，对于所有的界面&功能遍历操作,上下滑动页面和页面静止时观察是否有红框出现。
严格模式标准：对于所有的界面&功能遍历操作,上下滑动页面和页面静止时不出现红框闪烁。
2过度绘制操作步骤：
1、【设置】→【开发人员选项】→勾选“显示GPU过度绘制”；
2、进入待测应用，观察界面颜色；
界面颜色含义如下：
没有颜色：表示没有重绘。每个像素只画了一次。
蓝色：1x过度绘制。每个像素只画了两次。
绿色：2x过度绘制。每个像素画了三次。
淡红色：3x过度绘制。这个像素被画了四次。
红色：4x过度绘制。这个像素被画了五次及以上。需要解决。
过度绘制标准：1、不允许存在4x过度绘制（红色区域）；2、不允许存在面积超过屏幕1/4区域的3x过度绘制（淡红色区域）。
a)软件测试的方法：
使用命令的前提是：开发者选项-->GPU(HWUI)呈现模式分析确保打开-->在adb shell dumpsys gfxinfo中/ 在屏幕上显示为线型图
1、adb shell dumpsys gfxinfo命令将输出最近120帧的时间信息，并将其分成几个不同的类别，可以直观的显示各部分的快慢，每帧不同阶段的时间相加，不超过16.67ms就是流畅的；
2、若停止不动，app内部也没有刷新处理屏幕的需求，会输出0，有时未开始滑动会直接没有数据输出；
3、以上导致了如果app内部也没有刷新处理屏幕的需求，很流畅，但由于实际每秒处理的帧数不多，fps的值可能也会很少；
4、本方案需要拖动屏幕产生的数据才比较准确，对于需要适配多种机型和版本的情况就不太适合了
5、adb shell dumpsys gfxinfo packagename reset 重置所有计数器，并重新收集的数据
6、启动应用以后，在应用的页面上做滑动，然后执行:
adb shell dumpsys gfxinfo packagename > D:\ex\fps.txt 或 adb shell dumpsys gfxinfo packagename framestats > D:\ex\fps.txt
#Framestats数据格式 在Android 6.0以后为gfxinfo提供了一个新的参数framestats，framestat是每一个frame的信息，记录这不同阶段下更精准的帧的时间戳信息。此输出的每一行代表应用程序生成的一帧。每一行的列数都相同，
每列对应描述帧在不同的时间段的耗时情况。由于数据块以CSV格式输出，因此将其粘贴到您选择的电子表格工具中非常简单。打印每一帧的统计信息(最多120帧且是最后的120帧)。
详细计算方法如下：
打开生成的fps.txt，找到Profile data in ms这部分数据。（Android M 版本以上才支持）
Draw:表示在Java中创建显示列表部分中，OnDraw()方法占用的时间。
Process：表示渲染引擎执行显示列表所花的时间，view越多，时间就越长
Execute：表示把一帧数据发送到屏幕上排版显示实际花费的时间。其实是实际显示帧数据的后台缓存区与前台缓冲区交换后并将前台缓冲区的内容显示到屏幕上的时间。
Draw + Process + Execute = 完整显示一帧 ，这个时间要小于16ms才能保证每秒60帧。
计算总数据的行数 frame_count = row_num,
计算每行渲染时间render_time = Draw + Prepare+Process + Execute,
render_time >16.67ms(1000/60),该帧已经渲染超时
一旦render_time>16.67 算一次jank(丢帧),一旦jank，需要用掉额外的vsync
vsync_overtime = 向上取整(render_time/16.67) - 1
比如：render_time = 66.68 vsync_overtime = 3
render_time = 67 vsync_overtime = 4
一次命令执行获得的fps = int( frame_count * 60 / (frame_count + vsync_overtime_sum))
##adb shell dumpsys gfxinfo packagename framestats 收集的数据##
Applications Graphics Acceleration Info: Uptime: 22215460 Realtime: 38892707 ** Graphics info for pid 4731 [net.oneplus.launcher] ** #表明当前dump的为设置界面的帧信息，pid为4731 Stats since: 54444436332ns #表示该应用的统计信息是从系统开机多长时间（纳秒）后开始统计的。 Total frames rendered: 11835 #总帧数, 本次dump搜集了11835帧的信息 Janky frames: 2803 (23.68%) #总帧数中有2803帧耗时超过了16ms，卡顿率为23.68% 50th percentile: 12ms #表示50%的帧是在12ms中完成的 90th percentile: 21ms #表示90%的帧是在21ms中完成的 95th percentile: 27ms #表示95%的帧是在27ms中完成的 99th percentile: 61ms #表示99%的帧是在61ms中完成的 Number Missed Vsync: 296 #垂直同步延迟1ms以上的帧数量 Number High input latency: 32 #处理input耗时超过1.5*f的帧数量 (f为处理一帧的理想时间1/fps) Number Slow UI thread: 1092 #因UI线程上的工作导致耗时超过0.5*f的帧数量 Number Slow bitmap uploads: 159 #因bitmap的加载耗时超过0.2*f的帧的数量 Number Slow issue draw commands: 1251 #因绘制导致耗时超过0.75*f的帧的数量
#直方图数据，输出用时为某秒的帧数，如耗时0-5ms为1254帧,5-6ms的为581帧。帧数之和等于Total frames rendered中的总帧数 HISTOGRAM: 5ms=1254 6ms=581 7ms=663 8ms=697 9ms=720 10ms=930 11ms=917 12ms=981 13ms=753 14ms=646 15ms=530 16ms=597 17ms=419 18ms=332 19ms=298 20ms=320 21ms=179 22ms=140 23ms=91 24ms=73 25ms=69 26ms=33 27ms=35 28ms=29 29ms=31 30ms=30 31ms=24 32ms=53 34ms=29 36ms=42 38ms=33 40ms=35 42ms=34 44ms=22 46ms=16 48ms=27 53ms=26 57ms=21 61ms=16 65ms=19 69ms=13 73ms=11 77ms=12 81ms=12 85ms=2 89ms=2 93ms=5 97ms=2 101ms=2 105ms=1 109ms=2 113ms=0 117ms=4 121ms=1 125ms=0 129ms=0 133ms=1 150ms=9 200ms=1 250ms=3 300ms=3 350ms=0 400ms=1 450ms=0 500ms=0 550ms=0 600ms=1 650ms=1 700ms=0 750ms=0 800ms=1 850ms=0 900ms=0 950ms=0 1000ms=0 1050ms=0 1100ms=0 1150ms=0 1200ms=0 1250ms=0 1300ms=0 1350ms=0 1400ms=0 1450ms=0 1500ms=0 1550ms=0 1600ms=0 1650ms=0 1700ms=0 1750ms=0 1800ms=0 1850ms=0 1900ms=0 1950ms=0 2000ms=0 2050ms=0 2100ms=0 2150ms=0 2200ms=0 2250ms=0 2300ms=0 2350ms=0 2400ms=0 2450ms=0 2500ms=0 2550ms=0 2600ms=0 2650ms=0 2700ms=0 2750ms=0 2800ms=0 2850ms=0 2900ms=0 2950ms=0 3000ms=0 3050ms=0 3100ms=0 3150ms=0 3200ms=0 3250ms=0 3300ms=0 3350ms=0 3400ms=0 3450ms=0 3500ms=0 3550ms=0 3600ms=0 3650ms=0 3700ms=0 3750ms=0 3800ms=0 3850ms=0 3900ms=0 3950ms=0 4000ms=0 4050ms=0 4100ms=0 4150ms=0 4200ms=0 4250ms=0 4300ms=0 4350ms=0 4400ms=0 4450ms=0 4500ms=0 4550ms=0 4600ms=0 4650ms=0 4700ms=0 4750ms=0 4800ms=0 4850ms=0 4900ms=0 4950ms=0 #内存相关的信息，没啥好说的 Caches: Current memory usage / total memory usage (bytes): TextureCache 3108068 / 100663296 #纹理缓存已使用大小/最大可用大小 LayerCache 0 / 67108864 (numLayers = 0) # layer缓存使用大小/最大可用大小（texture） Layers total 0 (numLayers = 0) # layer数量 RenderBufferCache 0 / 12582912 GradientCache 0 / 1048576 PathCache 0 / 40894464 TessellationCache 0 / 1048576 TextDropShadowCache 108736 / 7340032 PatchCache 128 / 131072 FontRenderer A8 60887 / 4194304 A8 texture 0 60887 / 4194304 FontRenderer RGBA 0 / 0 FontRenderer total 60887 / 4194304 Other: FboCache 0 / 0 Total memory usage: #使用缓存的总大小 7411236 bytes, 7.07 MB Pipeline=FrameBuilder Profile data in ms: # FrameInfoVisualizer（帧信息视图）的统计信息。draw行代表绘制信息 prepare 同步时间 Process gl绘制时间 Execute swapbuffer时间 Draw:表示在Java中创建显示列表部分中，OnDraw()方法占用的时间。 Process：表示渲染引擎执行显示列表所花的时间，view越多，时间就越长 Execute：表示把一帧数据发送到屏幕上排版显示实际花费的时间。其实是实际显示帧数据的后台缓存区与前台缓冲区交换后并将前台缓冲区的内容显示到屏幕上的时间。 Draw + Process + Execute = 完整显示一帧 ，这个时间要小于16ms才能保证每秒60帧。 net.oneplus.launcher/net.oneplus.launcher.Launcher/android.view.ViewRootImpl@a827964 (visibility=0) Draw Prepare Process Execute 5.41 0.26 3.94 0.77 2.54 0.23 9.28 1.34 8.46 7.72 23.74 1.36 1.81 0.20 1.17 2.42 9.37 0.23 6.01 0.66 1.30 0.19 16.54 0.59 1.20 0.22 15.05 0.47 1.15 0.27 16.66 0.90 1.87 0.44 11.98 2.56 3.19 0.42 3.83 1.29 1.57 0.36 2.11 0.88 1.49 0.31 2.06 0.85 1.41 0.30 2.23 0.91 2.00 0.32 2.00 0.92 3.45 0.39 2.97 1.19
#Framestats数据格式 在Android 6.0以后为gfxinfo提供了一个新的参数framestats，framestat是每一个frame的信息，记录这不同阶段下更精准的帧的时间戳信息。此输出的每一行代表应用程序生成的一帧。每一行的列数都相同，
每列对应描述帧在不同的时间段的耗时情况。由于数据块以CSV格式输出，因此将其粘贴到您选择的电子表格工具中非常简单。下表说明了输出数据列的格式。所有的时间戳都是纳秒。打印每一帧的统计信息(最多120帧
且是最后的120帧)。
---PROFILEDATA---
Flags,IntendedVsync,Vsync,OldestInputEvent,NewestInputEvent,HandleInputStart,AnimationStart,PerformTraversalsStart,DrawStart,SyncQueued,SyncStart,IssueDrawCommandsStart,SwapBuffers,FrameCompleted,DequeueBufferDuration,QueueBufferDuration, 0,21256019939003,21256019939003,9223372036854775807,0,21256021611264,21256021663399,21256021840691,21256023720795,21256025349180,21256025417982,21256025679753,21256029621160,21256030392410,491000,416000, 0,21256036634257,21256036634257,9223372036854775807,0,21256037009024,21256037028503,21256037252253,21256038165482,21256039177670,21256039226160,21256039455118,21256048731055,21256050073347,432000,376000 ---PROFILEDATA--- View hierarchy: net.oneplus.launcher/net.oneplus.launcher.Launcher/android.view.ViewRootImpl@a827964 368 views, 466.32 kB of display lists #view的数量大小，通过allocer统计 Total ViewRootImpl: 1 #viewroot总数量 Total Views: 368 #view总数量 Total DisplayList: 466.32 kB #总大小 注： ●FLAGS FLAGS列为'0'的行可以通过从FRAME_COMPLETED列中减去INTENDED_VSYNC列计算其总帧时间。 如果非零，则该行应该被忽略，因为该帧的预期布局和绘制时间超过16ms，为异常帧。 ●INTENDED_VSYNC 帧的的预期起点。如果此值与VSYNC不同，是由于 UI 线程中的工作使其无法及时响应垂直同步信号所造成的。 ●VSYNC 花费在vsync监听器和帧绘制的时间（Choreographer frame回调，动画，View.getDrawingTime（）等） ●OLDEST_INPUT_EVENT 输入队列中最旧输入事件的时间戳，如果没有输入事件，则输入Long.MAX_VALUE。 此值主要用于平台工作，对应用程序开发人员的用处有限。 ●NEWEST_INPUT_EVENT 输入队列中最新输入事件的时间戳，如果帧没有输入事件，则为0。 此值主要用于平台工作，对应用程序开发人员的用处有限。 然而，通过查看（FRAME_COMPLETED - NEWEST_INPUT_EVENT），可以大致了解应用程序添加的延迟时间。 ●HANDLE_INPUT_START 将输入事件分派给应用程序的时间戳。 通过查看这段时间和ANIMATION_START之间的时间，可以测量应用程序处理输入事件的时间。 如果这个数字很高（> 2ms），这表明程序花费了非常长的时间来处理输入事件，例如View.onTouchEvent（），也就是说此工作需要优化，或者分发到不同的线程。请注意，某些情况下这是可以接受的，
例如发起新活动或类似活动的点击事件，并且此数字很大。 ●ANIMATION_START 运行Choreographer注册动画的时间戳。 通过查看这段时间和PERFORM_TRANVERSALS_START之间的时间，可以确定评估运行的所有动画器（ObjectAnimator，ViewPropertyAnimator和常用转换器）需要多长时间。 如果此数字很高（> 2ms），请检查您的应用是否编写了自定义动画以确保它们适用于动画。 ●PERFORM_TRAVERSALS_START PERFORM_TRAVERSALS_STAR-DRAW_START，则可以提取布局和度量阶段完成的时间。（注意，在滚动或动画期间，你会希望这应该接近于零..） ●DRAW_START performTraversals的绘制阶段开始的时间。这是录制任何无效视图的显示列表的起点。 这和SYNC_START之间的时间是在树中所有无效视图上调用View.draw（）所花费的时间。 ●SYNC_QUEUED 同步请求发送到RenderThread的时间。 这标志着开始同步阶段的消息被发送到RenderThread的时刻。如果此时间和SYNC_START之间的时间很长（> 0.1ms左右），则意味着RenderThread忙于处理不同的帧。在内部，这被用来区分帧做了太多的工作，
超过了16ms的预算，由于前一帧超过了16ms的预算，帧被停止了。 ●SYNC_START 绘图的同步阶段开始的时间。 如果此时间与ISSUE_DRAW_COMMANDS_START之间的时间很长（> 0.4ms左右），则通常表示有许多新的位图必须上传到GPU。 ●ISSUE_DRAW_COMMANDS_START 硬件渲染器开始向GPU发出绘图命令的时间。 这段时间和FRAME_COMPLETED之间的时间间隔显示了应用程序正在生产多少GPU。像这样出现太多透支或低效率渲染效果的问题。 ●SWAP_BUFFERS eglSwapBuffers被调用的时间。 ●FRAME_COMPLETED 帧的完整时间。花在这个帧上的总时间可以通过FRAME_COMPLETED - INTENDED_VSYNC来计算。
b)硬件的方法
这里需要引入高速相机，打开高速相机，开启摄像模式，录制人滑动或者扫动被测应用的视频，再通过人工或者程序（VirtualDub、Avidemux）数帧的方法对结果进行计算得到帧率。
对于屏幕滑动平滑度的测试，方法如同帧率测试，唯一的差异就是最后的结果计算公式的差异
手机屏幕正常连续显示两张不同画面时，由于留影的效果，在高速相机下观察得到的手机屏幕变化效果为：清晰——模糊——清晰。又手机屏幕采取逐行扫描的方式进行显示，因此如果界面上的某一处出现了“清晰——模糊——清晰”的变化过程，则说明此帧显示正常；如果屏幕未能正常显示两帧，即界面未发生变化，则界面在高速相机下效果为没有明显的清晰-模糊变化。
1滑动帧率测试方法：
1、保证测试的界面内容超过一个屏幕；
2、高速相机在被测手机的正上方开始摄像；
3、手指从手机的任一端，滑动2/3以上屏幕，停顿1~2秒钟，然后以反方向滑动2/3以上屏幕，上下各滑动5次，期间手指不离开屏幕；
4、测试结束，将视频放置到分帧器中处理；
5、利用VirtualDub.exe分帧器将视频打开。点击键盘中的向右箭头，一直到手指接触到屏幕。当手指接触到屏幕后，一帧一帧的观看屏幕图像，记录屏幕变模糊的那一刻 Frame 数值，之后连续按三次向右箭头，4帧一组测试。之后每4帧一组数据，观察图像的清晰模糊变化。当一个范围内清晰模糊没有明显变化时，判断为结束，记录下此刻的Frame 数值。
2扫动帧率测试方法：
1、保证测试的界面内容超过一个屏幕；
2、高速相机在被测手机的正上方开始摄像；
3、手指从手机的任一端，扫动2/3以上屏幕，停顿1~2秒钟，然后以反方向扫动2/3以上屏幕，上下各扫动5次，扫动后手指离开屏幕；
4、测试结束，将视频放置到分帧器中处理；
5、同样利用分帧器将视频打开，前期操作都一样，记录的数值是图像变模糊的前一帧数据，比如654帧时图像变模糊，那么我们记录653为起始帧，之后连续按向右箭头两次，653/654/655/656 这4帧变为一组数据。之后的操作和滑动一样，4帧一组观察图像的清晰模糊变化。
3帧率计算方法：
以240帧的速率对手机屏幕进行摄像，则录像中的4帧相当于手机上的一帧。如果前进4帧，界面某处出现清晰-模糊变化，则为正常刷新；如界面没有明显的清晰-模糊变化，则出现丢帧。手机理论帧率为60fps，则:实际帧率=实际帧数/理论帧数*理论帧率（60）
如视频中界面起始帧数为284，终止帧数为475。则在滑动过程中视频一共经历191帧，理论手机刷新应为191 /4=47.75帧，而实际刷新46.75帧 （丢了1帧），这本次滑动的实际帧率为：
实际帧率=46.75*60/47.75=58.74 fps
4数丢失帧：
鼠标点击软件界面左方向按钮或按动键盘左方向键，每四次记为一帧，如果在这四次中，画面一直保持清晰，则记为丢失一帧；如果四次中，画面有模糊到清晰的变化，则正常。
5注意事项：
1、起始帧和终止帧必须是奇、偶，或者偶、奇。比如起始帧是543、那么终止帧就是550，比如起始帧是542，那么终止帧就是549；
2、在操作过程中，最好不要操作到底部或者顶部，在中间范围内进行滑动和扫动操作最好。
应用UI卡顿分析解决方法
分析UI卡顿我们一般都借助工具，通过工具一般都可以直观的分析出问题原因，从而反推寻求优化方案，具体如下细说各种强大的工具。
使用HierarchyViewer分析UI性能
我们可以通过SDK提供的工具HierarchyViewer来进行UI布局复杂程度及冗余等分析。选中一个Window界面item，然后点击右上方Hierarchy window或者Pixel Perfect window即可操作。先看下Hierarchy window，如下：
一个Activity的View树，通过这个树可以分析出View嵌套的冗余层级，左下角可以输入View的id直接自动跳转到中间显示；Save as PNG用来把左侧树保存为一张图片；Capture Layers用来保存psd的PhotoShop分层素材；右侧剧中显示选中View的当前属性状态；右下角显示当前View在Activity中的位置等；左下角三个进行切换；Load View Hierarchy用来手动刷新变化（不会自动刷新的）。当我们选择一个View后会如下图所示：
类似上图可以很方便的查看到当前View的许多信息；上图最底那三个彩色原点代表了当前View的性能指标，从左到右依次代表测量、布局、绘制的渲染时间，红色和黄色的点代表速度渲染较慢的View（当然了，有些时候较慢不代表有问题，譬如ViewGroup子节点越多、结构越复杂，性能就越差）。
当然了，在自定义View的性能调试时，HierarchyViewer上面的invalidate Layout和requestLayout按钮的功能更加强大，它可以帮助我们debug自定义View执行invalidate()和requestLayout()过程，我们只需要在代码的相关地方打上断点就行了，接下来通过它观察绘制即可。
可以发现，有了HierarchyViewer调试工具，我们的UI性能分析变得十分容易，这个工具也是我们开发中调试UI的利器，在平时写代码时会时常伴随我们左右。
使用GPU过度绘制分析UI性能
我们对于UI性能的优化还可以通过开发者选项中的GPU过度绘制工具来进行分析。在设置->开发者选项->调试GPU过度绘制（不同设备可能位置或者叫法不同）中打开调试后可以看见如下图（对settings当前界面过度绘制进行分析）：
可以发现，开启后在我们想要调试的应用界面中可以看到各种颜色的区域，具体含义如下：
| 颜色 | 含义 |
|---|---|
| 无色 | WebView等的渲染区域 |
| 蓝色 | 1x过度绘制 |
| 绿色 | 2x过度绘制 |
| 淡红色 | 3x过度绘制 |
| 红色 | 4x(+)过度绘制 |
由于过度绘制指在屏幕的一个像素上绘制多次（譬如一个设置了背景色的TextView就会被绘制两次，一次背景一次文本；这里需要强调的是Activity设置的Theme主题的背景不被算在过度绘制层级中），所以最理想的就是绘制一次，也就是蓝色（当然这在很多绚丽的界面是不现实的，所以大家有个度即可，我们的开发性能优化标准要求最极端界面下红色区域不能长期持续超过屏幕三分之一，可见还是比较宽松的规定），因此我们需要依据此颜色分布进行代码优化，譬如优化布局层级、减少没必要的背景、暂时不显示的View设置为GONE而不是INVISIBLE、自定义View的onDraw方法设置canvas.clipRect()指定绘制区域或通过canvas.quickreject()减少绘制区域等。
使用GPU呈现模式图及FPS考核UI性能
Android界面流畅度除过视觉感知以外是可以考核的，常见的方法就是通过GPU呈现模式图或者实时FPS显示进行考核，这里我们主要针对GPU呈现模式图进行下说明，因为FPS考核测试方法有很多（譬如自己写代码实现、第三方App测试、固件支持等），所以不做统一说明。
通过开发者选项中GPU呈现模式图工具来进行流畅度考量的流程是在设置->开发者选项->GPU呈现模式（不同设备可能位置或者叫法不同）中打开调试后可以看见如下图（对settings当前界面上下滑动列表后的图表）：
当然，也可以在执行完UI滑动操作后在命令行输入如下命令查看命令行打印的GPU渲染数据（分析依据：Draw + Process + Execute = 完整的显示一帧时间 < 16ms）：
adb shell dumpsys gfxinfo [应用包名]打开上图可视化工具后，我们可以在手机画面上看到丰富的GPU绘制图形信息，分别展示了StatusBar、NavgationBar、Activity区域等的GPU渲染时间信息，随着界面的刷新，界面上会以实时柱状图来显示每帧的渲染时间，柱状图越高表示渲染时间越长，每个柱状图偏上都有一根代表16ms基准的绿色横线，每一条竖着的柱状线都包含三部分（蓝色代表测量绘制Display List的时间，红色代表OpenGL渲染Display List所需要的时间，黄色代表CPU等待GPU处理的时间），只要我们每一帧的总时间低于基准线就不会发生UI卡顿问题（个别超出基准线其实也不算啥问题的）。
可以发现，这个工具是有局限性的，他虽然能够看出来有帧耗时超过基准线导致了丢帧卡顿，但却分析不到造成丢帧的具体原因。所以说为了配合解决分析UI丢帧卡顿问题我们还需要借助traceview和systrace来进行原因追踪
5、流量
流量测试，同样需要引入几个名词。中等负荷：应用正常操作。高负荷：应用极限操作
流量测试包括以下测试项：
- 应用首次启动流量提示
- 应用后台连续运行 2 小时的流量值
- 应用高负荷运行的流量峰值
- 应用中等负荷运行时的流量均值
流量测试一般都是用软件来进行的，这里我们一般分为2类：
- 采用市场提供的第三方工具来进行测试，如流量宝之类的
- 自研工具进行测试
自研工具进行测试一般包含 2 类方法，
- 通过
tcpdump抓包，再通过wireshake直接读取包信息来获得流量 - 首先获得被测应用的
uid信息，可以通过adb shell dumpsys package来获取 然后在未操作应用之前，我们可以通过查看adb shell cat /proc/uid_stat/uid/tcp_rcv 和adb shell cat /proc/uid_stat/uid/tcp_snd获取到应用的起始的接收及发送的流量，然后我们再操作应用，再次通过上述 2 条命令可以获取到应用的结束的接收及发送的流量，通过相减及得到应用的整体流量消耗
6、功耗
功耗测试主要从以下几个方面入手进行测试：1测试手机安装目标APK前后待机功耗无明显差异。2常见使用场景中能够正常进入待机，待机电流在正常范围内。3长时间连续使用应用无异常耗电现象。功耗测试的方法分为两类，一类为软件测试，一类为硬件测试。
a软件测试一般分为2类，
1就是自写工具进行，这里一般会使用3种方法：第一种基于android提供的PowerManager.WakeLock来进行，第二种比较复杂一点，功耗的计算=CPU消耗+Wake lock消耗+数据传输消耗+GPS消耗+Wi-Fi连接消耗，第三种通过 adb shell dumpsys battery来获取
b硬件测试
一般使用万用表或者功耗仪进行测试，使用功耗仪（Agilent（安捷伦））测试的时候，需要制作假电池来进行的，有些不能拔插电池的手机还需要焊接才能进行功耗测试
|
关闭数据业务 空载待机电流 |
1、测试样机恢复出厂设置； |
1、按power键灭屏，测试空载待机30分钟电流； |
|
开启数据业务 空载待机电流 |
1、测试样机恢复出厂设置； |
1、开启数据业务，如果应用需要联网，需要在设置-》应用联网管理，关闭其他应用联网开关，同时限制后台移动数据； |
|
静态IDEL功耗 |
1、测试手机无后台应用运行 |
1、在桌面无图标一屏，测试3分钟亮屏电流。 |
|
关闭数据业务 应用待机电流 |
1、测试样机恢复出厂设置； |
1、安装测试应用，并开启应用放后台运行； |
|
数据业务 应用待机电流 |
1、测试样机恢复出厂设置； |
1、开启数据业务，如果应用需要联网，需要在设置-》应用联网管理，关闭其他应用联网开关，同时限制后台移动数据； |
|
单次被动类业务电流测试 |
1、测试样机恢复出厂设置； |
1、启动应用并将应用放后台运行； |
|
数据加载-数据业务 |
1、测试手机无其他后台应用运行 |
1、从设备桌面点击应用icon 2、记录从开始进入首页到加载完成首页的亮屏平均电流 |
|
心跳电流测试 |
1、测试样机恢复出厂设置； |
1、启动应用并将应用放后台运行； |
|
wifi应用待机电流 |
1、测试样机恢复出厂设置； |
1、打开数据业务； |
|
wifi单次被动类业务电流测试 |
1、测试样机恢复出厂设置； |
1、开启wifi，并连接热点； |
|
数据加载-WiFi |
1、测试手机无其他后台应用运行 |
1、从设备桌面点击应用icon，在账号登录页面登录已在本机同意过协议的账号 |
|
wifi心跳电流测试 |
1、测试样机恢复出厂设置； |
1、开启wifi，并连接热点； |
|
应用唤醒次数测试 |
1、测试样机恢复出厂设置； |
1、启动应用并将应用放后台运行； |
|
应用唤醒时间测试 |
1、测试样机恢复出厂设置； |
1、启动应用并将应用放后台运行； |
三、APP兼容性专项测试
APP兼容性测试维度包含：新旧版本兼容测试、不同机型测试（系统兼容性、屏幕兼容性、分辨率兼容、尺寸兼容）、不同网络兼容，具体如下：
一、新旧版本兼容性测试
- 新旧版本覆盖安装升级正常
- 新增功能，新旧版本覆盖安装后使用正常
二、不同机型测试
1.系统兼容性
- iOS系统：iOS11.x、iOS12.x、iOS13.x、iOS14.x
- Android系统：Android5.x、Android6.x、Android7.x、Android8.x、Android9.x、Android10.x、Android11.x
2.屏幕兼容性
- iOS：
（1）刘海屏：例如：iPhone x、iPhone xs 、iPhone XR、iPhone 11、iPhone 11 Pro、iPhone 11 pro max、iPhone 12、iPhone 12 pro、iPhone 12 pro max、iPhone 12 mini
（2）非刘海屏：例如：iPhone 8、iPhone 8 plus、iPhone 7、iPhone 7 plus、iPhone 6、iPhone 6s、iPhone 6s plus、iPhone 5s
- Android：
（1）全面屏：例如：华为P30、红米K30至尊纪念版、荣耀X10、vivo APEX 2020等
（2）非全面屏：例如：华为P10、华为P10 plus、荣耀8等
（3）曲面屏：例如：三星Galaxy S10+、三星Galaxy Note 10+ 5G、华为Mate30 Pro、华为P30 Pro、vivo NEX3等
（4）折叠屏：例如：华为Mate XS 5G、华为mate X2、三星Galaxy Z Fold2 5G、三星 Galaxy W21 5G
3.分辨率兼容性
- iOS
（1）1080*2340 ：iPhone 12 mini
（2）1284*2778：iPhone 12 pro max
（3）1170*2532：iPhone 12 、iPhone 12 pro
（4）750*1334：iPhone SE 2、iPhone 7、iPhone 8、iPhone 6、iPhone 6s
（5）1242*2688：iPhone 11 pro max、iPhone XS Max
（6）1125*2438：iPhone 11 pro
（7）828*1792：iPhone 11、iPhone XR
（8）1125*2436：iPhone XS、iPhone X
（9）1242*2208：iPhone 8 plus、iPhone 7 plus、iPhone 6s plus
（10）640*1136：iPhone 5s
（11）iOS系统自带的显示模式：标准模式、放大模式
- Android
（1）1440*3200：小米11
（2）1344*2772：华为mate 40 Pro
（3）1080*2400：一加8T、vivo S7、OPPO Reno5、荣耀30、小米10青春版、荣耀X10、荣耀Play4T Pro、OPPO A92s、Redmi K30 Pro、华为nova7、三星Galaxy S20 Ultra、荣耀30 Pro 5G、荣耀V30、荣耀V30 Pro、vivo S5、OPPO R17
（4）1080*2460：中兴AXON 20
（5）1080*2376：IQOO 5、vivo X50、vivo X50 Pro、vivo X60 Pro、一加8Pro
（6）1080*2340：锤子坚果R2、荣耀30Pro、魅族17、魅族17Pro、iQOO U1、华为畅享20Pro、华为nova7 Pro、红米9、realme X2
（7）1600*720：红米9A
（8）1080*2408：vivo Y31s、IQOO Neo3、IQOO z1
（9）720*1560：荣耀Play4T
（10）1080*2256：vivo NEX 3 5G
（11）720*1600：OPPO A32、OPPO A8
（12）1080*1920：Mi 10 Pro
（13）2340*1080：小米10
（14）3220*1400：三星Galaxy S20
（15）1080*2280：三星Galaxy Note10
说明：因为Android不同厂家机型多，不同多屏幕分辨率也多，以上主要是列举常见的
4.尺寸兼容性
- iOS主要机型尺寸：4寸-6.7寸
- Android主要机型尺寸：5寸-6.7寸
5.不同网络兼容性
- Wi-Fi切换4G/5G网络情况下功能是否正常
- 4G/5G网络切换Wi-Fi情况下功能是否正常
- 有网切换无网情况下功能是否正常
- 无网切换有网情况下功能是否正常
四、弱网测试
弱网测试作为健壮性测试的重要部分，对于移动端测试来说必不可少。这是因为目前移动端产品的使用用户所处的网络并非完全的流畅WIFI环境，仍有相当体量的用户主要使用4G、3G、2G等网络，另外因移动端产品使用场景多变，如进地铁、上公交、进电梯等，使得弱网测试显得尤为重要。毕竟考虑到各种场景的客户端展示及容错，能极大提升产品印象和用户体验。
一、弱网测试的思路篇
弱网测试概要思路
总结了下（如上图所示），弱网测试主要进行特殊网络状态下的功能测试同时关注用户体验，具体来说，弱网测试包括弱网功能测试、无网状态测试、网络切换测试等，测试的同时关注用户体验的诸多方面。
1.弱网功能测试
这一部分主要是在各种非wifi网络环境下进行的功能测试，同时模拟高延时和高丢包的异常网络环境进行健壮性测试。2G/3G/4G的网络可以通过使用电话卡移动／联通／电信等网络进行模拟，关注页面的响应时间、页面呈现是否完整一致等。高延迟和高丢包的网络环境需要借助工具来模拟，在windows环境下可以使用fiddler和network emulator for windows toolkit来模拟，在mac环境下则可以使用charles和Xcode自带的开发环境网络异常模拟工具进行。工具的使用在工具篇具体介绍。
弱网功能测试建议将整体的功能测试用例在弱网环境下进行一轮测试，相同模块下的功能可以分多个网络条件进行测试。这部分发现的问题可能会有：页面图片在弱网环境下加载不出来（图片加载逻辑需优化）、需要模版的页面版式结构混乱（模版文件在弱网环境的加载需优化）、页面响应时间较长没有任何显示（页面显示逻辑待优化、重试机制加入）等。
2.无网状态测试
无网状态测试则是在切段网络的情况下进行的测试，主要关注页面的显示与交互、本地数据的存储、断网功能的使用等，经常该部分也需要与网络切换部分协同进行。通常来说，（1）断网情况下请求一个非本地数据的页面需要设定一定的时间等待上限，及时提示网络异常以及提示重试；（2）断网情况下请求一个部分本地数据的页面需要观察本地数据的部分是否加载显示正常，待请求的部分是否符合交互给的缺省样式一致；（3）断网情况下请求一个完全本地数据的页面是否显示正常。这里还需考虑本地数据存储的情况，有些需要联网后上报服务器的数据本地是否正确存储，联网后这些数据能否正常上报。
无网状态测试建议按照页面划分进行，针对每个页面单独测试无网状态的显示，页面间跳转的显示，页面内功能的点击和显示，同时关注无网到有网时的页面恢复显示状态、数据上报情况是否正常。
3.网络切换测试
这部分主要是进行几个不同网络场景的切换，包括wifi-2G/3G/4G、wifi-无网、2G/3G/4G-wifi、2G/3G/4G-无网、无网-2G/3G/4G、无网-wifi等。主要关注页面的显示与交互，尤其是弱网到wifi，wifi到弱网的情况，是否会有页面的crash以及显示的错乱、session是否一致、请求堆积处理等。
4.用户体验关注
弱网测试的目的就是尽可能保证用户体验，关注的关键点包括：
（1）页面响应时间是否可接受，关注包括热启动、冷启动时间，页面切换，前后台切换，首字时间，首屏时间等。
（2）页面呈现是否完整一致
（3）超时文案是否符合定义，异常信息是否显示正常。
（4）是否会有超时重连
（5）安全角度：是否会发生dns劫持、登录ip更换频繁、单点登录异常等。
（6）大流量事件风险：是否会在弱网下进行更新apk包、下载文件等大流量动作。
五、App弱网测试与常用模拟工具
不同网络环境设置可参考如下图：
1. iOS平台
ios平台通过自带的开发者选项 》Network Link Conditioner, 即可简单的模拟各种速度的网络情况：
2、Android平台通过fiddler模拟
1 ）fiddler操作：自定义延迟 》开启网络模拟即可，如图：
fiddler主要是使用Rules->Performance->Simulate Modem Speeds功能进行的网络延迟模拟，点击Rules->Customize Rules进行设置，打开自定义脚本编辑器，如下图所示：
红框内标出的就是设置延迟时可以操作的上行和下行网络延迟时间，意为每上传／下载1KB的数据要延迟多少毫秒。这里我把请求（上行）时间延迟设置为3000ms，响应（下行）时间延迟设置为1000ms（模拟了2G网络的速度）。这里通过计算上行和下行的网络延迟时间，可以模拟出想要的网络效果。利用 （1KB/下载速度）x1000 = 要delay的毫秒数 来计算。比如我们要模拟2G的网络。
3、Android平台通过Charles模拟
Charles操作：延迟设置 》选择相应的网络延迟设置或者自定义延迟 》开启延迟即可，如图：