PerfDog 助力自動化效能測試探索

背景：
遊戲專案採用敏捷開發，版本開發迭代很快，基本 1-2 週一個版本

效能測試必要性
效能問題在整個專案的階段數量

效能問題不是一開始就有的，也不是某一天突然出現的，而是隨著我們的開發進度不斷累積產生的；
到後來我們希望用幾天的時間去解決幾個月甚至幾年的問題，而實際上結果往往不會盡如人意。而且相同的問題，相同的人，在不同的時間去處理所花費的經歷與時間完全不同。
所以說效能問題看上去是研發團隊的技術問題，但本質上其實是研發團隊的開發流程問題

如果我們可以規範流程，做到每一個版本皆有一份資料展示，一旦發現問題，及時處理，那麼可以大大減少以後的最佳化時間；而人力每個版本做效能又比較雞肋，所以完全可以採用自動化的方式處理，那麼自動化的操作究竟會不會對我們得到的效能資料產生影響，下面我們來探索下；

自動化對應用效能資料的影響
第一組測試對比
測試背景：
1.開啟 Perfdog，記錄手動跑功能和自動化跑功能的效能資料
2.本次所使用自動化功能為 Airtest

測試用例：
1.未開啟 Airtest IDE 連線，手動跑功能
2.開啟 Airtest IDE 連線，手動跑功能
3.開啟 Airtest IDE 連線，使用自動化指令碼跑功能
4.斷開 Airtest IDE 連線
5.關閉 Airtest IDE 程序

自動化指令碼：
只會執行一個戰鬥小功能，很短的時間

下面測試用例的斷開連線是指：

先來看看 FPS

很明顯我們發現是否採用自動化的方式跑遊戲功能對比 FPS 的影響幾乎沒有

再來看看記憶體

發現自動化對記憶體也沒有影響，開不開自動化對於記憶體幾乎都一樣

再來看看 CPU

我們發現在開啟 airtest 的 IDE 連線時，Total cpu 的使用率顯著上升，在跑自動化指令碼時 Total cpu 的使用率也在上升。而 app 的 cpu 使用率幾乎是沒有影響的。
這是因為在開啟 airtest ide 的連線時，ide 要使用 minicap 服務獲取手機的螢幕截圖，所以會對 cpu 的整體使用率有影響，而在執行指令碼時 airtest 要進行影像搜尋匹配，所以也要佔用 cpu。但是對於 app 的使用率則不會有影響。

第二組測試對比
本次測試不適用自動化指令碼，單獨對比 ide 的影響

測試用例：
1.靜止頁面不連線 airtest ide
2.靜止頁面連線 airtest ide
3.靜止頁面斷開 airtest ide 連線不退出 ide
4.靜止頁面斷開 airtest ide 連線退出 ide

FPS 資料

是否開啟 IDE 對應用的 fps 絲毫不影響

記憶體
在這裡插入圖片描述

CPU 使用率

和第一組的結論一樣，也是開啟 ide 會對 total cpu 使用率造成影響，需要注意的是斷開 IDE 與手機的連線後效能消耗還在，因為 mincap 服務實際沒有被中斷，要退出關閉 IDE cpu 才會恢復正常。

第三組資料
所選則是手機 APP，非遊戲

FPS

記憶體

CPU

我們發現結論和上面相同

推薦使用規範化 CPU 利用率
為什麼推薦這個值作為 CPU 使用率的衡量標準呢，因為發現還是規範化比較適合自動化，更為準確一些，關於規範化利用率的文件：
規範化利用率介紹

結論
完全可以使用自動化的方式獲取應用的效能資料啦，這是因為我們所獲取的資料都是針對單個應用，所以自動化的操作不會演算法該應用之內，不過接入自動化 sdk 的就要另外考慮了，SDK 所消耗的資源會被算在應用頭上。