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

陈小乖爱吃土豆豆

已于 2023-07-25 11:46:30 修改

阅读量823

点赞数

分类专栏：高级测试 App 文章标签：可用性测试

于 2023-07-17 17:04:31 首次发布

本文链接：https://blog.csdn.net/weixin_39431589/article/details/131769170

版权

高级测试同时被 2 个专栏收录

4 篇文章 0 订阅

订阅专栏

App

2 篇文章 0 订阅

订阅专栏

前言

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

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

移动端测试的复杂性：
① 操作系统上：主要体现在系统版本众多。
② 网络上，手机支持的网络很多（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. 数据来源

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

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稳定性测试工具有 (工具对比详情)：

Google Monkey
AppCrawler
Maxim自动化遍历
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的启动将经历两个阶段：

阶段一

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

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

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

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

1.2. 热启动

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

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

1.3. 温启动

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

2. 启动优化方案

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

利用提前展示出来的Window，快速展示出来一个界面，给用户快速反馈的体验；
避免在启动时做密集沉重的初始化（Heavy app initialization）；
定位问题：避免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也是一种传感器，定位中没有及时关闭，会导致耗电；

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