【软件测试】用例

1. 测试用例

1.1 概念

        实施测试而向被测试的系统提供一组集合（测试环境、操作步骤、测试数据、预期结果等）

        测试集合通常是在开发阶段的同时编写，因为测试时无法一时想出太多的测试用例，为了避免耗时，所以应该提前准备好一组测试用例集合

1.2 编写测试用例

• 使用 excel 表格编写测试用例

这种方法在以前用的很多，但现在很少使用了，常见的测试用例应该包括以下几方面的内容

要素	说明
用例编号	唯一标识（如TC_LOGIN_001）
测试标题	简洁描述测试目的（如“验证用户使用正确密码能否登录”）
前置条件	执行前的系统状态（如“用户已注册且账号未锁定”）
测试步骤	详细操作步骤（步骤1：输入用户名；步骤2：输入密码…）
预期结果	每一步的正确结果（如“页面跳转至首页”）
实际结果	执行后记录（测试时填写）
优先级	P0（核心流程）~P3（边缘场景）
测试数据	使用的输入数据（如用户名：test01，密码：123456）

• 使用 思维导图/脑图 来编写测试用例

2.1 常规思维 + 逆向思维 + 发散性思维

万能公式：功能测试 + 界面测试 + 性能测试 + 安全测试 + 兼容测试 + 易用性测试

测试类型	描述	关键关注点
功能测试	验证软件功能是否符合需求规格说明书的要求。	确保所有功能模块按预期工作；检查业务逻辑的正确性。
界面测试	检查软件界面的元素如布局、颜色、字体大小等是否符合用户交互和视觉设计规范。	用户界面的一致性和美观性；确保文本清晰可读；元素对齐等。
性能测试	评估软件在不同负载条件下的响应时间、吞吐量、资源利用率等性能指标。	软件在高负载下的稳定性；响应速度；资源使用效率（CPU、内存等）。
安全测试	检查软件的安全漏洞，确保数据保护机制的有效性以及访问控制的正确实施。	数据加密；用户认证与授权；防止SQL注入、XSS攻击等常见安全威胁。
兼容测试	验证软件在不同的操作系统、浏览器、设备上的运行情况，确保兼容性。	不同环境下的显示效果和功能表现；跨平台支持能力。
易用性测试	测试软件是否易于学习和使用，评估用户体验的好坏。	界面直观；操作简便；帮助文档清晰；减少用户错误发生的可能性。

3. 设计测试用例的方法

3.1 基于需求的设计方法

        基于软件的需求规格说明书设计测试用例，确保所有功能模块都按预期工作并检查业务逻辑的正确性。

3.2 具体的设计方法

3.2.1 等价类法

        将输入范围划分为几个子集（等价类），然后从每个子集中选取少量代表性的数据作为测试用例.

• 有效等价类：对于程序的规格说明书是合理的、有意义的输⼊数据构成的集合，利⽤有效等价类验证程序是否实现了规格说明中所规定的功能和性能
• 无效等价类：根据需求说明书，不满⾜需求的集合。

根据等价类设计测试⽤例的⽅式：

1）确定有效等价类和⽆效等价类

2）编写测试⽤例，设计具体测试数据

缺点：等价类只考虑输⼊域的分类，没有考虑输⼊域的组合，需要其他的设计⽅法和补充。

3.2.2 边界值法

        描述：主要用于选取输入域或输出域的边界值作为测试数据。这种方法基于一个观察：大部分错误往往发生在定义域或边界附近，而非在其内部区域。因此，通过重点测试这些边界条件，可以更高效地发现潜在问题。这个方法通常是对等价类法的补充，对等价类中的边界值进行测试。

边界值法增加的测试用例为 边界值 + 次边界值
这里的 边界值 和 次边界值 是相对的
如果 边界值 为有效等价类中的，则此边界值就为 无效等价类 的边界
如果 边界值 为无效等价类中的边界，则次边界值就为 有效等价类 的边界值

例如：若在某项测试中，有效等价类为 [ 5 , 15]；无效等价类为 [ , 5) & ( 15, ]

这里需要增加的测试用例就为 边界值 + 次边界值  （5，15）和 （4，16）

以下是根据你提供的大纲内容，逐条填充的详细说明：

3.2.3 判定表法

定义：
判定表法是一种基于逻辑决策表的测试用例设计方法，主要用于处理复杂的逻辑条件组合。它将输入条件、条件组合和预期输出以表格形式表示，帮助测试人员系统地覆盖所有可能的逻辑路径。

步骤：

1. 列出所有输入条件：明确系统输入的所有条件。

2. 确定条件组合：根据输入条件的可能组合，列出所有可能的逻辑情况。

3. 定义输出结果：为每种条件组合定义预期的输出结果。

4. 优化表格：合并重复或冗余的条件组合，简化表格。

示例：
假设有一个登录功能，输入条件为“用户名”和“密码”，条件组合包括：

• 用户名正确/错误

• 密码正确/错误

判定表如下：

条件组合	用户名正确	密码正确	预期输出
情况1	是	是	登录成功
情况2	是	否	登录失败，提示密码错误
情况3	否	是	登录失败，提示用户名错误
情况4	否	否	登录失败，提示用户名和密码错误

优点：

• 能够系统地覆盖所有可能的逻辑组合。

• 适合处理复杂的逻辑条件。

缺点：

• 当条件较多时，组合数量会急剧增加，导致表格过于庞大。

3.2.4 正交法

定义：
正交法是一种统计学方法，用于在有限的测试用例中覆盖尽可能多的参数组合。它通过正交表来选择参数组合，减少测试用例数量，同时保证覆盖度。

步骤：

1. 确定测试参数：列出所有需要测试的参数及其取值范围。

2. 选择正交表：根据参数数量和取值范围选择合适的正交表。

3. 生成测试用例：根据正交表的组合生成测试用例。

示例：
假设有一个搜索功能，参数包括：

• 搜索引擎（百度、谷歌、必应）

• 搜索结果排序方式（相关性、时间、热度）

选择正交表 L9(3^4)，生成以下测试用例：

测试用例	搜索引擎	排序方式1	排序方式2
1	百度	相关性	时间
2	百度	相关性	热度
3	百度	时间	热度
4	谷歌	相关性	时间
5	谷歌	相关性	热度
6	谷歌	时间	热度
7	必应	相关性	时间
8	必应	相关性	热度
9	必应	时间	热度

优点：

• 能够用较少的测试用例覆盖大部分参数组合。

• 适用于参数较多的场景。

缺点：

• 需要一定的统计学知识来选择正交表。

• 不适合处理参数之间的强依赖关系。

3.2.5 场景法

定义：
场景法是一种基于业务流程的测试用例设计方法，通过模拟用户在实际场景中的操作步骤，设计测试用例。

步骤：

1. 识别业务流程：明确系统的主要业务流程和分支流程。

2. 设计主场景：设计用户最常用的路径（主流程）。

3. 设计分支场景：设计用户可能遇到的异常或特殊路径（分支流程）。

4. 生成测试用例：将主场景和分支场景转化为测试用例。

示例：
假设有一个用户注册功能，主流程包括：

1. 用户输入用户名、密码和邮箱。

2. 系统验证输入信息。

3. 系统发送验证码到邮箱。

4. 用户输入验证码完成注册。

分支场景包括：

• 用户输入错误的邮箱格式。

• 用户输入的用户名已存在。

• 用户输入的验证码错误。

优点：

• 能够覆盖完整的业务流程。

• 贴近用户实际使用场景。

缺点：

• 需要对业务流程有深入理解。

• 可能遗漏一些边界条件。

3.2.6 错误猜测法

定义：
错误猜测法是一种基于经验和直觉的测试用例设计方法，测试人员根据经验和对系统的理解，猜测可能存在的错误，并设计测试用例来验证这些猜测。

步骤：

1. 分析系统功能：了解系统的主要功能和可能的薄弱环节。

2. 列出可能的错误：根据经验猜测可能存在的问题。

3. 设计测试用例：针对每个猜测的错误设计测试用例。

示例：
假设有一个文件上传功能，可能的错误猜测包括：

• 文件大小超过限制。

• 文件格式不支持。

• 上传过程中网络中断。

针对这些猜测，设计以下测试用例：

1. 上传一个超过限制大小的文件。

2. 上传一个不支持格式的文件。

3. 在上传过程中断开网络连接。

优点：

• 灵活性高，可以根据经验快速发现问题。

• 适用于探索性测试。

缺点：

• 依赖测试人员的经验，可能遗漏问题。

• 缺乏系统性。

3.3 其他案例

3.3.1 针对命令行编写测试用例

场景：
假设有一个命令行工具，用于复制文件，命令格式为：
copy <源文件> <目标文件>

测试用例设计：

1. 正常情况：

   • copy file1.txt file2.txt（成功复制文件）。

2. 边界情况：

   • 源文件不存在。

   • 目标文件路径无效。

   • 源文件和目标文件相同。

3. 异常情况：

   • 源文件无读取权限。

   • 目标文件无写入权限。

   • 磁盘空间不足。

4. 参数验证：

   • 命令格式错误（如 copy file1）。

   • 参数数量不足。

优点：

• 能够全面覆盖命令行工具的各种输入情况。

• 适合验证命令行工具的健壮性。

3.3.2 针对接口编写测试用例

场景：
假设有一个用户登录接口，接收用户名和密码，返回登录状态。

测试用例设计：

1. 正常情况：

   • 输入正确的用户名和密码（登录成功）。

2. 边界情况：

   • 用户名或密码为空。

   • 用户名或密码长度超过限制。

3. 异常情况：

   • 输入错误的用户名或密码（登录失败）。

   • 用户被禁用或不存在。

   • 密码错误次数过多导致账户锁定。

4. 性能测试：

   • 并发登录请求的处理能力。

5. 安全测试：

   • 防止SQL注入攻击。

   • 防止暴力破解。

优点：

• 能够验证接口的正确性和健壮性。

• 适合自动化测试。

这些方法可能在有些时候并不会用到，但能够作为我们设计测试用例的参考，提高我们设计测试用例的思维。