피들러 ---- APP 약한 네트워크 검사
HTTP : //www.51testing.com/html/01/n-3727001.html에서 이동
APP 약한 네트워크 시뮬레이션 테스트
PC의 종료점에서 다른 가변성 이동 단말 테스트 테스트는 네트워크로 서로 다른 네트워크 환경 및 네트워크 표준의 차이 앱을 사용하는 사용자에 일부 영향 것이다.
예를 들어 지하철로, 버스, 앱이 네트워크 이상 과정의 다양한 호환되지 않는 경우 엘리베이터 등으로, 사용자가 일상에있을 수 있습니다
삶의
다시 만남 APP 플래시, ANR, 데이터 손실 및 기타 문제. 따라서, 특히 약한 네트워크 테스트에서 응용 프로그램의 네트워크 테스트는 특히 중요하다.
아날로그 간단한 네트워크 환경을 달성하기 위해 다운로드 네트워크 트래픽 크기 설정 네트워크 시뮬레이션 모뎀 기능 들러 속도 향상, 사용 및 업로드하면 약한 네트워크 시뮬레이션 테스트, 즉, 네트워크 지연 시간 데이터 송신 데이터를 통해 다운로드하거나 수신 제한하기를 제공한다 속도와 업로드 속도, 제한 속도를 달성 할 수 있도록.
약한 네트워크 검사 3.1 예 --APP
파일 검색 키워드에서 Rules-> Cutomize 규칙에서 선택한 피들러 : m_SimulateModem;
m_SimulateModem, 즉, 개방형 네트워크 시뮬레이션 사실이다 수정 :
| var에 m_SimulateModem : 부울 = 거짓; |
다른 시나리오에게 약한 네트워크를 시뮬레이션 업로드, 다운로드 된 데이터를 수정 :
|
경우 (m_SimulateModem) {
// 지연 업로드 KB 당이 300ms로 전송한다.
oSession [ "요청 트리클 지연"] = "384";
// Delay receives by 150ms per KB downloaded.
oSession["response-trickle-delay"] = "2560";
}
|
上传1KB需要300ms，转化一下上传速度：1Kb/0.3s = 10/3(KB/s)，如果想设置上传的速度为50KB/s，你则需要设置Delay 时间为 20ms;（=1000/50）
PS:设置之后可以通过http://www.speedtest.cn/在线测试网速，看是否生效；
2G一般上行/下行速率约为：2.7、9.6kbs，模拟设置为：uploaded 约 2962 ms，downloaded 约 833 ms;（弱网一般指2G网络）
3G一般上行/下行速率约为：384、2560kbs，设置为：uploaded 约 2.6 ms，downloaded 约 0.39 ms;
PS：弱网模拟还可以通过其它工具实现，比如360WiFi的限速设置等；
3.2、扩展弱网络规则
可能在测试中不会想要一个同样虚弱的网络环境，而是随机强弱的网络，这样比较贴切真实情况，那么可以修改上述代码为：
|
static function randInt(min, max) {
return Math.round(Math.random()*(max-min)+min);
}
if (m_SimulateModem) {
// Delay sends by 300ms per KB uploaded.
oSession["request-trickle-delay"] = ""+randInt(1,2000);
// Delay receives by 150ms per KB downloaded.
oSession["response-trickle-delay"] = ""+randInt(1,2000);
}
|
这里的randInt(1,2000)应该很好理解，代表1-2000中的一个随机整数，这样就会出现偶尔有延迟偶尔网络又良好的情况。
4、前端性能分析及优化
前端性能在一定程度可以提升用户体验，而前端的性能数据可以通过fiddler的Statistics和Timeline来获取，从而为性能分析及优化提供依据。
4.1、实例--前端性能数据获取分析
通过陈列出所有的HTTP通信量，Fiddler可以很容易的向您展示哪些文件生成了您当前请求的页面。使用Statistics页签，用户可以通过选择多个会话来得来这几个会话的总的信息统计，比如多个请求和传输的字节数。
选择第一个请求和最后一个请求，可获得整个页面加载所消耗的总体时间。从条形图表中还可以分别出哪些请求耗时最多，从而对页面的访问进行访问速度优化。
同时，还可以通过Timeline分析资源加载时序图，可以很直观地看到页面上各个资源加载过程所需要的时间和先后顺序，有利于找出加载过程中比较耗时的文件资源，帮助我们有针对性地进行性能优化。
5、小结
总的来说，fiddler是移动互联网测试的利器，除以上介绍的这些常见的日用场景外，还有很多其它用途，如域名的重定向、API的测试等，这里就不一一列举，如有兴趣，可抽空一起探讨。
转自：http://www.51testing.com/html/01/n-3727001.html
APP弱网模拟测试
移动端测试区别于PC端测试的一点就是网络的多变性；不同的网络环境和网络制式的差异，都会对用户使用app造成一定影响。
例如：进地铁、上公交、进电梯等，如果app没有对各种网络异常进行兼容处理，那么用户可能在日常
生活中遇到APP闪退、ANR、数据丢失等问题。因此，app网络测试，特别是弱网测试显得尤为重要。
利用fiddler的Simulate Modem Speeds功能，可以通过设置网络的上传、下载的网络流量大小来达到模拟弱网环境，从而实现弱网模拟测试，即通过延迟发送数据或接收的数据的时间来限制网络的下载速度和 上传速度，从而达到限速的效果。
3.1、实例--APP弱网测试
fiddler中选中Rules->Cutomize Rules，在文件中搜索关键字：m_SimulateModem；
修改m_SimulateModem值为true，即开启网络模拟：
| var m_SimulateModem: boolean = false; |
修改uploaded、downloaded的数据来模拟不同的弱网场景：
|
if (m_SimulateModem) {
// Delay sends by 300ms per KB uploaded.
oSession["request-trickle-delay"] = "384";
// Delay receives by 150ms per KB downloaded.
oSession["response-trickle-delay"] = "2560";
}
|
上传1KB需要300ms，转化一下上传速度：1Kb/0.3s = 10/3(KB/s)，如果想设置上传的速度为50KB/s，你则需要设置Delay 时间为 20ms;（=1000/50）
PS:设置之后可以通过http://www.speedtest.cn/在线测试网速，看是否生效；
2G一般上行/下行速率约为：2.7、9.6kbs，模拟设置为：uploaded 约 2962 ms，downloaded 约 833 ms;（弱网一般指2G网络）
3G一般上行/下行速率约为：384、2560kbs，设置为：uploaded 约 2.6 ms，downloaded 约 0.39 ms;
PS：弱网模拟还可以通过其它工具实现，比如360WiFi的限速设置等；
3.2、扩展弱网络规则
可能在测试中不会想要一个同样虚弱的网络环境，而是随机强弱的网络，这样比较贴切真实情况，那么可以修改上述代码为：
|
static function randInt(min, max) {
return Math.round(Math.random()*(max-min)+min);
}
if (m_SimulateModem) {
// Delay sends by 300ms per KB uploaded.
oSession["request-trickle-delay"] = ""+randInt(1,2000);
// Delay receives by 150ms per KB downloaded.
oSession["response-trickle-delay"] = ""+randInt(1,2000);
}
|
这里的randInt(1,2000)应该很好理解，代表1-2000中的一个随机整数，这样就会出现偶尔有延迟偶尔网络又良好的情况。
4、前端性能分析及优化
前端性能在一定程度可以提升用户体验，而前端的性能数据可以通过fiddler的Statistics和Timeline来获取，从而为性能分析及优化提供依据。
4.1、实例--前端性能数据获取分析
通过陈列出所有的HTTP通信量，Fiddler可以很容易的向您展示哪些文件生成了您当前请求的页面。使用Statistics页签，用户可以通过选择多个会话来得来这几个会话的总的信息统计，比如多个请求和传输的字节数。
选择第一个请求和最后一个请求，可获得整个页面加载所消耗的总体时间。从条形图表中还可以分别出哪些请求耗时最多，从而对页面的访问进行访问速度优化。
同时，还可以通过Timeline分析资源加载时序图，可以很直观地看到页面上各个资源加载过程所需要的时间和先后顺序，有利于找出加载过程中比较耗时的文件资源，帮助我们有针对性地进行性能优化。
5、小结
总的来说，fiddler是移动互联网测试的利器，除以上介绍的这些常见的日用场景外，还有很多其它用途，如域名的重定向、API的测试等，这里就不一一列举，如有兴趣，可抽空一起探讨。