认识软件测试
软件测试能力要求
- 软件测试用例设计能力
- 缺陷管理能力
- 抓包工具能力
- 数据库操作能力
- 项目部署能力
- 项目实战经验
- 代码编写能力
学习路径：
1.用例设计 2.缺陷管理 3.抓包管理 4.数据库操作 5.环境部署 6.项目实战
一、软件测试的步骤
1.需求分析----》2.测试点设计----》3.编写测试用例----》4.执行测试用例----》5.缺陷管理----》6.测试报告
1.需求
根据产品需求文档，提取出规则要求
目的是为了明确软件的有那些功能以及要求，为测试点做准备。
2.测试点
需要验证的点，根据需求规则设计测试点
防止测试测试时有遗漏，为编写测试用例做准备。
3.测试用例
将测试点转化为测试执行的文档
4.执行测试用例
在执行过程中对比测试用例的实际结果与预期结果是否一致
5.缺陷管理
当执行的用例结果与预期结果不符合时，就需要对缺陷进行管理。
管理缺陷—》缺陷创建—》缺陷跟踪—》缺陷验证
目的就是为了减少软件缺陷（提交缺陷->等待修复->验证缺陷）
6.测试报告
对于本次执行的测试以及发现的缺陷进行分析统计，对于本次测试实施进行总结
缺陷统计、缺陷分析、遗留缺陷、测试总结
一、测试用例（test case）
用例：用户使用的案例
测试用例：执行测试过程中的用户案例
使用目的：保障测试点的正确执行
用例编写要素：
用例编号、测试环境、测试目标、输入数据、输出数据、操作步骤。
| 用例编号 | 测试环境 | 测试目标 | 优先级 | 测试步骤 | 测试数据 | 预期结果 | 实际结果 |
|---|---|---|---|---|---|---|---|
| 01 | window10 | 登录 | p0 | 1.输入账号2.输入密码3.点击登录按钮 | 1.账号：134565432.密码：123456 | 登录成功，跳转到个人主页 |
测试用例设计方法
1.等价类
含义：将测试数据中具有某种共同特征的数据集合，对这个集合进行划分。
例：
对年龄进行划分分为成年人和未成年
0~18不等于18岁：未成年
大于等于18：成年人
分类：有效等价类、无效等价类
例：
公司应聘者需满18岁。
未成年：无效等价类
成年人：有效等价类
步骤：1. 明确需求 2.确定有效等价类和无效等价类 3.提取数据编写测试用例
例：
根据条件需满18周岁设计相关测试用例，17岁、19岁、23岁、0岁、-1岁、32岁等。
17岁、0岁、-1岁：无效等价类
19岁、23岁、32岁：有效等价类
适用场景：需要有大量测试数据输入，且测试数据无法穷举。
2.边界值
含义：选取正好等于、刚好大于、刚好小于边界的值作为测试数据。
例：
测试数字是否大于-99且小于99
选取测试数据：-98、-99、-100、98、99、100
分类：上点（边界上的点）、离点（距离上最近的点）、内点（在数据范围内的点）
例：
上点：-99、99
离点：-98、-100、98、100
内点：97~-97
步骤：1.明确需求 2.确定有效和无效等价类 3.确定边界值范围 4. 提取数据编写测试用例
例：
通过边界值法验证标题长度的合法性，标题长度需要大于1，不超过30个字符（0<长度<=30）
有效等价类：0<长度<=30
无效等价类：长度<0 and 长度>30
上点：0、30
离点：-1、1、29、31
内点：2~28
边界值优化政策：离点（开内闭外）如果两个数之间是开区间，取内侧数据值，如果两个数之间是闭区间则取外侧数据值。
例：
[0,30]
上点（必选）：0、30
离点：-1、31
内点（必选）：97~-97
(0,30)
上点（必选）：0、30
离点：1、29
内点（必选）：97~-97
适用场景：在等价类的基础上针对有边界范围的测试数据输入的地方
常见词语描述：大小、重量、最大、最小、最多、最少……
典型代表：有边界范围的输入框类测试
3.判定表法
含义：是一种以表格形式表达多条件逻辑判断的工具。
例：
蓝牙耳机有电且未连接到其他手机时，可以进行蓝牙连接。
1.蓝牙耳机有电，连接到其他手机，无法进行蓝牙连接
2.蓝牙耳机无电，未连接到其他手机，无法进行蓝牙连接
3.……
组成：1.条件桩：列出问题的所有条件，次序无所谓。
2.动作桩：列出问题可能采取的操作，操作的排序顺序无关紧要。
3.条件桩：列出条件对应取值，所有情况下的真假
4.动作桩：列出条件下、各种取值下应该采取的动作结果
例：
蓝牙连接情况测试表
条件1 是否有电 是 是 否 否 条件2 是否连接其他手机 否 是 否 是 操作 是否可以被连接 是 否 否 否
规则：判定表中贯穿条件和动作一列就是一条规则。
判定表的规则与条件个数有关，条件为n，规则就为2^n
步骤：1.明确需求 2.画出判定表 3.根据条件项的组合确定动作项 4.简化、合并相似规则 5.根据规则编写测试用例
例：（订单检测）
1.金额大于500，未过期订单，发出批准单和提货单；
2.金额大于500，过期订单，不发出批准单和提货单；
3.金额小于或等于500，不论是否过期，都发出批准单和提货单；
4.过期情况时不管金额大小都需要再发通知单；
条件 具体情况 条件1 金额是否大于500 是 否 是 否 条件2 是否过期 是 是 否 否 操作1 批准单 否 是 是 是 操作2 提货单 否 是 是 是 操作3 通知单 是 是 否 否
适用场景：有多个输入条件、输入条件之间存在组合关系、输入条件和输出条件有依赖关系。一般适用于条件组合较少的情况。
4.场景法
含义：也称为流程图法，是使用流程图描述用户的使用场景、然后通过覆盖流程路径来设计测试用例。
例：（ATM机取款流程）
用户插入银行卡->ATM机验证银行卡->用户输入密码->ATM机传送密码到银行主机->银行主机验证密码->用户选择取款，输入取款金额->ATM机验证金额->银行主机验证余额充足->ATM机出钞并打印凭证->用户选择退出银行卡->ATM机退出银行卡
角度分析：
用户使用角度：多个功能的组合进行使用
测试人员角度：单个功能点进行测试、容易忽略多个功能点的组合测试
例：
流程图
步骤：1. 明确需求 2.根据需求画好流程图3.根据流程图编写测试用例
例：
用例 标题 模块 条件 优先级 测试步骤 测试数据 预期结果 01 取款失败(非银行卡) ATM 非银行卡 p0 1.插入卡片 无 取款失败，提示非银行卡 02 取款失败（密码错误三次） ATM 准备一张银行卡 p1 1.插入卡片2.输入错误密码三次 密码：111111 吞卡，取款失败 03 取款失败（银行卡余额不足） ATM 准备银行卡一张 p1 1.插入卡片2.输入正确密码3.输入取款金额 密码：123456取款金额：6000 提示余额不足，取款失败
提示非银行卡 |
| 02 | 取款失败（密码错误三次） | ATM | 准备一张银行卡 | p1 | 1.插入卡片2.输入错误密码三次 | 密码：111111 | 吞卡，取款失败 |
| 03 | 取款失败（银行卡余额不足） | ATM | 准备银行卡一张 | p1 | 1.插入卡片2.输入正确密码3.输入取款金额 | 密码：123456取款金额：6000 | 提示余额不足，取款失败 |
适用场景：根据实际的场景业务来设计测试用例，验证整个流程图之间的逻辑正确。