• 专项


    前言: 针对目前系列突出问题整理 发现几类问题总容易被用户吐槽  时间长了 就形成了重灾区  针对重灾区的重点分析就显得尤为重要.

    一般有较大版本的更新、版本发布后用户反馈问题多、监控的崩溃率等明显上升等情况下  需要做专项测试

    1、崩溃类问题(anr 主线程加载>5s  Java crash   native crash)

    2、某场景下易卡顿( 掉帧 cpu问题)

    3、用户反应使用过程中相应太慢( 复杂场景冷启动  交互影响  H5页面加载)

    4、发热(硬件)

    5、兼容性(机型)

    ...

    针对用户反应的重灾区进行分类后基本上归为几类: 

    1、崩溃(Crash,弱网)
    2、卡顿 (掉帧、gc、cpu)

    3、响应慢(启动时间、交互响应、H5加载)
    4、发热 (cpu,mem、io、network、gps等硬件使用)

    5、掉电快(硬件占用)
    6、兼容性问题 (机型覆盖、回归)

     ...

    解决方案:

    APM方案:OneApm 听云 NewRelic

    Crash分析:腾讯Bugly Fabric

    LeakCanary:内存泄漏检测方案

    BlockCanary:UI卡顿检测方案

    弱网:测试云服务 

    ...

    根据反馈问题指定专项测试策略:

    1、崩溃 自动遍历、monkey测试、横竖屏切换、快速进退

    2、卡顿 (掉帧、gc、cpu) 卡顿测试、内存泄漏测试、method profile

    3、响应慢(启动时间、交互响应、H5加载) 冷热启动、界面切换、h5性能测试

    4、发热 (cpu,mem、io、network、gps等硬件使用)
    5、method profile、gc统计、io统计、流量统计、硬件使用统计、耗电量分析

    6、兼容性问题 (机型覆盖、回归) 兼容性测试、自动化测试、自动遍历、monkey测试

    一、App性能测试:

    Android应用加载流程:

    Android是基于Linux的开发的, 打开一个app,首先是liunx先创建一个进程, 并为其分配内存等资源,

    然后进入到Android的虚拟机层,ART  ---applicationOncreat启动一个主线程加载Activity会话 ActivityOncreat去加载资源(联网,下载广告,获取基础数据并渲染,第三方apk)

    1、Activity 加载时间测试(只能计算出activity创建时间)

    501 package='包名'
    502 adb shell pm clear $package          #清缓存
    503 adb shell am force-stop $package  #停止进程
    504 adb shell am start -S -W $package/.view.WelcomeActivityAlias  #启动app 包名加主activity
    507 adb logcat |grep "Displayed "   #获取Displayed数据

    2、通过录屏+拆帧计算响应时间  https://developer.android.google.cn/studio/command-line/adb#screenrecord

    511 adb shell screenrecord /sdcard/demo.mp4    #开始录屏
    515 adb pull /sdcard/demo.mp4          #将录屏pull到本地后  执行open

    ffmpeg -i demo.mp4 -r 20 image-%03d.png  # 使用黑盒工具ffmpeg 将mp4视频文件拆帧,每50ms一帧; 

    ffmpeg -i demo.mp4 -b:v 640k demo.flv  #使用黑盒工具ffmpeg将mp4文件转换成flv格式,并将码率设置成640kbps。

    ffmpeg -i demo.mp4 -ss 00:00:09.85 -to 00:00:12.70 demo.gif  #将视频的第09.85到12.70时间段的图片帧数制作成gif动图

    3、手机webview页面性能测试  检测工具:chrome://inspect

    • 需要代理
    • 需要chrome 62版本 高版本在一定情况下会有bug  chrom开发者历史版本下载
    • 找一个默认开启webview debug属性的模拟器,网易mumu就不行,genymotion、as自带的模拟器是可以的
    • 真机上需要研发配合打开debug开关
    • sdk版本要对

    4、webview,H5页面性能测试  (W3C 标准)

    加载流程: Dns解析,主资源及附加资源加载,cs加载,js加载,头图

     查看单个资源的性能:

     

     5、接口性能: CDN  DNS解析  HTTP   JSON解析  download

     ···

    二、崩溃测试, 可以深度遍历来补充自动化测试  期间监控系统的logcat  实时上报错误信息

    adb logcat *:S *:E | grep AndroidRuntime

    508 adb logcat |grep -i displayed   #找到哪个应用启动在首页

    adb shell ps |grep xxx.xxx.xx 找到进程号

    512 adb logcat |grep 9744 |grep *:E  过滤进程中的错误信息
    520 adb shell monkey -p com.xueqiu.android -v 5000

     1、一般在发版前进行测试  使用mongkey  appcrawler  进行遍历测试

    弱网可以使用charles代理工具配置或者启动模拟器时

    $(which emulator) -avd [your-avd-image] -netdelay 20000 -netspeed gsm

    2、场景测试:

    后端接又问题:

      弱网:完全超时、2G、3G

      接又返回异常:null返回

      接又变更问题:字段类型变更

    逻辑问题:

     异步线程问题:打开新页面再快速返回

    逻辑处理不当:横竖屏切换、前后台切换
     内存消耗:低内存、循环翻页、执行可累计内存的操作
    

    3、测试过程中可以建立监控体系, 将测试崩溃日志上报留档

      日志捕获

      外接sdk  如bugly

    三、卡顿分析

    一般是在页面加载滑动的时候, 页面的帧数来判断页面是否卡顿,一般标准是美妙不低于60fps   

    内存问题:(内存抖动、full gc)

    cpu (计算耗时 计算布局  控件大小应该如何渲染  计算完成后交给GPU完成渲染工作)

    render (布局复杂、overdraw在开发者选项中可以直接配置,配置完成后,页面会出现4中颜色来表示页面的渲染复杂度)

    1、打开页面渲染复杂度

    2、查看GPU的渲染分析, 页面开启渲染分析, 如果页面有卡顿, 绿线以上部分代表大于16ms(但是不能代表卡顿,肉眼仍感觉流畅)

     查看硬件资源占用:

    adb shell dumpsys procstats --hours 3
    adb shell dumpsys meminfo package_name|pid [-d]

    adb shell dumpsys batterystats --charged package- name

    adb shell dumpsys netstats detail
    adb shell dumpsys gfxinfo package-name  #绘制出界面帧的情况  (获取想要的包名adb shell pm list package |grep zhiyihealth)

     

    janky  称为一次跳帧,绘制出现延迟.

    3、使用页面卡顿分析工具systrace来分析卡顿页面

    python 2.7.x only  使用pyenv管理python版本切换到2.7  pyenv global 2.7

    505  find $ANDROID_HOME -name 'systrace.py'

    506  cd /Users/wangjianqing/Applications/adt-bundle-mac-x86_64-20131030/sdk/platform-tools/systrace


    ./systrace.py -l 列举所有支持的性能数据分类      ./systrace.py -t 10 收集10s左右的系统性能数据      ./systrace.py -t 10 -j 保存一份json数据文件用于编程分析 

    #运行systrace
    python2.7 systrace.py
    #等待开始提示
    #操作app
    #操作完成
    #在systrace窗口内按enter
    open trace.html 查看html报告
     

    三、内存及CPU

    CPU MEM的获取

    pids=$(adb shell ps -ef | grep packageName | head -1 | grep -v grep | awk '{print $2}' | xargs | sed 's# #,#g')
    #获取要测试的package的pid 用逗号隔开
    #adb shell top -n 1 -d 1 -p ${pids} 去掉-n 1可以持续刷新
    for((i=0;i<20;i++)); do
    content=$(adb shell top -d 1 -p $pids -o %CPU,%MEM,NAME -n 1 -b | grep bili)
    echo $content #通过linux的top命令每过一秒获取一次cpu和mem的数据 -d 1 一秒刷新一次 -n 1只展示一次数据, -p 制定一个pid列表 -o输出的结果显示标题
    cpu=$(echo "$content" | awk '{print $1}') #通过awk取cpu数据
    mem=$(echo "$content" | awk '{print $2}')
    echo curl -i -XPOST 'http://47.95.238.18:8086/write?db=android' --data-binary "cpu,user=$USER,app=bili value=$cpu" #将cpu和mem写入到infludb数据库中
    echo curl -i -XPOST 'http://47.95.238.18:8086/write?db=android' --data-binary "mem,user=$USER,app=bili value=$mem"
    done

    监控平台

    Profile (Android studio tools)

    • CPU profile
    • mem profile
    • systrace GPU profile
     
  • 相关阅读:
    WPF Caliburn 学习笔记(五)HelloCaliburn
    MSDN 教程短片 WPF 20(绑定3ObjectDataProvider)
    MSDN 教程短片 WPF 23(3D动画)
    比赛总结一
    HDU3686 Traffic Real Time Query System
    HDU3954 Level up
    EOJ382 Match Maker
    UESTC1565 Smart Typist
    HDU3578 Greedy Tino
    ZOJ1975 The Sierpinski Fractal
  • 原文地址:https://www.cnblogs.com/1026164853qqcom/p/11402953.html
Copyright © 2020-2023  润新知