如何做 Android 应用流量测试.docx

如何做 Android 应用流量测试.docx

《如何做 Android 应用流量测试.docx》由会员分享，可在线阅读，更多相关《如何做 Android 应用流量测试.docx（11页珍藏版）》请在冰豆网上搜索。

如何做Android应用流量测试

如何做Android应用流量测试

前言

我们经常手机应用有这样的困惑：

想知道应用费不费流量；想知道某几款同类应用，做同样的事儿，哪个更省流量；更深入的，想知道一款应用为什么这么费流量，流量都消耗在哪了；想知道在大4G时代，一觉醒来怎么房子车子就变成别人的了。

。

本文将介绍给您，解答上述困惑的简单方法。

工具

GT（中文产品名称：

随身调）：

是腾讯出品的开源调试工具，本次测试中用其进行手机的流量统计和抓包。

请在Android手机上安装GT应用（可以通过官网或应用宝下载）。

Wireshark：

抓包的分析工具，也提供了Android手机的抓包实现，GT中抓包的功能就是在其提供的实现基础上的易用性封装，本次测试中用Wireshark进行抓包的分析。

请在PC上安装Wireshark。

正文

其实想知道一款应用费不费流量，大部分Android4.x版本系统已经可以简单的查看了：

关注流量比较粗的话，看一下上面这里也就够了，但从测试的需求看，这里只能观察到宏观的流量情况，到1天的流量消耗就没法再细化了，如果想知道具体一个业务操作或一段时间内的流量消耗呢？

如果想知道应用一次启动的流量消耗呢？

这时就该使用前面介绍的工具了。

比前面稍微深入一些，我们可能需要知道一个业务操作过程内，消耗的流量，及发出请求的流量、收到响应结果的流量各有多少，并且流量的消耗曲线是怎样一个走势。

这时就该使用GT，关于GT的基本使用和为什么用GT，GT网站有详细的说明，这里只介绍和流量相关的部分。

GT提供了一种简单的测试方式，也提供了一个严谨但麻烦的测试方式。

首先我们来看简单的方式：

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

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

3.退到应用界面，执行需测试的业务操作。

4.业务操作后，回到GT界面，停止流量数据的采集，查看本次业务操作流量的变化。

到这里，从前面一张图我们已经可以知道一个业务操作过程中消耗的流量，包括发出请求的流量、收到响应结果的流量、流量消耗曲线是怎样一个走势了。

5.我们可以保存本次测试结果到文件，以备后面更深入的分析。

参观一下这个文件：

用强大的Excel把GT应用里显示的趋势图还原出来不是难事。

我们再来看看麻烦而严谨的方式：

如果只是纯粹测测流量，上面的方式也足够了，那我们为什么需要麻烦而严谨的方式呢？

这里有两个原因，一个是仅仅知道流量的大小和趋势，还不足以对后续的流量优化进行明确的指导，即知道流量可能有点多，但不知道该如何着手优化。

另一个是原因是弥补上面方式的一个不足：

有的应用，使用了本地socket和手机里其他进程产生交互，有时候Android系统会把这种手机内部的socket传输的数据量也计算到应用消耗的流量里（比如常见的视频应用不少都有这个问题），此时上面的方式就显得不够准确了，要获得真是网卡上发生的流量，就需要抓包这种终极方法了。

注意掌握这种方法的前提是您得先掌握基础的TCP和HTTP网络知识。

手机抓包是针对手机的网卡，所以这种方式无法单独抓一个应用的包，需要后续将归属于应用的包分析出来，而为了后续分析减少工作量，测试时候应尽量把其他能消耗流量的应用都关了。

Android手机的抓包是Wireshark提供的实现，GT上面做了封装，使手机可以不必连着PC即可抓包，方便在室外测试的场景。

1.先从GT启动抓包。

2.之后还是执行测试的业务操作。

3.被测业务操作结束后，点击stop，即停止抓包，并把抓包文件保存在对应的目录中。

将抓到包文件导入到PC，用Wireshark即可分析抓包文件。

关于Wireshark的使用，和PC上的使用没有区别，请大家自行在网上搜索，这里仅对使用Wireshark的要点提示下：

1我们最先需要知道我们的应用发出了哪些请求，对应了上行流量，可以在Wireshark左上角【过滤】框输入"http"或"tcp"（如果确认过被测应用都是http请求，就只需要按http过滤）,确认测试场景GET和POST的请求类型和个数（过滤结果可按【Info】分类更方便统计）。

2在具体请求上可以右键“followtcpstream”，等同于过滤条件tcp.streameqxx，这样可以过滤出和它在同一个TCP流的消息。

3过滤条件出来后再点击【统计】->【概要】，对应Bytes栏【显示】列的数据即为流量。

4通过对包的过滤分析，我们自然就可以得到流量的大小，产生流量的类型和原因，请求的频率，这样就能够对后续的流量优化进行指导了。

5更谨慎的，抓包和GT采集流量数据可以相互对照，避免分析时有所遗漏。

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

如果看流量的绝对值看不出高低，那就找几个同类型的产品对比一下。

如果完成同样的事务，被测应用比同类产品高很多，那就是偏高了，可能有优化空间。

如何找到有效的优化点

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

常见的流量问题

最后简单例举几类可控的比较容易优化的流量问题给大家：

1）冗余内容

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

错误的处理方式是每次请求服务器都返回一次静态信息。

2）冗余请求

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

3）无用请求

有的请求，你会发现谁也不知道它是干嘛的，很可能是以前版本遗留下来的无用请求，或者是引用的其他代码包偷偷发出的，甚至是间谍请求，请收集一切证据后，毫不犹豫的干掉它

4）永远无法得到回应的请求

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

5）过多的失败请求

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

举个简单的场景，某类请求，间隔1分钟后连续发两次，总是先有一次失败的请求，1s后马上再次发出一次同样的请求就成功了（这里1s后发出的请求是指业务逻辑层判断前面请求失败后延迟1s后重传的）。

很好奇为什么第一次总失败是吧，就有这么种情况，客户端两次请求乐观的想要复用同一个TCP连接（长连接半长连接），但是服务端不这么想，也许是客户端发起两次请求的间隔，超出了服务端长设置的长连接无响应时限。

。

如何判断呢？

看看失败的那次请求，是否和前一次成功的请求复用了同一个TCP连接（体现在Wireshark的streamId）。

6）非预期请求

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