软件测试（AI、Web、App）

1、AI快速入门

1.1AI介绍

AI即

人工智能

（Artificial Intelligence），旨在使机器能够

模拟

和

执行

人类

智能

活动。

作用

•

提

高速度和

效

率

•

缺陷预测与分析

传智星云AI助手

1.2AI应用

通过输入【指令】和模型进行互动。

指令(Prompt)：其实就是文字

•

它可以是问题（如：帮我解释一下什么是芯片）

•

也可以是任务（如：帮我写一首诗）

扩展：指令（ Prompt ）组成

角色

：给 AI 定义一个最匹配任务的角色，比如：「你是一位软件测试工程师」

指示

：对任务进行描述 比如：「需要对以下需求进行设计测试用例」

上下文：给出与任务相关的其它背景信息

例子：必要时给出举例，[实践证明其对输出正确性有帮助]

输入：任务的输入信息；在提示词中明确的标识出输入

输出

：输出的格式描述，以便后继模块自动解析模型的输出结果，比如（excel表格）

1.3 案例 登录需求

1、账号密码登录

•

系统验证账号和密码的正确性。

•

验证通过，用户登录成功，进入个人中心；验证失败，提示错误信息并允许用户重新输入。

2、短信验证码登录

•

用户输入手机号，点击获取验证码，系统向用户手机发送验证码。

•

用户输入验证码，点击登录，系统验证验证码的正确性。

•

验证通过，用户登录成功，进入个人中心；验证失败，提示错误信息并允许用户重新输入。

3、第三方授权登录

•

用户点击第三方登录按钮（如微信、QQ、支付宝），系统跳转至第三方授权页面，用户进行授权操作。

•

第三方返回授权信息至系统，系统验证授权信息的有效性，创建或绑定用户账号。

•

验证通过，用户登录成功，进入个人中心。

1. 账号密码登录

测试用例 ：

2. 短信验证码登录

测试用例 ：

3. 第三方授权登录

测试用例 ：

角色:你是一名测试工程师

指示:需要针对以下需求，设计测试用例

需求:

1、账号密码登录

系统验证账号和密码的正确性。

验证通过，用户登录成功，进入个人中心;验证失败，提示错误信息并允许用户重新输入。

2、短信验证码登录

用户输入手机号，点击获取验证码，系统向用户手机发送验证码。

用户输入验证码，点击登录，系统验证验证码的正确性。

验证通过，用户登录成功，进入个人中心;验证失败，提示错误信息并允许用户重新输入。

3、第三方授权登录

用户点击第三方登录按钮(如微信、QQ、支付宝)，系统跳转至第三方授权页面，用户进行授权操作。

第三方返回授权信息至系统，系统验证授权信息的有效性，创建或绑定用户账号。

验证通过，用户登录成功，进入个人中心。

输入:功能测试、兼容性测试、SQL注入

输出:使用EXCEL表格形式输出，并且格式参考用例设计八大要素

以下是根据给定的需求设计的测试用例，以Excel表格形式呈现，并遵循了测试用例设计的八大要素（用例编号、用例标题、测试模块/功能、前置条件、输入数据、执行步骤、预期结果、实际结果）。

请注意，在“实际结果”列中，你需要在执行测试后填写实际观察到的结果。这里我暂时留空，因为在真实的测试环境中，这些结果会根据实际情况而有所不同。

1.4测试分类

1. 按照软件产生的阶段划分

按照软件生成过程划分：单元测试、集成测试、系统测试、验收测试

1. 张三开发实现完成注册功能，针对自己开发的该功能

代码进行测试

属于（）？

A：单元测试

B：集成测试 C：系统测试 D：验收测试

2. 从注册、登录、下单

联动一起

的测试属于（）？

A：单元测试

B：集成测试

C：系统测试 D：验收测试

3. 项目相关开发人员完成了全部系统的核心业务实现，最后提交给测试

全面测试

，属于（）？

A：单元测试 B：集成测试 C：系统测试

D：验收测试

4. 整个电商系统测试通过后，最后交付给

用户正式使用

，一般需要完成（）？

A：单元测试 B：集成测试 C：系统测试

D：验收测试

2. 按照代码可见度划分

根据程序的源代码可见程度划分

案例

对某系统按代码可见度测试

登录

界面

输入账号、密码、验证码，点击登录测试属于（）

A：黑盒测试

B：灰盒测试 C：白盒测试

无界面，通过工具/代码实现登录功能测试属于（）

A：黑盒测试 B：灰盒测试

C：白盒测试

无界面，直接对开发实现的登录功能的

源代码进行测试

属于（）

A：黑盒测试 B：灰盒测试

C：白盒测试

3. 其他测试

冒烟测试：对

核心功能

的验证

作用：保障

提测

内容具备可测性

回归测试：对

已修复bug

\

更新后

对

已测内容再次测试

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

回归测试：对已

修复功能

\

更新后

对已测内容再次测试

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

4.总结

1. 按照阶段划分

①单元测试：针对程序源代码的测试【开发】

②集成测试：针对功能模块组装的测试

③系统测试：针对整个系统（功能、非功能）进行测试

④验收测试：以用户身份验证系统是否满足需求【用户】

2. 按代码可见度划分

①黑盒测试：针对有UI界面软件系统输入输出类测试

②灰盒测试：针对无UI界面软件系统输入输出和内部逻辑结

构的测试（能看到部分源代码）

③白盒测试：针对程序源代码及内部逻辑本身进行测试

3. 其他

冒烟测试：保障提测内容具备可测性

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

2.质量模型

衡量一个软件质量的

维度

2.1功能性

软件是否具备某方面的能力

2.2性能

多用户同时使用能否满足要求（时间、资源）

2.3兼容性

2.4易用性

易学、易用、用户粘性好

2.5安全性

敏感数据存储/传输安全

2.6可靠性

长时间运行稳定，不出现异常

2.7 可移植性

应用系统升级/数据迁移方便

2.8 可维护性

运行过程出现问题维护操作是否方便

2.9案例

如何验证某系统质量呢？以微信为例

1. 功能性：

与需求数量一致，功能正确

2. 性能：

响应快、占用资源少

3. 兼容性：

不同设备平台正常使用

4. 易用性：

用户体验好

5. 安全性：

敏感信息无泄密存储有保障

6. 可靠性：持久运行无异常

7. 可移植性：升级迁移数据不丢失

8. 可维护性：出现异常恢复简单、可扩展功能、升级更新便捷

3.客户端测试

3.1 案例 登录

3.2等价类划分

一种用

少量数据

获得

较好测试效果

的工具。

场景：

表单类页面元素测试使用（输入框、下拉框、单选框、复选框）等

3.3总结

1. 等价类划分法是什么？

一种用

少量数据

获得

较好测试效果

的工具。

2. 适用场景

表单类页面元素测试使用（输入框、单选按钮、下拉列表）

3. 步骤

① 划分有效等价类：满足需求的数据集合

② 划分无效等价类：不满足需求的数据集合

③ 每类中选取代表数据

3.4练习

登录功能测试设计

3.5边界值分析法

一个边界范围

限制选取测试数据工具。

选取

1. 上点：刚好是边界上的点，必选（不考虑是否包含上点）100 300

2. 离点：距离上点最近的点，选择

2

个（

不包含

上点选择

范围内

的点，

包含

上点选择

范围外

的点）99 301

3. 内点：边界范围内的任意点，必选（建议选择中间范围） 200

步骤

1. 边界值分析（负责测试

长度范围

）

2. 划分等价类（负责测试

类型

和

规则

）

3. 提取数据

3.6练习 注册测试设计

3.7非功能测试

非功能：除了软件功能测试，其他都是非功能测试。

1. 兼容

2. 易用

3. 性能（专项）

4. 安全（专项）

Web浏览器

兼容：Chrome浏览器、Edge浏览器、Firefox浏览器、Safari苹果浏览器

易用：参考竞品，主观感受为主。

总结：

1. 非功能测试范围

•

兼容性、易用性、安全性、性能

•

可移植性、可维护性、可靠性

2. 非功能重点测试项

•

兼容性：web项目测试浏览器兼容

谷歌、火狐、苹果、Edge

•

易用性：主观感受为主，简洁易用。

•

安全和性能测试属于专项测试

4.测试用例

4.1测试用例介绍

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

作用

1. 测试点能被精准的执行

2. 便于团队协作

测试用例核心内容

用例编号、用例标题、所属模块、优先级、前置条件、测试步骤、测试数据、预期结果

4.2测试用例编写

4.3案例

1.网易注册页面功能测试点转化为测试用例

总结：

1. 啥是测试用例

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

2. 为什么转测试用例

•

测试点能被精准的执行

•

便于团队协作

3. 测试用例八大要素

用例编号、用例标题、所属模块、优先级、

前置条件、测试步骤、测试数据、预期结果

登录测试点转用例

将5条登录测试点转为用例文档

4.4判定表

02-判定表介绍

案例： 某促销活动规则正确性验证

需求：

1. 指定时间段内（符合开始时间和结束时间）

2. 消费金额满1000元

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

总结：

1. 判定表作用

多条件并且条件之间有约束规则的需求设计测试点。

2. 判定表组成

条件桩、条件项、动作桩、动作项

3. 提示：

•

判定表中贯穿条件项和动作项的一列就是一条规则

•

假设有n个条件，每个条件的取值有两个(0,1)，全组合有2的n次方种规则

4.5 练习 提现规则验证

需求：

商家账户余额每日累计提现金额为50000元，每日累计提现次数为5次

如果超过累计提现金额或累计提现次数，当日都无法提现

5.用例执行

5.1.用例执行

登录练习用例执行

总结：

1. 执行用例是啥？

开始对项目进行测试

2. 执行之前准备

•

项目提测内容开发已交付测试

•

测试项目环境已准备好

3. 执行用例关注

•

实际执行结果与预期执行结果一致，不一致为缺陷（bug）。

•

项目执行隐性结果与用例预期隐性结果相似

•

实际结果与预期结果有争议，参考用户角度业角度去衡量。

5.2.练习

163邮箱注册

执行邮箱注册用例

地址：https://mail.163.com/register/index.htm?from=163mail&utm_source=163mail#/pn

5.3.缺陷

缺陷介绍

案例

判断下面问题是否是缺陷

1. 金融结算系统，在汇总季度费用时，计算结果比实际多了3毛  是

2. 物流管理系统中，额外的实现了供应商管理功能                      是

3. 穿越火线子弹穿越墙体命中对方，对方未掉血                          是

4. 会员管理系统，管理员删除会员时没有二次确认直接删除        是

5. 双11淘宝搞活动，秒杀某商品时提示系统繁忙请稍后再试        是

缺陷描述及提交

目的：

将缺陷提交给开发，开发根据描述可复现缺陷

工具：

禅道、jira、……

案例

执行失败的用例提交bug

使用禅道工具提交以下缺陷

总结：

1. 软件缺陷

软件中存在的任何

异常问题

（bug）

2. 缺陷判断标准

多功能、少功能、功能错误、隐性功能缺失、体验不好

3. 缺陷主要内容

•

当前指派：将bug提交给谁

•

Bug类型：代码错误、设计缺陷、……

•

Bug标题：描述bug问题

测试点描述及预期结果（实际结果）

•

严重程度：bug严重程度

•

优先级：bug修复紧急程度

•

重现步骤：复现步骤

•

附件：执行实际结果截图或日志文件

缺陷跟踪流程

5.4业务测试

业务：

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

下单业务（登录->搜索->添加购物车->下单->支付）

作用：

测试软件系统单功能之间关联性数据处理逻辑是否正确

例：添加购物车时对登录状态的判断

方法：流程图法

流程图：使用一些特定图形和带箭头的线表达程序业务走向。

步骤：

1、确认业务流程图

2、流程图中从开始到结束每条路径都是一条用例

案例

发布文章业务测试设计

总结:

1. 业务测试方法

流程图法

2. 流程图设计测试点步骤

①确认流程图

②流程图从开始到结束每条路径都为一条测试用例

3. 提示

l

项目先测主业务在测单模块

l

提测时先对主业务流程正向用例进行测试（冒烟）

5.5 练习

某小程序购物流程测试设计

6.项目实战

6.1项目介绍

项目是什么

Tpshop商城

，类似于淘宝、京东类的（B2C）

电子商务

平台，主要为线上用户提供优质便捷的

购物服务

。

前台地址：

后台地址：

项目有什么？

本次目标：

1. 核心业务：

下单业务

2. 核心模块：

注册登录、搜索、购物车、下单、支付

6.2 项目测试流程

个人实施测试流程

本次目标：

1.核心业务：

下单业务测试

2.核心模块：

注册登录、搜索、购物车、下单、支付

总结：

1. 项目是什么？

电商b2c平台（web客户端、web管理端）

2. 项目测什么？

核心业务及模块

待测业务：下单业务测试

待测模块：注册登录、搜索、购物车、下单、支付

3. 项目测试流程

需求分析与评审、制定测试计划与方案

设计测试用例、执行测试用例、跟踪管理缺陷

编写测试报告

6.3 下单业务

案例

设计下单（购物车）业务测试用例

购物车下单流程：

选择商品->加入购物车->登录成功->提交订单成功->支付成功

步骤：

1、熟悉需求

2、确认下单流程

购车下单流程：选择商品->加入购物车->登录成功->提交订单成功->支付成功

3、确认流程图

工具：

4、编写测试用例

6.3.1 流程图绘制

总结：

1. 业务流程测试步骤

1、熟悉需求

2、确认下单流程

3、确认流程图

•

需求文档获取

•

自己绘制

4、编写测试用例

2. 下单业务流程（购物车）

选择商品->加入购物车->登录成功->提交订单成功->支付成功

6.3.2 用例设计

6.3.3 用例执行

业务测试用例执行

执行准备

①开发提测冒烟测试通过

②测试用例设计完成

执行方式

顺序执行

执行结果

① 通过：pass

② 失败：fail ->

提bug

总结：

1. 执行前提

开发提测后，冒烟测试通过

测试用例编写完成

2. 执行过程

①执行通过标记pass

②执行失败标记fail

3. 注意事项

用例执行失败需要立即提交bug

6.3.4 缺陷跟踪管理

案例

通过禅道模拟演示缺陷跟踪流程

1. 通过测试账号登录提交bug，验证bug

2. 通过开发账号登录修复bug

链接地址：

总结：

1. 缺陷跟踪

测试：提交bug、验证bug、关闭/打开bug

开发：确认bug、修复bug

2. 回归测试

①验证当前问题是否修复

②验证是否引发新问题

3. 回归测试注意事项

确认修复的软件版本，更新环境版本后再验证

6.3.5 单模块测试

功能模块

下单业务线中核心单功能

登录

购物车功能

下单功能

支付功能

单功能测试步骤：

①

熟悉需求

②

提取测试点覆盖需求

③

测试点转执行测试用例

④

缺陷管理

、

熟悉需求

需求从哪来？

需求文档

产品原型图

已存在的软件界面（不一定有）

怎么熟悉需求？

阅读并理解文档描述

操作或梳理业务规则及流程

案例

登录

测试点

案例

将以下3个测试点转为用例执行文档

6.3.6 购物车

6.3.7 支付

6.3.8 项目非功能测试

质量模型：

功能性、兼容性、易用性、性能、安全、迁移性、维护性、可靠性

重点测试

：功能性、兼容性、易用性、性能、安全

独立测试

：安全、性能

测试目标

：

兼容性：谷歌、火狐、Edge、苹果

易用性：主要参考依据

产品原型设计

或优秀

竞品设计

7.App测试

7.1APP测试介绍

APP与Web的区别

系统架构：APP是

C/S

结构，web是B/S结构

C/S（ Client/Server ） ：即客户端/服务器，需要下载安装客户端。

B/S（ Browser/Server ）：即浏览器/服务器，基于浏览器访问

。

App测试范围

总结：

1. APP项目测试范围

功能测试：业务、单功能模块

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

性能测试：内存、CPU、电量、流量、启动时间、流畅度、 稳定性

2. web与APP的区别：

APP是C/S结构，web浏览器是B/S结构

APP发布

将开发完成的移动应用程序通过特定的

渠道

和流程，向公众发布，使得用户可以下载、安装并使用

应用程序。

分类：

内部发布渠道

线上发布渠道

内部发布

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

如：蒲公英、Testlink等

步骤：

1. 开发将应用测试包上传到这些平台上

2. 平台可以生成对应的二维码

3. 测试直接扫码进行应用安装

线上发布

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

安卓应用：豌豆荚、应用宝、360手机助手、各类手机品牌商城等；

IOS应用： 主要有 App store、iTools

步骤：

1. 开发者账号注册，申请在发布平台（各种应用商店）上架

2. 针对不同的发布平台，在软件包中加入对应的平台ID（渠道ID），上传到发布平台

3. 平台审核通过后，用户即可在应用商店中下载

注意事项

一般线上发布过程，由开发人员负责。

在软件包加入平台ID后，上传到发布平台时，需要测试人员验证核心的业务功能

发布策略

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

总结：

1. APP发布方式

内部发布：

蒲公英、Testlink等

线上发布：

安卓应用：豌豆荚、应用宝、360手机助手、应用市场等；

IOS应用： 主要有 App store、iTools;

2. 上线发布策略

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

灰度发布：

部分用户可用，若有异常则回滚

线上发布：

所有用户可用

7.2 功能测试

功能测试

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

对象：

核心业务、单功能

流程

1. 需求分析

2. 测试计划

3. 测试用例设计

4. 测试用例执行

5. 缺陷管理

6. 测试报告

方法

等价类：穷举数据选取

边界值：长度范围覆盖

判定表：多条件之间约束限制

流程图：业务流程

7.3 登录案例

7.4 练习

练习

搜索

7.5App专项测试

什么是专项测试？

说明：在不同的移动设备上能

持久

、

稳定

的运行App程序。

专项测试目的

保障主流移动设备能正常使用App应用

不同的网络环境APP应用正常使用

不同APP版本正常使用

专项测试内容

总结：

专项测试：

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

7.6 App测试环境

学习目标

能搭建app项目测试环境

环境

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

依赖

mumu模拟器（移动设备）

App安装包

下载地址

mumu模拟器（移动设备）

说明：由网易编写一款安卓模拟器(window/mac)

安装：双击下一步安装完成即可。

App安装包

通过apk安装包进行安装或通过应用平台进行安装。

总结：

1. 环境：模拟器 + apk

2. apk安装：将apk拖入模拟器

学习目标

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

7.7安装测试

正常场景：

1.在不同的操作系统版本上安装

2.从不同的安装渠道安装（APP商城、手机助手、直接下载apk或者ipa文件安装）

3.不同的安装路径（安装到手机上、安装到SD卡上）

4.卸载后安装

5.正在运行时覆盖安装

异常场景：

1.安装时出现异常（关机、断网），恢复后能否继续安装

2.安装时存储空间不足

3.安装时手动取消后再次安装

4.低版本覆盖安装高版本

卸载、升级测试

注意事项：

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

据混乱）

总结：

1. 安装：

系统版本+渠道+路径+异常后安装

2. 卸载：

正常卸载+运行时卸载+取消后卸载

3. 升级：

临近版本+跨版本+不同渠道

7.8 兼容性测试

学习目标

能对tpshop（兼容性）设计测试点

兼容性测试

应用兼容性测试关注点

兼容性测试

测试方式：

① 方式1：使用公司已有的真机进行兼容性测试。

② 方式2：使用第三方的兼容性平台进行测试。

如：线上云测平台testin（https://www.testin.cn/）

总结：

兼容性：品牌型号+分辨率+网络+软件+硬件

7.9 Push消息

学习目标

能对tpshop（push消息推送）设计测试点

Push消息介绍

Push消息是APP推送的各种通知。

如：点赞、评论、关注

Push消息推送方式

Pull（拉）客户端主动获取：

客户端固定时间主动向服务器获取消息。

Push（推）客户端被动接受：

当服务器有更新消息时，主动发送到客户端。

Pull方式

消耗

客户端和服务器

资源

Push方式

节省

客户端和服务器

资源

提示：

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

消息

Push消息推送流程

Push消息测试关注点

总结：

1. Push消息：app接收的各种通知

2. 推送服务器：操作系统级别+自己搭建+三方推送

3. 关注点：内容+业务规则+人群+显示/关闭通知+位置

7.10 交叉测试

交叉测试

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

的测试。

如：

在App前台/后台运行同时接听来电或者下载文件等

交叉事件测试关注点：

APP运行时接打电话；

APP运行时收发信息；

APP运行时查看应用推送

APP运行接上蓝牙设备

APP运行时接收文件弹窗提醒

APP运行时旋转屏幕

APP运行时切换网络（4G、Wi-Fi）；

App运行时使用相机、计算器等手机自带应用；

App运行时电量告警、插拔充电器。

7.11 用户体验测试

用户体验测试

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

总结：

1. 交叉测试：app应用使用过程中被其他操作干扰影响

2. 用户体验：UI界面+易用(导航、菜单、提示)+横竖屏

8.App性能测试

8.1APP性能测试

APP性能测试

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

分类

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

② App稳定性

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

说明：使用

工具

或命令进行测试

工具

SoloPi是一个无线的 Android 自动化工具，具备录制回放、性能测试等功能。

功能

性能测试：能够对CPU、内存与网络环境进行限制，复现应用在性能较差、网络环境不佳场景下的表现。

录制回放：能够将用户的操作记录下来，支持在各个设备上进行回放。

一机多控：操作一台主机设备来控制多台从机设备，进行重复冗杂的兼容性测试，能够极大提升兼

容性测试的效率。

下载：

安装 ：独立安装的 SoloPi（APK，IOS无该版本），像普通APP一样安装。

8.1SoloPI

SoloPi使用（选择测试项）

SoloPi使用（监控）

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

SoloPi使用（查看结果）

SoloPi使用（查看结果）

总结：

1. App性能测试分类：

资源占用 + 稳定性

2. App性能工具：

① Android：工具（ solopi、GT） + 命令（adb）

② Ios：苹果开发工具xcode

8.2内存

APP性能测试关注点

APP使用时对CPU、内存的占用情况；

APP使用时是否流畅等;

APP使用时电量流量的消耗情况；

APP的启动时间是否过长；

APP是否能长时间稳定运行

内存监控指标

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

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

Private dirty（私有内存）：

进程独占内存，也就是进程销毁时可以回收的内存容量。

PSS（实际使用内存）：

将跨进程共享页也加入进来， 进行按比例计算PSS。这样能够比较准确的表示进程占用的实际物

理内存。

内存问题的现象

案例 性能内存测试

需求：浏览tpshop首页平均内存消耗情况。

步骤：

（1）打开SoloPi工具，配置内存监控

（2）进入APP，操作上述业务，观察运行时的内存指标

（3）查看内存运行结果

检查程序实际使用的内存PSS值

总结：

1. 性能：

① 内存 + cpu + 流量 + 电量

② 启动速度 + 流畅度 + 稳定性

2. 内存关注：

① 实际使用内存（

PSS

）

② 私有内存

3. 内存常见问题：

① 内存泄漏：申请内存无释放内存。

② 内存溢出：申请内存时，无内存可用。

8.3 cpu

CPU监控指标

SoloPi工具提供了两个CPU的监控指标：

全局占用

CPU和

应用进程

CPU。

全局占用CPU：

整机的CPU使用水平，即当前手机的CPU整体使用率。

在 Linux 系统下，CPU 利用率分为

用户态

、

系统态

和

空闲态

用户态

：表示 CPU 处于应用程序执行的时间

系统态

：表示系统内核执行的时间

空闲态

：表示空闲系统进程执行的时间。

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

应用进程CPU：

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

CPU消耗引起的现象

CPU使用长时间处于90%以上

手机发热、耗电量增加

响应变慢、引起ANR（Application Not Responding）

案例 性能CPU测试

需求：

测试滑动首页CPU使用率

步骤：

（1）打开SoloPi工具，勾选CPU监控指标

（2）进入tpshop，操作上述业务，观察运行时的CPU指标

（3）查看CPU运行结果

检查APP运行时CPU是否长时间处于90%以上

总结：

1. 关注：长时间90%以上

2. cpu问题现象：手机发热 + 耗电量增加 + 反应变慢 + 无响应

8.4 流量

流量介绍

操作APP会与服务器交换数据，流量就是指这些交互

数据

的总大小。

案例 性能流量测试

需求：

打开tpshop首页，上下滑动动态20秒，获取消耗的网络流量。

总结：

流量优化策略：

数据的压缩

不同数据格式的采用

控制访问的频次

只获取必要的数据

缓存机制

针对不同的网络类型设置不同的访问策略

8.5 电量

电量

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

常见的耗电量大的场景：

定位

网络传输

屏幕亮度

wake_locker（锁屏-解锁）

案例 性能电量测试

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

步骤：

（1）打开SoloPi工具，勾选电量监控指标：电池

（2）进入APP，操作上述业务，观察运行时的CPU指标

（3）保存电量详细数据后，可以查看电量详细的数据统计。

提示：

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

总结：

1. 耗电量大场景：

定位

网络传输

屏幕亮度

wake_locker（锁屏-解锁）

2. 分析结果：

•

与基准数据对比（基准数据来自于产品经理，或者以往数据积累）

•

横向对比（竞品）

8.6 流畅度

流畅度介绍

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

流畅度的监控指标

SoloPi工具提供了流畅度的监控指标：

帧率FPS

即Frames per second：GPU在一秒内绘制的帧数。（简单理解为一秒内呈现给用户的图片数）

FPS值越高

画面越

流畅

流畅度问题产生的影响：

想要让大脑觉得动作是连续的，至少是每秒10-12帧的速度

想达到流畅的效果，至少需要每秒24帧

60帧每秒的流畅度是最佳的，我们的目标就是让程序的流畅度能接近60帧每秒

注意事项

当页面多为静态时，FPS值很小是正常的

页面数据多为动态加载时，FPS值比较大（建议在24帧以上）

案例 性能流畅度测试案例

需求：

打开tpshop，进入首页，上下滑动动态2分钟，记录FPS值。

步骤：

（1）打开SoloPi工具，勾选帧率

（2）进入APP，操作上述业务，观察运行时的流畅度指标

（3）查看流畅度运行结果

总结：

流畅度：

• 达到流畅效果24/S

• 最佳流畅效果60/S

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

8.7启动速度

启动速度介绍

APP启动速度：

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

APP启动分类：

冷启动、热启动

冷启动：启动

app进程，这种启动方式叫做冷启动。

热启动

：将app从后台置于前台

。

Solopi指标：

启动耗时计算

案例 性能启动时间测试

需求：

分别获取tpshop冷启动和热启动时间

总结：

启动分类：

热启动+冷启动

冷启动：

启动

app进程，这种启动方式叫做冷启动。

热启动：从后台切换到前台

8.8 Android-sdk环境搭建

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->adb version

8.9 稳定性

在使用app过程中，是否遇到以下现象？

什么是稳定性？

app程序能

持久良好

的运行。

Monkey介绍

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

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

情况。

Monkey程序是Android系统中自带一款稳定性测试工具，由Java语言编写。

【无需单独安装】

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

稳定性测试步骤

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

2、检查日志异常

Monkey命令

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

参数：

-p:

指定包名

-v:

log详细程度（最高支持’-v -v -v’最详细）

次数:

要执行随机操作的次数

:重定向（保存）日志

检查日志

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

常见关键字：

•

无响应: 在日志中搜索 “ANR”、timeout

•

崩溃:在日志中搜索 “NullPointerException”或 Exception

•

闪退：memory out 、memory Leak

•

错误：error

注意事项

提示：

1、测试人员一般不需要分析错误日志原因，如果具备日志分析能力可以辅助开发定位缺陷原因。

2、日志错误类型原因有很多，需要经验积累，以上关键字提供了常见错误关键字

案例 tpshop稳定性测试

需求：针对tpshop商城进行稳定性测试

分析：

① 获取app包名: com.tpshop.malls

② 执行monkey命令： adb shell monkey -p 包名 –v 次数 >c:\日志.log

③ 检查日志异常关键字： [ANR,timeout,Exception,out,leak,error]

④ 将异常日志发给开发

扩展

总结：

1. 常见app不稳定的现象

崩溃、闪退、无响应、卡顿

2. 稳定性测试

在app应用中

随意

操作，挖掘有可能出现的异常。

3. 稳定性怎么测？

① Android系统使用自带monkey工具

② 测试次数

【工作中50W-80W次】

4. Monkey工具应用

① 执行Monkey命令：

adb shell monkey -p 包名 -v 次数 > 日志.log

② 检查日志是否有异常，有异常将日志发给开发

下载地址

9.AI应用

9.1需求分析

AI介绍

AI，即

人工智能

（Artificial Intelligence），旨在使机器能够

模拟

和

执行

人类

智能

活动。

测试流程

1-AI助力需求分析

1、阅读需求，对业务进行学习。

2、评审需求，提出疑问。

AI

作用

分析需求

，协助理解需求

评审需求

合理性，提出需求不足之处。

需求：

1. 账号：必填，已经注册手机号或邮箱

2. 密码：必填，注册账号的密码

3. 验证码：正确且未过期

评审以下给出的需求，我们可以从完整性、明确性、可行性以及用户体验等角度进行分析，并提出潜在的不足之处：

需求评审

1. 账号

• 需求描述 ：账号是必填项，且必须是已经注册的手机号或邮箱。
• 不足之处 ：
  • 缺乏错误处理说明 ：当输入的账号不存在或格式不正确时，系统应给出明确的错误提示。
  • 账号验证流程 ：虽然提到了账号必须已注册，但并未明确说明账号验证的具体流程，如是否通过数据库查询等。

2. 密码

• 需求描述 ：密码是必填项，且应与注册账号时设定的密码相匹配。
• 不足之处 ：
  • 密码安全性 ：需求中未提及密码的加密存储和传输要求，这是保障用户密码安全的重要方面。
  • 密码错误处理 ：未明确说明密码输入错误时的处理机制，如错误次数限制、锁定账户等。

3. 验证码

• 需求描述 ：验证码必须正确且未过期。
• 不足之处 ：
  • 验证码生成与发送 ：需求中未提及验证码的生成规则和发送方式（如通过短信、邮件等）。
  • 验证码过期时间 ：未明确验证码的有效期是多久，这对用户体验和系统安全性都有影响。
  • 验证码错误处理 ：未说明验证码输入错误时的处理机制，如是否允许重新获取验证码，以及重新获取的次数限制等。

综合不足之处

1. 缺乏详细的错误处理机制 ：对于账号不存在、密码错误、验证码错误等情况，应给出明确的错误提示，并可能包含下一步操作的建议（如重新输入、找回密码、重新获取验证码等）。
2. 安全性考虑不足 ：密码的加密存储和传输、验证码的生成与发送方式、验证码的有效期等，都是保障系统安全性的重要方面，但需求中均未明确提及。
3. 用户体验考虑不足 ：如验证码的过期时间设置不合理，可能会导致用户频繁重新获取验证码，影响用户体验。此外，对于密码输入错误次数过多时，是否应锁定账户以保护用户账号安全，也是用户体验和系统安全性之间的权衡点。

建议改进

• 明确错误处理机制，包括各种可能的错误情况和相应的处理流程。
• 加强安全性考虑，明确密码的加密存储和传输要求，以及验证码的生成、发送和有效期等细节。
• 优化用户体验，合理设置验证码的有效期，避免用户频繁重新获取验证码。同时，考虑密码输入错误次数过多时的处理机制，如暂时锁定账户一段时间后再允许尝试等。

9.2 测试计划

明确测试范围、进度安排、人力物力的分配，制定整体测试策略，并制定风险评估与规避措施。

AI

作用

根据关键数据，

编写测试计划

。

9.3 测试用例设计

编写测试用例，参考需求文档、原型图、概要设计、详细设计等文档。

AI

作用

提取测试点

编写测试用例

为了设计针对给定需求的测试用例，我们可以遵循参考用例的8大要素格式（虽然具体8大要素可能

因不同组织或框架而异，但这里我们可以假设包括测试用例编号、测试标题、测试目的、前置条

件、输入数据、预期结果、实际结果、测试状态等）。以下是一个使用Excel表格形式设计的测试

用例示例：

请注意，实际测试时，您需要确保“任意值”是符合其字段要求但非预期的测试值，以便验证系统是

否按预期处理这些非预期输入。此外，测试用例的实际结果和测试状态应在测试执行后填写。

9.4 用例执行

4-AI助力测试用例执行

搭建测试环境，执行冒烟测试（预测试），正式测试，对发现的bug进行管理直到测试结束。

AI

作用

生成环境部署文档/脚本

生成测试用例（冒烟、所有用例）

缺陷预测

为了编写一个安装MySQL 8.0的Shell脚本，在CentOS 7上，我们需要先添加MySQL的官方仓库，

因为CentOS 7的默认仓库中可能不包含MySQL 8.0的最新版本。以下是实现这一要求的Shell脚本

示例：

#!/bin/bash  
  
# 检查是否以root权限运行  
if [ "$(id -u)" != "0" ]; then  
   echo "此脚本必须以root权限运行" 1>&2  
   exit 1  
fi  
  
# 安装必要的工具和库  
echo "正在安装必要的工具和库..."  
yum install -y wget  
  
# 添加MySQL官方仓库  
echo "正在添加MySQL官方仓库..."  
wget https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm  
rpm -Uvh mysql80-community-release-el7-3.noarch.rpm  
  
# 安装MySQL服务器  
echo "正在安装MySQL服务器..."  
yum install -y mysql-community-server  
  
# 启动MySQL服务并设置开机自启  
echo "正在启动MySQL服务并设置开机自启..."  
systemctl start mysqld  
systemctl enable mysqld  
  
# 获取临时密码  
echo "正在获取MySQL临时密码..."  
temp_password=$(grep 'temporary password' /var/log/mysqld.log | awk '{print $11}')  
echo "MySQL临时密码为: $temp_password"  
  
# 允许root用户远程访问（可选，出于安全考虑，请谨慎使用）  
# 注意：这只是一个示例，生产环境中通常不建议这样做  
# echo "正在配置MySQL允许root用户远程访问..."  
# mysql -uroot -p"$temp_password" -e "ALTER USER 'root'@'localhost' IDENTIFIED BY '新密码'; CREATE USER 'root'@'%' IDENTIFIED BY '新密码'; GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION; FLUSH PRIVILEGES;"  
  
# 脚本结束  
echo "MySQL 8.0 安装完成！"

9.5 测试报告

5-AI助力测试评估

此阶段需要出测试报告，确认软件是否可以上线。

AI

作用

根据关键数据，

编写测试报告。

注意事项