黑马软件测试笔记

Sudan_God

已于 2025-04-20 12:13:15 修改

阅读量1.1k

点赞数 25

文章标签：笔记

于 2024-09-10 10:55:28 首次发布

本文链接：https://blog.csdn.net/Sudan_God/article/details/140545484

版权

测试

分类

按软件生成过程划分

分类	测试内容	测试人	举例（电商）
单元测试	源程序代码	开发	用户名验证
集成测试	模块之间的功能交互	测试	用户登录
系统测试	整个系统	测试
验收测试	项目是否符合预期需求	用户

按程序源代码可见程度划分

分类	测试重点	代码可见度	UI可见度	使用场景	对标
黑盒测试	数据输入、结果输出	不可见	可见	web	系统测试
灰盒测试	数据访问通道	部分可见	不可见	postman	集成测试
白盒测试	代码语法和逻辑	可见	不可见	idea	单元测试

其他测试

冒烟测试

测试内容：对核心功能（用户经常使用的功能）进行测试

作用：保证提测内容具备可测性。而不会造成主要功能没完成就开始测试，导致浪费人力

回归测试

测试内容：对（已修复的bug / 更新后对已测试的内容）重新测试

作用：保证（bug修复，确保bug修复 / 版本更新）不会影响其他正常功能

质量模型

质量性能	内容
功能性	功能数量与文档一致，且功能能够正常实现
性能	多用户同时使用是否满足（时间、资源）
兼容性	在不同的（平台 \ 设备）上使用
易用性	从流畅、简洁、美观三个方面衡量易学、易用、用户粘性
安全性	数据传输和存储的安全
可靠性	长时间运行稳定，不出现异常（死机、卡顿、无响应）
可移植性	应用升级时数据迁移方便
可维护性	运行过程出现问题维护操作是否简便

功能测试

测量功能性

非功能测试

质量模型中除了功能性都是非功能测试

兼容性

软件	测试内容
Web	不同浏览器（谷歌、Edge等）
App	不同操作系统（android、ios）

测试过程（Web）

1.需求分析与评审

2.制定测试计与方案（用思维导图提取测试点）

业务

业务测试

定义：为满足用户的一系列功能，由多个或单个单功能组成

使用场景：测试软件单功能之间关联性数据处理逻辑是否正确

优先级：在项目测试中优先级最高，先测主业务，再测单模块

方法：流程图法

步骤

1.确认流程图

2.从开始到结束每条路径确定一条测试点
3.将测试点转为测试用例

测试数据：反向测试用例错误数据原因不唯一（重点在于验证功能之间的联系）

举例（发布文章）

1.确认流程图

2.从开始到结束每条路径确定一条测试点：
发布文章失败（提交失败）、发布文章失败（审核失败）、发布文章成功
3.将测试点转为测试用例

单功能

等价类划分法

作用：用少数数据获得较好的测试效果（类似排列组合）

适用场景：表单类元素（输入框、下拉框、单选框、复选框）

步骤

1.划分有效等价类：满足需求的数据集合
2.划分无效等价类：不满足需求的数据集合
3.每类中选取代表数据组合测试数据：多个有效数据组合，单个无效数据与其他有效数据组合

举例（登录）

1.有效用户名user123，有效密码password123
2.无效用户名error1，无效密码error2
3.排列组合：user123-password123，user123-error2，error1-error2，error1-password123

边界值分析法

使用场景：数据有边界范围限制

步骤

1.边界值分析法选取长度
a).选取上点（边界值）
b).选择两个离点（距离上点最近的点）：包含上点选择范围外的点；不包含上点选择范围内的点
c).选择内点（范围内的点）：最好是中间范围
2.等价类划分法
3.提取数据排列组合

举例（密码长度限制8-13位）

1.选取上点：8，13
2.选取离点：7，14（8-13是包含在有效数据的）
3.选取内点：11

判定表

使用场景：多条件之间有约束规则

步骤

1.列出问题的所有条件（条件桩）
2.列出问题的所有可能采取的动作（动作桩）
3.列出条件对应的取值，值为是或否（条件项）
4.根据条件项推导出可能采取的动作，值为√或×（动作项）
5.根据规则（一列的动作项和条件项）提取测试点

举例（指定时间内消费满1000元，打9折）

1.列出条件桩：指定时间、>= 1000元
2.列出动作桩：打9折、不打折
3.列出条件对应的取值
4.推导动作项
5.根据规则提取测试点：不打折（在指定时间内 + 消费不满1000元）

3.设计测试用例（Excel）

步骤

1.提取测试点
2.根据测试点编写测试用例

标题	内容	举例
用例编号	项目_模块_数字	shop_login_001
用例标题	预期执行结果（测试点）	登录失败（密码为空）
所属模块	模块名	登录
优先级	用例的重要程度（高P0-低P3）	p1
前置条件	执行操作不在的前置条件	1.账号已注册 2.打开登录页面
测试步骤	测试点执行的关键步骤	1.输账号 2.输密码 3.点击按钮
测试数据	输入数据	1.账号：注册手机号 2.密码：空
预期结果	预期执行结果及隐性结果	登录失败，提示信息
实际结果	用例的实际执行结果	通过 / 不通过

举例

4.执行测试用例

前提条件：

1.测试内容已经开发交付

2.测试环境已经准备好

关注点：

1.实际执行结果是否与预期结果一致，一致通过，不一致则为bug

2.预期隐性结果应与执行隐性结果相似

3.实际结果与预期结果有争议的地方，多从用户角度衡量

5.缺陷跟踪管理

定义：任何问题都是缺陷

常用工具：禅道、jira

衡量标准

缺陷	内容	举例
少功能	软件为实现说明书中明确要求的功能	学生端无提交作业
多功能	软件实现说明书未要求的功能	学生端出现批改作业
功能错误	软件出现了说明书中指明不应该有的错误	金额结算错误
隐性功能缺失/错误	软件未实现说明书中未明确但应该实现的要求	删除没有二次确认
不易使用	软件难以理解，不易使用，运行缓慢，用户体验不好	提示系统繁忙

缺陷主要内容

缺陷	内容	举例
当前指派	将bug提交给谁	开发人员A
Bug类型	代码错误、设计缺陷...	设计缺陷
Bug标题	描述Bug问题(测试点描述及预期结果(实际结果))	账号为空+密码不为空，提示登录失败，账号不为空（实际结果：...）
严重程度	Bug严重程度	高
优先级	Bug的修复紧急程度业务：正向P0，逆向P1 功能：正向P2，逆向P3 兼容性为P2或P3	P3
重现步骤	复现步骤	1.输入账号：空 2.输入密码：123 3.点击登录按钮
附件	执行实际结果截图或日志文件

缺陷跟踪流程

流程	解释	负责人
提交缺陷	提交发现的缺陷	测试
分派缺陷	将缺陷分派给其他开发	开发
是否重复	查看缺陷是否已经提交过	开发
是否Bug	检查缺陷是Bug还是设计如此	开发
推迟处理	安排处理缺陷是现在还是后续版本	开发
处理缺陷	修复Bug	开发
回归测试	修复Bug后让测试重新测试	测试
验证通过	判断Bug是否真正被修复	测试
关闭缺陷	缺陷已解决或缺陷已经提交过	测试
重新打开	缺陷并未修复	测试

6.编写测试报告

App

测试范围

功能测试

业务测试

功能模块测试

性能测试

目的：测试App使用期间占用硬件资源（CPU、内存、流量、电量）使用情况

常用工具：

Android：SoloPi、GT、命令（adb）

ios：xcode

SoloPi

功能：

        录制回放（自动化）
        性能测试（监控资源）
        一机多控（兼容性）

使用：打开要测App之后再开始录制

测试分类

资源占用

内存

监控指标

1.私有内存（Private dirty）：进程独占内存，销毁时可回收的内存容量
2.实际使用内存（PSS）：私有内存 + 共享内存，按比例计算PSS可准确表示进程占用的实际物理内存

内存问题现象（PSS持续增长）

1.内存泄露：无法释放程序申请的内存空间，最终会导致内存溢出
2.内存溢出：程序在申请内存时，没有足够的内存空间使用

CPU

CPU利用率

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

监控指标

1.全局占用CPU：当前手机的CPU整体使用频率 = CPU执行非系统空闲进程时间 / CPU总的执行时间
2.应用进程CPU：当前应用的CPU整体使用频率

CPU问题现象（CPU长时间处于90%以上）

1.手机发热
2.耗电量增加
3.响应变慢
4.引起ANR（应用无响应）

流量

定义：App与服务器交换数据的大小

分类：

上行消息：App发送给服务器的数据

下行消息：服务器发给App的数据

监控指标

模拟器无法统计电脑流量使用情况（全局上行下行流量），看进程使用流量

1.网络

流量优化策略

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

电量

监控方法

方法	优点	缺点
系统自带接口	方便	无法查看固定某一段时间的电池精确消耗
硬件检测	精确获得对应应用的电量消耗	需要拆机，成本过高
软件工具检测		精确度取决于第三方软件的准确性

常见耗电量大的场景

1.定位
2.网络传输
3.屏幕亮度
4.锁屏-解锁

流畅度

监控指标

帧率FPS：GPU一秒内绘制的帧数（一秒内呈现给用户的图片数）

流畅度问题现象

1.10-12帧：让大脑觉得动作是连续的
2.>24帧：流畅效果
3.60帧：最佳效果

启动时间

定义：从启动App到主页面加载完成的速度

分类：

冷启动：启动App进程（从无到有）

热启动：App从后台置于前台

监控指标

1.启动耗时计算

稳定性

测试内容：在App中随意操作，挖掘可能出现的异常（卡顿 / 闪退 / 奔溃 / 无响应）

工具：Monkey

sdk环境

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

安装

1.解压到指定目录
2.将安装目录添加到path中
a).新建环境变量：ANDROID HOME=D:\Android\sdk
b).添加path路径：%ANDROID HOME%\tools 、%ANDROID HOME%\platform-tools
3.在cmd输入adb version验证

Mokey

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

位置：/system/framework/monkey.jar（android）

测试步骤

1.获取包名（测试软件名）

adb shell dumpsys window windows | grep usedApp

2.执行命令，并将执行结果写入日志

adb shell monkey -p 包名 基础参数 (事件类型) (调试选项) 次数 > 存放文件

eg：
1.adb shell monkey -p com.tpshop.malls -v 2000 > tpshop.1og
2.adb shell monkey -p your.package.name --pct-touch 50 -v 1000
3.adb shell monkey -p your.package.name --throttle 500 -v 1000
4.adb shell monkey -p your.package.name -s 12345 -v 1000
5.adb shell monkey -p your.package.name -s 12345 --throttle 500 -v -v 1000
6.adb shell monkey -p your.package.name -s 12345 --throttle 500 -v -v --pct-touch 50 --pct-motion 30 --ignore-crashes --ignore-timeouts 1000 > /path/to/your/logfile.log
7adb shell monkey -p your.package.name -v -v --pct-touch 50 --pct-motion 30 --ignore-crashes --ignore-timeouts 1000 > /path/to/your/logfile.log.

分类	参数	解释	例子
基础参数	-v	日志的详细程度，一共三个级别，-v -v -v最高	-v
	-S	随机动作的序列	-S 123
	--throttle	随机事件之间的延迟	--throttle 500
事件类型	--pct-touch	触摸事件（点击 / 长按）的百分比	--pct-touch 20
	--pct-motion	动作事件（滑动 / 拖动）的百分比	--pct-motion 50
	--pct-trackball	轨迹事件（轨迹球）的百分比	——
	--pct-syskeys-	系统按键（音量 / 关机）的百分比	——
	--pct-anyevent	其他事件的百分比	——
调试选项	--ignore--crashes	忽略应用程序崩溃	--ignore--crashes
	--ignore-timeouts	忽略无响应ANR	——
	--ignore-security-exceptions	忽略许可证书崩溃	——
	--kill-process-after-error	发生错误停止运行并保持当前状态，防止错误扩散	——
	--monitor-native-crashes	监视并报告Androids系统本地代码的崩溃事件	——

3.打开日志，搜索异常关键字检查异常

异常	关键字
无响应	ANR、timeout
崩溃	NullPointerException、Exception
闪退	memory out、memory Leak
错误	error

关注测试点

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

专项测试

目的：

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

2.不同网络环境App能正常使用

3.不同App版本正常使用

环境搭配

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

常用工具：模拟器（移动设备） + App安装包（apk）

安装方法：将apk拖入模拟器

安装卸载升级

安装场景

正常场景

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

异常场景

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

卸载关注点

1.正常卸载(APP手动卸载、工具卸载)
2.运行时卸载
3.取消卸载
4.卸载异常中断后卸载
5.卸载后无数据残留

升级关注点

1.从临近版本升级
2.跨版本升级
3.不同渠道升级(应用商场、手机助手)
4.升级提醒成功(可不提醒、可以提示升级、强制升级)
5.应用内升级时非WIFI提醒

服务器push消息推送

定义：App推送的各种通知

推送方式

方式	内容	优缺点
Pull（拉）客户端主动获取	客户端固定时间主动向服务器获取消息	消耗两端资源
Push（推）客户端被动获取	当服务器有更新消息时，主动发送到客户端	节省两端资源

Push消息推送流程

1.服务器有更新信息
2.服务器将消息推送到推送服务器中（专门用来推送的服务器）
3.推送服务器将信息推送到App中

推送服务器种类

种类	平台
操作系统级别	ios：APNs Android：C2DM
自己搭建推送服务器
第三方推送平台	手机厂商类：小米推送、华为推送第三方平台类：友盟推送、极光推送、云巴（基于MQTT） BAT大厂平台：阿里云移动推送、腾讯信鸽推送、百度云推送

Push消息关注测试点

关注点

App服务器设置：

1.推送内容

2.推送时机

3.推送频率

4.推送人群（全部用户/部分用户）

手机端设置：

1.是否接受通知

2.提醒位置

测试点

APP服务器设置测试点：
1.Push消息是否按指定业务规则发送
2.当Push消息是针对特定用户时，检查收到的Push与用户身份是否相符等
手机端设置测试点:
1.设置不接收推送消息时，用户是否会收到Push消息

2.设置push消息显示的位置，是否与配置一致

3.收到push消息，是否能正常打开跳转等
其他测试:
1.APP在前台使用时，收到push消息如何提示

2.APP在后台运行时，收到push消息如何提示

3.APP离线，是否能收到PUSH消息。

交叉事件测试

定义：一个功能在执行过程中，另外一个事件或者操作对该过程进行干扰

关注测试点

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

用户体验测试

关注测试点

易用性测试：
1.是否有空数据界面设计，引导用户去执行操作
2.菜单层次是否太深
3.完成业务操作的步骤是否过多

4.界面中按钮可点击范围是否适中

关注手机应用上的其他辅助功能：

1.放大字体

2.反色

3.语音转换

4.多点触碰等功

UI界面测试：对照UI交互设计文档，检查每个界面设计菜单、对话框、窗口、风格、布局等

横竖屏测试：横竖屏的切换是否正常(表格因为横竖屏的显示宽度不一样)

兼容性测试

测试范围	内容
品牌型号（品牌、系统版本、分辨率）	品牌（Android、ios）
	android系统：5.1、6.0、7.0、8.0 ios系统：11.x、12.x、13.x
	分辨率：10801920、7201280 屏幕尺寸：5.5、4.7
网络	2G / 3G / 4G / 5G / wifi
软件兼容	系统软件：wlan设置、系统时间调节、LBS定位其他app：后台播放音乐、进入动态页面点击动态视频
硬件兼容	手机硬件：home键、电源键、音量调节外部硬件：耳机、蓝牙、数据线

测试方式

1.使用公司已有的真机进行兼容性测试
2.使用第三方兼容性平台进行测试（线上云测平台testin）

App发布

发布方式

内部发布

作用：为了方便测试程序包的安装和管理

常用工具：蒲公英、Testlink

步骤

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

线上发布

Android常用工具：豌豆荚、应用宝、360手机助手、各类手机品牌商城

ios常用工具：App store、iTools

步骤

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

发布策略

阶段	环境
开发阶段	开发环境
测试阶段	测试环境（预发布环境）
灰度发布	先发布少数服务器（少数客户可见，有异常回滚）
生产环境	服务器集群（多台电脑）