“纸上得来终觉浅”
最近一做ios的朋友遇到一个问题：产品说他做的app加载页面老是转圈，他认为是接口返回的慢，可是拿不出有信服力的证据。作为一名测试，抓包看接口返回时间不是经常做的事嘛，以Charles为例：
这个duration就是接口从请求到返回的时长嘛~
可是只从这个指标貌似无法说明后端接口处理的慢啊，毕竟这个是包括了DNS寻址、建立连接、网络传输、后端处理、断开连接等系列因素在内的。
于是乎我想到了Charles里Overview里有一个Timing属性，里边是各个处理过程的时长，如下图所示：
Timing中的各个字段
作为一个英语战五渣，从字段上看觉得应该是response的时间就是服务器的处理时间，我截好图准备发送给好友。这时候我突然想，要不我自己验证一下，response后边的时间会不会随着服务器处理时间增长而增长？
本着实事求是、认真负责的态度，我决定自己先验证一下。如下图所示，我在接口处理过程中加入“睡罗汉”代码：
睡罗汉代码实例
根据单一变量原则，通过修改sleep时长，观察request后边的时间来证明结论。结果自不必说，打脸总是来得很快：request时长并没有按我sleep的秒数增加。不过我观察到，Latency这个字段却跟着我sleep增加了。what？莫非这个字段才是服务器处理时延指标？
不行，作为一个实事求是、认真负责的QA，我 百度 了一下，没有搜索到Charles关于Latency和Timing的解释。于是乎我决定去Charles的官网一探究竟：
Charles官网对latency的解释
找了好长时间总算找到了相关解释，根据官网的解释，这个latency包括了接口处理延时和网络延时。这下就好办了，内网里的网络延时几乎可以忽略不计。如果是外网，也可以两个接口的latency差值确定某个接口的服务器处理延时比较高。
如果是fiddler进行抓包，问题更简单了。如下图所示，fiddler右侧的Statistics里ServerBeginResponse和ServerGotRequest时间差值就是服务器处理时长~~~
fiddler表现优秀
总结：Charles的Timing里的latency才是服务器处理时间的指标，但是也包括了网络延时；不能犯经验注意错误，只有经过验证的结果才有说服力。
网友评论