一、测试准备
测试设备
测试环境
测试场景
测试准备.png
二、测试结果展示和分析
1. 编辑器常规设置
查看完整结果
测试场景的FPS初步分析
FPS初步分析.png
数据分析：
-
编辑器完成常规设置总结，完成调色/声音/倍速/选择滤镜设置，返回视频页面，出现1或者2次junk，说明完成设置绘制渲染界面，存在卡顿可能性
-
完成设置后，处于编辑器页面出现junk，疑似卡顿，需要对比看FPS和frametime数据，是否是渲染图示内容超时
对比FPS图表/junk图表/frametime图表
FPS图表/junk图表/frametime图表.png
-
出现junk时，Frametime中单帧绘制没有超时
-
frametime超时比如图中红框3，此时frame=1773ms 并没有展示junk数据，说明缓存buffer绘制生效，缓存区域绘制数据，不影响已绘制界面的展示
测试结论：编辑器完成设置后绘制渲染界面 大概率出现junk（卡顿），需要开发详细定位 '编辑器完成设置后绘制渲染界面，不流畅’的情况
2. 编辑器涉及进度设置（倒放）
2.1 测试场景
测试场景.png
2.2 数据分析
-
总体数据分析
总体数据.png
场景是 进度条更新进度，所以FPS 基本小于18是正常的，毕竟界面进度慢，基本几秒一点更新
delta_Ftime.png
特别关注 delta(Ftime)两帧之间时间差>100ms 的每小时内总次数，由于基本FPS<18 相当于两帧时间差大概率>100ms所以 展示数据符合场景，并不代表卡顿
-
对比FPS图表/junk图表/frametime图表
FPS图表/junk图表/frametime图表.png
数据分析：
1）Junk 完成倒放 0~100%进度条，完成100%返回编辑器页面，明显卡顿1次
2）frametime：数据不连续，说明绘制中依据实际要求内容进行绘制，并非场景流程卡顿；进度完成100%，绘制内容并未突然变大（并非超大渲染内容导致的卡顿）
测试结论：不通过，针对‘完成100%返回编辑器页面’场景，需要分析为什么出现卡顿
3.CPU数据
CPU usage.png
CPU usage_normalized.png
数据分析：CPU处于20~40%，数据正常
测试结论：通过
4.memory数据
memory.png
数据分析：momery数据峰值超过500M，需要关注此部分数据
momery数据峰值超过500M.png
测试结论：不通过，场景‘完成倒放（100%成功）返回编辑器界面’（和前面junk数据分析一致）
PS 衡量系统内存是否有瓶颈主要靠SWAP（与虚拟内存交换）交换空间利用率，一般情况下，SWAP交换空间利用率要低于70%
3. 编辑器生成创造视频
FPS结果.png
数据分析：分析junk数据出现时间点，其实是 场景之前，说明是框选区域时，误差
测试结论：通过
3.1 CPU
CPU usage.png
CPU usage_normalized.png
数据分析：输出处于20~40%之间，可以接受
测试结论：测试通过
3.2 Momery
Momery.png
数据分析：momery数据峰值超过500M，需要关注此部分数据 0%的进度，7%的进度，说明是生成进度中，出现部分超过500M
测试结论：测试通过，持续时间比较短暂，所以可以接受
3.3 Network
Network.png
Network(Recv/Send，测试目标进程流量)
数据分析：开始0%进度下载，00:2秒处，此时请求send是1-2kb/s，receive 是收到 6-7kb/s，界面进度是0~5%，说明前期请求进行编辑；完成前期请求？后，后续正常编辑并生成创作视频
测试结论：通过
网友评论