目录
1.测试分类
按照软件产生的阶段划分
按照代码可见度划分
其他测试
2.质量模型：衡量一个软件质量的维度
3.软件测试
1.单功能测试
等价类划分法：一种用少量数据获得较好测试效果的工具
边界值分析法：一个边界范围限制选取测试数据工具
2.测试用例
1.测试用例介绍
2.作用
3.测试用例核心内容
4.测试用例编写
3.判定表
1.作用：多条件并且条件之间有约束规则的需求设计测试点
2.组成：条件桩、条件项、动作桩、动作项
3.提示:
4.执行用例：开始对项目进行测试
执行之前准备
执行用例关注
5.缺陷管理
缺陷介绍
缺陷描述及提交
6.业务测试
1.测试分类
按照软件产生的阶段划分
按照软件生成过程划分：单元测试、集成测试、系统测试、验收测试
- 单元测试：针对程序源代码进行测试（开发自测）
- 集成测试：针对模块之间功能交互进行测试，又称组装测试（测试人员）
-
系统测试： 对整个系统进行全面测试（测试人员）
- 验收测试：以用户代表为主验证项目是否符合预期需求（用户测试）
按照代码可见度划分
- 黑盒测试：关注数据输入、结果输出
1、源代码可见
2、UI功能可见
- 灰盒测试： 关注输入输出、数据访问通道
1、部分源代码可见
2、UI功能可见
- 白盒测试：关注代码本身语法逻辑
1、全部源代码可见
2、UI功能可见
其他测试
- 冒烟测试：对核心功能的验证
作用：保障提测内容具备可测性
- 回归测试：对已修复bug\更新后对已测内容再次测试
作用：保证bug修复、确保新功能对旧功能没有影响
2.质量模型：衡量一个软件质量的维度
1. 功能性：与需求数量一致，软件是否具备某方面的能力
2. 性能：多用户同时使用能否满足要求（时间、资源）
3. 兼容性：在不同的设备/平台上能否正常使用
4. 易用性：易学、易用、用户体验好
5. 安全性：敏感数据存储/传输安全
6. 可靠性：长时间运行稳定，不出现异常
7. 可移植性：应用系统升级/数据迁移方便
8. 可维护性：运行过程出现问题维护操作是否方便
3.软件测试
1.单功能测试
单功能：
软件程序或应用程序只提供一项核心功能或特性，而不包含其他附加功能。
等价类划分法：一种用少量数据获得较好测试效果的工具
适用场景：表单类页面元素测试使用（输入框、单选按钮、下拉列表）
步骤：
- 划分有效等价类：满足需求的数据集合
- 划分无效等价类：不满足需求的数据集合
- 每类中选取代表数据
边界值分析法：一个边界范围限制选取测试数据工具
适用场景：有边界范围的数据测试时使用
选取
1. 上点：刚好是边界上的点，必选（不考虑是否包含上点） 100、300
2. 离点：距离上点最近的点，选择
2
个 99、301
3. 内点：边界范围内的任意点，必选（建议选择中间范围） 200
步骤
1. 边界值分析（负责测试
长度范围
）
2. 划分等价类（负责测试
类型
和
规则
）
3. 提取数据
2.测试用例
1.测试用例介绍
测试用例：描述测试点执行的文档（测试输入、执行条件、预期结果等）
2.作用
1. 测试点能被精准的执行
2. 便于团队协作
3.测试用例核心内容
用例编号、用例标题、所属模块、优先级、前置条件、测试步骤、测试数据、预期结果
4.测试用例编写
1. 用例编号：项目_模块_数字 Html_login_001
2. 用例标题：预期执行结果（测试点） 登录失败（密码为空）
3. 所属模块：模块名 登录
4. 优先级：用例的重要程度（高P0~P3低） p1
5. 前置条件：执行操作步骤的前置条件
1
、账号已注册
2
、已打开登录页面
6. 测试步骤：测试点执行的关键步骤
1
、输入账号
2
、输入密码
3
、点击登录按钮
7. 测试数据：输入数据
1
、账号：已注册手机号
2
、密码 ：空
3
、点击登录按钮
8. 预期结果：预期执行结果及隐性结果。
登录失败，提示：密码不可为空，请正确输入注册账号密码。
3.判定表
1.作用：多条件并且条件之间有约束规则的需求设计测试点
2.组成：条件桩、条件项、动作桩、动作项
3.提示:
判定表中贯穿条件项和动作项的一列
就是一条规则
假设有n个条件，每个条件的取值有两个(0,1)，全组合有2的n次方种规则
4.执行用例：开始对项目进行测试
执行之前准备
• 项目提测内容开发已交付测试
• 测试项目环境已准备
执行用例关注
• 实际执行结果与预期执行结果一致，不一致为缺陷（bug）
• 项目执行隐性结果与用例预期隐性结果相似
• 实际结果与预期结果有争议，参考用户角度业角度去衡量
5.缺陷管理
缺陷介绍
软件中存在的任何
问题
，也叫缺陷（ bug ）。
缺陷衡量标准：
1. 软件未实现需求(规格)说明书中明确要求的功能 –>
少功能
2. 软件实现的功能超出需求(规格)说明书指明的范围 –>
多功能
3. 软件出现了需求(规格)说明书中指明不应该出现的错误 –>
功能错误
4. 软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求 –>
隐性功能缺失/错误
5. 软件难以理解，不易使用，运行缓慢，用户体验不好 –>
不易使用
缺陷描述及提交
目的：
将缺陷提交给开发，开发根据描述可复现缺陷
工具：
禅道、jira、……
缺陷评判标准：
多功能、少功能、功能错误、隐性功能缺失、体验不好
重点：
•
当前指派：将bug提交给谁
•
Bug类型：代码错误、设计缺陷、……
•
Bug标题：描述bug问题
测试点描述及预期结果（实际结果）
•
严重程度：bug严重程度
•
优先级：bug修复紧急程度
•
重现步骤：复现步骤
•
附件：执行实际结果截图或日志文件
6.业务测试
业务：
是指软件为满足用户特定的业务需求而设计并实现的一系列功能。
下单业务（登录->搜索->添加购物车->下单->支付）
作用：
测试软件系统单功能之间关联性数据处理逻辑是否正确
例：添加购物车时对登录状态的判断
方法：流程图法
流程图：使用一些特定图形和带箭头的线表达程序业务走向。
步骤：
1、确认业务流程图
2、流程图中从开始到结束每条路径都是一条用例
![[数据集][目标检测]航拍屋顶检测数据集VOC+YOLO格式458张3类别](https://i-blog.csdnimg.cn/direct/dcf5ba6064ca493c8bb4d1e85a835602.png)
