APP性能测试关注点
- 1、性能测试常见指标
- 2、预期标准指定原则
- 3、工具及方法
- 4、不同角色关注点
- 4.1 运维角度
- 4.2 开发(架构)工程师角度
- 4.3 用户角度
- 4.4 测试工程师角度
关于APP的性能测试，貌似在我的博客中写的并不多(谦虚的说法)，为了能迎合更多的大(mei)佬(zi)，我也得改变一下，多写点关于APP方向的性能测试博文。
今天的这篇博文，先来一个总结，后期的博文，会慢慢展开进行详细例举。
据说妹子都喜欢倒叙，慢慢顺其延伸。
1、性能测试常见指标
- 内存
- CPU
- 流量
- 电量
- 启动速度
- 滑动速度
- 界面切换速度
- 与服务器交互的网络速度
通常Android对上面的关注点会更多一些，毕竟… 你懂得！
2、预期标准指定原则
- 分析竞品，所期望指标与竞品的差值或超过竞品
- 满足产品经理给出的预期性能指标
- 符合业内标准
3、工具及方法
内存：
- 方法：使用adb shell脚本进行测试，查看Log数据
- 命令：adb shell dump meminfo
CPU：
- 方法：使用adb shell脚本进行测试，查看Log数据
- 命令：adb shell top
敲黑板：程序持续运行及操作过程中，内存不能一直增加，否则系统会自动Kill(弄死)掉进行；
流量监控：
- 工具：可以借用网易的开源工具Emmagee
电量监控：
- 方法：和竞品做对比测试，同一机型的测试机在不同时间，不同网络条件，不同功能使用的情况下分别测试电量使用情况；
启动速度/滑动速度/界面切换速度：
- 方法：编写测试代码，打桩到源码中，进行测试后通过log进行数据分析；
4、不同角色关注点
关于不同的角色，对性能的要求及关注点，小鱼在《深聊性能测试，从入门到放弃之：初识性能测试》的第三章详细写过，虽然当时没有明确的写出是Web还是App，总的来说，还是离不开这些；
当然，像小鱼我这种乐(为)于(了)助(妹)人(子)，我愿意再详细的总结一下，针对App性能，各个不同角色大佬的关注点。
4.1 运维角度
- 响应时间
- 服务器资源使用情况是否合理
- 应用服务器和数据库资源使用是否合理
- 系统能否实现扩展
- 系统最多支持多少用户访问、系统最大业务处理量是多少
- 系统性能可能存在的瓶颈在哪里
- 更换那些设备可以提高性能
- 系统能否支持7×24小时的业务访问
4.2 开发(架构)工程师角度
- 架构设计是否合理
- 数据库设计是否合理
- 代码是否存在性能方面的问题
- 系统中是否有不合理的内存使用方式
- 系统中是否存在不合理的线程同步方式
- 系统中是否存在不合理的资源竞争
4.3 用户角度
- 加载时间
- 反应时间
4.4 测试工程师角度
①链接超时
这个问题必须重视，因为在移动应用中网络错误数据比例报错中最高的就是连接超时错误；
②崩溃/闪退
APP的崩溃，就是用户的崩溃。
当用户使用你的App出现闪退或崩溃时，他们很有可能跑去App Store赠送你一个“一星”好评；
我也曾给过某APP一星好评。
③系统交互（电话短信干扰，低电量提醒，push提醒，usb数据线插拔提醒，充电提醒等）
在APP使用过程中，可能会遇到各种中断场景，那么一旦发生这些场景，APP就卡死或者闪退，想必也没有多少用户愿意持续使用你的APP；
不行就学学某宝，超过xx秒，重新加载进首页，不仅规避网络加载失败问题，还能得到一笔广告费。
④弱网下的运行
电梯里、地铁上，网络信号差时，APP页面的菊花转不停，界面卡死，同时错误提示一堆，
主要卡在菊花这个标志上，着实有点尴尬。
⑤ CPU使用问题
CPU频率设置过高时会导致过热，过热导致耗电更严重， CPU频率设置过低导致手机滞后，
应用处理缓慢同样会导致耗电。
更多时候，用户解决CPU超载问题只能关闭甚至卸载App，App就被Kill！
小鱼遇到这种事情，直接卸载，然后对此APP说拜拜。
以上的就是今天总结的APP性能测试的关注点，
接下来，会针对上面的内容，逐步的展开，让妹子遨游在知识的海洋~
