APP 性能测试是什么
从网上查了一下，貌似也没什么特地的定义，我这边依据本人的教训给出一个本人的定义，如有偶合纯属雷同。
客户端性能测试就是，从业务和用户的角度登程，设计正当且无效的性能测试场景，制订各性能场景下的客户端性能指标 (内存、CPU、卡顿数、帧率、电量、加载时长等)，并制订规范化的执行流程，依照执行规范执行性能场景同时使用性能测试具收集性能数据，并对数据进行剖析，如果有性能问题并对问题进行定位，配合开发进行修复验证公布，最初输入残缺的性能报告。
从下面的定义中，咱们能够得出，在 APP 的性能测试须要关注以下几方面，性能测试的场景的设计、性能指标的定义、规范化的执行流程、性能数据数据收集、性能数据分析、性能问题定位、性能测试报告。
性能测试并不是说咱们上来找个工具，轻易跑个场景，拿到数据，输入个报告，就能够了。每一步都应该做到对症下药，从而体现出测试人员的专业性。
APP 性能测试怎么做
上面咱们别离来看一下：
性能测试场景的设计
场景可能是一个操作的一直反复，也可能是几个操作的组合再反复，对于性能测试的场景来说，他肯定有反复的操作或者继续的操作，目标是通过反复或者继续的操作，把性能问题放大到肯定水平，可能让咱们发现问题。
举个栗子：以 B 站举荐 tab 为例，想测试 feed 滑动状况下的性能体现，那性能场景能够设计成，feed 滑动 50 次，每次滑动距离 2s。
性能指标的定义
常见的挪动端性能指标有：内存、cpu、帧率、卡顿数、wakp up 数、展现时长等，关注什么性能指标是依靠于咱们的性能测试场景。
举个栗子：以 B 站举荐 tab 为例，当咱们冷启 APP 进入举荐 tab 的时候，更关注数据展现时长，滑动场景更关注卡顿数，为不同场景设计正当的性能指标也是咱们须要认真思考的。
规范化执行流程
场景和指标都定义好了当前，就要开始执行了，这里要求要规范化执行，规范化执行不是简略的依照场景的定义去执行就好，而是要有很多关注的点。
能够定义的标准有哪些：
- 场景开始执行前须要期待多少 s
- 执行后须要期待多少 s
- 每次测试需不需要冷启或是必须重新安装
- 装置好须要期待多久才能够开始测试
- 测试账号、测试数据、设施、网络需不需要固定 每一个点都可能影响的性能数据的准确性，必须要定义标准，每次都要按着标准去执行，而且这个标准是动静，随着咱们一直的测试，会发现很多影响性能数据的问题，都必须定制标准，加以躲避。同时好的标准可能未咱们前面进行性能数据分析打下基础。
性能数据数据收集
性能数据收集可能是整个客户端性能测试中最简略的局部了，有成熟的工具 perfdog 能够应用，不便简略，也能够应用商业化的 perfdog service 实现自动化的性能数据收集，就是须要花钱。
性能数据分析
在收集到性能数据之后，就要去剖析数据，如何剖析，上面我简略说一下，前面会出文章专门说如何对性能数据进行剖析
-
走势图，从走势图上咱们大抵能够看出该场景在以后版本的性能体现，能够得出以下论断：
- 和之前版本的走势图进行比照，性能指标的稳定状况
- 性能指标峰值、场景的均值以及涨幅的变动
- 场景的起始值与之前版本的变动
- 场景完结后的值与之前版本的变动
性能问题定位
在进行完性能数据分析当前，如果有问题，就须要去定位问题是那一块业务的问题或者是哪一个 mr 引起的问题，就须要回溯。
- 先找开发，和开发沟通一下，看是否依据问题表象确定问题，如果确认不了，就须要测试定位是哪个 mr 合入引起的
- 列出本次版本合入所有 mr，筛选出那些 mr 是性能问题所在的业务
- 找 mr 合入前后的包从新跑，确认每个 mr 是否有影响
- 当确定是哪个 mr 合入引起的性能问题后，再次和开发沟通
性能测试报告
性能测试报告的目标是给出以后版本的性能体现状况，须要蕴含一些外围的模块
- 测试论断
- 性能问题归因
- 各个场景的性能指标数据
- 测试环境以及计划
- 各个场景的性能指标走势图
以上我对 app 性能测试的一些浅显了解和教训，有问题能够留言，一起探讨。。