一、測試準備

測試設備
測試環境
測試場景

測試準備.png

二、測試結果展示和分析

1. 編輯器常規設置

查看完整結果
測試場景的FPS初步分析

FPS初步分析.png

數據分析：

1. 編輯器完成常規設置總結，完成調色/聲音/倍速/選擇濾鏡設置，返回視頻頁面，出現1或者2次junk，說明完成設置繪制渲染界面，存在卡頓可能性

2. 完成設置后，處于編輯器頁面出現junk，疑似卡頓，需要對比看FPS和frametime數據，是否是渲染圖示內容超時

對比FPS圖表/junk圖表/frametime圖表

FPS圖表/junk圖表/frametime圖表.png

3. 出現junk時，Frametime中單幀繪制沒有超時

4. frametime超時比如圖中紅框3，此時frame=1773ms 并沒有展示junk數據，說明緩存buffer繪制生效，緩存區域繪制數據，不影響已繪制界面的展示

測試結論：編輯器完成設置后繪制渲染界面 大概率出現junk（卡頓），需要開發詳細定位 '編輯器完成設置后繪制渲染界面，不流暢’的情況

2. 編輯器涉及進度設置（倒放）

查看完整結果

2.1 測試場景

測試場景.png

2.2 數據分析

1. 總體數據分析

   
   
   總體數據.png

場景是 進度條更新進度，所以FPS 基本小于18是正常的，畢竟界面進度慢，基本幾秒一點更新

delta_Ftime.png

特別關注 delta(Ftime)兩幀之間時間差>100ms 的每小時內總次數，由于基本FPS<18 相當于兩幀時間差大概率>100ms所以 展示數據符合場景，并不代表卡頓

2. 對比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%，說明前期請求進行編輯；完成前期請求？后，后續正常編輯并生成創作視頻

測試結論：通過