前言

• 项目介绍：https://testerhome.com/topics/19978
• 如何手动或自动进行 app 的启动速度测试：https://testerhome.com/topics/22067
• 项目地址：https://github.com/williamfzc/stagesepx
• 例子地址：https://github.com/williamfzc/work_with_stagesepx

背景

我来啦，感谢社区的朋友们对这个项目的支持，这次有机会到 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