fiddler弱网测试_移动端专项测试（下）

流畅度

流畅度，即每秒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，就代表执行了刚才修改的网速。

专项测试原则：

相同竞品之间 相同功能进行指标对比,比如流量；

相同的功能，在app各个版本上，这个指标进行对比各个指标的

横向对比，纵向对比