App性能测试——使用GT监控手机流量

使用GT测试流量：
对流量要求没有那么严格的话可以在安卓的设置里面查看
Wireshark：抓包分析工具，也提供了安卓手机的抓包实现，GT中抓包的功能就是
在其提供的实现基础上的易用性封装起来，在本次测试中用wireshark进行抓包分析。PC端安装

如果我们可能需要知道一个业务操作过程内，消耗的流量，及发出请求的流量，收到的响应结果的流量各有多少，并且流量的消耗曲线是一个什么走势，这个时候我们就需要GT了，这里GT提供了两个方法一种进行简单的测试方法，也提供了一个严谨但麻烦的测试方法

1.在安卓查看APP消耗的流量：
设置——》流量管理———》流量排行、
接下来我们使用GT监控APP流量的测试：
首先我先来介绍这种简单的方式

1. 先将应用运行起来，然后启动 GT 并在 GT 上选中被测应用及被测项 NET（流量）。
   

2.业务操作前，启动数据采集，将会记录选中应用的流量的变化，为了方便统计，可以先 把业务操作前发生的流量记录归零。

3.退到应用界面，执行需测试的业务操作。
4.业务操作后，回到 GT 界面，停止流量数据的采集，查看本次业务操作流量的变化。

我们再来看看麻烦而严谨的方式：
如果只是纯粹测测流量，上面的方式也足够了，那我们为什么需要麻烦而严谨的方式 呢？这里有两个原因，一个是仅仅知道流量的大小和趋势，还不足以对后续的流量优化进 行明确的指导，即知道流量可能有点多，但不知道该如何着手优化。另一个是原因是弥补 上面方式的一个不足：有的应用，使用了本地 socket 和手机里其他进程产生交互，有时候 Android 系统会把这种手机内部的 socket 传输的数据量也计算到应用消耗的流量里(比如常 见的视频应用不少都有这个问题)，此时上面的方式就显得不够准确了，要获得真是网卡上 发生的流量，就需要抓包这种终极方法了。注意掌握这种方法的前提是您得先掌握基础的 TCP 和 HTTP 网络知识。
手机抓包是针对手机的网卡，所以这种方式无法单独抓一个应用的包，需要后续将归属 于应用的包分析出来，而为了后续分析减少工作量，测试时候应尽量把其他能消耗流量的应 用都关了。Android 手机的抓包是 Wireshark 提供的实现，GT 上面做了封装，使手机可以不 必连着 PC 即可抓包，方便在室外测试的场景。

注意这里需要在PC端安装一个Wireshark 	

好了 我们第一步 ：点击插件 —>>选择抓包

看来这里 你们需要准备一个Wireshark 这个工具直接百度下载就好
把文件下载到电脑上面，选择Wireshark 打开选择统计下面的第一个

通过对包的过滤分析，我们自然就可以得到流量的大小，产生流量的类型和原因，请 求的频率，这样就能够对后续的流量优化进行指导了。
常见的流量问题 最后简单例举几类可控的比较容易优化的流量问题给大家：  1.冗余内容
同类请求被间隔执行，请求的内容包含一些相对静态的信息，正确的处理是第一次请求 包括静态信息就好，后面的同类请求只包含必要的即时变化信息即可。错误的处理方式是每 次请求服务器都返回一次静态信息。
1.冗余请求
有的时候会发现应用短时间内发出多个同样的请求，收到结果也都几乎一样，这种情况 应该尽量减少请求次数，同时注意排查程序逻辑错误，也许问题不像表面看起来那么简单。 
2.无用请求
有的请求，你会发现谁也不知道它是干嘛的，很可能是以前版本遗留下来的无用请求， 或者是引用的其他代码包偷偷发出的，甚至是间谍请求，请收集一切证据后，毫不犹豫的干 掉它。 

3.永远无法得到回应的请求
如果见到某类请求永远的连接失败或被返回 404 之类的失败结果，那它不是历史遗留的 多余请求，就是某个不易察觉的功能已经失效了。 
4…过多的失败请求
有见过一类或一组请求，n 个成功之中夹着 m 个失败的吗？举个简单的场景，某类请 求，间隔 1 分钟后连续发两次，总是先有一次失败的请求，1s 后马上再次发出一次同样的 请求就成功了（这里 1s 后发出的请求是指业务逻辑层判断前面请求失败后延迟 1s 后重传 的）。很好奇为什么第一次总失败是吧，就有这么种情况，客户端两次请求乐观的想要复用 同一个 TCP 连接(长连接半长连接)，但是服务端不这么想，也许是客户端发起两次请求的间 隔，超出了服务端长设置的长连接无响应时限。。如何判断呢？看看失败的那次请求，是否 和前一次成功的请求复用了同一个 TCP 连接（体现在 Wireshark 的 streamId）。 
5.非预期请求
比如一种常见的情况，应用退后台后，有些请求就没必要了，观察下自己的产品，是 否在后台真的没有发出这些请求

欢迎各位大佬小白加入软件测试提升群：337237612