软件功能测试–app测试

app与web的区别

• 系统架构
  • app是C/S结构
  • web是B/S结构
• C/S：即客户端/服务器，需要下载安装客户端
• B/S：即浏览器/服务器，基于浏览器访问。

app测试范围

1. 功能测试
   1. 业务测试
   2. 功能模块测试
2. 性能测试
   1. CPU、内存占用
   2. 启动速度
   3. 流量和电量消耗
   4. 流畅度
   5. 稳定性
3. 专项测试
   1. 安装卸载与升级
   2. push消息推送
   3. 交叉事件测试
   4. 用户体验测试
   5. 兼容性测试

app发布

将开发完成的移动应用程序通过特点的渠道和流程，向公众发布，使得用户可以下载、安装并使用应用程序。

分类：

• 内部发布渠道
• 线上发布渠道

内部发布

• 在实际测试工作中，为了方便测试程序包的安装和管理，可以使用一些应用内测分发平台。
  • 蒲公英
  • testink等

步骤：

1. 开放将应用测试包上传到这些平台上
2. 平台可以生成对应的二维码
3. 测试直接扫码进行应用安装

线上发布

• 产品测试完成后，将app发布到应用各种平台上。

步骤：

1. 开发者账号注册，申请在发布平台上架
2. 针对不同的发布平台，在软件包中加入对应的平台ID，上传到发布平台。
3. 平台审核通过后，用户即可在应用商店下载。

发布策略

项目发布时采用的一种测率，先发布少数（1-3）服务器，待运行稳定后再发布到所有服务器。

常见环境：

1. 开发环境
2. 测试环境
3. 预发布环境
4. 生产环境

app功能测试

功能测试定义

使用技术手段，验证程序功能是否符合应用需求。

测试对象：

• 核心业务
• 单功能

测试流程：

1. 需求分析与评审
2. 测试计划设计
3. 测试用例设计与评审
4. 测试用例执行
5. 缺陷管理
6. 编写测试报告

测试方法：

• 等价类：穷举数据选取
• 边界值：长度范围覆盖
• 判定表：多条件之间约束限制
• 场景法：业务流程

登陆案例

需求分析

• 登录
  • 账号
    • 正向：已注册手机号
    • 反向
      • 手机号未注册
      • 空
  • 密码
    • 正向：正确密码
    • 反向
      • 为空
      • 错误密码
  • 协议
    • 正向：勾选
    • 反向：为空不勾选
  • 三方
    • 正向
      • 微信
      • QQ
• 其它：
  • 关闭登录窗口成功（点击X）
  • 密码可见成功（点击眼睛使其睁开）
  • 打开注册协议成功
  • 打开隐私协议成功
  • 打开注册界面成功（点击手机快速注册）
  • 打开找回密码页面成功（点击找回密码）
  • 登陆页面布局与原型图一致

测试点提取

• 测试点提取
  • 正向
    • 登陆成功（账号+密码+协议）
    • 登陆成功（微信）
    • 登录成功（QQ）
  • 反向
    • 登陆失败（手机号未注册）
    • 登录失败（手机号为空）
    • 登陆失败（密码为空）
    • 登陆失败（密码错误）
    • 登录失败（协议未勾选）

搜索功能测试练习

测试点提取

搜索成功（汉字）

搜索成功（拼音）

搜索成功（单词）

搜索成功（错别字）

搜索成功（同音字）

搜索成功（数字同音）

搜索成功（标点符号释义）

搜索成功（匹配分类）

搜索成功（匹配标题）

搜索成功（匹配商品名称）

搜索成功（匹配品牌）

搜索成功（匹配厂商）

搜索成功（分词搜索）

搜索推荐内容成功（为空）

• 其他
  • 自动不全提示成功

app非功能测试

app专项测试

专项测试：app在不同的移动设备上能持久、稳定的运行app程序

专项测试的目的

• 保障主流移动设备能正常使用app应用
• 不同的网络环境app应用正常使用
• 不同app版本正常使用

专项测试内容

1. 安装卸载与升级
2. 兼容性测试
3. push消息推送测试
4. 交叉事件测试
5. 用户体验测试

总结就是：

专项测试是app应用的安装、卸载、升级测试，兼容性测试，push消息推送测试，交叉事件测试，用户体验测试

app项目测试环境搭建

环境

app应用运行所依赖的软硬件

依赖

1. mumu模拟器（移动设备）
2. app安装包

安装

将apk拖入模拟器进行安装

对app（安装、卸载、升级）设计测试点

安装测试

• 正常场景：
  • 在不同的操作系统版本上安装
  • 从不同的安装渠道安装（app商城，手机助手，直接下载apk或者ipa文件安装）
  • 不同的安装路径（安装到手机、安装到sd卡上）
  • 卸载后安装
  • 正在运行时的覆盖安装
• 异常场景
  • 安装时出现异常（关机、断网），恢复后能否继续安装
  • 安装时存储空间不足
  • 安装时手动取消后再次安装
  • 低版本覆盖安装高版本
• 安装测试点提取
  • 安装成功（安卓）
  • 安装成功（ios）
  • 安装成功（鸿蒙）
  • 安装成功（手机助手）
  • 安装成功（安装包安装）
  • 安装成功（SD卡）
  • 安装成功（卸载后安装）
  • 安装成功（运行时覆盖安装）
  • 安装成功（安装一半关机后继续安装）
  • 安装成功（断网）
  • 安装成功（安装存储空间不足，清理后安装成功）
  • 安装成功（取消后再次安装）
  • 安装成功（跨版本安装）

卸载、升级测试

• 卸载关注点
  • 正常卸载（app手动卸载、使用工具卸载）
  • 运行时卸载
  • 取消卸载
  • 卸载异常中断后卸载
  • 卸载后无数据残留
• 升级测试的关注点
  • 从临近版本升级
  • 跨版本升级
  • 不同渠道升级（应用商场、手机助手）
  • 升级提醒成功（可不提醒，可以提示升级、强制升级）
  • 应用内升级时非wifi提醒
• 卸载测试点提取
  • 卸载成功（手动卸载）
  • 卸载成功（通过工具卸载）
  • 卸载成功（运行时卸载）
  • 卸载成功（取消卸载后再次卸载）
  • 卸载成功（异常中断再卸载成功–如关机）
  • 卸载成功（无数据残留）
  • 卸载成功（保留配置数据）
• 升级测试点提取
  • 升级成功（临近版本升级）
  • 升级成功（快版本升级）
  • 升级成功（从应用商场升级）
  • 升级成功（从手机助手升级）
  • 升级成功（在线升级）
  • 升级成功（升级提醒成功（非wifi提醒））

注意事项：

升级后要观察升级前的数据是否正常（当数据结构改变而开发没有处理好时很容易出现升级前的数据混乱）

测试点转用例

抽取5条测试点（安装、卸载、升级）转成测试用例 

对app兼容性设计测试点

兼容性：

程序可以在不同的设备上运行正常。

例如：

• 不同的品牌型号
  包括但不限于：品牌、系统版本、分辨率
• 在不同网络中
• 软件兼容问题
• 硬件兼容问题

应用兼容性测试的关注点

1. 与手机硬件兼容
   1. home键、电源键、音量调节
2. 与外部硬件设备兼容
   1. 耳机、蓝牙、数据线
3. 与操作系统软件兼容
   1. wlan设置、系统时间调节、lbs定位等
4. 与其它app兼容
   1. 后台在播放音乐时，进入动态页面点击动态视频的播放，系统如何处理。

兼容性测试方法

1. 使用公司已有的真机进行兼容性测试
2. 使用第三方的兼容性平台进行测试
   地址：线上云测平台（https://www.testin.cn/）

   

兼容性测试就是品牌型号+分辨率+网络+软件+硬件之间的兼容问题。

兼容性测试点提取

测试目的：

• app运行正常

要根据实际型号来写

• app运行正常（华为XXX）
• app运行正常（小米XXX）
• app运行正常（oppoXXX）
• app运行正常（2g）
• app运行正常（3g）
• app运行正常（4g）
• app运行正常（5g）
• app运行正常（wifi）
• app运行正常（与home键应用不冲突）
• app运行正常（与音量键应用不冲突）
• app运行正常（与有线耳机不冲突）
• app运行正常（与蓝牙耳机不冲突）
• app运行正常（数据线不冲突）
• app运行正常（wlan设置不冲突）
• app运行正常（系统时间调节不冲突）
• app运行正常（LBS定位不冲突）
• app运行正常（音乐播放不冲突）
• app运行正常（微信应用不冲突）
• app运行正常（支付宝应用不冲突）

app中的push消息推送测试点设计

push消息时app推送的各种通知。

如：

• 点赞、评论、关注

push消息推送方式

• pull（拉）客户端主动获取：客户端固定时间主动向服务器获取消息。
• push（推）客户端被动接受：当服务器有更新消息时，主动发送到客户端。

pull方式消耗客户端和服务器资源。

push方式节省客户端和服务器资源。

注意：

在app项目中，基于手机电量与流量的考虑，使用的都是push方式进行消息推送，因此又叫push消息。

push消息推送流程：

当服务器有更新消息时——》推送服务器到app——》由app通知用户。

常用的三种推送服务器：

1. 操作系统级别的消息推送服务器
   1. ios、安卓
2. 自己搭建的推送服务器
   1. 好处：性能强，安全性高
   2. 缺点：成本高
3. 第三方推送平台
   1. 手机厂商
   2. 第三方平台
   3. BAT大厂的推送

push消息推送测试的关注点

push消息推送的设置：

• app服务器设置
  • 推送内容
  • 推送时机
  • 推送频率
  • 推送人群（全部用户和部分用户）
• 手机端设置
  • 是否接受通知
  • 提醒位置等

push消息测试关注点

• app服务器设置测试点
  • push消息是都按照制定业务规则发送
  • 当push消息是针对特定用户时，检查收到的push与用户身份是否相符等
• 手机端设置测试点
  • 设置不接受消息推送时，用户是都会收到push消息
  • 设置push消息显示的位置，是否与配置一致
  • 收到push消息，是否能正常打开跳转等
• 其他测试
  • app在前台使用时，收到push消息如何提示
  • app在后台运行时，收到push消息如何提示
  • app离线，是否能收到push消息。

push消息推送测试点提取

push消息推送的最终目的：

• 收到消息

测试点：

• 收到消息成功（全部用户）
  • 覆盖：内容、时机、频率
  • 前置：app正在前台使用
• 收到消息成功（部分用户）
  • 前置：app后台运行
• 收到消息成功（离线后再上线）
• 收到消息失败（离线）
• 收到消息失败（关闭手机推送权限）

总结

push消息测试点转用例

将所有测试点（push消息）转成用例。

app交叉测试、用户体验设计测试点

交叉测试

交叉测试又叫（冲突、干扰）测试，是指一个功能正在执行过程中，另外一个事件或操作对该过程进行干扰的测试。

比如：

• 在app前台或者后台运行同时接听来电或者下载文件等。

交叉事件测试的关注点

1. app运行时接打电话
2. app运行时收发信息
3. app运行时查看应用推送
4. app运行时接上蓝牙设备
5. app运行时旋转屏幕
6. app运行时切换网络
7. app运行时使用相机、计算器等手机自带应用
8. app运行时电量告警，插拔充电器等

交叉测试点提取

关注点：

• 正常使用中对我的感染不受影响

测试点：

• 应用正常使用（电话干扰）
• 应用正常使用（短信干扰）
• 应用正常使用（push消息推送干扰）
• 应用正常使用（蓝牙设备干扰）
• 应用正常使用（接收文件干扰）
• 应用正常使用（旋转屏幕）
• 应用正常使用（网络切换）
• 应用正常使用（切换相机应用）
• 应用正常使用（切换计算器应用）
• 应用正常使用（切换闹钟应用）
• 应用正常使用哦个（电量警告）
• 应用正常使用（插拔充电器）

用户体验测试

以主观的角度去感知产品或服务的舒适、易用、友好亲切程度。

1. UI界面测试
   对照UI交互设计文档，检查每个界面设计菜单、对话框、窗口、风格、布局等
2. 易用性测试
   1. 是否有空数据界面设计，引导用户去执行操作
   2. 菜单层次是否太深
   3. 完成业务操作流程的步骤是否过多
   4. 界面中按钮可点击范围是否适中
3. 横竖屏测试
   1. 横竖屏的切换是否正常（特别要关注app中有表格，因为横竖屏的显示宽度不一样）
4. 关注手机应用上的其他辅助功能
   1. 可以重点关注“方法字体”、“反色”、“语音转换”、多点触碰等功能

用户体验测试点提取

测试点提取

• 页面布局是否与原型设计一致
• 页面字体、图片、颜色与UI设计一致
• 分辨率切换成功（横竖屏）
• 必填框空判断成空
• 菜单层级在3级内
• 操作步骤在5步内
• 按钮点击范围适中
• 任意界面导航明确

注意事项

用户体验测试较为主观，描述问题时尽量具体，需要有一定依据。

总结

app交叉测试、用户体验测试点提取

将5个测试点（交叉、用户体验）转成用例。

app性能测试

app的性能测试：测试app使用期间占用硬件资源（cpu、内存、流量、电量）使用情况

分类：

1. app程序运行时占用手机硬件资源情况
2. app稳定性

如何测试app（资源）性能？

使用工具或者命令进行测试

• 工具
  • solopi是一个无线的安卓自动化工具，具备录制回放、性能测试等功能
• 功能
  • 性能测试：
    • 能够对cpu、内存与网络环境进行限制，复现应用在性能较差、网络环境不佳的场景下的表现。
  • 录制回放
    • 能够将用户的操作记录下来，支持在各个设备上进行回放
  • 一机多控
    • 操作一台主机设备来控制多太从机设备，进行重复冗余的兼容性测试，能够极大提升兼容性测试的效率。

下载地址：

https://www.pgyer.com/solopi

安装：

独立安装的solopi（ios无该版本），像普通app一样安装

solopi的使用（选择测试项）

1.打开solopi，选择性能测试

2.选择被测应用，勾选监控指标，勾选后悬浮窗会出现在手机屏幕上

提示：

solopi使用时，需要申请悬浮窗权限（adb权限、读写权限），根据弹唱提示进行授权。

solopi的使用（监控）

3. 点击开始监控，随后打开被测app应用，开始测试

solopi使用（查看测试结果）

4. 查看数据采集结果

solopi使用（查看测试结果）

总结

1. app性能测试分类：
   1. 资源占用
   2. 稳定性
2. app性能工具
   1. 安卓：工具（solopi、GT）+命令（adb）
   2. ios：苹果开发工具xcode

app性能测试关注点

1. app使用时对cpu、内存的占用情况
2. app使用时是否流畅等
3. app使用时电量的消耗情况
4. app启动时间是否过长
5. app是否能够长时间稳定运行

1.内存

内存的监控指标：

每个程序运行时都需要将代码和数据放入内存中，内存不足则程序无法正常运行。

注意：

solopi工具提供了两个内存监控指标（private和pss）

• private dirty（私有内存）
  • 进程独占内存，也就是进程销毁时可以回收的内存容量
• pss（实际使用内存）
  • 将跨进程共享页也加入进来，进行按比例计算pss。这样能够比较准确的表示进程占用的实际物力内存。

内存问题的现象

常见的现象：

• 内存泄露
  • 内存泄漏memory leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄漏危害可以忽略，但内存泄露泄露堆积后果严重，无论多少内存，迟早会被占光。
  • memory leak最终会导致内存溢出。
• 内存溢出
  • 内存溢出out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of momery。

内存问题产生的影响：

• 程序实际使用的内存pss持续增长可能是内存泄露。

  

• 程序出现crash（崩溃）可能是内存溢出。

案例：性能内存测试

需求：

• 浏览被测应用首页平均内存消耗情况。

步骤：

1. 打开solopi工具，配置内存监控
2. 进入被测应用，操作上述业务，观察运行时的内存指标。
3. 查看内存运行结果
   1. 检查程序实际使用的内存（pss）值

总结

2.CPU

cpu监控指标

solopi工具提供了两个cpu的监控指标：

• 全局占用cpu
• 应用程序cpu

全局占用cpu：整机的cpu使用水平，即当前手机的cpu整体使用率

• 在linux系统下，cpu利用率分为用户态、系统态和空间态。
• 用户态：表示cpu处于应用程序执行的时间
• 系统态：表示系统内核执行的时间
• 空间态：表示空间系统进程执行的时间。
• cpu使用率=cpu执行非新系统空闲进程时间/cpu总的执行时间
  （cpu使用率 = 应用进程cpu执行的时间 / cpu执行的总时间）

应用进程cpu：表示自开机以来，应用程序消耗的cpu时间的总数。

cpu消耗引起的现象

• cpu使用长时间处于90%以上
• 手机发热、耗电量增加
• 响应变慢、引起ANR（应用程序无响应）

案例：性能cpu测试

需求：测试滑动首页cpu使用率

步骤：

1. 打开solopi工具，勾选cpu监控指标
2. 进入被测应用，操作上述业务，观察运行时的cpu指标
3. 查看cpu运行结果
   1. 检查被测app运行时cpu是否长时间处于90%以上

总结

3.流量

流量介绍

操作app会与服务器交换数据，流量就是指这些交互数据的总大小。

• 上行消息
• 下行消息

上行消息是app发送给服务器的数据，下行消息是app接收的服务器的数据。

solopi提供了流量监控指标：网络

案例：性能流量测试

需求：打开被测app首页，上下动态滑动20秒，获取消耗的网络流量。

步骤：

1. 打开solopi工具，点击性能测试，勾选流量监控指标网络
2. 进入被测app，操作上述业务。
3. 查看流量统计结果

注意：在模拟器中无法统计电脑流量的使用情况，查看进程使用流量即可。

总结

4.电量

app应用使用时对电池电量的平均消耗。

常见的耗电量大的场景：

• 定位
• 网络传输
• 屏幕亮度
• wake-locker（锁屏-解锁）

电量的监控方法：

系统自带接口：

• 最新的ios和安卓系统内置的setting里可以查看各个app的电池消耗。
• 该方案不能检测固定某一时间段内的电池精准消耗。

硬件检测：

• 通过硬件可以精准的获取应用的电量消耗（如：powermonitor 硬件设备）
• 该方案测试时需要拆机，成本太高比较麻烦。

软件工具检测：

• 通过第三方的软件来获取应用的电量消耗（如：360省电王，solopi等）
  （solopi工具提供了电量的监控指标：电池）
• 该方案取决于第三方软件的计算准确性。

结果分析：

• 与基准数据对比（基准数据来自于产品经理，或者以往数据的积累）
• 横向对比（竞品）（目前多采用这种方法）

案例：性能电量测试

需求：打开被测应用，进入首页，上下动态滑动2分钟，获取消耗的电量。

步骤：

1. 打开solopi工具，点击性能指标，勾选电量监控指标，电池
2. 进入app，操作上述业务，观察运行时的cpu指标。
3. 保存电量详细数据后，可查看电量详细的数据统计

注意：

模拟器没有电池，无法获取电量数据。

总结：

5.流畅度

流畅度介绍

动画播放或者图片切换的流畅性。

流畅度的监控指标

solopi工具提供了流畅度的监控指标：帧率fps

• 即frames per second：GPU在一秒内绘制的帧数，（简单理解为一秒内呈现给用户的图片数）
• FPS值越高画面越流畅

流畅度问题产生的影响：

• 想要让大脑觉得动作是连续的，至少是每秒10-12帧的速度。
• 想达到流畅的效果，至少需要每秒24帧。
• 60帧每秒的流畅度是最佳的，我们的目标就是让程序的流畅度能接近60帧每秒。

注意事项：

• 当页面多为静态时，FPS值很小是正常的
• 页面数据多为动态加载时，FPS值比较大（建议在24帧以上）

案例：性能流畅度测试案例

需求：打开被测应用，进入首页，上下动态滑动2分钟，记录FPS值。

步骤：

1. 打开solopi工具，点击性能测试，勾选帧率
2. 进入被测app，操作上述业务，观察运行时的流畅度指标。
3. 查看流畅度运行结果。

总结

6.启动速度

启动速度介绍

app启动速度：从启动app到主页加载完成的速度。

app启动分类：冷启动，热启动

• 冷启动：启动app进程，这种启动方式叫冷启动（启动之前app是没有运行的）
• 热启动：将app从后台置于前台（app已经运行，但不是当前焦点）

solopi指标：启动耗时计算

adb安卓速度测试方法：

• 格式
  • adb shell am start -W 包名/Activityming<界面名>
• 示例
  • adb shell am start -W com.tpshop.malls/com.tpshop.malls.SplashActivity
• 常见参数
  • -s：表示每次启动前先强制停止
  • -R：表示重复测试次数

该命令获取3个关键指标：

1. thistime：当前时间activity的时间。（这次消耗的时间）
2. totatime：应用的启动时间，包括创建进程、app初始化、activity初始化到界面显示。（总计消耗的时间）
3. waittime：前一个应用activity pause的时间+totaitime的时间（等待消耗的时间）

注意事项

• 热启动HOT和冷启动COLD的启动速度测试命令完全相同
• 冷启动的时间 一般 大于 热启动的时间。

案例：性能启动时间测试

需求：分别获取被测app冷启动和热启动时间

Android-sdk环境搭建

Android-sdk环境说明

它是Android开发、调试工具包。

作用：Android应用稳定性测试、调试工具、日志记录等

下载：https://pan.baidu.com/s/1BBpXjxxdq-hMwu1CEABuvw?pwd=nx7a

安装：

• 解压到指定目录（如 D：\android\sdk）
• 将目录添加到path环境中

  

adb常用命令

• 验证：打开终端管理工具，输入：adk version

  

• 显示系统中连接的全部设备：adb devices
• 设备的连接和断开
  • 连接设备：adb connect ip地址:端口号
  • 断开设置：adb disconnect ip地址:端口号

    

• 应用启动和停止
  • 启动命令
    • adb shell am start 包名/Activity名
    • 示例：adb shell am start com.tpshop.malls.splashActivity

      

  • 停止命令
    • adb shell am force-stop apk包名
    • 示例：adb shell am force-stop com.tpshop.malls

      

• 开启或关闭adb服务
  • 开启：adb start-server
  • 关闭：adb kill-server

    

• 安装和卸载软件
  • 安装：adb install apk路径
    • 选项：[-r] 覆盖安装时保留数据和缓存文件。
    • 示例：adb install soubaoShopMobile-relese.apk
  • 卸载：adb uninstall apk包名
    • 选项：[-k] 卸载时保留数据和缓存文件
    • 示例：adb uninstall com.tpshop.malls

      

• 获取软件包名
  • 列出手机装的所有app包名：adb shell pm list packages
  • 列出系统应用的所有包名：adb shell pm list packages -s
  • 列出除了系统应用的第三方应用包名：adb shell pm list packges -3
  • 显示当前打开的应用包名：
    • windows：adb shell dumpsys window | findstr mCurrentFocus
    • mac/linus：adb shell dumpsys window | grep mCurrentFocus

注意事项：

包名（package）：决定程序的唯一性（不是应用的名字）

界面名（activity）：目前可以理解，一个界面名，对应着一个界面。

• 清除应用数据和缓存
  • adb shell pm clear （apk包名）
  • 示例：adb shell pm clesr com.tpshop.malls
• 启动和停止应用
  • 启动：adb shell am start 包名/界面面
  • 停止：adb shell am force-stop （apk包名）
• 获取手机日志
  • 使用查看日志命令：adb logcat
  • 获取app日志：adb logcat > 指定路径
    • 执行完成按ctrl+c结束日志获取
  • 日志等级
    • D：调试
    • I：通知
    • W：警告
    • E：错误（关注
    • F：致命（关注
• adb文件传输
  • 上传：adb push 电脑的文件路径文件名   手机的文件夹路径文件名
  • 下载：adb pull 手机的文件夹路径文件名    电脑的文件夹路径文件名
• adb shell 进入Linux系统
• 输入 exit 退出linux系统
• 获取内存
  • adb shell dumpsys meminfo 包

    

• 查看cpu占用情况
  • adb shell top -s 列号
  • 说明：-s 按指定行排序
  • 参数含义

  • 

• 获取app使用流量
  • 上行：transmit
  • 下行：receive

7.稳定性测试

什么是稳定性测试？

稳定性指app程序能否持久良好的运行。

在app应用中随意操作，挖掘有可能出现的异常

• 闪退
• 卡顿
• 崩溃
• 无响应等

monkey介绍

monkey就是钩子，monkey测试就像一只猴子在玩手机（乱抓、乱点）

作用：

模拟用户随机（触摸屏幕、滑动、按键）等操作来对程序进行稳定性测试，检测程序异常情况。

测试时机：

一般需要等产品稳定，bug比较少的时候，再用monkey去测试待测应用的稳定性。

注意事项

monkey程序是Android系统自带的一款稳定性测试工具，由Java语言编译。无需单独安装

Android位置：/system/framework/monkey.jar

稳定性测试步骤

1. 执行命令，执行结果写入日志

   

2. 检查日志异常

   

monkey命令

语法：

adb shell monkey -p (包名) -v (次数) > (结果文件)

参数：

• -p：指定包名
• -v：log详细程度（最高支持”-v -v -v“最详细）
• 次数：要执行随机操作的次数
• 重定向（保存）日志

提示：

获取当前运行的包名：adb shell dumpsys activity activities | findstr “ResumedActivity”

获取指定包名：adb shell pm list packages | findstr “wechat”

• findstr 是 Windows 的 grep 替代命令，用于搜索包含 wechat 的包名。

获取所有已安装应用的包名：adb shell pm list packages

检查日志

检查日志中是否有异常关键字，提取相关日志发给开发。

常见关键字：

• 无响应：在日治中搜索“ANR”、timeout
• 崩溃：在日志中搜索NullPointerException或者Exception
• 闪退：memory out、memory leak
• 错误：erro

提示：

1. 测试人员一般不需要分析错误日志原因，如果具备日志分析能里，可以辅助开发定位缺陷原因。
2. 日志错误类型原因有很多，需要经验积累，以上关键字提供了常见错误关键字

案例：稳定性测试

需求：针对被测应用进行稳定性测试

分析：

1. 使用adb命令获取app包名，执行前检查adb是否正常“adb devices”
2. 执行monkey命令：adb shell monkey -p 包名 -v 次数 > 日志文件存放路径
3. 检查日志异常关键字：
4. 将异常日志发给开发

扩展

总结