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本次測試不適用自動化指令碼，單獨對比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才會恢復正常。

記憶體

我們發現結論和上面相同

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

規範化利用率介紹

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