首先网络测试不是新概念。早在富客户端时代，网络已经是常规测试中不可或缺的一项了。由于PC端时代，通常不存在弱网情况，所以大部分测试会聚焦在网络异常，即断网情况，如：
　　·异常信息
　　·容错机制
　　·超时机制
　　·重连机制
　　到了移动时代，网络的形态也不再是单一的有线连接。2g/3g/edge/4g/wifi，不同的协议，不同的制式，不同的速率。场景也更加丰富，空旷的大街，拥挤的地铁，快速飞驰的汽车。流量就是钱，凡是和钱相关的事情，就是大事。所以对于应用开发和测试都有不小的挑战。那从测试角度来说，需要关注的就远不止断网情况了。我试着从功能，性能，稳定，异常处理，场景特性等几个维度来归纳下，当然一切都是为了用户体验：

　　功能
　　在做弱网下，做功能测试，不仅是次性能测试，也是一种可靠性测试。就像公交车虽慢，但总能送你到目的地。如果在业务方明确要求的网络情况下，基本功能不能保证的话，这个应用是不合格的。通常来说，我们应该要求至少在一种弱网的理想情况下把所有的功能都走一遍，比如联通的WCDMA或者移动的Edge。弱网的高延迟和高丢包，往往会伤害到实时性要求非常高的应用或者场景。
　　你要对业务有更高的敏感度，要清楚哪些业务出问题的几率比较大。当然也不要强人所难，网络实在不行，就不要聊重要的事情了。

　　响应时间
　　这是性能维度。有人会说流畅度，加载时间，这里就用响应时间代表。以前有个三秒定律，是说网页加载如果超过三秒，就会开始流失用户。这个三秒也被用进了移动应用。我们通常会测试很多场景的响应时间，比如：
　　·热启动
　　·页面切换
　　·前后台切换
　　启动时间久了，iOS 和 Android 都不会给你好脸色看。Android 5 秒 ANR， iOS 大概 20 多秒。而对于性子急的用户，直接就杀应用了，所以如果发现主线程里非得干网络 IO 的事情，那么弱网更需要测试了。页面切换也是同样的情况，一般 native 的会好很多。如果遇到 HTML5 页面，各种白屏，闪屏，转菊花，那体验就糟糕透顶了。这个时候，作为测试就要需要拿一套 HTML5 的性能数据去挑战开发了，
　　·首字时间
　　·首屏时间
　　·是否有302跳转
　　·页面大小
　　·是否开启 GZip
　　喂，你要好好看看 HTML5 性能优化的文章啊。
　　那 native 的数据可以用高速摄像机，GoPro或者iPhone5s+摄像头拍摄后数帧获得，也可以自己埋点（让开发帮忙埋更加靠谱）。HTML5的数据可以通过 Chrome 或者 Safari 的 remote debug 来获取。
　　除了直观的时间测试，我们还需要做各个场景网络请求的 API 消耗时间。当今的手机硬件，在本地渲染数据，事实上已经很难存在瓶颈了。很多时候，是网络请求的 API 返回的慢。我们需要观测的数据有：
　　·整体时间
　　·response body 大小
　　从这两个数据，来推断是服务器处理的慢，还是需要治理传输包了。如果时间很少，body又小，还很慢的话，这下就是客户端代码写的烂了。
　　强网络形态场景测试
　　如果你开着4G，然后一不小心打开了一个高清在线视频，刷刷刷，就欠费上万了，你的胸中必须有千万头草泥马了吧。这就是强网络形态场景，有些场景就必须是开着wifi才能做的，有些场景必须对 2g 优化的。这事情开发必须清楚，他不清楚的话，测试需要帮忙测试出来。
　　据我所知，微信的升级就会监听用户是否插着电，连着wifi，一旦监听到了，就马上告诉你，现场可以升级。之前论坛里有人报过支付宝的bug，说一开应用刷刷几个M就没了，事实上，这是因为支付宝内部的 html5 应用包升级，就没有对具体网络场景做判断，导致用户心疼了把流量。
　　所以在设计这一块测试用例的时候，最好和开发，pd一起讨论下，毕竟只有pd定了，开发写了，才能测的安稳。这块的测试就必须上真机真卡了，目前为止还没有哪位同学模拟出基站来的。
　　异常机制
　　这块其实传统互联网时候做的很多了。对于用户而言，可怕的不是遇到问题，而是遇到问题不知道为什么，所以异常信息的文案一定要做的漂亮，否者就等着数不清的反馈和投诉吧。
　　容错机制主要是考虑弱网情况下带来的不稳定，等待超时 ANR了，或者直接异常闪退了。这些的处理，一定要做的优雅，不能粗鲁。由自己控制总好过系统控制，会让用户看出产品的用心。
　　重连机制涉及两块，一块是客户端是否会重发请求，一块是服务端是否接受重连。配合超时机制，多久没有得到反馈才会发起重连，失败几次会不允许重连，重连是否会让服务器重复写或者写重复？
　　这块测试就需要制造异常，无论从服务端还是客户端，还是人为制造。举个例子，重连测试，给个延迟很高的热点，或者用代理工具伪造一个延迟很高的proxy，就可以触发超时了。
　　无网状态测试
　　无网络其实是异常机制中的一种，之所以单独拉出来讲，是因为这里很容易发现问题。首先，页面呈现。做的好的应用会直接规避掉，如果无网络，直接退出到登陆界面。而做的差，就给你一个残页给你，这是非常糟糕的设计。数据完整性和session一致性其实是一样的，这个在金融交易或者即时游戏中很重要。比如你打副本打的很开心，然后突然地铁钻下去了，没网了，副本还在进行，你可能都不知道已经没网了。在网络恢复之后，会是怎样一个状态？另外，还需要关注的是，无网状态下会不会还不断的请求网络，不断的做网络相关的操作。从无网状态恢复到有网络，会不会有请求堆积？
　　请求堆积
　　这一点我没有放到 mind 图里，是因为这个情况在弱网情况下时时都可能发生。比如你通过某做的很烂的应用，向某人转钱，网络不好，出现了再试一次，然后你比较傻，点了个四五次（我一般都不点）。然后突然网络好了，你转出去四五笔钱。你不心态流量也心态钱啊。
　　总结
　　我大致讲了讲，移动网络也是我转到支付宝做商户APP专项中的一项，提到的这些肯定都是遇到的坑和即将遇到的坑，总觉有什么地方遗漏了，希望大家帮忙补充。最近家里养了金鱼，记忆力也被传染了。