软件高级测试之APP专项测试

---

前言

1. 移动端指的是以智能手机为主、平板电脑为辅的机器。
2. 移动端的操作系统：IOS（苹果公司）、Android（谷歌公司）、Symbian（诺基亚）、Blockberry
3. 移动端应用：原生APP（application）、Web APP、小程序
4. 移动端测试的分类：传统手机测试、手机应用软件测试

• 传统手机测试（移动端设备的测试）：针对手机硬件的测试（电量、网络、kang摔、抗压······）
• 手机应用软件测试（移动端软件测试）：运行在手机上的各种软件和应用程序的测试。

5. 移动端测试的复杂性：
   ① 操作系统上：主要体现在系统版本众多。
   ② 网络上，手机支持的网络很多（wifi、2G、3G、4G、5G）
   ③ 硬件上：手机品牌多、配置各种各样，增加了测试的复杂度
   ④ 手机携带各种芯片和部件，额外的功能和APP的实用度。

故而，移动端测试就是符合多种网络、不同系统、不同分辨率、不同硬件配置下发现软件缺陷，并保证提高软件质量的过程。

我们对比了下，移动端测试与PC端软件测试区别：

比较点	移动应用	PC应用
应用类型	Native App和Web App以及混合型	Client和Web
操作方式	多点触摸	鼠标和键盘
界面布局	操作界面少，流程简单	操作界面复杂且流程复杂
设备尺寸	移动设备屏幕小，手机和平板的屏幕尺寸相差巨大，且各自屏幕大小种类繁多	PC显示屏幕大且其软件应用也不受屏幕限制
功能	强调主要功能以及用户常用功能	支持全部功能
设备网络连接方	主要是2G/3G/4G/WiFi	有线方式或者WiFi
应用设备限制	存储空间小，连接不稳定、带宽较小、流量费用限制、动互联网上的风险等	存储空间大，带宽相对较宽，连接一般也较稳定,各种安全软件安装齐全
用户使用习惯	移动用户随时随地就会使用移动软件应用，强调移动性	用户一般在固定的地点使用PC应用

移动端测试流程：

接下来，就从以下几个方面来说明下移动端的专项测试。

---

一、兼容性测试

兼容性测试是软件测试过程中的一个重要环节，它的主要目标是验证软件在不同的操作系统、浏览器、设备以及其他相关环境中的兼容性。

更多显示内容，请定位到文章开始位置，点击下载Excel文档：
资源来源于：https://blog.csdn.net/tcc374254426/article/details/121976688

二、弱网测试

在我们日常的工作过程中，常用**Charles**做移动端模拟弱网的测试，具体细节请查阅https://blog.csdn.net/tcc374254426/article/details/121975527

三、健壮性测试

健壮性测试又称为容错测试，他只是一个概念，用于测试系统在出现故障的时候，是否能够自动恢复或者忽略故障继续持续的运行，比如说我们在使用APP的过程中，有多个模块，其中有一个模块出现了问题，其他模块是否能够正常运行，或者该模块在等待五秒后是否能够自动恢复。

对于健壮性测试的原理我们可以理解为对应用的APP进行随机盲点测试，例如monkey测试，或者是模拟网络较差的情况等，常使用的工具主要有Monkey，Maxim，Charles，Appcrawler。
在这里我们这里要讲的就是，在接口数据返回异常时，APP可以继续运行，不崩溃。

1. 数据来源

1. 本地数据（读取本地文件、代码中配置等）
2. 网络请求的数据

App客户端网络请求的数据，一般都是以开发时约定好的json格式的形式来传输，在这个过程中，会出现各种各样的状况，比如：

情况1：客户端开发认为：我请求了，就一定会给我结果，写代码时，就没有考虑到请求不返回的情况。导致 --> 页面始终处于loading加载中，未做超时处理。

情况2：客户端开发认为：我请求了，就一定会给我正确的格式，写代码时，就没有考虑到请求返回的格式不正确的情况，比如上图的json结构发生变化
情况3：接口返回的某个字段的value值，需要客户端进行二次处理，开发在处理时，没有考虑到一些异常值的情况，比如上图的code，msg等值为空或者NULL等等
这两种情况，均会导致空指针或数组越界报错，APP直接闪退。

以上几种情况，如果不进行专门的容错测试，从测试直到上线，可能都是没问题的，但突然有一天，服务器接口修改或者其他情况，导致接口数据返回出现异常，线上就出现很多严重的崩溃问题，bug率急剧飙升，这就是因为客户端没有进行很好的容错处理。

2. 优化方案

2.1 Monkey

monkey一般在功能测试通过、产品稳定以后进行，测试应用是否会出现闪退、崩溃等。它是Android SDK自带的一个命令行工具,可以运行在模拟器或真机中,它向系统发送伪随机的用户事件流(如按键输入、触摸屏输入、手势输入等)，monkey是一种测试软件的稳定性、健壮性的快速有效的方法。
具体使用详情，请参考：
https://blog.csdn.net/tcc374254426/article/details/121931732

2.2 Charles

App对服务端接口数据的容错测试的测试方法，我们主要采用Charles来实施，具体细节请查阅 https://blog.csdn.net/tcc374254426/article/details/121975527

四、稳定性测试

一个App安装在一台设备上,总是闪退、屏幕热、机身热、设备卡死甚至崩溃等现象,直接影响用户使用功能或者用户卸载App,最终的结果是流失用户群里。

同时，项目迭代中,一般会对每个版本的App进行稳定性测试,在正式发布前拦截Crash。而稳定性测试方案中对于测试工具的选型方案是决定了发现Crash问题的可能性。
常见Android稳定性测试工具有 (工具对比详情)：

1. Google Monkey
2. AppCrawler
3. Maxim自动化遍历
4. Fastbot

1. Fastbot

官网地址：https://github.com/bytedance/Fastbot_Android
基于model-based testing 结合机器学习、强化学习的APP 稳定性测试工具。
其优势有以下几点：

优势	描述
Android iOS兼容	同时兼容Android5-12，兼容国内各厂商定制化的Android系统及原生Android系统
事件快速注入	继承原生Monkey的优势，快速点击，每秒最高可发送12个事件
专家系统	不同业务线支持不同的个性化需求，业务深度定制化
智能化测试	基于model-based 边遍历边建模，利用强化学习等算法做高收益决策
跨平台	支持非标准化控件，YOLOv3、ocr、cv分割等UI图像识别能力

具体使用，可参考：https://zhuanlan.zhihu.com/p/517792117
字节自研 Fastbot 如何助力今日头条稳定性测试

五、安全测试

至于APP的安全测试，看这一篇文章就够了：https://blog.51cto.com/laoyinga/2155341

六、启动性能分析

app启动是和用户的第一个交互过程，app启动速度是否过慢，启动过程中会不会遇到白屏黑屏等… 流畅快速的启动app，会给用户留下良好的第一印象，也是我们在app测试过程中需要关注的方面。

APP的启动有三种方式：冷启动（cold start）、热启动（hot start）、温启动（warm start）

1. 启动方式

1.1. 冷启动

系统不存在App进程（APP首次启动或APP被完全杀死）时启动APP
此时，APP的启动将经历两个阶段：

阶段一

1. 加载并启动app
2. app启动后，第一时间为app显示一个空白的window
3. 创建app进程

阶段二
系统一旦创建了app进程，app进程就要负责做以下的任务：

1. 创建app对象
2. 启动主进程ActivityThread
3. 创建启动Main Activity对象
4. 加载渲染View
5. 执行onLayout （布置屏幕）
6. 执行onDraw，进行第一次绘制
7. 完成第一次绘制后，把mainActivity替换已经展示的BackgroundWindow

作为普通应用，App进程的创建等环节我们是无法主动控制的，可以优化的也就是Application、Activity创建以及回调等过程。

1.2. 热启动

当我们按了Home键或其它情况app被切换到后台，再次启动app的过程，称之为热启动。

热启动时，系统将Activity带回前台。如果应用程序的所有activity存在内存中，则应用程序可以避免重复对象初始化、渲染、绘制操作。但是如果由于内存不足导致对象被回收，则需要在热启动时重建对象，此时与冷启动时将界面显示到手机屏幕上一样。

1.3. 温启动

温启动包含了冷启动的一些操作，由于app进程依然在，温启动只执行冷启动的第二阶段，这代表着它比热启动有更多的开销。

2. 启动优化方案

这里比较关注的是冷启动，因为热启动本来时间就很短，不需要进行优化，
这里，Google给出的启动加速的方向：

1. 利用提前展示出来的Window，快速展示出来一个界面，给用户快速反馈的体验；
2. 避免在启动时做密集沉重的初始化（Heavy app initialization）；
3. 定位问题：避免I/O操作、反序列化、网络操作、布局嵌套等。
   方向1属于治标不治本，只是表面上快；方向2、3可以真实的加快启动速度。

比较专业的优化方案，也是需要研发人员实施的方案，可参考文章 App性能优化（一）—— 启动优化，冷启动，热启动，温启动
而作为测试，我们是没有权限和能力去修改开发的代码的，那么我们就需要借助app启动性能分析工具 adb logcat，计算分析启动花费时间，具体实施可参考文章： https://blog.csdn.net/tcc374254426/article/details/121975251

七、耗电量测试

相对于PC端来说，移动设备的电池电量是非常有限的，保持持久的续航能力尤为重要。Android的很多特性都比较耗电（如屏幕、GPS、sensor传感器、唤醒机制、CPU、连网等的使用），我们必须要慎重检查APP的电量使用，以免导致用户手机耗电发热，带来不良体验。

1. 耗电场景

主要的耗电场景有：

• cpu：复杂的运算逻辑、死循环等会直接导致CPU负载过高，会导致耗电；
• wakelock：只要有应用拿到wakelock这个锁，系统就无法进入睡眠状态。频繁wakelock或者申请了wakelock没有释放，会导致耗电；
• wifiscan和wifilock：wifiscan和wifilock也会导致手机的wifi模块处于激活状态，频繁的wifiscan或者wifilock不释放，会导致耗电；
• sensor：传感器打开后会导致系统持续监听设备外围环境的数据变化，使用后不及时关闭，会导致耗电；
• network：大量的数据传输，或者长时间的移动网络数据传输导致radio长期处于活跃状态，会导致耗电；
• gps：gps也是一种传感器，定位中没有及时关闭，会导致耗电；

业务层面，用户最核心基础的模块：

• 新增的基础逻辑，倘若入口明显，潜在较大访问，必须保证性能；
• 活动需要，因为活动上新的逻辑，存在较大的用户访问，需尽力提升用户体验；
• 反馈体验不好的模块。

2. 耗电量测试分析

2.1 Android

• Battery Historian耗电量消耗

参考：Android app耗电量测试

2.2 IOS

• Energy Impact
• Sysdiagnose

参考： APP专项测试之耗电量测试

七、流量测试

在 移动产品的测试中，很有必要对App使用的流量进行度量，大致来说，流量可以从用户使用的的相关性角度分为：

1. 用户的操作直接导致的流量消耗
2. 后台，即在用户没有直接使用情况下的流量消耗

1. 测试项

流量测试应该注意的测试项:

1）应用首次启动的流量提示；
2）应用后台连续运行2小时的平均流量值；
3）应用在运行极限的平均流量值（大数据传输）
4）针对场景法涉及的应用主流程方法的测试
5）在首次登陆时的平均值（多台设备测试）

2. 测试分析

• Android系统自带统计功能（总体流量数值）
• Wireshark+tcpdump
• GT（随身调）工具（直接调用android的api）

参考：App 流量常见测试方法

---

附录参考文档地址：
移动端测试
https://blog.csdn.net/tcc374254426/category_11537622.html