写文章的原因:梳理思路,总结一下,在弱网络这块,简单聊聊自己做过之后的想法,对于工具怎么模拟的实际操作,其他博客一搜也一大把,主要是把整个过程梳理出来,自己遇到相同的情况,才知道怎么处理,也算是给其他想做弱网络测试的同学一些参考;
1、为什么要做弱网络测试
1)首先明白一点,弱网络是属于健壮性测试的一种
2)弱网环境下,缺少丢包、延时软件的处理机制,程序处理出问题,造成用户的流失;
用户在地铁里,巴士上,甚至是电梯,车库等场景使用(APP),2g/3g/4g/WiFi/假热点,来回切换;
3)这种非正常情况下,BUG概率会增加
例如:客户现场反馈一个操作步骤很简单就复现的BUG,自己死活复现不了,这时候就要考虑环境的因素,首先应该想到的是弱网;
4)什么场景需要做弱网络测试
实时同步性高的场景-微信视频聊天、远程会议,同步书写等
例如:直播功能 网络差会导致绿屏,花屏,条纹,丢帧等问题
2、怎么做弱网络测试
1)原理、工具介绍
基本弱网参数:延迟、抖动、丢包、乱序、重复、包损坏(篡改)、节流
工具介绍:Charles、Fiddler →这两款适合做手机代理,模拟弱网环境,便捷的做移动端的弱网络测试;
小缺点:延迟模拟比实际模拟值偏大,是因为网络有损耗;
clumsy → PC端,安装即用,非常方便,控制所有发送包或者收到包的速度,还能设定本地 ipv4 tcp/udp速度;
NEWT(Network Emulator for Windows Toolkit) NEWT的下载地址:https://blog.mrpol.nl/2010/01/14/network-emulator-toolkit/ (注意32和64位系统)
相对于NEWT,开源移动网络测试工具Augmented Traffic Control(ATC),可模拟移动APP延迟,丢包,断线等复杂的网络环境
linux自带工具TC命令 搭建较复杂,采用一端网口eth0进入,eth1出来(带弱网络)
linux2.4以上版本的内核中自带了有netem(net emulation)模块和tc(traffic contrl)模块,前者用于网络仿真,后者用于流量整形控制,都是通过tc命令进行配置
2)弱网络工具原理
网络请求→代理proxy(进行目标操作(修改返回值&延迟&丢包等))→返回给数据接收端
3)测试点分析
了解基本知识
1、丢包。丢包应该是最常见的问题。在TCP协议中,需要不停的发送请求,来确认连接状态,一旦发生丢包,就需要重传。这个时候就需要去检查产品的处理机制,给予什么提示,如果未响应怎么处理这些。
2、延时。延时也是很常见的问题。由于网络太差,产生了网络波动,导致数据包在传输的时候出现抖动。可能导致请求出现超时的现象。这个时候就需要给予相应的提示,或者是其他的处理方式。
对比遇到的问题
如果认为以上设计用例还不全面,也可从协议本身入手..
还有websocket..等等
3、怎么才是适合项目的弱网络测试用例
1)结合现有的东西
使用以上技术测试目前项目的现状,做成数据表格;
对标行业内其他产品抗弱网络的能力,竞品分析,做出表格;
控制变量,保证网络上下行一致,弱网络环境想同;
根据自己的测试用例延迟100ms/200ms往上加,丢包也类似10% 20%测出现状;
2)探讨标准
自己反思,怎么拿出有公信力的标准。
第一从产品竞争力方面来入手,如果抗弱网络低于**值,我们产品就没有竞争力了,同行都骑在我们头上了,销售方面压力很大;
第二从体验方面,体验方面,民用网络一般延迟,丢包是多少,我们产品在这个条件下都用不了,必须优化;
再反思,我们提了问题之后,开发就会说,你这个抗弱网络要求太高了,我们现阶段根本完成不了;
对策:根据现状,给出建议,跟产品探讨,推动开发,排优化计划,逐个版本优化,最终做到最好;
最后啰嗦几句:
其实这个跟做性能调优最后的环节类似,我们测试出了性能瓶颈,发现很多问题,开发也很头疼,就会尽可能回避这类问题,每个版本说做性能优化,优化2行代码也是优化,所以一定要做好自己的职责,问题具体化,要求开发写明优化点1 、2 、3具体做什么优化,需要多长时间,优化到什么程度,因为人都是有惰性的,没有具体的目标来提醒,就没有压力,就会导致项目无限期的延后;