APP测试弱网测试

1、为什么要做弱网测试
当前APP网络环境比较复杂，网络制式有2G、3G、4G网络，还有越来越多的公共Wi-Fi。不同的网络环境和网络制式的差异，都会对用户使用app造成一定影响。
另外，当前app使用场景多变，如进地铁、上公交、进电梯等，使得弱网测试显得尤为重要。
2、如何做弱网测
1、SIM卡的网络切换：手机-设置-移动网络设置-网络类型选择

 2、具体弱网场景测试，常见场景包括：地铁/巴士、电梯、楼梯间、停车场
3、使用虚拟机模拟网络速度，如用树莓派搭建的弱网测试仪
4、使用软件进行网络代理，模拟不同的网络带宽、延时率、丢包率
3、弱网模拟常用工具
①fiddler主要用来抓包定位bug
②Charles
抓包原理：通过控制发送数据或接收数据的大小来限制网络的上传和下载
Charles测试配置步骤：
首先，打开Charles，在Throttle Settings中设置网络状况，点击proxy—》throttling settings
勾选【enable throttling】使得限制网速可用，相当于开启了限制网宿的功能
关于网速的选择：
概念介绍：Bandwidth（带宽）、Utilistation（利用百分比）、Round-trip（往返延迟）、MTU（最大传输单元）
3G：300k-2Mbps左右
2.5G(GPRS)一般在100kbps
2G（GSM）一般在5-9kbps
如果不习惯自定义设置带宽等，可直接在Throttle Preset下拉列表中选择，按照顺序，网速逐渐提升
只对某地址的请求进行弱网测试，勾选【only for selected hosts】

4、常见错误现象
1、用户登录应用时下载初始化大数据，下载过程中因网速太慢点击取消重新登录，数据初始化完成后出现重复，导致数据不一致
原因：数据下载过程中，下载失败后，未进行数据回滚，中止后重新下载，出现数据重复
解决：通过事务处理数据下载逻辑，可以是下载失败后，应用本地数据库进行数据回滚
2、用户点击数据上传，数据上传过程中网络弱或不稳定，基于联网状态自动触发数据上传，导致出现数据重复写入，造成脏数据
3、原因：数据上传过程中，由于失败重传机制，会出现连续2次写操作，并且未做唯一识别处理
解决方案：根据数据特性，对可能造成脏数据的地方，通过关键字段，例如创建时间，key-value值等生成hash值，标记记录唯一性，即数据写入时，检查hash键师傅存在，如果存在不在新增
4、在弱网环境下，用户输入用户名和密码点击登录，应用链接超时返回用户名和密码错误提示
原因：在弱网环境下的连接超时后，按照业务逻辑处理，导致返回超时异常
解决方案：弱网连接超时后，检查应用本地数据库是否有用户登录信息，若存在，获取本地用户信息登录
5、在弱网环境下，用户输入用户名和密码点击登录，登录过程中应用崩溃并闪退
原因：弱网环境下数据下载超时，加载数据严重依赖于后来的异步加载，数据还没来得及返回，应用跳转到下个activity，导致崩溃
解决：健壮数据加载流程，通过标记后台数据下载状态加载界面，依赖数据下载完成后，再进行页面跳转
6、弱网环境下，用户请求页面响应时间较长，等待的过程中页面部分控件仍然可以操作，当用户点击控件时，出现闪退现象
原因：没有对数据加载流程进行判断，直接暴露控件可控，当出现依赖数据的控件操作时，没有再数据返回前做兼容处理
解决：再数据加载过程中，设置页面对外暴露的控件为“不可操作”，当数据加载完再释放
7、弱网环境下，用户第一次输入搜索关键字没有得到响应后，再次输入全新的关键字并发送请求，等待搜索结果返回后，当期结果页被之前的关键字搜索结果刷新覆盖
原因：中间的请求返回较慢，显示最终的结果后，之前的请求返回的数据应不做处理，客户端经常做一种处理，请求对象发送返回失败，客户端会重试，请求必须是异步进行的，此时可 能会出现重试失败，仍然一直在发请求，重试策略有问题
解决：对异步请求未完成的任务进行cancel
8、弱网下，页面加载过程中程序闪退
原因：webview超时处理未在UI线程。Toast、关闭页面等操作需要再UI线程。
9、302跳转页面，达到内置超时阀值后，webview自动关闭
原因：业务员有页面加载超市自动关闭的逻辑，超时机制未考虑302场景

 

5、测试要点

 

应用
1.场景：互联网金融APP，申购流程中创建订单后是否支付成功，用户关注度最高（涉及扣费）。
测试点：弱网环境，创建订单失败，用户关注是否被扣费；创建订单成功后支付失败，再次支付是否重复扣费等。
2.场景：弱网环境下直至超时，ui界面友好&app是否稳定
测试点：弱网环境直至超时时，判定为断网专题，UI界面和提示友好（若容错机制主要是考虑弱网情况下带来的不稳定，常见的问题是：loading超时导致ANR ：application not respanding）or crash
3.场景：断网后环境下，是否自动重发请求
测试点：断网后恢复网络，是否堆积网络请求（目前来说 理财模块 当10s左右无返回 则会重发请求），此时请求和返回正常情况下，是否出现异常情况。比如1次支付操作，断网后堆积多个支付请求，恢复网络后因堆积多个支付请求，是否完成多次支付。
4.场景：微信希望在线升级某些内容，会自动监听用户是否插着电 or 连着wifi，一旦监听符合上述场景，APP自动升级
测试点：
1）插电场景 确保升级过程中，耗电不会导致手机低电量甚至没电。
2）wifi场景，确保升级过程中，流量消耗不会使用用户话费中流量包，不会导致因消耗话费流量伤害用户体验
6、网络测试的一般流程
step1：首先要考虑网络正常的情况
①　各个模块的功能正常可用
②　页面元素/数据显示正常
step2：其次要考虑无网络的情况
①　APP各个功能在无网络情况下是否可用
②　APP各个页面之间切换是否正常
③　发送网络请求时是否会导致闪退、卡死等异常情况
④　APP各个页面是否显示完整美观，未刷新的页面是否做了相应的提示和处理
⑤　在无网络情况下数据是否会丢失
⑥　无网络提示信息是否友好
step3：再次考虑弱网情况
①　弱网情况下APP是否针对请求做了超时处理
②　网络延迟的情况下，操作app进行数据同步、OTA升级是否会发生Crash、ANR等严重错误
③　弱网情况下，APP请求回调未完成时，执行其他动作以及交互时，是否会出现APP闪退（如：驾考IOS开屏闪退）等异常。
④　弱网情况下，原始数据是否出现丢失的情况（弱网下载时会出现丢包情况）
⑤　弱网环境下，是否会出现请求堆积的情况
⑥　弱网环境下，APP各个页面是否显示完整
⑦　系统超时，提示信息是否清晰明确
⑧　弱网情况下APP的响应时间是否在一个合理的时间范围内
⑨　请求回调未完成–XXX项目XX难题攻克弹窗
⑩　这个弹窗是服务器说了算，服务器知道该用户啥时候弹弹窗。若用户在做题页面时返回了，则该用户下次进入且在服务器缓存时间内，应该给出弹窗（产品逻辑：弹窗出现后用户必须看到才消失）
⑪　请求堆积：水池注水排水问题
step4：最后考虑网络状态之间的转变
①　断开网络连接以后，操作APP各个功能是否正常
②　同步数据过程中，断开网络连接，APP是否出现异常情况
③　传输数据过程中，网络由wifi切换到gprs，APP是否出现异常情况
④　弱网环境下发送的请求是否在恢复网络以后出现重复提交的情况