当前位置：首页 > news >正文

软件测试学习笔记丨测试用例设计方法

news 2025/10/31 22:47:39

本文转自测试人社区，原文链接：https://ceshiren.com/t/topic/31921

一，黑盒测试方法论

1，等价类

1.1 定义

等价类划分是一种重要的、常用的黑盒测试方法
不需要考虑程序的内部结构，只需要考虑程序的输入规格即可
它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性
用户所有可能输入的数据，划分成了若干个子集，然后从每一个子集当中选取少数具有代表性的数据作为测试用例
在有限的测试资源的情况下，用少量有代表性的数据得到比较好的测试效果

1.2 等价类分类

有效等价类：指符合《需求文档》，输入合理的数据集合
无效等价类：指不符合《需求文档》，输入不合理的数据集合

1.3 设计步骤

先划分等价类：找出所有可能的分类
确定有效等价类：需求中的条件
确定无效等价类：与条件相反的情况，再找到特殊情况
从各个分类中挑选测试用例数据

2，边界值

2.1 定义

边界值分析法是一种很实用的黑盒测试用例方法，它具有很强的发现故障的能力
边界值分析法是作为对等价类划分法的补充，测试用例来自等价类的边界

2.2 边界值确定

上点：边界上的点
离点：离上点最近的点
内点：在输入域内任意一个点
选取正好等于、刚好大于或刚好小于边界值作为测试数据

2.3 边界值总结

确定边界情况
选取正好等于、刚刚好大于或刚刚好小于边界值作为测试数据
确定各个值的等价类

3，判定表

3.1 定义

因果图只是一种辅助工具，通过分析最终得到判定表，再通过判定表编写测试用例
画因果图非常麻烦，影响测试效率，可以直接写判定表，进而编写测试用例

3.2 组成

条件桩：问题的所有条件
动作桩：问题的所有输出
条件项：针对条件桩的取值
动作项：条件项的各种取值情况下的输出结果

3.3 设计步骤

列出所有的条件桩和动作桩
确定规则数：条件取值个数^条件数
填入条件项
填入动作项。得到初始判定表
简化判定表

4，场景法

4.1 定义

场景法就是模拟用户操作软件时的场景，主要用于测试系统的业务流程
- 基本流：按照正确的业务流程来实现的一条操作路径
- 备选流：导致程序出现错误的操作流程

4.2 用例设计步骤

根据需求规格说明，画出功能模块流程图；
根据流程图，描述出程序的基本流及备选流；
根据基本流和备选流生成不同的场景，构造场景列表；
对每一个场景生成相应的测试用例；
对生成的所有测试用例重新复审，去掉多余的测试用例；
测试用例确定后，为每一个测试用例确定测试数据值

5，因果图

5.1 定义

因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法
它适合于检查程序输入条件的各种组合情况
- “因” —— 输入条件
- “果” —— 输出结果

5.2 适合场景

描述多种条件的组合
产生多个动作

5.3 因果图中的基本符号

恒等：若原因出现，则结果出现；若原因不出现，则结果也不出现
非：若原因出现，则结果不出现；若原因不出现，则结果出现
或：有多个原因。若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现
与：有多个原因。若几个原因都出现，则结果才出现；若其中一个原因不出现，则结果不出现

5.4 因果图中的约束条件

互斥 E：a、b、c 只能有一个成立，但是可以都不成立
包含 I：a、b、c 中至少有一个成立
唯一 O：a、b、c 有且仅有一个成立
要求 R：如果 a 成立，则要求 b 必须也成立，其他的不约束
屏蔽 M：如果 a 成立的时候，强制 b 不成立，其他的不约束

5.5 因果图法基本步骤

找出所有的输入条件（因）
找出所有的输出条件（果）
明确所有输入条件之间的制约关系以及组合关系
明确所有输出条件之间的制约关系以及组合关系
找出什么样的输入条件组合会产生哪种输出结果
把因果图转换成判定表
为判定表中的每一列表示的情况设计测试用例

6，正交法

6.1 定义

简介
正交法(0rthogonalArray)是一种设计实验方案和测试用例的统计方法，旨在通过有限次试验来研究多个因素对结果的影响，同时尽可能减少试验次数。正交法的主要特点是通过一种合理的方式选择一组试验参数的组合，以实现对所有可能的参数组合进行有效的覆盖，从而节省试验资源和成本。

正交法的核心思想是在所有可能的因素组合中，选择一组互相正交的因子水平组合，以尽可能少的试验次数来观察所有因素的影响。

正交表是一种特制的表格，一般用 Ln(m^k)表示，L代表是正交表，n代表试验次数或正交表的行数，k代表最多可安排影响指标因素的个数或正交表的列数，m 表示每个因素水平数。

其中，因素是影响试验结果的一个变量或因素，可以是独立变量、处理水平或参数。因素可以是产品的属性、工艺参数、环境条件等。水平是每个因素可能的取值或状态。例如，一个因素可以有多个不同的水平，如高、中、低等。

6.2 使用场景及操作步骤

使用场景

多参数系统：当系统具有多个输入参数，而且这些参数之间存在相互影响时，正交法特别有用。
多条件覆盖：当需要覆盖不同的条件组合，以测试系统在不同情况下的行为。
资源有限：当测试资源有限，需要在较小的测试用例集中获得尽可能广泛的覆盖。

常用正交表

正交表根据参数数量和取值范围的不同，有多种等级和类型可供选择。选择适当的正交表可以有效地设计测试用例，覆盖各种参数组合，以达到最佳的测试覆盖和效率

操作步骤
1.确定测试参数和取值范围:识别系统的输入参数和条件。这可能包括各种参数、设置、状态等。
2.确定正交表和参数等级:根据参数数量和取值范围，选择合适的正交表
3.设计正交表:使用正交表工具，根据系统的输入参数和条件构建正交表，
4.生成测试用例:从正交表中选择测试用例，以覆盖尽可能多的参数组合。确保所选用例能够测试系统的各个方面。

7，基于模型的测试

二，测试用例设计

1，用例组成（以我测过的项目为例）

需求名称
一级模块
二级模块
用例标题
优先级
前提条件
测试步骤
期望结果（预期结果）

2，用例设计方法的选择

任何情况下，都需要采用等价类划分法，将无限测试变成有限测试
在规定了数据范围的情况下，必须采用边界值分析法
如果需要关注它的主要功能和业务流程、业务逻辑是否正确实现，考虑使用场景法
如果含有输入条件的组合情况，考虑选用因果图和判定表法
采用错误推断法再追加测试用例

3，测试用例编写步骤

划分功能模块
正向功能验证
单个功能项验证
功能之间交互验证
隐形需求

4，测试用例的粒度

测试用例可以写的很简单，也可以写的很复杂
最简单的测试用例是测试的纲要，仅仅指出要测试的内容
测试用例写的过于简单，则可能失去了测试用例的意义
测试用例写得过于复杂或详细，会带来两个问题：
- 效率问题
- 维护成本问题

5，用例评审

测试用例的本身的描述是否清晰，是否存在二义性
测试用例内容是否正确，是否与需求目标相一致
测试用例的期望结果是否确定、唯一
测试用例是否覆盖了所有的需求
测试用例是否具有可执行性
是否从用户层面来设计用户使用场景和业务流程的测试用例
场景测试用例是否覆盖最复杂的业务流程
用例设计是否包含了正面、反面的用例

三，面试测试用例设计

1，设计思路

需求分析
- 明确需求
- 和面试官交流需求细节
界面
- 页面布局设计和产品原型图一致
- 页面文案正确
功能
- 正向功能验证
- 单个功能项验证
- 功能之间交互验证
- 接口验证
易用性
- 功能操作是否简便
- 页面布局是否美观合理
- 提示语相关信息是否易于理解
兼容性
- APP
  - 平台
  - 厂商
  - 系统版本
  - 屏幕大小与分辨率
- WEB
  - 浏览器
  - 操作系统
  - 分辨率
性能
- 服务器性能测试
- APP 客户端性能测试
安全性
- 注入攻击
- 加密
- 权限
- APP 测试要点
  - 网络
  - 中断
  - 系统权限
- WEB 测试要点
  - 链接测试
  - 多个浏览器同时访问

四，白盒测试方法

1，白盒测试的度量

根据待测产品的内部实现细节来设计测试用例
白盒测试的执行手段是可以涵盖单元测试、集成测试
使用代码覆盖率作为白盒测试的主要度量指标

2，代码覆盖率常见概念

语句覆盖：每行代码都要覆盖至少一次
判定覆盖：判定表达式的真假至少覆盖一次
判定/条件覆盖：判定覆盖与条件覆盖都必须覆盖
条件组合覆盖：判定表达式中的所有条件组合都需要覆盖
分支覆盖：控制流中的每条边都要被覆盖一次
路径覆盖：所有的路径都要尽量覆盖
指令覆盖：一行代码会被编译为多条指令，尽可能的覆盖所有指令
方法覆盖：每个方法至少要被覆盖一次
类覆盖：每个类至少被覆盖一次

3，覆盖率统计的工具

emma
cobertura
jacoco

4，插桩原理

对jvm的字节码插桩
基于block插桩
计算覆盖的代码块

5，流程覆盖

利用代码执行流代表流程
流程覆盖用路径覆盖率表达
对流程进行裁剪获得一个适合业务的小规模的业务子集
流程覆盖率=测试经过的路径/业务子集路径

6，精准化测试

代码调用链与黑盒测试用例的关联
根据代码变更自动分析影响范围
黑盒测试过程中借助代码流程覆盖数据指导探索式测试
利用线上数据推导有效测试用例
代码流程分析与覆盖率统计