1 APP应用架构

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在发送给用户。
  

（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在后续版本中排期修改，在新版版中发布