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

williamfzc · February 12, 2020 · Last by 阳光 replied at February 21, 2020 · 2717 hits
本帖已被设为精华帖!

前言

背景

我来啦,感谢社区的朋友们对这个项目的支持,这次有机会到MTSC2019深圳站上分享。虽然讲得还不够好,但是对自己也是一次难得的历练机会。
开发维护至今,很开心能得知,已经有不少团队将该工具落地到实际项目中,其中不乏来自各大厂的业务团队们。这也是开源项目的意义之一。

当然,随着使用范围增大,功能更加复杂,我们也在不断改进与优化这个工具。目前,stagesepx已经迭代了35个版本,稳定性与功能比起之前也不可同日而语。
在启动速度测试这一块上,应用已经趋向稳定。因此,本文将针对这一项,进行一个完整例子的讲解。

起因

其实,对于一般应用来说,可以参考前言中 如何手动或自动进行app的启动速度测试 的方式去做就可以。之所以会有这么一项,是因为:

  • 一些超级app的启动过程非常复杂且可变
  • 无法满足游戏的需求

简而言之,也就是部分同学最关心的动态化问题。举个例子,抖音的启动过程是这样的:

可以看到,它有五个阶段(你也可以按照你的理解划分):

  1. 初始阶段(app没打开)
  2. 首屏(抖音字样)
  3. 插屏广告(可能有)
  4. 应用内首屏(视频未加载,但主体控件已加载完成)
  5. 应用完成(视频与控件均以加载完成)

看起来还好,但是:

  • 插屏广告每次打开都不一样,且不一定有
  • 抖音的主页是动态的,会大面积动,而且每次都不一样

由于模型的限制,之前的 stagesepx 没法满足这个问题,所以,这类问题也成为它应用的瓶颈。
本篇文章将以抖音为例(此条五毛),描述现在的版本如何处理复杂情况下的启动速度测试问题。

这里选抖音只是因为抖音的启动流程够复杂,方便讲解

流程

所有代码可以在 例子地址 找到。

场景设计

对于测试来说,场景与过程设计永远是最重要的。如果标准都没有定下来,操作没有任何意义。
这里我们的规划保持与上面相同,五个阶段。另外在本次测试中我们姑且认为:

应用完成的首点 - 初始阶段的结束点 = 启动耗时 (这里自行根据实际需要去界定)

操作

这里请先阅读 如何手动或自动进行app的启动速度测试 中的自动测试部分,操作流程差不多。这里不会赘述

与上文一样,我们可以利用几个视频,得到一系列的截图。通过人工分拣,我们可以将截图按我们上面设计好的类别进行归类。训练集大概是这样:

然后一样的,我们在上面进行训练就可以得到我们想要的模型。
看起来与传统模式非常相似,不同之处在于,在这种模式下我们不再使用传统的SVM分类器,而改用keras支持的神经网络分类器。
当然,这一切对于用户来说几乎是无感知或不需要了解的,这也是我们在设计初期希望的,api保持稳定,用户并不需要关心过多实现细节,能够更快实现功能。

from stagesepx.classifier.keras import KerasClassifier


data_home = "./dataset"
model_file = "./keras_model.h5"

cl = KerasClassifier(
# 轮数
epochs=10,
# 保证数据集的分辨率统一性
target_size=(600, 800),
)
cl.train(data_home)
cl.save_model(model_file, overwrite=True)

而代码上的修改也仅仅是从 SVMClassifier 替换为 KerasClassifier。那么我们就可以利用这个训练好的模型进行预测,并得到一个字典:

OrderedDict([('-3',
[<ClassifierResult stage=-3 frame_id=63 timestamp=1.062857142857143>,
<ClassifierResult stage=-3 frame_id=64 timestamp=1.0797278911564627>,
...
('0',
[<ClassifierResult stage=0 frame_id=1 timestamp=0.01687074829931973>,
...

从这个字典中我们可以知道,每一帧分别对应的:

  • 被分类到哪一个类别
  • 时间戳
  • 帧编号
  • ...

那么理论上,我们可以由下一段脚本来处理这些结果,达到自动计算的目的。回到我们一开始的设计:

应用完成的首点 - 初始阶段的结束点 = 启动耗时

对应到我们分好的类别(0、1、2、3、4),就是:

阶段4[0] - 阶段0[-1] = 启动耗时

即可自动计算出耗时。在此基础上,你可以根据实际需要进行额外的扩展,例如部署到jenkins上使其定时执行。

一些问题

看起来好像跟普通版本没什么变化,为什么要用keras分类器?

神经网络的介入主要为了强化分类的普适性。例如,抖音的插屏广告可能形态各异,而他们在被分类时又应该被分到同一个类别。让SVM完成这项任务未免有些强人所难。

训练完的模型效果并不好

动态情景下最大的问题是,每个阶段的表现可能是不相同的。以插屏广告为例,每次打开时插屏广告都不一样,此时我们需要扩大训练集,尽量让模型找到广告之间的共性,能够正确地将他们划分到同一类别。

对于抖音的例子,我这边大概用了四个视频作为训练集,此后的预测基本可以满足要求。当然对于真实的业务来说,你完全可以继续增大你的训练集,使其稳定性更强。

切换到keras,性能是否有影响?对硬件(GPU)是否有要求?

诚然,神经网络的计算量相比之前要大许多,但并没有想象中那么大。

  • 模型并不复杂
  • 场景要求不高(仅做单标签分类)
  • 训练集很小(百级别)

在这种情况下,用cpu训练已经足够。参考数据:

  • 200张图片
  • epoch = 10
  • MacBook Pro 2019 16g
  • 耗时3分钟左右
  • 最终accuracy: 0.9871

除此之外,在切换到神经网络之后,虽然在训练过程上我们需要花费更多的时间,但分类的效率被极大地提高了。总的来说,这个结果是非常积极的。

最后

任何建议与意见可以留言或到主库留issue~

https://github.com/williamfzc/stagesepx

共收到 8 条回复 时间 点赞
Author only

可以,你留我加你吧,我没法仅你可见

Author only
恒温 将本帖设为了精华贴 13 Feb 09:27

我有比这更熟悉,完全自动化.图像识别+自动化脚本

chenyouan 回复

欢迎出来遛遛

chenyouan 回复

嗯嗯,看起来是已经落地挺完全的哈。不过这种做法在最初的时候我们就试过了,在MTSC上也已经拿出来分析过,弊端也是比较多的。就拿这篇文章里的内容来说的话:

  • 对于抖音这类高度动态化的app基本是无从下手
  • 即时分析这条路会导致高度的延迟,如你文章说到的200-300ms,对于现代app来说是完全不可接受的误差

业务界自动化工具录制后基本上还是要维护脚本代码(包括:qtp,selenium,robotframwork等),对用例的维护是相当的耗时,也此是长期以来自动化叫好叫卖的原因,很多公司使用一段时间,消耗了大量人力,也看不到时实际的效果,积极性不段的降低。不过k还是有好的产品分享给大家,kylinTOP是一款难得好用的自动化测试工具。完全跳出了代码维护,是所见即所得的操作界面,不需要代码维护。kylinTOP具有大量的智能属性,如:支持元素智能判断、步骤智能等待等一系智能化的操作。可以给测试人员节省大量的时间,优其是在版本不段变更的情况下,也能很好的识别元素。优其适合自动化不懂的人员,学习起来非常容易。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up