APP测试

发布时间:2024-09-13 19:01

APP测试

  • 1 APP应用架构
    • 1.1 APP架构和WEB架构的异同点:
  • 2 APP项目环境(后端)
  • 3 APP应用发布(前端)
  • 4 测试要点
    • 4.1 业务功能测试
    • 4.2 兼容性测试
    • 4.3 安装、卸载、升级测试
    • 4.4 交叉事件测试
    • 4.5 PUSH消息推送测试
    • 4.6 用户体验测试
    • 4.7 稳定性测试
    • 4.8 性能测试
      • 4.8.1 性能测试指标
      • 4.8.2 关注点
      • 4.8.3 性能测试工具GT
        • 4.8.3.1 GT安装方法:
        • 4.8.3.2 CPU测试
        • 4.8.3.3 内存
        • 4.3.8.4 流畅度
        • 4.3.8.5 流量
        • 4.3.8.6 电量
        • 4.3.8.7 启动速度
  • 5 APP上线后的注意事项

1 APP应用架构

\"APP测试_第1张图片\"

1.1 APP架构和WEB架构的异同点:

相同点:

  • APP和WEB使用的后端服务器是相同的;
  • 前后端都是用HTTP协议进行交互(部分APP使用socket)。

不同点:

  • APP是C/S架构,WEB是B/S架构;
  • APP前后端交互的数据以JSON为主,WEB前后端交互的数据以HTML为主。

2 APP项目环境(后端)

一般公司内部开发、测试人员会使用不同的环境,以隔离工作过程中彼此的干扰。同时,上线给用户使用的产品也会单独部署环境。

  • 开发环境
    开发人员开发时调试运行的环境。

  • 测试环境
    提供测试人员使用,用于测试人员执行测试,回归缺陷。

  • 预发布环境
    使用后端的测试代码,连接生产环境的数据库进行测试。目的是测试最新的代码对线上复杂数据的处理情况。
    注意点:
    a. 预发布环境中只针对基本业务进行测试
    b. 测试进行写的操作时,只能使用自己构造的数据
    c. 升级涉及表结构变更时,可将生产环境数据数据库环境数据备份到测试库中升级并测试

  • 生产环境
    最终用户使用的环境。

  • 灰度发布策略
    https://baijiahao.baidu.com/s?id=1692367749356717047&wfr=spider&for=pc
    灰度发布策略是在预发布环境测试之后,正式发布线上之前的一种发布策略。
    注意点:
    a. 一般情况下切一小部分流量,验证时间一周至一个月之间,如果运行无问题,则在某个流量少的时间点,不停机更新服务器环境;
    b. 若运行有问题,应及时在测试环境定位问题,尽快修复问题;若问题比较严重,需回滚代码,保障线上用户正常使用。

3 APP应用发布(前端)

APP开发完成后,开发人员会打出应用程序包,由测试人员安装测试。

  • APK测试包(安卓)
  • IPA测试包(IOS)

1. 应用内测分发平台:

在实际测试过程中,为了方便测试程序包的安装和管理,通常将测试程序包上传到一些免费的应用内测分发平台上,测试人员通过扫描生成的二维码下载对应的程序包进行安装测试。(如:蒲公英、fir.im、第八区等)

2. 应用线上发布平台:
产品测试完成后将在线上进行发布,让用户下载使用。常用的发布平台和渠道:

  • 安卓:手机商城、应用宝、豌豆荚等;
  • IOS:App store、iTools。

3. 线上发布流程:
step1:APK/IPA包测试完成;
step2:提交app包到应用市场审核(苹果的APP store审核一个应用需要一周左右时间,安卓各市场审核普遍在3天左右);
step3:应用市场审核完成后会给这个app分配一个平台ID
step4:将平台ID打包到对应app,之后对这个包进行测试(主要业务流程测试)
step5:正式提交发布

4 测试要点

4.1 业务功能测试

按照用户的需求(需求说明书、原型等)去检验开发的代码实现是否满足用户的功能性需求。

(1)测试对象:

  • 功能点(单独模块)->单元测试
  • 多模块->集成测试
  • 业务流程->系统测试、验收测试、冒烟测试

(2)测试角度:

  • 显性需求: 需求文档写明的功能

  • 隐性需求:
    1)功能影响到的相关业务
    2)分支流程、逆向操作、异常操作(网络中断等)
    3)根据测试策略、业务知识、测试经验补充用例进行测试

4.2 兼容性测试

APP在不同的软硬件环境都能够正常使用(具有可移植性)

(1)信息获取渠道:
1)第三方网站统计工具
2)官网数据
3)埋点技术:网站分析的一种常用的数据采集方法

(2)选取测试机原则:
1)需在一定数量真机上进行测试
2)借助模拟器:腾讯的手游助手、网易的mumu、蓝叠模拟器; 知名度比较高的还有雷电模拟器、夜神模拟器、靠谱模拟器、海马模拟器等等
3)云测平台:
a. 国内云测平台:testin、百度MTC、腾讯WeTest、阿里MQC等
b. 国外云测平台:perfecto、TestDriod

(3)兼容性测试关注点:

1)硬件兼容性:

覆盖市场主流手机厂商及各型号产品,考虑APP线上品牌和机型排名,需要做app的安装卸载测试,保证app能正常运行。

2)操作系统兼容性
覆盖市面上的主流操作系统及各版本,考虑线上系统版本排名,iOS直接挑选相应的操作系统,android根据android系统版本和各厂商在其之上的定制版本做一些组合挑选(可以跟硬件兼容一同交叉考虑),主要做app的安装卸载测试,并对核心功能进行回归。

3)分辨率兼容性
覆盖市面上各种主流的屏幕分辨率和屏幕尺寸。主要关注UI上对各种分辨率和尺寸的适配情况。参考网站:http://www.woshipm.com/screen/

5)网络兼容性:
在不同的网络制式下,不同的网络运营商提供的网络下,app能不能正常运行,需要使用真机测试,对核心的包含网络请求的功能进行测试。

4.3 安装、卸载、升级测试

(1)安装测试关注点:
1)正常流程安装,测试是否安装成功
2)不同安装渠道安装(应用市场、手机助手、直接下载APK或IPA文件)
3)版本覆盖
4)版本回退
5)在不同手机、不同操作系统、不同分辨率、不同屏幕大小的手机上安装
6)安装结束应用程序启动是否正常
7)安装结束重启手机应用程序启动是否正常
8)安装时出现意外情况,如断网、接听电话、查看消息、关机等,恢复后是否继续安装
9)安装时内存不足
10)正在运行时覆盖安装
11)取消后再次安装

(2)卸载测试关注点:
1)正常卸载(APP卸载、工具卸载)
2)运行时卸载
3)取消卸载
4)卸载时出现意外情况,如断网、接听电话、查看消息、关机等
5)在不同手机、不同操作系统、不同网络环境下进行卸载
6)卸载后安装,是否正常使用
7)卸载后是否存在卸载残留

(3)升级测试关注点:
1)从临近版本升级
2)跨版本升级
3)不同渠道升级(应用市场、手机助手、直接下载)
4)升级提醒
a. 强制升级:软件存在严重BUG、软件不能向下兼容
b. 可不提醒
c. 可以提醒升级
5)应用内升级时,非WI-FI提示
6)升级后需观察升级前数据是否正常(数据结构改变若未妥善处置容易出现数据混乱)
6)断点续传:
7)程序下载过程中出现异常情况(断网、关机等),重新恢复后,是否能继续下载

4.4 交叉事件测试

交叉测试又叫冲突测试或者干扰测试。是指一个功能正在执行过程中,另外一个事件或操作对该过程进行干扰的测试。如:在运行过程中接听电话等。

测试点:
(1)APP运行时接打电话(要出现接听电话的界面)
(2)APP运行时接收/发送短信息
(3)APP运行时查看应用消息推送
(4)APP运行时插拔耳机
(5)APP运行时接收文件弹窗提醒
(6)APP运行时旋转屏幕
(7)APP运行时网络切换
(8)APP运行时使用系统自带应用(摄像头、计算器等)
(9)APP运行时电量告警、插拔充电器

4.5 PUSH消息推送测试

(1)消息推送场景:

1)产品角度:功能需要,工具类产品的公告推送、咨询类产品的新闻推送等
2)运营角度:活动运营需要,召回用户、电商类产品促销等

(2)消息推送原理:

1)客户端主动获取(PULL)
a. 客户端间隔固定时间主动向服务器获取信息,若有信息更新则发送到客户端
b. 基于短链接

2)客户端被动接受(PUSH)
a. 服务器消息更新时,主动发送到客户端
b. 基于长链接

3)对比
PUSH优于PULL:
a. PUSH方式在满足需求情况下更省资源
b. PULL方式,客户端需不断监测服务器变化,消耗更多服务器资源(CPU、网络流量、系统电量)

(3)PUSH消息推送实质:

  • 当服务器有新消息推送给用户时,先发送给应用APP,应用APP在发送给用户。
    \"APP测试_第2张图片\"

(4)PUSH消息推送方式:

1)操作系统消息推送服务

a. IOS:

  • 应用的后台服务器 -> APNS:苹果的消息推送服务器 -> 手机 -> 应用APP
  • 消息推送服务器有一个统一入口,当有后台有信息更新,后台服务器把消息发送至消息推送服务器,手机开机后,IOS系统会把手机信息注册到消息推送服务器中,因此消息推送服务器能将消息推送到具体的手机,又因应用APP会在操作系统里注册,所以操作系统能将消息推送到应用APP。

b. Android: C2DM (Cloud to Device Messaging),目前使用较少,因为是Google开发的,Google很多网址国内无法正常访问。

2)调用第3方推送平台:
a. 手机厂商开发:小米推送、华为推送
b. 软件大厂BAT推送:腾讯信鸽、百度云推送、阿里云移动推送
c. 专门做推送的第三方平台:极光推送、友盟推送

3)自搭建推送服务器
无论是功能、性能还是安全性都比较好,但是成本较高, 一般小公司无能力搭建

(5)消息推送形式:
a. 弹窗
b. 消息通知栏

(6)PUSH推送设置:
1)APP服务器设置:
a. 推送对象:

  • 全部用户
  • 部分用户
  • 特定用户

b. 推送方式:

  • 主动推送:在应用服务器明确消息需推送给哪些用户,直接推送消息
  • 被动推送:在应用服务器后台设置对应的规则,满足规则的用户收到对应的消息(如:淘宝监控一年以内的消费情况, 不同的消费金额推送不同的优惠卷)

2)手机端设置:是否接收通知,提醒位置等

(7)测试关注点:
1)Push消息能否按设定业务规则发送
2)Push消息针对特定用户,收到的push消息与用户身份是否相符
3)系统设置不接收该APP通知消息时,用户应该不再收到Push消息
4)Push消息显示的位置是否与设置一致
5)Push消息能否正常打开
6)APP在前台使用时,Push消息如何提示
7)APP在后台运行时,Push消息如何提示
8)APP离线时,能否收到Push消息
9)设备锁屏状态下,能否收到Push消息
10)设备网络断开后再一次建立连接时,能否收到Push消息

4.6 用户体验测试

主观站在用户角度观察被测APP的可用、舒适、友好等方面,提交问题时,为“建议”类别。

关注点:
(1)UI界面测试
对照UI交互设计文档,检查每个界面设计菜单、对话框、窗口、风格、布局等

(2)易用性测试(易理解、易操作、易使用、符合用户正常操作习惯)
1)是否有空数据的界面设计,以引导用户执行操作(比如购物车中无商品时的界面显示、游戏APP的新手指引)
2)菜单层次的深度
3)交互流程分支是否过多
4)完成业务操作的步骤是否过多
5)界面中按钮可点击的范围
6)是否定义back的逻辑(手机自带的返回键)

(3) 横竖屏测试
针对每个页面做横竖屏测试(特别关注APP中的表格)

(4)关注手机应用上的辅助功能
放大字体、反色、语音切换、多点触碰等

4.7 稳定性测试

通过长时间对应用程序进行无序操作,检验应用程序是否会出现异常,如闪退(crash)、无响应(ANR)等。

测试工具Monkey: Monkey是有安卓官方提供的一个命令行工具。通过Monkey模拟用户的进行随机操作(触摸、点击、滑动、系统按键等),从而实现对APP的压力测试和稳定性测试。

测试时机: 产品稳定,BUG较少时进行稳定性测试

4.8 性能测试

4.8.1 性能测试指标

内存、CPU、流量、电量、启动速度、流畅度等

4.8.2 关注点

1)APP的启动时间是否过长
2)APP使用时对CPU、内存的占用情况
3)APP使用时,电量流量的消耗情况
4)APP使用是否流畅等
5)反复长期的操作情况下,系统资源的使用情况

4.8.3 性能测试工具GT

GT(随身调),安卓版是腾讯MIG专项测试组自行研发的APP随身调测平台,是直接运行在手机上的“集成调测环境“,可以使用GT完成以下测试工作:
(1)基础性能测试:手机整机或手机上安装的任何APP的CPU、内存、网络流量、流畅度/帧率、电量等基础性能指标的实时展示、历史数据采集、excel格式存储、曲线绘制等
(2)查看日志
(3)抓包:直接用手机抓包保存成pcap文件,在PC端用Wireshark查看

4.8.3.1 GT安装方法:

(1)像普通APP一样独立安装(只有APK版本)
(2)GT SDK:将GT SDK嵌入到被调测的应用程序工程中
(3)下载地址:https://github.com/Tencent/GT/releases/tag/v3.1.0

4.8.3.2 CPU测试

(1)GT 的两个CPU性能监控指标:CPU 和 jiffies

1)CPU:
a. 整机的CPU使用水平,即当前手机的CPU整体使用率。
计算公式:
a) android系统基于Linux系统,在Linux系统下,CPU利用率分为用户态、系统态和空闲态:

  • 用户态:表示CPU处于应用程序执行的时间(手机上安装的程序使用CPU的时间)
  • 系统态:表示系统内核执行的时间(手机系统在控制电池消耗、屏幕显示、数据读写时使用CPU的时间)
  • 空闲态:表示空闲系统进程执行的时间(没有任何程序运行,启动idle进程,idle进程占用CPU,不执行任何操作,若有应用程序启动或操作系统任务即将执行,idle进程将释放CPU给用户进程或系统进程)

b) CPU使用率 = CPU执行非系统空闲进程 / CPU总的执行时间,即 CPU使用率 = (用户态 + 系统态) / (用户态 + 系统态 + 空闲态)

2)jiffies:
表示自开机以来,应用程序消耗的CPU时间片总数(CPU在工作的时候会划分为若干个时间片,每个时间片的时间间隔以微秒记)

(2)CPU问题产生的现象:
1)CPU使用长时间处于90%以上
2)手机发热,耗电量增加
3)反应变慢,引起ANR(应用程序没有响应)

(3)CPU测试方法:
step1:打开GT,配置CPU监控指标(可配置告警阈值)
step2:进入待测APP进行业务操作
step3:进入GT,观察待测APP运行时CPU指标变化(CPU是否有快速飙升、CPU使用率是否长时间90%以上)
step4: 保存CPU详细数据并分析

4.8.3.3 内存

(1)GT的两个内存监控指标:PSS 和 Private dirty:
1)PSS(实际使用内存):私有内存 与 共享内存之和;有一块内存空间是供所有程序一起使用的,即共享内存。进程占用的共享内存在进程销毁时,不会回收内存容量,会分配给其他进程。
2)Private dirty(私有内存):进程独占内存,即进程销毁时可以回收的内存容量

(2)常见的内存问题
1)内存溢出(out of memory),指程序在申请内存时,没有足够的内存空间供其使用,出现out of memory
2)内存泄漏(memory leak),指程序在申请内存后,无法释放已申请的内存空间,一次内存泄露危害可以忽略,但内存泄露堆积后会导致内存被占光;内存泄漏最终将导致内存溢出。

(3)内存问题产生的现象
1)程序实际使用内存PSS持续增长
2)程序出现crash(内存溢出通常导致程序crash)

(4)内存测试方法:
step1:打开GT,配置内存监控指标(可配置告警阈值)
step2:进入待测APP进行业务操作
step3:进入GT,观察待测APP运行时内存指标变化(程序实际使用内存PSS是否持续增长、程序是否出现crash)
step4: 保存CPU详细数据并分析

4.3.8.4 流畅度

(1)GT的流畅度指标:FPS:
1)FPS,即每秒的帧率,GPU在一秒内绘制的帧数
2)动画片由一张张图片连贯执行产生动画效果,当每张图片间切换速度足够快的时候,会欺骗人眼,形成动画。图片切换不够快的时候,反馈给用户的就是卡顿现象

(2)流畅度问题产生的现象:
1)要达到至少每秒10-12帧的速度,大脑才会将觉得动作是连续的
2)至少每秒24帧的速度,才能达到流畅的效果
3)最佳的流畅度是每秒60帧
4)通常要求FPS在24帧/s以上,最低不能低于10帧/s,最高不超过10帧/s

(3)流畅度测试方法:
step1:打开GT,配置流畅度监控指标
step2:进入待测APP进行业务操作(主要针对上下滑动等)
step3:进入GT,观察待测APP运行时流畅度运行结果
step4: 保存流畅度详细数据,计算平均值(FPS是否在24帧/s—60帧/s)

4.3.8.5 流量

(1)GT的流量监控指标:NET:
手机通过运营商网络访问Internet,运营商替我们的手机转发数据报文,数据报文包含手机上下行报文,数据报文的总大小(字节数)即流量。
1)上行消息:APP发往应用服务器的消息
2)上行流量:上行消息总大小
3)下行消息:服务器发给APP的消息
4)下行流量:下行消息总大小

(2)常用的流量测试方法:
1)统计测试法:获取应用程序收发数据的报文,统计出对应的流量
2)抓包测试法:利用工具抓包,如fiddler 或 Tcpdump,导出pcap文件后在Wireshark中打开

(3)流量测试方法:
step1:打开GT,配置流量监控指标NET
step2:进入tab,选择抓包以获取业务测试报文(抓包参数配置为:-p -s 0 -vv -w)
step2: 进入待测APP进行业务操作
step4:查看流量统计结果
step5: 操作结束后进入抓包插件,停止报文获取
step6: 保存流量详细数据并分析

(4) 流量优化方法(主要优化服务器下发数据):
1)压缩数据
2)采用不同数据格式(使用普通图片而非高清图)
3)控制访问频次(控制向服务器请求数据的次数)
4)只获取必要的数据(比如访问知乎,不获取知乎详情页的数据)
5)利用缓存
6)针对不同的网络设置不同的访问策略(WI-FI:高清图;4G:缩略图)

4.3.8.6 电量

(1)GT的流量监控指标:电流、电压、电量、温度:
电量测试:移动设备电量消耗快慢的一种测试方法。一般用平均电流衡量电量消耗速度;平均电流越小,说明设备使用时间越长。

(2)常见耗电场景:
1)定位(尤其调用GPS定位)
2)网络传输(尤其非WI-FI环境)
3)屏幕亮度
4)CPU频率
5)内存调度频率(内存调度频繁时,CPU消耗一般较高)
6)wake_locker(锁屏和重新解锁屏幕)时间和次数

(3)电量测试方法:
step1: 打开GT,进入插件tab,点击耗电数据采集
step2: 选择采样频率、屏幕亮度和采集参数
step3: 进入待测APP进行业务操作
step4: 测试完成后,回到参数页面,点击停止录制
step5: 保存电量数据并分析

(4)电量测试结果分析
1)与基准数据对比(基准数据来自于产品经理或历史数据积累)
2)横向对比,与竞品电量消耗数据对比分析(目前采用最多);在同样的网络、手机,相似的测试场景下对竞品进行测试,对比自有产品和竞品在耗电量方面的差距,给出优化建议

4.3.8.7 启动速度

(1)冷启动和热启动
1)冷启动:app被后台杀死后,在这个状态打开app
2)热启动:app仍在后台运行,再次打开app

(2)测试方法
1)使用命令:abd shell am start -W -n 包名/Activity名
a. 包名:应用程序包名具有唯一性
b. Activity名:页面名
c. 上述命令获取3个指标:

  • thistime:表示一连串启动Activity的最后一个Activity启动耗时,一般<=Total Time时间(当前Activity页面的时间)
  • Total Time:应用的启动时间,包括创建进程、APP初始化、Activity初始化到页面显示
  • Wait Time:前一个应用Activity pause的时间+Total Time

(3)启动时间测试结果分析

  • 与基准数据对比(基准数据来自于产品经理或历史数据积累)
  • 横向对比,与竞品启动时间数据对比分析(目前采用最多);在同样的网络、手机,相似的测试场景下对竞品进行测试,对比自有产品和竞品在启动时间方面的差距,给出优化建议

5 APP上线后的注意事项

(1)用户反馈跟踪:
收集用户反馈的问题进行排查分类,明确是用户体验问题或是BUG(用户体验问题提交为“建议”性BUG,若是BUG进行线上BUG处理)

(2)线上BUG处理:
分析BUG的严重程度
a. 一般程度BUG:在测试环境重现、定位BUG,在后续版本解决
b. 严重BUG:进行版本回滚

(3)版本优化:
用户体验问题和一般问题BUG在后续版本中排期修改,在新版版中发布

ItVuer - 免责声明 - 关于我们 - 联系我们

本网站信息来源于互联网,如有侵权请联系:561261067@qq.com

桂ICP备16001015号