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