共计 1326 个字符，预计需要花费 4 分钟才能阅读完成。
背景：
游戏我的项目采纳麻利开发，版本开发迭代很快，根本 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 所耗费的资源会被算在利用头上。