一天搞定软件测试基础！——包含Web测试、App测试

以下👇是2024新版黑马程序员软件测试零基础入门到精通全套视频教程的所有笔记！

有一些缺点，就是我是在7月份的时候进行该课程学习的，所以网课老师准备的一些网盘资源都已经失去连接了，所以我无法在我的电脑里进行测试，文章中涉及到App软件测试步骤的图片也是在老师网课上截取下来的，所以会看到图片和网课的一模一样。不过也不影响我们学习，整体思路跟着老师去做就能学会啦！而且整体下来，本套课程没有很多难点，所有视频看完之后就能明白测试的基本原理了。💪⛽️

文章目录

测试基础
- 软件测试分类
- 质量模型
- 单功能测试
- - 等价类划分
  - 提取测试数据（组合）
  - 总结
- 边界值分析
- 非功能测试设计
测试用例
- 判定表
- 用例执行
- 缺陷管理
- - 缺陷描述及提交
  - 缺陷跟踪流程
- 业务测试
Web项目实战
- 项目介绍
- 测试流程
- - 转成用例执行文档
  - Web项目非功能测试
App端测试
- App测试范围
- - App发布策略
- App功能测试
- App专项测试
- - 搭建App项目测试环境
  - 安装、卸载、升级测试
  - - 安装测试关注点
    - 卸载测试关注点
    - 升级测试关注点
  - 兼容性测试
  - push消息推送
  - - push消息测试关注点
  - 交叉测试
  - - 交叉测试关注点
    - App交叉测试点编写
  - 用户体验测试
- App性能测试
- - SoloPi使用步骤
  - App性能测试关注点
  - App内存测试
  - App的CPU测试
  - App流量测试
  - - 扩展：流量优化策略
  - App电量测试
  - App流畅度测试
  - App启动速度测试
  - App稳定性测试
  - - Android-sdk环境配置
    - App稳定性测试步骤

测试基础

软件测试分类

按生产阶段划分：

单元测试：针对程序源代码进行测试（开发自测）
集成测试：针对模块之间功能交互进行测试（由测试人也完成—）
系统测试：对整个系统进行全面测试（测试人员完成）
验收测试：以用户代表为主验证项目是否符合预期需求（由用户测试完成）

按代码可见度划分

根据程序的云巅爱可见度进行划分

黑盒测试：源代码不可见，UI功能可见；关注数据输入结果输出。（系统测试）
灰盒测试：部分源代码可见，UI功能不可见；关注输入、输出，以及输出访问通道。（集成测试）
白盒测试：全部源代码可见，UI功能不可见；关注代码本身语法逻辑。（单元测试）

其他测试

冒烟测试：对核心功能的验证

作用：保障提测内容具备可测性

回归测试1：对已经修复的bug、更新后对已测试内容再次测试

作用：保证bug修复、确保新功能能对旧功能没有影响。

注意⚠️：开发在修复bug的时候有可能会引发新的bug

回归测试2：对已修复功能\更新后对已测内容再次测试

作用：保证bug修复、确保新功能对旧功能没有影响

要求：对新功能有关联的旧功能一定要测试

质量模型

质量模型：衡量一个软件质量的维度

功能性：软件是否具备某方面的能力
性能测试：多用户同时使用能否满足要求
兼容性：再不同的设备、平台上能否正常使用
易用性：易学、易用、用户粘性好
安全性：主要考虑数据存储和输出传输的安全
可靠性：长时间运行稳定，不出现异常
可移植性：应用系统升级、数据迁移方便程度
可维护性：运行过程出现问题维护操作是否方便（出现异常的时候，容易被恢复）

单功能测试

单功能：软件程序或应用程序只提供一项核心功能或特性，而不包含其他附加功能。

比如我们一个电商系统项目中，有注册功能、登录功能、支付功能，他们都是只负责干这些任务，没有附加的其他功能，所以就是叫做单功能。

等价类划分

一种用少量数据获得较好测试效果的工具。

步骤：

划分有效等价类：满足需求的数据集合
划分无效等价类：不满足需求的数据集合
每类中选取代表数据

提示：提取测试数据，可以使用xming或excel工具

举一反三：

我们对上面的“账户登录”例子进行等价类划分：

- 账号
  - 有效
    - 已注册手机号
    - 已注册邮箱
  - 无效
    - 为空
    - 手机号未注册
    - 邮箱未注册
- 密码
  - 有效
    - 注册密码
  - 无效
    - 为空
    - 错误密码
- 图片验证码
  - 有效
    - 正确且未过期
  - 无效
    - 为空
    - 错误
    - 过期

提取测试数据（组合）

原则：

单个选项无效数据组合其他选项有效数据应用
多个选项有效数据建议组合应用

根据上述例子我们来进行分析：

有效测试点（专业术语叫做“正向”）
- 登录成功1（有效的手机号+有效密码+有效验证码）
- 登录成功2（有效的邮箱+有效密码+有效验证码）
无效测试点（专业术语叫做“逆向”）
- 登录失败1（账号为空+有效密码+有效验证码）
- 登录失败2（手机号未注册+有效密码+有效验证码）
- 登录失败3（邮箱未注册+有效密码+有效验证码）
- 登录失败4（注册手机号+空密码+有效验证码）
- 登录失败5（注册手机号+错误密码+有效验证码）
- 登录失败6（注册手机号+注册密码+空验证码）
- 登录失败7（注册手机号+注册密码+错误验证码）
- 登录失败8（注册手机号+注册密码+过期验证码）

总结

首先先进行测试类分析，分析出需求，然后对其需求进行等价类划分（分成有效和无效）。

第二步通过测试点提取，输出测试用例。

有效测试用例：

无效测试用例：

边界值分析

如上图，他会对密码栏目进行字符进行限制，如果我们用之前学习的等价类划分进行分析的话如下：

有效：8位包含大小写字母及数字
无效长度：5位大小写字母及数字、18位大小写字母及数字
无效规则：空、纯大写字母、纯小写字母、纯数字

假设我们密码的长度大于8位，小于16位。但是按照上述规则需求是要求大于等于8位，小于等于16位，但是我们设计的测出用例中，只是对8位进行了分析，没有对16位进行限制。所以上面测试用例是有遗漏的。这个时候就要引入我们的新的方法——边界值分析。

边界值分析：一个便捷范围限制选取测试数据工具。

选取

上点：刚好是边界上的点，必选（不考虑是否包含上点）
离点：距离上点最近的点，选择两个（不包含上点选择范围内的点，包含上点选择范围外的点）
内点：边界范围内的任一点，必选（建议选择中间范围

步骤：

边界值分析：负责测试长度范围
划分等价类：负责测试类型和规则
提取数据

回到一开始的问题，我们用上述方法进行分析：

密码
- 有效
  - 上点（第一步：考虑边界值）
    - 8位大写、小写及数字组成
    - 16位大写、小写及数字组成
  - 内点（第一步：考虑边界值）
    - 11位大写、小写及数字组成
  - 规则（第二步：考虑规则，使用等价类）
    - （已经被上面用例符合完了）
- 无效
  - 离点（第一步：考虑边界值）
    - 5位大写、小写及数字组成
    - 18位大写、小写及数字组成
  - 规则（第二步：考虑规则，使用等价类）
    - 长度符合、全部为大写字母
    - 长度符合、全部为小写字母
    - 长度符合、全部数字
    - 空

我们在仔细一点，把所有的测试分析写完。所以之后我们要对“账号”进行分析：

账号
- 有效
  - 未注册手机号
- 无效
  - 空
  - 已注册手机号
  - 非11位数字
  - 11位非数字
条款
- 有效
  - 勾选
- 无效
  - 未勾选

测试点提取：

回顾提取规则

多项有效数据组合应用
无效数据各项+其他项有效数据组合

我们先来数一下一共有多少条有效数据：

之后设计无效数据：

无效用例分析：

（无效账号+有效密码+勾选协议）
（有效账号+无效密码+勾选协议）
（有效账号+有效密码+未勾选协议）

非功能测试设计

还记得之前说的质量模型吗？前面所学的都是功能测试，就是对质量模型中的功能性进行测试。本节我们要学习的是非功能测试，其实也就是围绕着质量模型的除了功能性以外的部分进行测试，这个就叫做——非功能测试。

非功能必测项目：

兼容性
易用性
性能测试（有专项测试人员）
安全性（有专项测试人员）

测试用例

测试用例：描述测试点执行的文档（测试输入、执行条件、预期结果等）

测试用例的作用：

测试点能够被精确的执行
便于团队协作

测试用例核心内容（八大要素）：

用例编号：项目-模块-数字
用例标题：预期执行结果（测试点）
所属模块：模块名称
优先级：用例的重要程度（P0级~P3级）
前置条件：执行操作步骤的前置条件
测试步骤：测试点执行的关键步骤
测试数据：输入数据
预期结果：预期执行结果以及隐形结果

我们依旧是回到之前注册邮箱的案例，讲测试点转化为测试用例：

测试文档大同小异，我们就只拿一个例子进行描述就OK啦。

注册成功（8位合格密码+未注册手机号+勾选协议）改称为测试用例文档：

用例编号：
email_register_001

用例标题：
注册成功（未注册手机号+8位合格密码+勾选协议）

项目模块：
注册模块

优先级：
P1

前置条件：
已打开注册页面
准备一个未注册的手机号

测试步骤：
输入账号
输入密码
选择协议
点击注册

测试数据
账号：未注册手机号
密码：Test1234
协议：勾选

预期结果：
注册成功，自动跳转到登录页面

判定表

判定表：一种以表格的形式表达多条件逻辑判断的工具。

作用：多条件之间有约束规则的需求设计测试点、

组成：

条件桩：列出问题中的所有条件（次序无所谓）
动作桩：列出问题中可能采取的操作（可以有多个）
条件项：列出条件对应的取值，所有可能情况下真假值
动作项：推导出条件项（各种取值情况）下应该采取得到操作结果
提示：
1. 判定表中贯穿条件项和动作项的一列就是一条规则
2. 假设有n个2条件，每个条件的取值有两个（0，1），全组合有2^n种规则

例如：某促销活动优惠，在指定时间段内消费并且消费金额满1000元，享受9折优惠。

条件桩：指定时间段、满1000
动作桩：9折、无折扣
条件项：是、否
动作项：打9这，不打折

案例：

指定时间段内（符合开始时间和结束时间）
消费金额满1000元

如果上述条件同时满足，则可以享受9折优惠，否则不可以享受。

测试点：

打折（在指定时间段内+消费满1000）
不打折（不在指定时间段内+消费满1000）
不打折（在指定时间段内+消费不满1000）
不打折（不在指定时间段内+消费不满1000）

用例执行

通过这一小节的学习，大家就能掌握测试的完整流程。

执行用例：也就是对项目开始测试。

前置

项目提测内容开发已交付测试
测试项目环境已准备好

关注

实际执行结果与预期结果一致，一致通过，不一致为缺陷
项目执行隐形结果与用例预期隐形结果相似
实际结果与预期结果有争议处，参考用户角度衡量

案例：登录练习用例执行

执行完成之后对原先的测试用例表进行备注：

缺陷管理

缺陷：软件中存在的人和问题，都叫做缺陷。

缺陷衡量标准：

软件未实现需求（规格)说明书中明确要求的功能 -> 少功能
软件实现的功能超出需求（规格）说明书指明的范围 -> 多功能
软件出现了需求（规格）说明书中指明不应该出现的错误 -> 功能错误
软件未实现需求（规格）说明书中虽未明确指明但应该实现的要求 -> 隐性功能缺失/错误
软件难以理解，不易使用，运行缓慢，用户体验不好 -> 不易使用

缺陷描述及提交

目的：讲缺陷提交给开发，开发根据描述可复现缺陷

工具：禅道、jira等

我们以禅道来作为本次学习工具，下面是简单总结的一些重点控制项：

当前指派：将bug提交给谁
Bug类型：代码错误、设计缺陷
Bug标题：描述bug问题
测试点描述及预期结果（实际结果）
严重程度：bug严重程度
优先级：bug修复紧急程度
重现步骤：复现步骤
附件：执行实际结果截图或日志文件

缺陷跟踪流程

通过本小节的学习，就可以知道开发和测试对缺陷的完整流程。下图是缺陷跟踪流程：

测试：提交bug→验证bug→关闭bug/打开bug
开发：确认bug→修复bug

在一般情况下，测试人员主要关注：提交缺陷、关闭缺陷和回归测试，其他都是由开发人员进行操作。

业务测试

业务：是指软件为满足用户特定的业务需求而设计并实现的一系列功能。

作用：测试软件系统单功能之间关联性数据处理逻辑是否正确。（例如：添加购物车时对登录状态的判断）

方法：流程图法【流程图绘制网站】

例如：登录流程图示例

流程图设计测试点步骤：

确认业务流程图
流程图中从开始到结束每条路径都是一条用例

接下来我们看一下案例：

分析出测试点：
在这里插入图片描述

之后我们将测试点转成用例文档：

提示：

项目先测主业务在测单模块
提测时先对主业务流程正向用例进行测试（冒烟）

Web项目实战

项目介绍

Tpshop商城，类似于淘宝、京东类的（B2C）电子商务平台，主要为线上用户提供优质便捷的购物服务。

前台地址：https://hmshop-test.itheima.net/

后台地址：https://hmshop-test.itheima.net/admin

本次目标：

核心业务：下单业务
核心模块：注册模块、搜索、购物车、下单、支付

测试流程

当我们拿到一个项目的时候：

我们要先测试核心业务（核心业务：用户常用的业务和功能为核心业务功能）
再测试核心业务中单功能

个人实施测试流程：

熟悉需求
设计测试用例
执行测试用例
缺陷跟踪管理

项目测试的完整流程

需求分析与评审
制定测试计划与方案
设计测试用例
执行测试用例
缺陷跟踪管理
编写测试报告

回到我们的Tpshop商城，我们打算设计一个下单（购物车）业务测试用例来当做我们本次教学案例，实现步骤如下：

熟悉需求
确认下单流程：选择商品->加入购物车->登录成功->提交订单成功->支付成功
确认流程图
编写测试用例
1. 测试点编写：
2. 测试用例文档：

用例执行

缺陷管理

同样的使用禅道进行缺陷管理，将上面用例执行输出的错误进行提交。

项目单模块测试

对下单业务线中核心单功能测试：

登录功能
购物车功能
下单功能
支付功能

单功能测试步骤：

熟悉需求
- 需求获取的路径
  - 需求文档
  - 产品原型图
  - 已存在的软件界面
- 怎么熟悉需求
  - 阅读并理解问候描述
  - 操作或梳理业务规则流程
提取测试点覆盖需求
测试点执行测试用例
缺陷管理

废话不多说，我们直接上例子：
在这里插入图片描述

要实现这个登录功能满足右边要求的需求。

测试点分析：

这三个是非登录界面的功能

转成用例执行文档

我们抽取一下红框范围内的测试点转成测试用例执行文档：

当~！测试文档一下就写好啦！大家可以参考要一下。

下一步也是一样的进行执行用例。

Web项目非功能测试

质量模型：功能性
兼容性、易用性、性能、安全、迁移性、维护性、可靠性

重点测试：功能性、兼容性、易用性、性能、安全

独立测试：安全、性能

所以我们这边只能测试兼容性和易用性

之后转换成测试用例

App端测试

App与Web的区别：

系统架构：APP是C/S结构，Web是B/S结构

C/S（Client/Server）：即客户端/服务器，需要下载安装客户端。（消耗的一些资源都是客户端的）
B/S（Browser/Server）：即浏览器/服务器，基于浏览器访问。（都是浏览器自带的，不需要下载）

App测试范围

功能测试（与web相同）

业务测试
功能模块测试

性能测试

CPU、内存占用
启动速度
流量、电量消耗
流畅度
稳定性

专项测试

安装卸载升级
push消息推送
交叉事件测试
用户体验测试
兼容性测试

App发布策略

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

分类：

内部发布渠道：在实际测试工作中，为了方便测试程序包的安装和管理，可以使用一些应用内测分发平台。（蒲公英、Testlink等）
- 步骤：
  1. 开发将应用测试包上传到这些平台上
  2. 平台可以生成对应的二维码
  3. 测试直接扫码进行应用安装
线上发布渠道：产品测试完成后，将APP发布到应用各种平台上。（安卓应用：豌豆荚、应用宝、360手机助手、各类手机品牌商城等；IOS应用：主要有 App store、iTools
- 步骤：
  1. 开发者账号注册，申请在发布平台（各种应用商店）上架
  2. 针对不同的发布平台，在软件包中加入对应的平台ID（渠道ID），上传到发布平台
  3. 平台审核通过后，用户即可在应用商店中下载

一般线上发布过程，由开发人员负责。在软件包加入平台ID后，上传到发布平台时，需要测试人员验证核心的业务功能

在整个软件项目生产过程中，一共有三大环境，分别是：开发阶段的开发环境，测试阶段的测试环境，上线发布阶段的生产环境。

生产环境：项目发布时采用的一种策略，先发布少数（1-3）服务器，待运行稳定后再发布到所有服务器。

灰度发布：部分用户可用，若有异常则回滚。

所以App发布策略：开发环境->测试环境->（策略：灰度发布）->生产环境

线上发布：所有用户可用

App功能测试

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

对象：核心业务、单功能
流程：
1. 需求分析
2. 测试计划
3. 测试用例设计
4. 用例执行
5. 缺陷管理
6. 测试报告
方法：
1. 等价类划分：穷举数据选取
2. 边界值分析：长度范围覆盖
3. 判定表：多条件之间约束限制
4. 流程图：业务流程

App专项测试

专项测试是为了在不同的移动设备上能持久的、稳定的运行App程序。

目的：

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

专项测试内容：

安装卸载升级
兼容性
push消息推送
交叉事件
用户体验

搭建App项目测试环境

所谓的环境就是App应用运行所以来的软硬件。

在电脑上我们可以使用网易mumu模拟器模仿手机，然后讲相关的apk文件拖入模拟器当中。

安装、卸载、升级测试

安装测试关注点

正常场景：

在不同的操作系统版本上安装
从不同的安装渠道安装（APP商城、手机助手、直接下载apk或者ipa文件安装）
不同的安装路径（安装到手机上、安装到SD卡上）
卸载后安装
正在运行时覆盖安装

异常场景：

安装时出现异常（关机、断网），恢复后能否继续安装
安装时存储空间不足
安装时手动取消后再次安装
低版本覆盖安装高版本

测试点编写：

安装测试：
- 不同操作系统安装
  - 安装成功（安卓）
  - 安装成功（苹果）
  - 安装成功（鸿蒙）
- 不同渠道安装
  - 安装成功（App商城）
  - 安装成功（手机助手）
  - 安装成功（安装包安装）
- 不同安装路径
  - 安装成功（SD卡安装）
- 卸载后安装
  - 安装成功（卸载后安装）
- 运行时覆盖安装
  - 安装成功（运行时覆盖安装）
- 安装出现异常
  - 安装成功（关机）
  - 安装成功（断网）
- 安装时存储空间不足
  - 安装成功（空间不足）
- 安装成功（取消后再次安装）
- 安装成功（跨版本覆盖）

卸载测试关注点

正常卸载（APP手动卸载、工具卸载）
运行时卸载
取消卸载
卸载异常中断后卸载
卸载后无数据残留

测试点编写：

卸载成功
- 卸载方式
  - 卸载成功（手动卸载）
  - 卸载成功（工具卸载）
- 卸载成功（运行时卸载）
- 卸载成功（取消卸载后再卸载）
- 卸载成功（异常中断卸载成功）
- 卸载后无数据残留
  - 卸载成功（无数据残留）
  - 卸载成功（保留设备配置数据）

升级测试关注点

从临近版本升级
跨版本升级
不同渠道升级（应用商场、手机助手）
升级提醒成功（可不提醒、可以提示升级、强制升级）
应用内升级时非WIFI提醒

测试点编写：

升级测试
- 升级成功（临近版本）
- 升级成功（跨版本）
- 升级成功（应用市场）
- 升级成功（手机助手）
- 升级成功（在线更新）

兼容性测试

兼容性：程序能在不同的设备上运行正常。

兼容性测试内容：

品牌型号（品牌、系统版本、分辨率）
网络
软件兼容
硬件兼容

测试方式：

使用公司现有的真机进行兼容性测试
使用第三方的兼容性平台进行测试。线上云测平台testin

push消息推送

消息推送方式：

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

区别：

Pull方式消耗客户端和服务器资源；

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

push消息是app推送的各种通知。push消息推送流程：

APP服务器设置：

推送内容
推送时机
推送频率
推送人群（全部用户/部分用户）

手机端设置：

是否接收通知
提醒位置等

push消息测试关注点

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

测试点编写：

交叉测试

交叉测试又叫（冲突、干扰）测试，是指一个功能正在执行过程中，另外一个事件或操作对该过程进行干扰的测试。例如：在App前台/后台运行同时接听来电或者下载文件等。

交叉测试关注点

APP运行时接打电话
APP运行时收发信息；
APP运行时查看应用推送
APP运行接上蓝牙设备
APP运行时接收文件弹窗提醒
APP运行时旋转屏幕
APP运行时切换网络（4G、Wi-Fi）；
App运行时使用相机、计算器等手机自带应用；
App运行时电量告警、插拔充电器。

App交叉测试点编写

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

用户体验测试

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

测试点编写

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

App性能测试

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

分类：

App程序运行时占用手机硬件资源情况
稳定性

App性能测试方法：

工具：SoloPi是一个无线的Android自动化工具，具备录制回放、性能测试等功能。安装连接：https://www.pgyer.com/solopi

功能：

**性能测试：**能够对CPU、内存与网络环境进行限制，复现应用在性能较差、网络环境不佳场景下的表现。
**录制回放：**能够将用户的操作记录下来，支持在各个设备上进行回放。
**一机多控：**操作一台主机设备来控制多台从机设备，进行重复冗杂的兼容性测试，能够极大提升兼容性测试的效率。

SoloPi使用步骤

(1) 打开SoloPi，选择性能测试。

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

（3）点击开始监控，随后打开被测APP应用，开始测试。

(4) 查看数据采集结果

（5）结果展示

App性能测试关注点

APP使用时对CPU、内存的占用情况；
APP使用时是否流畅等；
APP使用时电量流量的消耗情况；
APP的启动时间是否过长；
APP是否能长时间稳定运行

App内存测试

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

提示：SoloPi工具提供了两个内存的监控指标：Privatedirty和PSS。

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

常见的现象：

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

步骤：

打开SoloPi工具，配置内存监控
进入APP，操作上述业务，观察运行时的内存指标
查看内存运行结果
- 检查程序实际使用的内存PSS值

App的CPU测试

SoloPi工具提供了两个CPU的监控指标：全局占用CPU和应用进程CPU。

下面来解释一下关于CPU的内容只是：

全局占用CPU：整机的CPU使用水平，即当前手机的CPU整体使用率。在Linux系统下，CPU利用率分为用户态、系统态和空闲态：

用户态：表示CPU处于应用程序执行的时间
系统态：表示系统内核执行的时间
空闲态：表示空闲系统进程执行的时间。

CPU使用率=CPU执行非系统空闲进程时间/CPU总的执行时间

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

CPU消耗引起的现象：

CPU使用长时间处于90%
手机发热、耗电量增加
响应变慢、引起ANR（Application Not Responding）（应用程序无响应）

性能测试步骤

步骤：

打开SoloPi工具，勾选CPU监控指标
进入tpshop，操作上述业务，观察运行时的cPU指标
查看CPU运行结果
- 检查APP运行时CPU是否长时间处于90%以上

App流量测试

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

所以：上行消息是APP发送给服务器的数据，
下行消息是APP接收的服务器的数据。

SoloPi工具提供了流量监控指标：网络。

性能流量测试步骤

打开SoloPi工具，勾选流量监控指标网络
进入APP，操作上述业务
查看流量统计结果

提示：在模拟器中无法统计电脑流量使用情况，看进程使用流量即可

扩展：流量优化策略

流量优化策略：

数据的压缩
不同数据格式的采用
控制访问的频次
只获取必要的数据
缓存机制
针对不同的网络类型设置不同的访问策略

App电量测试

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

常见的耗电量大的场景：

定位
网络传输
屏幕亮度
wake_locker（锁屏-解锁）

电量的监控方法：

系统自带接口
- 最新的IOS和Android系统内置的Setting里可以查看各个APP的电池消耗
- 该方案不能检测固定某一时间段内的电池精准消耗。
硬件检测
- 通过硬件可以精准地获得应用的电量消耗（如：PowerMonitor硬件设备）
- 该方案测试时需要拆机，成本太高比较麻烦。
软件工具检测
- 通过第三方的软件来获取应用的电量消耗（如：AccuBattery、360省电王、SoloPi等）
- 该方案取决于第三方软件的计算准确性。

步骤：

打开SoloPi工具，勾选电量监控指标：电池
进入APP，操作上述业务，观察运行时的CPU指标
保存电量详细数据后，可以查看电量详细的数据统计。

App流畅度测试

流畅度介绍：动画播放或图片切换的流畅性

流畅度的监控指标：SoloPi工具提供了流畅度的监控指标：帧率FPS。即Framesper second：GPU在一秒内绘制的帧数。（简单理解为一秒内呈现给用户的图片数）

流畅度问题产生的影响：

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

步骤：

打开SoloPi工具，勾选帧率
进入APP，操作上述业务，观察运行时的流畅度指标
查看流畅度运行结果

App启动速度测试

启动速度介绍：

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

APP启动分类：冷启动、热启动

冷启动：启动app进程，这种启动方式叫做冷启动。
热启动：将app从后台置于前台。

在Solopi中使用启动耗时计算指标就可以实现对App启动速度的监控。

App稳定性测试

稳足性：app程序能持久良好的运行。

稳定性测试：在app应用中随意操作，挖掘有可能出现的异常

安卓稳定性测试工具：Monkey

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

Android-sdk环境配置

android开发、调试工具包
作用：android应用稳定性测试、调试工具、日志记录等

安装：

1、解压到指定目录；如（D:\Android\sdk
2、将目录添加到path中

①新建环境变量：ANDROID_HOME=D:\Android\sdk
（这里为安装目录）
②添加path路径，在Path中添加：%ANDROID_HOME%\tools、%ANDROID_HOME%\platform-tools

验证：win:打开开始菜单->运行->输入cmd->adbversion

提示：

Monkey程序是Android系统中自带一款稳定性测试工具，由Java语言编写。
【无需单独安装】
Android位置：/system/framework/monkey.jar

稳定性测试步骤

执行命令，执行结果写入日志
检查日志异常

Monkey命令：

语法：adb shell monkey-p 包名-v 次数>tpshop.log

参数：

-p:指定包名
-v:log详细程度（最高支持’-V-V-v’最详细）
次数：要执行随机操作的次数

>:重定向（保存）日志

检查日志：

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

无响应：在日志中搜索 “ANR”、timeout
崩溃：在日志中搜索 "NullPointerException"或Exception
闪退：memory out、memory Leak
错误：error

日志事件信息参数表：