移动端专项测试

adb命令

稳定性monkey

内存使用情况

cpu使用情况

电量消耗

流畅度

流量消耗

弱网测试

弱网延迟测试

开源工具 SoloPi  阿里开源   GT腾讯开源已经不更新了

各个指标   横向对比、纵向对比

 

ADB ,Android调试桥（Android Debug Bridge）是一种功能多样的命令行工具，可让您与设备进行通信。

ADB 分为三部分:PC上的adb client 和 adb server 以及Android设备上的adb daemon(adbd)

adb的工作原理

ADB client:Client本质上就是Shell,用来发送命令给Server。发送命令时，首先检测PC上有没有启动Server，如果没有Server，则自动启动一个Server，然后将命令发送到Server，并不关心命令发送过去以后会怎样。

ADB server:运行在PC上的后台程序，目的是检测USB接口何时连接或者移除设备。

ADB Server维护着一个“已连接的设备的链表”，并且为每一个设备标记了一个状态：offline，bootloader，recovery或者online。
Server一直在做一些循环和等待，以协调client和Server还有daemon之间的通信。offline说明Server发现了一个设备，但是不能成功连接到Daemon。

ADB Daemon:运行在Android 设备上的一个进程，作用是连接到adb server（通过usb或tcp-ip）。并且为client提供一些服务。

服务器会与所有正在运行的设备建立连接。它通过扫描5555到5585之间（该范围提供16个模拟器使用，因为端口号是成对的）的奇数号端口查找模拟器。服务器一旦发现adb守护进程（adbd），便会与相应的端口建立连接。

服务器与所有设备均建立连接后，就可以使用adb命令访问这些设备。由于服务器管理与设备的连接，并处理来自多个adb客户端的命令，因此可以从任意客户端控制设备。

服务器 启动命令  adb start-server 

然后查看5037端口是否被监听  netstat -ano|findstr 5037

服务器关闭命令 adb kill-server

然后查看5037 端口是不是没有被监听了。

adb devices 获取设备连接信息

设备的状态包含三种：

Offline（不能调试仅是连接）

devices（正常状态可调式）

unauthorized（连接后不能调试，原因是未在手机上同意调试）

adb devices -l 可以查看更多的信息。

adb install 包名  安装包的命令

adb uninstall 包名  卸载包的命令

adb pull 从手机设备copy 指定的文件到本地开发机

adb push 从本地开发机copy指定文件到设备 

adb logcat >d:logcat.txt  收集日志，并且把日志存到本地电脑上，然后在日志里搜error 、crash、exception 这些关键词，看是否有问题

内存

adb shell cat /proc/meminfo 查看设备内存使用情况 ，这个是查看整机的内存。

adb shell dumpsys meminfo com.jd.yyc 查看的是一个应用的 静态的内存情况，我们需要看使用时候的内存使用情况。

使用安卓sdk  tools文件夹里自带的工具monitor ，使用的时候操作安卓手机里的应用，点击左上角第二个按钮dump下内存文件。

 把内存文件dump到本地，com.jd.yyc.hprof，这个文件需要转换，然后使用ecplise中有个插件MAT打开进行分析。

转换这个文件 要使用sdk中  这个目录下的 \sdk\platform-tools  ，hprof-conv.exe这个转化命令，当我们把sdk配置到环境变量后，就可以直接使用这个命令。在命令行窗口输入这个命令， hprof-conv com.jd.yyc.hprof com,jd.yyczhuanhuan.hprof   ,然后把com,jd.yyczhuanhuan.hprof这个文件用ecplise中MAT 打开 。

对于这个内存分析如何看呢，首先可以看Reports  的Leak Suspects 泄露疑点，但是并不是所有的疑点都是要改的

第二个可以对两次dump的堆内存文件进行对比，点击Histogram:  进入这个页面，

鼠标放到histogram上右键 选择Add to Compare Basket 把两个histogram加到一起

然后点击右侧的红色！号，上面就显示前后的两次 使用内存的一个情况。 

CPU使用情况

adb shell dumpsys cpuinfo 所有的应用cpu

adb shell "top" 宏观的一个cpu情况

我们可以用monitor 这个工具，在sdk里tools文件夹中，

 然后再手机上操作我们的app，然后再次点击红框的按钮，会生成如下图监控信息

黑块代表有频繁的函数调用，代表调用的更多

电量消耗

使用一个go语言开发的一个开源工具Battry Historian，使用这个工具来进行电量的消耗测试。首先需要安装环境，下载go安装包，官网是https://golang.google.cn/，如果网络不了，可以在我这个网盘里下载链接：https://pan.baidu.com/s/113fUd81bjCRUyS5AJcftKg 
提取码：p34y

如果默认路径安装的话，不需要配置环境变量了，然后接下来安装Battry Historian，使用git命令，git需要自行安装好。

然后用命令 git clone https://github.com/google/battery-historian.git

cd battery-historian

go get -d -u github.com/google/battery-historian/...    含义是下载依赖

go run setup.go

go run cmd/battery-historian/battery-historian.go

启动后是一个web项目，端口号是9999，这个时候我们在本地访问127.0.0.1:9999就可以访问。

然后我们要开始收集电量使用情况

首先 先重置电量，adb shell dumpsys batterystats --reset 重置电池数据收集

使用下面的命令收集电量。

adb bugreport bugreport.zip 安卓7以上

adb bugreport >bugreport.txt 安卓6以下

然后用上面的工具打开，文件，唤醒锁比较耗电，这个耗电量一般测整机的比较多。视频、音频、蓝牙。

流畅度

 流畅度，即每秒60帧（每帧16.6ms）的速度运行，也就是60fps，并且没有任何延迟或者掉帧。因此，关于流畅度的问题，我们先确定一下三个考量指标。

1、FPS：每秒的帧数

2、丢帧（SF）：在16.6ms完成工作却因各种原因没做完，占了后n个16.6ms的时间，相当于丢了n帧。

3、流畅度：和丢帧相对，在VSync机制中1s内Loop运行的次数。VSync机制：android系统每隔16ms发出VSYNC信号，触发对UI进行渲染，VSync是 垂直同步的缩写，是一种在PC上很早就用到的技术，可以简单的把它认为是一种定时中断。

我们如何测试这样的现象呢，有两种方式，第一种分析GPU的渲染速度，第二种是GPU的过度绘制。这两种都是测试流畅度的一种手段。

分析GPU的渲染速度：GPU渲染模式分析工具以滚动直方图的形式直观地显示渲染界面窗口帧所花费的时间（以每帧16毫秒的熟读作为对比基准）。在性能较低的GPU上，可用的填充率可能很低。随着绘制帧所需的像素数增加，GPU可能需要花费更长的时间来处理命令，并且要求系统的其余任务等待，直到系统可以跟上需求。

在设备上，找到开发者选项，在监控部分中，选择GPU呈现模式分析。在GPU渲染模式分析对话框中，选择在屏幕上显示竖条，以在设备的屏幕上叠加图形。打开我们要分析的应用。绿色的线就是16ms的基准，高于这个基准的就是超过16ms 一帧。

 对于不同的颜色给出建议如下

 第二个是，GPU的过度绘制，这也是在开发者选项中选择GPU过度绘制，颜色越深代表过度绘制越重，一般原色是做好的

对于过度绘制的一些规定

 如果页面上存在大面积的红色，说明页面上有很多过度绘制，对于过度绘制，我们可以提出一些建议，比如删除布局中不需要的背景、展平视图层次结构，降低透明度。

流量消耗

1、先获取app的pid

adb shell ps |findstr com.jd.yyc 

 

然后使用adb shell cat /proc/pid/net/dev

 

2、先获取app的userId

adb shell dumpsys package com.jd.yyc |findstr userId

然后通过uid获取流量，第六列代表下载，第八列代表上传

adb shell cat /proc/net/xt_qtaguid/stats |findstr userId 

上面是我们使用命令查看流量，然后我们也可以用monitor这个工具方便来看。

RX是代表收到的，TX是代表上传的，有上传的说明app不断的向后台发起请求。

如何判断一个应用的流量消耗偏高

流量优化的建议

如何判断一个应用的流量消耗偏高

如果看流量的绝对值看不出高低，那么我们可以找几个同类的产品对比一下，如果完成同样的事务，被测应用比同类产品高很多，那么就是偏高了，存在优化的空间。

 如何找到有效的优化点

把分析的不同类数据包，按包占总流量大小的比例，和包的数量排序，占比多的和消息数量多的，一个优化空间大，一个精简请求次数的机会大。

流量常见问题

冗余内容

同类请求被间隔执行，请求的内容包含一些相对静态的信息，正确的处理是第一次请求包括静态信息就好，后面的同类请求只包含必要的即时变化信息即可。错误的处理方式是每次请求服务器都返回一次静态信息。

冗余请求

有点时候会发现应用短时间内发出多个同样的请求，收到结果也都几乎一样，这样情况应该尽量减少请求次数，同时注意排查程序逻辑错误，也许问题不像表面看起来那么简单。

无用的请求

有的请求，你会发现谁也不知道它是干嘛的，很可能是以前版本遗留下来的无用请求，或者是引用的其他代码发出的，这些无用的请求需要去掉。

永远无法得到回应的请求

如果见到某类请求永远的连接失败或被返回404之类的失败结果，那它不是历史遗留的多余请求，就是某个不易察觉的功能已经失效了。

过多失败的请求

有见过一类或一组请求，n个成功之中夹着m个失败的，

非预期请求

比如一个常见的情况，应用退出后台，有些请求就没必要了，观察下自己的产品，是否在后台真的没有发出这些请求。

弱网测试

 弱网测试包括弱网功能测试（2G、3G、高延时、高丢包）、无网状态测试（断网功能测试、本地数据存储）、网络切换测试（wifi-4G、3G、2G 无网多状态切换）、用户体验关注（响应时间、页面呈现超时文案、超时重连、安全及大流量风险）。

弱网功能测试，这一部分主要是在各种非wifi网络下进行的功能测试，同时模拟高延迟和高丢包的异常网络环境进行健壮性测试。在windows下一般可以用fiddler 就可以模拟高延迟场景。

无网状态测试，是在没有网络环境下，关注页面的显示交互、本地数据的存储、断网功能的使用。断网情况下请求一个非本地数据的页面需要设定一定的时间等待上限，及时提示网络异常以及提示重试；无网状态测试建议按照页面划分进行，针对每个页面单独测试无网状态的显示，页面间跳转的显示，页面内功能的点击和显示，同时关注无网到有网时的恢复显示状态、数据上报情况是否正常。

网络切换测试，这部分主要是进行几个不同网络场景的切换，包括wifi-2G/3G/4G，wifi-无网、2G/3G/4G-wifi。主要关注页面的显示与交互，尤其是弱网到wifi，wifi到弱网的情况，是否会有页面crash以及显示的错误、session是否一致、请求堆积等

用户体验，弱网测试的目的就是保证用户体验，关注的关键点包括：

（1）页面响应时间是否可接受，关注包括热启动、冷启动时间，页面切换，前后台切换，首字时间，首屏时间等。

（2）页面呈现是否完整一致

（3）超时文案是否符合定义，异常信息是否显示正常

（4）是否会有超时重连

（5）安全角度，是否会发生dns劫持，登录ip更换频繁、单点登录异常等

（6）大流量事件风险，是否会在弱网下进行更新apk包、下载文件等大流量动作。

接下来我们使用fiddler 模拟高延迟场景

fiddler弱网模拟，主要是使用Rules>Performance>Simulate Modem Speeds 功能进行的网络延迟模拟，点击Rules>Customize Rulles进行设置，打开自定义的脚本编辑器，搜索delay

 if (m_SimulateModem) {
            // Delay sends by 300ms per KB uploaded.
            oSession["request-trickle-delay"] = "300"; 
            // Delay receives by 150ms per KB downloaded.
            oSession["response-trickle-delay"] = "150"; 
        }
这时间改为30000 ，就代表上传1kb 时间是30000ms，然后保存脚本，并且执行这个网速，使用Rules>Performance>Simulate Modem Speeds，就代表执行了刚才修改的网速。

SoloPi 下载安装

https://github.com/alipay/SoloPi/releases

专项测试原则，相同竞品之间 相同功能进行指标对比 ，相同的功能，在app各个版本上，这个指标进行对比，这个就是横向和纵向的对比。