可用于UOS桌面应用性能自动化工具的调研

相关术语

缩写	全称	描述
SSIM	Structural SIMilarity	结构相似性，是一种衡量两幅图像相似度的指标。
PSNR	Peak Signal to Noise Ratio	峰值信噪比，是一种评价图像的客观标准。
Keras	Keras API	一个用 Python 编写的高级神经网络 API。其目的是支持友好、快速的实验
StagesepX	stage sep(aration) x	轻量化的、基于图像处理与机器学习的、全自动的视频分析工具

问题

我们知道，应用界面响应速度是衡量应用综合性能的重要指标之一。

在传统的生产过程中，人们通常采用以下方法来获取应用性能数据：

• 数据埋点

  在应用运行的过程中，分别打上起点和终点，通过差值拿到耗时数据。

• 掐表

  在鼠标点击应用后按下秒表，等待应用加载结束后，停止秒表，从而得出耗时数据。

• 肉眼观察

  通过肉眼观察的形式，得到用户感知最真实的数据。

• 录屏分帧

  这也是最常见的一种方案。测试人员拿手机或录屏工具录制好视频，通过分帧工具对视频分帧，一帧一帧去查看整个过程，查找首尾帧，最后通过帧数来计算耗时。

在我们日常应用的性能测试过程中，测试人员大多采用录屏分帧的方法，该方法存在两个问题:

1. 耗时巨大。追其原因，是因为在我们测试过程中，需要测试的系统架构较多、操作繁琐，长时间的数据收集和分析会占用大量的时间。
2. 数据的准确性也可能存在不稳定的因素。原因是由于测试人员拍摄视频时，拍摄设备的曝光度不同，会导致对首尾帧的判断出现误判。甚至有时候，因为测试人员的主观判断，对于测试数据的误差达到了20%以上。

现状

如果我们想要提高测试效率，减少工作中的冗余杂乱，必然需要寻找一种性能测试方案来解决性能测试的资源消耗问题。

而且就目前的性能测试趋势来说，测试人员以后需要覆盖的性能平台越来越多，而且需要测试的性能指标也越来越多，这对于仅仅只靠人力测试的方式来说是致命的，不管是增加人力，还是增加测试时间来说，都无疑增加了项目成本，所以我们需要探索一个即能节约时间，也能节省人力的方案。

当前受到大家认可并且广泛使用的，有如下几个方案：

方案一：继续沿用传统测试方式，录制视频分帧计时

这是现在最精准的性能测试方案，具体的操作流程如图1所示：


这里就拿冷启动来举例，整个过程如图2所示：


等我们一次次拍摄完毕后，我们才会使用解帧工具进行分帧操作，然后再一张张图片的找到首尾帧，过程看似比较简单，但是其实是比较繁琐且复杂的。

这种方法的优点就是不会占用系统资源，不会影响测试结果的准确性，可是事实上这种方式可能会导致数据的不稳定性，首先对于拍摄设备来说，每个人使用的手机不同，录制视频的质量不同，拍摄角度、拍摄手法也不同，录制视频时，摄像头会因为屏幕的光线和外界的灯光，使录制出来的视频辨认程度大大降低，实际拍摄效果如图3所示：


这张图是看图启动时分帧结果中，UI界面出现的第二张图片，从图上可以看到很多细节都不能看见，本着对性能测试的精准性考虑，这张图就不能作为尾帧来使用，因为看图出来时，手机摄像头要重新聚焦屏幕，致使无法确定看图是否界面已经加载完毕，这样就导致分帧出来的结果会存在较大的偏差，不能得到最真实的启动数据，所以我们就需要选择界面很清晰的图片选来使用，清晰的效果如图4所示：


这种情况我们通过统一的规范要求来进行避免，使用统一的三脚架，统一的拍摄手法，统一的选图标准，来提升测试结果的准确性；我们通过日常实践证明，这确实可以提升性能测试数据的准确性；可是缺点也是很显而易见的，使整个性能测试周期延长，影响项目进度。

其实整个测试过程中，不仅仅是拍摄过程需要大量的时间，数帧也需要大量的时间，性能测试采用的分帧策略是1秒钟的视频分帧成33张图片，一帧图片的误差的时间只有33.3ms，对于准确度毫无疑问是很精准的。对于冷热启动来说，耗时少图片数量也少，一般视频长度也就5秒钟左右，只需要查看一二百多张图片就能完成找帧的工作，但是性能测试中也有很多很耗时的指标，视频长度往往需要十几秒，甚至几十秒，那么图片的基数就会变得很大，那么找帧工作就会很耗时，如图5所示，看图性能测试指标中的加载40MB图片的性能素材目录：


从图上可以很直观的看到目录中的总文件数为4004项，要从这些图片中找到首尾帧，不用想肯定是一件很耗时的事情，而且测试人员通常是每一个指标，拍摄至少7组视频，也就是说一个平台上面相当于就有28000张图片需要进行首尾帧的筛选，可见这个过程是一个很繁琐的工作。

多媒体所有的应用，或多或少都会有比较耗时的指标，整个性能测试测试下来，每个应用在每个平台上所需要查看的图片均在40000张及以上，像文管这种指标繁多的应用，甚至是有十几万张图片需要筛选。

所以纵观整个方案一，优点是精准度较高，但是最明显的缺点就是耗时巨大。

方案二：使用time命令启动应用，直接得到性能数据

Linux本身就提供了time命令，可用于性能测试的启动时间测试，还可以测量内存、I/O等的使用情况。我们可以直接使用命令time来开启应用，比如开启看图测试看图的启动时间，如图6所示：


在图中我们可以清晰的看见三个时间项，分别是real真实时间，user用户时间，sys系统时间，启动时间我们可以理解为用户时间加上系统时间，从图中可知是97毫秒，这个方法可以很快速的获取应用的启动时间，避免了录屏分帧的时间消耗，比方案一节约了不少时间上的消耗。

可是这个数据其实是不真实的，也是不准确的，我们依据方案一中的看图冷启动来看，分帧录屏与time命令之间差距为100ms左右，这对于毫秒级别的速度来说误差已经很大了，通过命令来开启应用，实际上与在桌面双击打开，以及dock栏打开完全是不一样的，我们知道从不同地方去调起应用，都是通过不同的接口，在调用接口之前，桌面或dock栏需要先将自己的程序跑完，然后才会调用接口，跟终端的代码执行时间肯定是不一样的，我们用户真实感受的时间，应该是图7所示的代码执行顺序：


只有从桌面或者dock栏来测试应用的启动时间，才是最贴近用户使用的，而这个time命令最大的缺点就是与用户使用场景是有冲突的，所以只从这一个方面看来就并不是很适用当前的性能测试策略。

其次，这个命令只能单一的启动程序，不能做一些其他较为复杂的操作，可我们的性能指标，不仅仅只是冷热启动，还有各式各样的操作，所以这种测试方法就显得很不实用，不能覆盖所有的测试场景，所以这种方案也不是目前的最优解。我们简单的来看一下文件管理器和相机的性能测试指标，如表2所示：

相机文件管理器	相机
文管首次启动应用响应时间（ms）	首次启动应用响应时间-插摄像头（ms）
文管非首次启动应用响应时间（ms）	非首次启动应用响应时间-插摄像头（ms）
回收站非首次启动响应时间（ms）	首次启动应用响应时间-不插摄像头（ms）
复制2G大小文件（盘内）（ms）	非首次启动应用响应时间-不插摄像头（ms）
复制2G大小文件（盘外）（s）	摄像头切换，画面预览展示时间（ms）
复制一个包含1000个文件的文件夹（盘内）（ms）	启动内存占用值-插摄像头（MB）
复制一个包含1000个文件的文件夹（盘外）（s）	启动CPU占用（占比趋势）
启动内存占用值（MB）
启动CPU占用率（占比趋势）

可以很直观的看出，我们不仅仅需要冷热启动的时间，更需要其他用户可能使用到的功能上的性能指标，所以time命令测试性能的方式太过于局限化和理想化，并不能贴近实际生活，更不能代表用户的体感，当然这种方式也不是很无用，测试人员在平常测试中可以当成一个性能参考值。

所以纵观整个方案二，其实并不太适合现在的性能测试环境，唯一的优点就是能立马获取启动时间，其他的缺点也是显而易见，无法适应更多的测试指标，无法保证测试结果的精准度。

方案三：在程序中增加埋点，通过埋点触发的时间差来计算时长

这个方法也就是在应用的代码上增加一个埋点，代码运行到埋点处打一个时间戳，再运行到下一个埋点处又打一个时间戳，这两个时间戳的差值，就是时间差值，整个流程如图8所示：


这个方法首先需要开发更改代码，在相应的地方增加埋点，然后再进行测试，这个方法其实和方案二比较相似，都是站在计算机的角度去测试时长，并没有站在用户只会使用眼睛感受的角度，此方案还有一个缺点就是性能测试版本与用户使用版本是不一样的，这也导致了测试指标可能是不真实的情况，版本都不是一个版本，又从何处去保证性能是一个性能呢，而且纵观之前的测试数据来说，数帧时间与埋点时间差值也是超过了100ms，所以也是十分不准确的。

其次，计算机执行代码是一行一行执行的，增加了很多个埋点在其中，对性能肯定是有影响的，从根本上就不能保证这个时间的准确性，而且计算机渲染也有时间问题，应用代码执行到了开启的那一行，可是渲染可能只渲染了一个窗口框架出来，这样肯定是有时间差距的，与time命令一样，与用户的感受是背道而驰的。

只是这个方案比time命令好的就是，它可以适应所有的性能指标，需要什么就在固定的位置增加埋点，通过时间差确实可以获得近似真实的性能值，之前测试性能指标确实也用了一段时间这种方法，可是最后之所以没有使用，就是因为使用应用的性能测试版本获得的性能测试结果，与真实用户使用的应用版本的结果偏差较大，所以经过实践，这种方法确实不是最优解，最多也就只能当成参考值。

所以纵观整个方案三，优缺点与方案二类似，可以解决耗时问题，可是对于更加重要的准确度却是力不从心，也不太适合现在的性能测试环境。

总结： 现目前这三种方案，都是各有优劣，方案二和方案三缺点很相似，最主要都是精准度不高。三个方案的优缺点如表3所示：

方案	优点	缺点
1	精准度高	耗时长
2	耗时短	覆盖性能指标少，无法贴近用户习惯，精准度不高
3	耗时短	精准度不高

在目前的测试环境下，方案二和方案三，明显不符合性能数据精准度的要求，对方案一进行优化，解决其耗时长的问题，是目前我们迫切需要的，所以使用图像处理技术优化方案一的耗时问题，是目前来说的最优解。

技术方案

经过调研，我们决定采用一种基于图像处理与机器学习的自动化视频分析方案 ——StagesepX。StagesepX是一个轻量化的、基于图像处理与机器学习的、全自动的视频分析工具。它完全开源，并且提供了丰富的可定制性，能够根据你的实际需求分析视频并将其拆分为一系列阶段。在此之后，你可以清晰地得知视频包含了几个阶段、以及每个阶段发生了什么。而这一切都是自动完成的。

StagesepX整个测试过程包括以下几个阶段：

1. 录制测试视频
2. 视频分帧
3. 判定稳定区间
4. 训练模型
5. 预测分析

它可以实现全自动处理视频并且给出我们需要的数据。StagesepX通过我们录制的视频，来训练一个可用的模型。利用该模型，可以对我们日常测试中录制的视频进行预测分析，从而得到一个我们想要的结果。我们可以用一个简单的流程图来描述我们整个测试过程，如图9所示：


整体设计

在StagesepX的应用过程中，每个阶段将承担不同任务。我们需要了解每个阶段StagesepX到底做了哪些工作，我们将怎样去运用它。

录制测试视频

不管是运用常规的性能测试方法，还是运用自动化去进行冷热启动的性能测试，我们都需要进行视频录制。在日常测试中，我们通常采用外部设备来进行录制。对于我们肉眼来说，我们可以主动判断当前帧的情况，决定其能否作为首帧或尾帧。而对于机器来说，外部设备录制的视频由于光线、清晰度、抖动等因素，会对SSIM值产生严重的影响。因此，我们需要更加稳定的视频。

我们对Linux平台下的视频录制工具做了大量的调研，先后验证了UOS截图录屏、FFmpeg、SimpleScreenRecorder、Guee等工具的录屏效果以及开启工具后是否会对我们应用本身的启动造成影响。调研结果显示：UOS截图录屏因为使用了FFmpeg，在MIPS平台和ARM平台启动录屏功能后，CPU占用分别达到了200%和120%，导致系统卡顿，影响应用本身启动性能；而直接使用FFmpeg，无法在MIPS架构下完成录屏，大量的丢帧导致视频不能正常使用；SimpleScreenRecorder占用大量的资源，对我们应用本身启动产生严重的影响。最后我们采用了UOS商店的第三方录屏软件Guee（在X86架构也可以使用UOS截图录屏，为方便获取实验数据，这里统一使用Guee进行实验验证），该应用在MIPS平台启动录屏后，稳定状态CPU占用约为70%，综合来说对应用的影响最小。

我们在各架构下，选取了4个UOS应用，分别使用外部录屏工具和Guee工具在相同的条件下进行录屏，分帧后对两者的结果进行对比，确保录制的视频能够被我们使用。如图10所示，为对比结果：


从结果来看，在各架构下使用Guee工具录屏，对于各应用有一定的影响，但是在我们可接受的范围内。

视频分帧和判定稳定区间

StagesepX将一个视频文件分成不同的阶段，并保存在本地文件夹中，每个文件夹被认为是一个"稳定阶段"。而处于"稳定阶段"内的图像，又被认为是非变化状态的。判定"稳定阶段"的标准是根据设定的SSIM值，如果两张图片的SSIM值小于我们到设定值，则被认为是稳定的，将被归类在同一个文件夹。举个例子，我们将一个录制好的视频文件，通过StagesepX进行处理，具体实现过程如下：

from stagesepx.cutter import VideoCutter, VideoCutResult
from stagesepx.video import VideoObject

video = '../videos/uos_demo.mp4'

video = VideoObject(
    video,
    # 通过FFmpeg，将视频文件处理为30帧，保证视频的稳定性
    fps=30,
)

# --- cut ---
cutter = VideoCutter()

# 开始切割
res = cutter.cut(
    video,
    # 默认为2，即切为4宫格；若为4，即切为16宫格，以此类推；为1即不做切割，全图比较
    block=4,
)

cut_result = res.dumps()
res = VideoCutResult.loads(cut_result)

stable, unstable = res.get_range(
    # 判定阶段是否稳定的阈值
    threshold=0.95,
)

# 对区间进行采样
res.pick_and_save(
    stable,
    # 每段区间的采样数，5即每个阶段等距离截取5张图片
    30,
    # 采样结果保存的位置
    './cut_result',
    meaningful_name=True,
)

分割以后，我们可以进入到本地文件夹，查看分帧结果，大致呈以下状态，如图11所示：


我们可以看到，StagesepX将我们的视频分解为不同的文件夹，每一个文件夹是一个阶段。在每一个文件夹内，又包含不同的图片，图片名称包含了视频帧率、图片编号以及该图片对应视频时间的时间戳。在每个阶段内，所有图片的变化都被认为是"相对稳定的"。但是通过我们的实际观察，情况并非如此。用通俗的话来讲，它讲视频文件切得过太过于"细"了。很多我们认为应该在一个阶段的图像，被它分为了两个阶段。为什么会发生这种情况呢？因为在StagesepX工作过程中，主要通过对比相邻图片的ssim值来进行划分。在我们肉眼观察中，两张图片也许很相似，但是机器很容易发现其中的区别，所以这两张图片被分为了2个阶段。这个时候，我们需要使用人工的方式，对所有图片进行主观上的划分，将其分为我们认可的不同阶段，后续我们会结合实际例子进行说明。

那么为什么我们要将图片进行分类呢？这就是StagesepX的下一个阶段——模型训练

模型训练

上面我们将分割的图片进行了手动分类，接下来需要实现下一个步骤——模型训练。在训练过程中，我们使用了由Python编写的开源人工神经网络库Keras来进行模型的建立。由于我们只使用了Keras的最基本的功能，就不过其进行更深的介绍；而至于SVM分析方法，由于其精准度没有Keras高，所以我们不做过多的概述。

训练的过程如下，我们需要利用Keras读取我们分类好的图片，来训练一个简单的模型，并将其保存在本地。

from stagesepx.classifier.keras import KerasClassifier

cl = KerasClassifier(
    # 训练轮数
    epochs=5
)
cl.train('./cut_result')
cl.save_model('./keras_model.h5', overwrite=True)

训练成功后，我们可以在本地看到生成了对应的keras_model.h5文件，如图12所示：


通过查询我们知道，H5文件是一种用于存储科学数据的一种文件格式和库文件，用以存储和组织大规模数据。有机会我们可以对其进行更深入的了解，这里暂时不做更多描述。

模型训练好以后，我们可以录制一个视频，来验证模型的可用性和准确性，然后我们就可以开始进行正式的测试了。

预测分析

使用Keras，加载我们训练好的模型，然后加载我们需要的测试素材。Keras会按照模型对我们的测试素材进行处理，将其分为多个"稳定阶段"。测试的过程如下所示，我们只需要加载我们训练的模型，来对即将测试的视频进行预测分析。

from stagesepx.classifier.keras import KerasClassifier
from stagesepx.reporter import Reporter
from stagesepx.cutter import VideoCutter, VideoCutResult
from stagesepx.video import VideoObject
import os

# --- use keras to forecast ---
cl = KerasClassifier()
cl.load_model('./keras_model.h5')

# --- reload test_video ---
video = '../videos/uos_test.mp4'
video = VideoObject(
    video,
    fps=30,
)

# --- cut ---
cutter = VideoCutter()

# 开始切割
res = cutter.cut(
    video,
    block=8,
)

cut_result = res.dumps()
res = VideoCutResult.loads(cut_result)

# 你可以通过res获取切割结果，获取稳定状态与活动状态分别对应的区间
stable, _ = res.get_range(
    threshold=0.96,
    limit=5,
    offset=3,
)

# 对区间进行采样
data_home = res.pick_and_save(
    stable,
    30,
    prune=None,
    meaningful_name=True,
)

# 对切分后的稳定区间，进行归类
classify_result = cl.classify(
    video,
    stable,
)

# --- draw ---
r = Reporter()

r.draw(
    classify_result,
    report_path=os.path.join(data_home, "report.html"),
)

至此，StagesepX完成了一次工作周期。我们可以从生成的report.html查看应用的变化情况，获取我们想要的数据。如下图所示：图片记录了我们执行点击操作后，右键菜单逐渐消失的过程，直到应用界面完整的加载出来，并且保持稳定。如图13所示：


另外，StagesepX记录了应用启动的过程，并以不同的阶段进行展示。同时记录了每一个阶段的变化情况和耗时。我们可以从下图中，看到区间的变化以及耗时情况，如图14所示：


关键技术

视频预处理

由于拍摄设备的不稳定和不确定性，会出现录制的视频出现帧不稳定的情况，具体表现为每一帧的时长不恒定，我们可以通过以下图片进行简单的理解，如图15所示：


可以看到，通过软件录屏时，软件对图像进行抓帧。都是一帧图像，但是其实际时长并不是恒定的，这会影响机器的分析结果，导致我们最终的数据出现误差。为了解决这个问题，我们需要先通过FFmpeg对视频进行预处理。而经过FFmpeg处理的视频，只对其fps进行了重整，对于整个测试过程来说，是没有任何影响的。具体方法如下：

video = VideoObject(
    video,
    # 结合 ffmpeg，在加载前对视频进行 fps 重整，使表现更加标准
    # 例如 fps=30 即将视频转换为fps30的格式（不会覆盖原视频）
    fps=30,
)

经过处理的视频，都以稳定的帧数进行呈现，更加利于我们的测试工作。

Hook方法

Hook的作用是忽略图像某一区域的变化。忽略之后，该区域不作为判定稳定性的依据。举个例子，UOS应用中，影院会播放视频。我们每次录制的视频，可能会导致StagesepX认为其出现了多个不稳定阶段，而播放的视频往往不是我们的关注点。这个时候，我们就可以使用Hook方法将视频区域屏蔽。实现方式如下：

# 指定的区域会被屏蔽掉
hook = addHook(
    # 默认情况下，所有的坐标都是从左上角开始的。如果我们需要偏移到右下角，意味着我们需要向下偏移 0.5 * height，向右偏移 0.5 * width
    # Hook采用两个参数size与offset，分别对应裁剪区域大小与偏移量
    size=(0.5, 0.5),
    offset=(0.5, 0.5),
    # 例如你希望屏蔽掉高度100宽度200的区域，则：
    # size=(100, 200),
    # offset=(100, 100),
    overwrite=True,
)

相对应的，StagesepX提供了CropHook函数，该函数的作用是只关注图像某一区域的变化，并将该区域判定为稳定阶段的依据。使用方法与上面相同。

更多参数的介入

参数名称	作用	默认值	取值范围
block	block 能够对每帧进行切割并分别进行比较，计算出更加敏感的ssim值。block值默认为2，即切为4宫格；若为4，即切为16宫格，以此类推；为1即不做切割，全图比较	2	[1, +∞)
threshold	根据ssim判定阶段是否稳定的阈值，越高则越严格（判定为稳定的区间更少）	0.95	[0, 1]
psnr_threshold	利用 psnr 进行增强型的检测，设定后，它将对被认为stable的区间进行二次检测。例如，设定为0.5时，稳定区间的条件将变为：ssim > 0.95 and psnr > 0.5	None	(0,1)
offset	offset主要用于弥补在变化过程中，有一些变化不大的相邻帧被判定为稳态，导致连续变化过程被切割成多个部分的情况。如果将offset设置为2，StagesepX会自动拟合在变化过程中长度小于等于2的稳定区间，使变化过程能够完整呈现	None	[0, +∞)
prune	prune被用于去除重复阶段。设置为0.9时，如果两个stage相似度超过0.9，他们会合并成一个类别	None	(0,1)
limit	limit 能够过滤掉一些过于短的阶段（你可以用它忽略一些持续时间较短的变化）。例如填入5，持续区间短于 5*step 的会被忽略	none	[1, +∞)
compress_rate	影响保存图片的缩放倍数，影响我们分析最后结果。默认为0.2，即将图片缩放为0.2倍	0.2	(0, +∞)

实验验证

视频录制

以UOS相册应用为例，我们使用Guee工具，在MIPS平台录制一个应用的启动过程。录制完毕后，使用FFmpeg对视频进行预处理，使其恒定为30FPS。

视频分帧

通过我们预先写好的代码来对uos_demo.mp4进行分帧。分帧结果如图16所示：


人工分拣

分帧好的图像素材，并不符合我们的预期。通过我们平常的测试经验，可以知道，在相册应用的启动过程中，分为以下几个稳定阶段：

• 桌面停留阶段：此阶段，鼠标在桌面停留，不做任何操作。

• 唤起dock栏右键菜单：此阶段，通过鼠标右键，点击dock栏相册图标，唤起右键菜单，不做其他动作。

• 应用加载完成：此阶段，应用界面加载完成，并保持稳定状态。

根据以上经验，我们通过人工，将分解的视频文件分为以上3个稳定阶段。分拣后的效果如图17所示：


模型训练

我们通过分拣好的素材，利用Keras将其训练成测试模型。需要提到的是，在训练过程中，并没有可用的参数。所以我们只要保证模型能训练成功即可。如图18所示：


训练好的模型将保存在本地，供我们使用。模型训练也是整个过程中最简单的一步。

结果预测

经过多轮试验，我们发现：使用不同的参数，SSIM值都会发生改变，直接影响StagesepX对于“稳定区间”的判断，导致测试结果发现误差。最后，我们找到了最佳的参数配置组合：

threshold=0.96

limit=5

offset=3

block=8

同时，为了不影响我们分析结果，我们将compress_rate参数调整到了0.4，方便我们对图像进行分析。

利用以上参数，我们对uos_test.mp4进行测试。最终生成报告文件report.html

结果分析与数据提取

通过浏览器打开report.html，我们可以看到以下结果，如图19所示：


根据我们的测试经验，我们需要的数据是：从点击【打开】按钮后，到界面加载结束的时间。

通过分析结果，我们可以看到，应用加载过程中第一个不稳定阶段为鼠标在桌面移动的阶段。此阶段由于鼠标不断移动，StagesepX认为该阶段不稳定。

第二个不稳定阶段为dock栏右键点击应用后，右键菜单弹出的过程。这个阶段有较为明显的变化。

第三个不稳定阶段为鼠标点击【打开】按钮后，直到页面加载完成的过程。我们通过截取此阶段详细图来了解一下该过程，如图20、图21所示：



通过图片，我们可以看到点击【打开】按钮后，dock栏右键菜单逐渐模糊，到应用主界面加载完成的过程。而这正是我们所需要的！

既然了解了此过程，我们只需要写一段代码，对html文件的数据稍加提取

import re
import string


def read_html(html_path):
    """
    读取html文件
    :param html_path:
    :return:
    """

    with open(html_path, 'r', encoding='utf8') as r:
        txt = r.read()

    str_ = re.compile(r'<h5>(.*?)</h5>', re.S)
    str_ = str_.findall(txt)

    duration_list = []
    for x in str_:
        if 'unstable' not in x:
            continue
        duration = x.split('duration:')[-1].strip()
        duration_list.append(float(duration))
    return duration_list

a = read_html('report.html')
print(a[2])

通过打印第三个unstable的数据，我们得到了以下结果，如图22所示：


对比传统测试的结果(230ms)，我们发现，通过StagesepX获得的数据，与我们预期的结果仅有一帧(30ms)的差距。这是一个让我们感到惊喜的结果！

小结

通过StagesepX实现自动化的视频处理，可以很大程度上提高我们的测试效率。目前测试人员完成一个应用的性能测试，需要依次在各个架构进行测试，耗费1-2天的时间。如果使用StagesepX来完成任务，可以多个架构任务并行，这样完成任务大概只需要消耗1/2的时间；同时可以解放更多的人力，投入到其他测试工作中。从测试结果来看，它产出的结果能够满足我们测试人员的需要，解决了我们以下难题：

• 效率低下，投入时间太高。

• 重复劳动，获取测试数据。

从长远来看，StagesepX具有以下优缺点：

编号	优点	缺点
1	可二次开发，定制性强	对于机器的CPU、内存要求较高
2	具备实现多架构同时性能自动化的能力	视频解析时间较长
3	测试数据稳定可靠，不带有主观偏见	需要较多的测试素材来构建、完善测试模型

诚然，StagesepX是个比较成熟的工具，经过实验论证，有实现性能自动化测试的能力，但是前期视频的录制仍然是我们当前的难点和痛点。我们调研了所有的多媒体应用，在MIPS和ARM架构，使用第三方视频录制工具会对部分应用性能产生较大的影响，如影院、相机等这类资源占用较高的应用。目前我们初步有了新的解决方案：使用视频采集卡。利用采集卡，将A电脑的视频信号，输出到B电脑，利用B电脑的性能，来处理接受到的视频信号，实现不占用A电脑资源的录屏。如图23所示：


当然，这其中也许会有其他问题，如：Linux系统的支持、驱动问题等，都等待我们去深入调研。

参考资料

图像分类、AI 与全自动性能测试

全自动化的抖音启动速度测试

StagesepX源码