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

2021-10-08 12:26:51 字數 2427 閱讀 8191

背景:

遊戲專案採用敏捷開發,版本開發迭代很快,基本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所消耗的資源會被算在應用頭上。

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

背景 遊戲專案採用敏捷開發,版本開發迭代很快,基本1 2周乙個版本 效能問題在整個專案的階段數量 效能問題不是一開始就有的,也不是某一天突然出現的,而是隨著我們的開發進度不斷累積產生的 到後來我們希望用幾天的時間去解決幾個月甚至幾年的問題,而實際上結果往往不會盡如人意。而且相同的問題,相同的人,在不...

自動化效能測試

整體思路 1.使用jenkins整合各個模組 2.整體分為四個模組 建立監控模組 建立使用者模組 建立測試資料模組 執行壓測模組 3.使用jenkins容器實現,最總只發布乙個docker compose檔案 建立監控模組 1.在jenkins容器中內建grafana prometheus cons...

robot framework 介面自動化測試

介面測試比ui測試更有價值,如果專案時間緊張,測試介面更好一些,但每次都頻繁的手工填寫介面進行測試也浪費時間,下面給大家介紹一下很好的自動化測試框架robot framework,並且做介面自動化測試事半功倍。其返回值驗證和與資料庫連線進行增刪改查很方便,邏輯也很嚴謹,如果公司沒有造輪子推薦這麼做。...