2020-11-09

IOS性能测试分类

录像分帧计时法

使用打日志的方式的方式，可以直接获得速度数据，能快速得出结果。而使用图像的方式则是一个繁琐的过程。首先得找到起始的两张图片，分别是开始点击的那张图和页面展示完的那张图，然后根据这两张图片计算出时间。通常来说，在众多图片中找到某一张图片是挺费时的。测试过程中每一秒钟都会生成数十张图片，一个操作通常会有数秒或数十秒的时间跨度，这样就会有成百上千张的图片，如果单凭人工去确认，会很费劲。因此，必须寻找一种方法，能够快速把这两张图片找出。

网页速度对比测试举例

QQ浏览器的网页速度测试，我们选择录屏的方式实现。截屏方式太占资源，而另外两种方式需要额外设备，人力投入也大。打日志计时的方式用不上，因为我们需要对比各种产品，所以没有办法获得它们的源码。

我们争取把整个测试过程都自动化，而不需要人工参与。

首先准备一台越狱的iPhone以及一台Mac机器，iphone上需要准备的软件有：触摸精灵；displsy Recorder.

大致测试流程如下.
1.准备自动执行的脚本,保证以下所有操作都是自动执行的.在ios平台上,推荐使用触摸精灵.脚本先通过录制生成,再人工编辑成适合执行的脚本.这里说的编辑一般是指对等待时长的编辑,比如脚本先单机启动了浏览器,需要等待10秒钟,再打开页面,这些等待时间最好是一致的,并且要预留足够长的时间,避免运行速度慢而导致预期的界面没有加载出来就开始执行下一步的动作.执行脚本不宜增加太多的逻辑判断,特别的图片对比的判断,因为这些对手机本身的性能有一定影响,所以可以用最简单的脚本去执行.

脚本的执行流程一般如下.
1.启动录屏
2.启动被测浏览器
3.在浏览器中打开一个页面
4.关闭这个页面
5.退出浏览器并结束录屏

也就是说,脚本执行会自动生成一段段的视频,每一段视频都会记录一个站点打开的过程.

步骤2:手机端执行脚本启动录屏.将两个打开网页的过程用录像保存下来分析

步骤3:手机端执行打开网页的操作.网页打开过程大致如图所示,图片中展示的浏览器的四个状态分别如下.

1.打开一个快链,白点出现的图;
2.网页加载过程中,跳转时出现的白屏;
3.网页加载过程中,首次出现页面内容的图;
4.页面加载完成的图片.

步骤4:手机端执行脚本结束录屏,保存录像.
步骤5:手机将新的视频传到Mac端处理，同时手机端继续执行步骤2.

scp 127.0.0.122 alpine:/video_in_iphone.mov ./video_in_Mac.mov
步骤6：Mac端执行脚本将视频分帧。分帧后的图片如图所示。
ffmpeg -i “videoFile.mov” -f image2 -vf fps=fps=40 “pngFiles.png”

步骤7：Mac通过计算找到初始打开网页的那张图的时间,作为开始计时的时间点.

当完成操作时,会在操作的位置画上一个白点,如图所示.我们的思路是,通过图片对比的方式把出现这个白点的第一张图给找出来.

直接获取某一区域的RGB值，如果RGB值有出现明显的变化，就会认为白点出现了。记录这张图片为第N张。核心代码如下：
public static blloenisChangeWhiteColor(AppUI des){
intscreenX = whitePointArea.x;
intscreenY = whitePointArea.y;
int width = whitePointArea.width;
int height = whitePointArea.height;
booleanisChanged = false;
//第一张图片
if(0 == lastWhiteSize){
lastWhiteSize = des.getWhitePositionSize(screenX,screenY,width,height);
return false;
}
// 第二张开始
else {
intcurSize = des.getWhitePositionSize(screenX,screenY,width,height);
if (Math.abs(curSize - lastWhiteSize) > diffpointcount_openwebseit{
isChanged = true;
lastWhiteSize = 0；
else {
isChanged = false;
lastWhiteSize = curSize;
}
}
returnisChanged;
}

步骤8：找到网页显示完成的那张图片。同样使用图片对比的方式。

这里先引入一个复杂度的概念。对于一张图片，我们把它平均分成P个小区域，对于每一个小区域，如果这个区域内颜色单一，就记这个小区域为0，否则记为1.如果最终计算有q个小区域颜色不单一，那么这张图片的复杂度为q/P.

上述中的“颜色单一”，也是通过色值对比得出的。我们随机取这个小区域中的部分离散点，如果这些点的RGB值都很接近，则认为“颜色单一”。

基于这样一个概念，我们容易理解：当一张图片是纯色的时候，其复杂度为0；当其颜色多样复杂的时候，复杂度接近1.

打开一个网页时有这样一个特点，就是网页的显示区域会先出现大片的空白，然后才逐渐填充网页的内容。我们按照时间顺序往后查找图片，那么可以认为，当这个显示区域的复杂度接近1时，就说明网页已经加载的差不多，记这种图片为第M张.

if(complexity > 0.9){
System.out.println(“首屏铺满=”+time[2]);
}

步骤9：计算这一次打开页面的时间为（M-N）/n,n为视频的FPS值。

由于整个测试过程都是用脚本自动执行的，所以可以长时间大量执行测试，采用大量的数据来说明页面速度存在问题，以对浏览器的打开页面做一个客观的评价。这是针对浏览器打开网页这种场景做的性能自动测试。可能具体的方法并不完全使用于其他场景，但是其中的思路是可以借鉴的。

讲到这里，我们不禁会想，能不能做更多的事呢？当我们说“这个浏览器的速度比那个浏览器的速度慢”的时候，我们仅仅是发现了问题而已，但是速度慢在哪不知道。所以我们做了更多的尝试。

我们的思路是，网页打开的速度由哪些因素组成，能不能计算出每部分的速度由多少？这样，一方面能验证上述方法的正确性（各块的速度之和等于总的打开速度）；另一方面能把问题原因的范围缩小，帮助定位。

首先要了解的是，网页打开的速度由网路速度和本地速度组成。本地速度（主要是解析、渲染、绘制）难以做进一步的分解和定位，但网路速度却有迹可循。网络速度由以下几个部分组成。

1）DNS时间：建立DNS连接的时间；
2）连接时间：与服务器建立连接的时间，即三次握手的时间；
3）发送请求时间：建立连接后到发送第一个请求的时间；
4）等待应答时间：发送请求后到接收到第一条数据的时间；
5）回包时间：接收服务器返回数据的时间。

通常，在测试网页速度的同时，我们会抓取网络数据包（.pcap），以供我们分析网络数据传输部分的速度。对于每一个请求，我们可以通过分析网络包打到每个时间节点的标志位来精确计算每一部分的时间，代码如下：

//连接时间
connect_time = request.ts_start - request.ts_connect
//发送请求时间
send_time = request.ts_end - request.ts_start
//等待应答时间
wait_time = response.ts_start - request.ts_end
//回包时间
receive_time = response.ts_end - response.ts_start

上述的request.ts_start、request.ts_connect等时间，都是直接从网络数据包.pcap中分析得出的。

这样的数据，对于定位问题很有帮助。能够清楚知道哪一个环节的速度慢，可以缩减定位问题的时间。