弱网测试的三个关键参数：上传速率、下载速率 、丢包率
验证丢包、延时的程序的处理机制
在非正常情况下，出现bug的概率会增加：
解决日常需求的支持外，会遇到用户反馈的一些无法简单复现的bug，有很大一部分原因是用户自身的网络环境波动。服务在面对这种网络恶劣的健壮性不够，就会出现一些意想不到的bug。
做弱网测试的目的：让app上线前提前预知在较差网络环境下的表现，以提前发现问题，进行针对性优化。
常用的模拟弱网的方法：
①在代理服务器上设置模拟恶劣环境的参数，使得通过这些代理服务器的流量都被转化为恶劣环境下的流量，如使用fildder、charles
②利用底层的驱动服务，控制网卡的收包发包的行为，模拟恶劣的网络环境
实际生活场景可做弱网测试：地铁/电梯
一、手机app上的弱网测试
配置fildder、charles。特有的，Qnet工具
二、PC端网页上的弱网测试
配置fildder、charles
弱网环境下的测试点关注：
一、弱网下某个操作响应时间
原因：APP用户对等待时间容忍度低，若弱网环境loading超过5s，用户很容易kill应用后再次进入应用
【测试点】性能测试中，加入弱网环境测试点，检测各个场景网络请求的 API 消耗时间（此处可以放入性能测试中，做为衡量APP性能好坏的指标）
二、弱网环境下直至超时，判定为断网状态，UI界面友好度&APP是否稳定
原因：容错机制主要是考虑弱网情况下带来的不稳定，常见的问题是：loading超时导致ANR or crash
【测试点】弱网环境直至超时，判定为断网状态，UI界面和提示，友好且理解无歧义
三、断网后恢复，是否自动重发请求
原因：不同模块，开发对请求处理不同。测试前可了解，代码是否支持自动重复请求，自动重发请求的频率是什么？
【测试点】断网后恢复网络，是否堆积网络请求（目前来说 理财模块 当10s左右无返回 则会重发请求），此时请求和返回正常情况下，是否出现异常情况。比如1次支付操作，断网后堆积多个支付请求，恢复网络后因堆积多个支付请求，是否完成多次支付
ps：断网后恢复网络，考虑APP进行操作目的是否对伤害用户体验，通过哪种手段 可以达到操作目的同时用户体验无感或者低伤害
比如，微信希望在线升级某些内容，会自动监听用户是否插着电 or 连着wifi，一旦监听符合上述场景，APP自动升级：
1）插电场景 确保升级过程中，耗电不会导致手机低电量甚至没电
2）wifi场景，确保升级过程中，流量消耗不会使用用户话费中流量包，不会导致因消耗话费流量伤害用户体验
四、网络请求中，kill进程（导致APP登录态掉线）
登录同一个账号成功，应该不继续相同网络请求（要和RD确认，程序实际实现）
登录不同账号成功，应该不继续相同网络请求（要和RD确认，程序实际实现）
弱网环境demo
1.场景：上传大图或者多图时，在弱网络环境下出现进度条走到一半卡住然后又从头开始
原因：采用分段上传方式，直至请求超时，分段传输没有结束，代码逻辑不对，导致每次重试都重头上传，一直循环
2.场景：在弱网络环境下容易出现登录不上或者登陆后立即掉线
原因：登录没有缓冲机制，而请求超时时间的设置没有区分同网络情况
解决方案：建议开发针对wifi、2g、3g、4g设置不同的超时时间
3.场景：弱网络环境下，请求的数据返回时间较长，等待的过程中，如果页面上的相关控件仍然可以操作，则容易出现异常现（闪退现象、触发底部时获得原页面请求数据）
原因：依赖数据的控件操作，在数据返回前没有做兼容处理
（侵删）
https://www.cnblogs.com/xiao-qing/p/9431600.html