背景:
游戏项目采用敏捷开发,版本开发迭代很快,基本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所消耗的资源会被算在应用头上。