美文网首页
移动端测试经验-专项测试

移动端测试经验-专项测试

作者: johnny_zhao | 来源:发表于2017-08-07 17:11 被阅读0次

    专项测试测什么?

    资源类性能测试

    Ø CPU占用

    Ø 内存占用/内存泄漏

    Ø 低资源环境表现

    Ø 弱网络测试

    速度类性能测试

    Ø FPS测试

    Ø 端到端业务延时

    Ø 速度分析:客户端+网络+服务器

    稳定性测试

    Ø MTTF

    Ø Monkey test

    兼容性测试

    Ø Android版本

    Ø 分辨率

    Ø 硬件配置

    应用定制测试项

    Ø 协议测试、数据冗余比、成功率

    专项测试怎么做?

    1.需求评审阶段

    Ø网络风险

    断网重连,断点续传逻辑

    是否会产生大流量,流量合理性(流量消耗和发送的文件大小是否近似)

    请求-响应来回次数较多,是否会增加失败率

    协议必须有压缩策略

    有没有缓存机制

    ØUI风险

    存在IO操作,例如保存,导入,导出,发送,上传,当遇到大数据时是否有加载过程

    元素或动态/可变元素过多过复杂,是否会造成界面卡顿和CPU长期偏高(如LISTVIEW复杂格式或有动态图)

    元素加载时机(如滑动列表时,头像加载的时机)

    Ø电量/CPU风险

    地理位置相关逻辑,检测逻辑(如人脸识别、贴耳检测),

    后台服务(如tcp心跳逻辑),

    音视频相关

    ØOOM风险

    缓存策略,加载大数据策略(如拉取查看大图bitmap)

    GC策略

    Ø兼容性风险

    较新的系统特性

    通过系统API/系统数据库获取数据

    硬件相关(摄像头,屏幕触碰效果,声音大小,gps)

    2.新功能阶段

    Ø 原则:发现问题为先,兼顾数据沉淀

    Ø 事前能做的:

    可对比的历史场景数据(注意再测试的设备/环境一致性)

    缺乏对比的历史数据先补充,沉淀现有数据

    用MonkeyRunner简单的自动化脚本,可以让资源监控的曲线的趋势更加明显

    测试环境准备:如测试号码,手机选型,测试数据预先构造等等

    Ø 流量指标可以先测

    Ø 发现专项问题,请直接先提单

    Ø 功能稳定后,再关注FPS,内存,CPU等

    Ø 关注FPS:动画效果

    例如,列表滚动,展示内容的滚动

    Ø 关注内存,CPU,线程:可重复执行的动作

    例如,切换帐号,界面打开关闭

    Ø 关注流量,耗时,成功率:网络相关操作

    例如,发送消息,发送图片,下载数据

    Ø 关注电量/CPU:持续的动作和用户高频率的操作

    例如,放置后台,发送心跳包

    Ø 关注速度:界面切换,内容加载

    例如,启动速度

    资源类测试

    Ø 主要测试场景:

    1)        测试场景是和用户密切相关的:要包含用户实际的使用场景、特性;

    2)        高资源消耗场景:加载大数据、重复性高的操作;

    3)        产品的关键路径:更多的考虑产品的特性,制定明确的关键路径;

    4)        需要尝试/探索测试的点:专项测试中的资源类和速度类测试包括发现相关问题以及性能的优化两方面;

    Ø 测试工具:

    1)       CPU、内存、流量:AndroidResMonitor(python脚本工具);

    2)       电量消耗:PowerMonitor(硬件设备检测),手机管理软件,如android助手等

    http://www.infoq.com/cn/articles/how-subject-test-works

    Android

    痛点工具名推荐原因工具类别落地优先级落地成本

    卡顿

    Chrome for android开源性能测试工具(surface_stats.py)里面已经涵盖了FPS和janky采集的方法,用python写的命令行,简单直接地跟自动化测试结合。发现P0低

     卡上报(AnimationPerfMon.java)在空间落地卡上报,跟处理crash一样,通过堆栈快速定位解决问题, 补充ANR的缺失发现+定位P0中

     听云/OneAPM基于UIThread/主线程的监控,都有不错的卡顿的发现能力。但是因为没有获取堆栈,而只有简单的方法名和activity,所以对于复杂的软件定位稍微困难。发现+定位(弱)P1低

     Fresco通过内存缓存的优化达到流畅的图片及列表展示性能解决P1低

     Realm通过更优秀的I/O性能,降低APP对持久化数据读写的损耗,从而提升交互性能。可替代sqlite。解决P1中

    闪退

    LeakCanary高效率发现大部分内存泄漏导致的OOM。发现+定位P0低

     Bugly/听云/OneAPM/TestinCRASH监控的能力大同小异,都能对数据上报的统计分析,清晰现网情况,用户痛点。但我会推荐腾讯的BUGLY, 因为ANR, CRASH都能提供比较足够的信息定位问题,另外,因为是腾讯的。发现+定位+反馈上报P0低

     Testin兼容性/稳定性测试利器,关键是机器的量够!发现+定位P0低

    待机时间短

    Chkbugreport从用户手机中提取BUGREPORT。通过这个工具是可以分析简单的耗电问题,如sensor或摄像头没有关闭,wakelock的问题。发现+定位P0中

    IOS

    痛点指标工具名推荐原因工具类别落地优先级落地成本

    卡顿

    FastImage通过节省decode的耗时等方法,提升图片及图片列表的展示性能解决P1低

     Realm通过更优秀的I/O性能,降低APP对持久化数据读写的损耗,从而提升交互性能。可替代coredata,userdefault,sqlite。解决P1中

     MGWatchdog实现类似ANR的机制,主要是要跟上报结合发现+定位P0低

    闪退

    Infer解决因内存泄漏导致的内存耗尽导致的闪退。能扫描简单的循环引用导致的内存泄漏。发现+定位P0低

     Bugly/听云/OneAPM/TestinCRASH监控的能力大同小异,都能对数据上报的统计分析,清晰现网情况,用户痛点。但我会推荐腾讯的BUGLY, 因为ANR, CRASH都能提供比较足够的信息定位问题,另外,因为是腾讯的。发现+定位+反馈上报P0低

    待机时间短

    iOSDiagnostics可以获取一些耗电的模块的信息,如果可以融合到数据上报中的话就更好了。发现+定位P0中


    通用

    痛点指标工具名推荐原因工具类别落地优先级落地成本

    流量大/速度慢

    BPG(android,类似webp)

    BPG(ios)

    BPG是H265帧内压缩做图片压缩,webp是利用VP8帧内压缩做图片压缩。图片压缩对于图片应用来说,除了能提升用户下载显示图片的速度,还能为企业节约带宽成本。解决P1中

     Pngquant利用PNG8压缩PNG图片,颜色单一的图片,效果会非常明显。解决P0低

     Wireshark实用的流量分析工具,包括export http object, I/O graph等等发现+定位P1中

     EmmageeAndroid的性能测试组件,里面涵盖很多性能数据获取的方法,可参考使用。发现P1低

     HAR PageSpeed利用tcpdump在手机上获取的PCAP, 利用HAR转换PCAP,然后给pagespeed组件分析。定位P1低

    弱网兼容性差(ios通用)ATCFacebook弱网络模拟工具。好处是模拟丢包,抖动的时候比较稳定,而且还有HTTP API可以调用, 方便和自动化配合。发现P0中

     SPDY/QUIC特别是QUIC, 就是为了网络抖动而设计的。解决P2中

     OKHTTP推荐的HTTP组件。性能好,弱网兼容也不错。解决P1低

    相关文章

      网友评论

          本文标题:移动端测试经验-专项测试

          本文链接:https://www.haomeiwen.com/subject/fdualxtx.html