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