弱网测试总结

1、【背景】

弱网测试，属于健壮性测试的内容。随着国内移动端迅猛发展，大大增长用户碎片化使用使用APP的。想象一下，用户在地铁里，巴士上，甚至是电梯，车库等场景使用APP，咱们就须要针对这些场景的弱网环境下，验证出现丢包、延时软件的处理机制，避免因用户体验不友好形成用户的流失。

 

1.用户体验

APP使用过程当中，弱网的高延迟和高丢包，在实时性要求很是高的场景，容易伤害用户体验。

2.非正常状况下，出现bug几率会增长

在解决平常的支持需求中，常常会遇到一些用户反馈一些没法简单复现的bug，有很大一部分的bug是因为用户自身的网络环境波动，或者是自己网络环境就较为恶劣，而服务在面对这种恶劣的网络环境的健壮性不够，致使会出现一些意想不到的bug。

完成弱网工具环境搭建，来梳理下弱网测试场景和测试点。

2、【弱网测试场景】

既然APP异常测试中，弱网测试属于必须考虑的测试项，哪些业务适合验证，哪些不须要验证呢？如下是我的浅见，欢迎抛砖引玉：

1.结合APP自己属性

好比社交类APP（聊天、抢红包）对网络环境依赖性大且用户关注度高，弱网环境下须要重点关注。

结合互联网金融APP，申购流程中建立订单后是否支付成功，用户关注度最高（涉及扣费）。例如 弱网环境，建立订单失败，用户关注是否被扣费；建立订单成功后支付失败，再次支付是否重复扣费等。

2.使用频率&易遇到弱网的场景

好比微博APP【观看小视频】，用户在碎片时间极易【观看小视频】（APP用户喜欢使用碎片化时间进行娱乐操做），同时增长了【刷微博】（微博小视频和刷微博 操做场景重合）此处就须要增强弱网环境测试。

好比金融APP，用户在碎片化时间使用金融APP，领取奖品、查看理财类新闻、查看收益。

好的例子：据我所知，微信的升级就会监听用户是否插着电，连着wifi，一旦监听到了，就立刻告诉你，现场能够升级。

2、【弱网环境测试点总结】

1.场景：弱网环境下某个操做响应时间

缘由：APP用户对等待时间容忍度低，若弱网环境loading超过5s，用户很容易kill应用后再次进入应用。

【测试点】性能测试中，加入弱网环境测试点，检测各个场景网络请求的 API 消耗时间（此处能够放入性能测试中，作为衡量APP性能好坏的指标）。

2.场景：弱网环境下直至超时，UI界面友好度&APP是否稳定

缘由：容错机制主要是考虑弱网状况下带来的不稳定，常见的问题是：loading超时致使ANR or crash。

【测试点】弱网环境直至超时，断定为断网状态，UI界面和提示，友好且理解无歧义。

3.场景：断网后环境下，是否自动重发请求

缘由：不一样模块，开发对请求处理不一样。测试前可了解，代码是否支持自动重复请求，自动重发请求的频率是什么？

【测试点】断网后恢复网络，是否堆积网络请求（目前来讲 理财模块 当10s左右无返回 则会重发请求），此时请求和返回正常状况下，是否出现异常状况。好比1次支付操做，断网后堆积多个支付请求，恢复网络后因堆积多个支付请求，是否完成屡次支付。

ps：断网后恢复网络，考虑APP进行操做目的是否对伤害用户体验，经过哪一种手段 能够达到操做目的同时用户体验无感或者低伤害。

好比，微信但愿在线升级某些内容，会自动监听用户是否插着电 or 连着wifi，一旦监听符合上述场景，APP自动升级：

1）插电场景 确保升级过程当中，耗电不会致使手机低电量甚至没电。

2）wifi场景，确保升级过程当中，流量消耗不会使用用户话费中流量包，不会致使因消耗话费流量伤害用户体验

4.网络请求中，kill进程 （致使APP登陆态掉线）。

登陆同一个帐号成功，应该不继续相同网络请求（要和RD确认，程序实际实现）。

登陆不一样帐号成功，应该不继续相同网络请求（要和RD确认，程序实际实现）。

3、【常见弱网问题和缘由分析】

1.场景：上传大图或者多图时，在弱网络环境下出现进度条走到一半卡住而后又从头开始

缘由：采用分段上传方式，直至请求超时，分段传输没有结束，代码逻辑不对，致使每次重试都重头上传，一直循环。

2.场景：在弱网络环境下容易出现登陆不上或者登录后当即掉线

缘由：登陆没有缓冲机制，而请求超时时间的设置没有区分同网络状况。

解决方案：建议开发针对wifi、2g、3g、4g设置不一样的超时时间。

3.场景：刷新页面很快就给出暂无内容的提示，明显没有到请求超时时间

缘由：多是链接超时时间过短，wifi下设置两秒，在弱网下设置须要更长。

4.场景：弱网络环境下，请求的数据返回时间较长，等待的过程当中，若是页面上的相关控件仍然能够操做，则容易出现异常现（闪退现象、触发底部时得到原页面请求数据）

缘由：依赖数据的控件操做，在数据返回前没有作兼容处理。

5.场景：搜索时输入关键字会连续发请求，停下时，显示最终的关键字搜索结果，但很快又会被前面的关键字搜索结果覆盖了；

缘由：中间的请求返回较慢，显示了最终的结果后，以前的请求返回的数据应不作处理。