『测试』测试用例设计的核心方法与技巧_新系统姓名字段该怎么测试-CSDN博客

本文链接：https://blog.csdn.net/2202_75303754/article/details/148446071

文章目录

1 测试用例的概念

测试用例是为了验证软件系统的某个功能, 特性或需求是否符合预期而设计的一组具体步骤, 条件和预期结果的文化描述, 它是测试过程中的核心组成部分, 通常包括测试环境, 操作步骤, 测试数据, 预期结果等要素;

在编写测试用例的过程中, 每个用例需要给出这些要素对应的信息;

在过去通常使用Excel来管理一个测试用例, 其样式如下

用例编号	TC-REG-001
标题	验证通过电子邮箱成功注册新账户
测试方法	手动功能测试
功能模块	用户注册模块
重要性	高
测试前提	1. 测试环境网络正常 2. 邮箱服务可用 3. 测试邮箱未注册过账户
测试环境	Chrome 115+ Windows 11 21H2
测试数据	测试邮箱: testuser_{当前时间戳}@example.com 密码: ValidPass123! 确认密码: ValidPass123!
测试步骤	1. 访问注册页面 2. 在邮箱字段输入测试数据邮箱 3. 在密码字段输入测试数据密码 4. 在确认密码字段重复输入密码 5. 点击【立即注册】按钮
期望结果	1. 页面跳转至注册成功引导页 2. 页面显示「验证邮件已发送至您的邮箱」提示 3. 收到包含激活链接的系统邮件（5分钟内） 4. 用户表新增状态为「未激活」的记录 5. 密码字段存储为加密散列值（非明文）

目前大部分来设计/编写测试用例通常使用思维导图的方式来进行;

在笔试过程中通常使用Excel的方式来答题, 而在面试过程中通常需要使用思维导图的方式来答题;

在测试之前通常需要设计测试用例, 主要原因是单纯的依靠头脑风暴无法完成一次完整的测试;

而通过某些方法编写/设计测试用例可以让测试过程中实际测试的功能覆盖更高;

通过全面的测试可使得不会将项目/软件中太多的问题暴露给用户从而避免用户的使用过程中体验感降低;

2 设计测试用例的思想

在设计测试用例的过程中, 其思想主要包括以下三点:

常规思考
逆向思维
发散性思维

在设计测试用例中通常有几个原则:

原则一

测试用例中一个必须部分是对预期输出或结果进行定义;
原则二

设计测试用例时主要思考到的情况是三种情况, 即有效情况, 无效情况以及边界/异常情况;

即考虑产品是否做了其应该做的, 以及其是否做了其不应该做的;

例如, 以一个水杯为例, 在水杯可以正常装水, 倒水以及喝水等功能的情况下, 其在杯中没有水的状态下如果能倒出水那么是否是一个错误;

同时在计划测试工作时不应默许假定不会发现错误;

3 万能公式

设计测试用例的万能公式为:

功能测试 + 界面测试 + 性能测试 + 兼容性测试 + 易用性测试 + 安全测试

根据不同的产品, 可能还会涉及到弱网测试以及安装卸载测试;

即:

以上述的万能公式再次为水杯进行一个测试用例的设计:

Ps: 上述测试用例只演示部分

3.1 弱网测试与安装卸载测试

弱网测试

通常一个网页或者是一个软件通常需要具备弱网功能, 即在弱网环境中使得页面不崩溃;

而弱网测试则是模拟弱网环境下对产品的访问来判断其功能是否能正常运行;

其包括:
- 页面响应时间是否可以接受
  
  关注点包括:
  - 热启动时间
  - 冷启动时间
  - 页面切换
  - 前后台切换
  - 首字时间
  - 首屏时间
  - …
- 页面呈现是否完全一致
- 超时文案是否符合定义与异常信息是否显示正常
- 是否有超时重连
- 安全角度
  - 是否会发生DNS劫持
  - 登录IP更换频繁
  - 单点登录异常
  - …
- 大流量事件风险
  
  是否会在弱网下进行更新apk包, 下载文件等大流量动作;
通常弱网情况下的测试需要通过工具来构造弱网环境, 可使用Fiddler;

在使用Fiddler构造弱网环境时, 可根据过滤器来选择指定需要抓包的域名;

并进行以下操作:
1. Ctrl + r打开Fiddler ScripEditor;
2. 通过Ctrl + f查找m_SimulateModem;
3. 修改上行/下行速率;
  
  其中
```
// Delay sends by 300ms per KB uploaded.
// 每上传 1KB 延迟发送 300 毫秒
            oSession["request-trickle-delay"] = "300"; 
            // Delay receives by 150ms per KB downloaded.
// 每下载 1KB 延迟发送 150 毫秒
            oSession["response-trickle-delay"] = "150"; 
```
  即为上行速率与下行速率的修改;
4. 修改完毕后通过Ctrl + s对编辑进行保存;
5. 通过点击Rules > Performance > Simulate Modem Speeds选项进行勾选打开弱网环境;
6. 进行测试;
7. 关闭时只需要再次通过通过点击Rules > Performance > Simulate Modem Speeds选项进行取消勾选关闭弱网环境;
安装卸载测试

通常安装卸载测试通常用于测试安装于卸载的完整性;
- 安装
  1. 安装包是否可以安装
  2. 卸载后是否可以继续安装
  3. 是否可以重复安装
  4. 更新后是否可以重复安装
  5. 安装中途取消后是否可以继续安装
  6. …
- 卸载
  1. 安装完成后是否可以卸载
  2. 安装完成后使用一段时间是否可以卸载
  3. 卸载中途取消后是否可以继续卸载
  4. …

4 设计测试用例的方法

4.1 基于需求的设计方法

通常在企业中, 可能会用到的测试用例的设计方法是基于需求的设计方法, 其中需求指的是产品中的产品需求/需求文档/产品规格说明书来对产品进行测试用例的设计;

通常情况下, 测试和开发工作展开的依据是所谓的软件需求;

在前文中提到, 需求通常有两种:

用户需求
软件需求

用户需求经过需求评审, 需求分析等步骤转变为软件需求, 在需求分析等过程中产品经理将会产出一系列的产品规格说明书,

在设计测试用例中, 测试人员需要对需求进行分析和验证, 从合理的需求中进一步的细化需求, 测试人员需要从需求中找出测试点, 再通过找出的测试点去设计合理的测试用例;

假设存在需求文档(实现用户注册功能)

1.1.1.1 注册账号
1.1.1.1.1 功能概述
1.1.1.1.1.1 匿名用户通过邮箱注册账户,需激活后登录

1.1.1.1.2 输入规则

字段名称	必填性	长度/位数	格式要求	附加规则
姓名	必填	6~15字符	汉字/字母/空格	-
邮箱	必填	-	标准邮箱格式	格式错误时提示
密码	必填	6~15字符	字母+数字组合	两次输入不一致时提示
验证码	必填	6位数字	纯数字	邮箱发送,有效期5分钟

1.1.1.1.3 处理规则 1.1.1.1.3.1 用户同意协议后填写信息,提交时校验字段合法性: 1.1.1.1.3.1.1 校验失败: 高亮错误字段并提示原因 1.1.1.1.3.1.2 校验成功: 发送含24小时有效激活链接的邮件

1.1.1.1.4 异常规则
1.1.1.1.4.1 未收到激活邮件: 登录界面可重新发送,每邮件限24小时有效

1.1.1.1.5 数据规则
1.1.1.1.5.1 存储表user_account,含user_id（自增主键）、email（唯一）、is_activated（默认false）
1.1.1.1.5.2 密码SHA-256加盐存储,激活链接含一次性Token

1.1.1.1.6 后置条件
1.1.1.1.6.1 未激活账户禁止登录及操作系统功能

通过上文的需求文档进行测试用例的设计可使用上文中提到的万能公式, 即包括功能测试, 性能测试, 界面测试, 兼容性测试, 易用性测试, 安全测试以及弱网测试进行测试用例的设计;

同样该用例为演示, 并不完整;

通常通过根据需求文档设计测试用例进行初步的测试用例设计, 但该方法并不能涵盖所有的测试用例或者并不是特别全面, 因此需要使用具体的设计方法来细化/补充测试用例, 使得其能够更加完善;

4.2 具体的设计方法

单纯的依靠"基于需求的设计方法"来设计测试用例并不能很好的完善或者照顾到某个细节;

同时在测试过程中, 测试人员应该测试产品是否做了其应该做的, 也同时需要测试产品是否做了其不应该做的;

就如上文中提到的需求文档(实现用户注册功能)来说, 其中1.1.1.1.2 输入规则部分的表格中出现了四个必填的项目, 而在测试用例的设计中需要测试四项必填项目是否为必填, 如果单纯的以穷举方式进行测试用例的设计的话, 那么这里需要设计 2⁴ 个用例;

测试用例ID	姓名	邮箱	密码	验证码
TC-001	填	填	填	填
TC-002	填	填	填	不填
TC-003	填	填	不填	填
TC-004	填	填	不填	不填
TC-005	填	不填	填	填
TC-006	填	不填	填	不填
TC-007	填	不填	不填	填
TC-008	填	不填	不填	不填
TC-009	不填	填	填	填
TC-010	不填	填	填	不填
TC-011	不填	填	不填	填
TC-012	不填	填	不填	不填
TC-013	不填	不填	填	填
TC-014	不填	不填	填	不填
TC-015	不填	不填	不填	填
TC-016	不填	不填	不填	不填

这种方式大大加大了测试人员的工作量, 并且可能出现因冗余的测试导致测试时间花的太多, 更何况在某些产品中因为测试项数量较多因此无法穷举测试;

因此需要用一些具体的设计方式来规划和细化较为粗糙的设计方式;

4.2.1 等价类

所谓的等价类为将输入或者输出(特殊情况考虑)划分为若干个等价类, 从等价类中挑选一个测试用例进行测试, 如果被挑选出来的测试用例通过测试则代表该测试用例的所有等价类都通过, 通过这种方式可通过较少的测试用例来尽可能的覆盖功能进行测试;

假设对一个奇偶数分类的函数进行测试, 测试其是否能测试奇偶数的分类;

在测试过程中这里一共有两种等价类, 分别为奇数与偶数, 在取较少数量的奇数进行测试后发现测试结果正确则说明该用例等价类的其他测试用例(奇数)均通过测试;

再将上文中的需求文档中的姓名为例, 其中姓名的要求为如下:

其中要求长度为6~15个字符, 同时在上文中提到, 在测试过程中, 需要测试功能是否做了其应该做的, 在这里指当长度再6~15字符时能否注册成功, 同时也需要测试其是否做了其不应该做的, 即姓名字段长度若是输入<6 || >15时是否会注册成功, 在这里这个区间以外的数量为∞, 因此无法直接使用穷举法进行测试用例的设计;

等价类分为两种, 分为有效等价类与无效等价类两类;

有效等价类

对于规格说明书是合理的, 有意义的输入数据构成的集合, 利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能;

产品/功能是否做了其应该做的, 称为有效等价类;
无效等价类

根据规格说明书中不满足需求的集合;

产品/功能是否做了其不应该做的, 称为无效等价类;

同样以上文的"姓名"举例, 要求说明长度为6~15个字符, 那么有效等价类即为长度为[6, 15]这个区间长度的字符串, 而无效等价类则是不属于这个区间的长度的字符串;

将该例子通过等价类法进行测试用例的设计, 那么将能得到下列用例:

但等价类法同样有缺点, 最大的缺点就是等价类只考虑输入域的分类, 没有考虑输入域的组合, 需要其他的设计方法和补充;

就以上文例子为例, 在该节内容中, 只举例了"姓名", 但未举例其他内容的组合(不关心各个组合之间的交互影响), 如:

姓名和验证码的组合
姓名和邮箱的组合
…

4.2.2 边界值分析法

边界值分析法是一种黑盒测试技术, 专注与测试输入或输出的边界值, 通过观察输入/输出范围边界值来判断程序/功能是否有误(某些情况下, 程序员可能会将边界值的>符号误写成>=等类似情况导致出现因边界而出现的错误);

同时边界值分析分析法是对等价类分类法的一种补充;

边界值通常包含两种, 即边界值与次边界值, 当边界值与等价分类法配合使用时, 边界值与次边界值也含有有效等价类与无效等价类的属性;

同样以上文中的姓名字段作为举例, 姓名字段中长度为6-15, 那么假设两种情况, 即开区间与闭区间;

(6, 15)

在该例子的开区间中, 边界值为6与15(无效), 次边界值为7与14(有效);

对应的边界值为无效等价类的边界, 次边界值为有效等价类的边界;
[6, 15]

在该例子的闭区间中, 边界值为6与15(有效), 次边界值为5与16(无效);

对应的边界值为有效等价类的边界, 次边界值为无效等价类的边界;

同样的对上文中的姓名案例进行测试用例的补充, 通过边界值与次边界值设定具体的用例, 那么结果为如下;

4.2.3 场景法

目前市场上大部分的软件/产品都是基于流程进行交互的, 通过不同的事件触发控制整体流程, 同一事件的不同触发顺序和处理结果形成了事件流;

事件触发时情景变成了场景, 场景法的核心是以用户视角覆盖正常, 异常和关键业务流程;

对应的, 不同的操作将会成为不同的事件流;

事件流分为两种, 分别为基本流与备选流;

在这个例子中存在一条基本流和两条备选流;

较为清晰的图例为如下:

场景法主要包括四种主要的类型, 分别为: 正常的用例场景, 备选的用例场景, 异常的用例场景, 假定推测的场景;

根据场景法设计测试用例的步骤为如下:

确定基本流
确定备选流
根据备选流补充测试用例
编写测试用例

在上文中的 "4.1 基于需求的设计方法"中已经存在了一个简单的基本事件流, 可通过这个基本事件流使用场景法设计对应的测试用例, 如下:

Ps: 该场景设计可能不全面, 仅为参考;

通过该场景设计可设计出以下测试用例:
- 场景 1: 正常注册流程
  - 步骤:
    1. 用户访问注册页面
    2. 用户同意用户协议
    3. 用户正确填写姓名（格式正确）、邮箱（格式正确）、密码, 并且两次输入的密码一致
    4. 点击发送验证码, 系统成功发送 6 位验证码
    5. 用户正确输入验证码并提交, 验证码校验通过
    6. 系统生成未激活账户, 并发送激活链接邮件
    7. 用户查收邮箱, 点击激活链接, 链接有效, 账户激活成功
  - 预期结果: 完成注册, 账户激活成功
- 场景 2: 不同意用户协议
  - 步骤:
    1. 用户访问注册页面
    2. 用户选择不同意用户协议
  - 预期结果: 返回注册页面, 无法继续进行注册流程
- 场景 3: 密码不一致
  - 步骤:
    1. 用户访问注册页面
    2. 用户同意用户协议
    3. 用户填写姓名、邮箱,两次输入的密码不一致
  - 预期结果: 系统提示 “两段密码内容不相同”,用户需重填密码字段
- 场景 4: 姓名字段格式不正确
  - 步骤:
    1. 用户访问注册页面
    2. 用户同意用户协议
    3. 用户填写的姓名字段格式不正确（如包含特殊字符等不符合要求的格式）
  - 预期结果: 系统提示 “姓名字段格式不正确”, 用户需重填姓名字段
- 场景 5: 邮箱格式错误
  - 步骤:
    1. 用户访问注册页面
    2. 用户同意用户协议
    3. 用户填写的邮箱格式错误（如缺少 @ 符号、无域名等）
  - 预期结果: 系统提示 “提示邮箱格式错误”, 用户需修正邮箱格式
- 场景 6: 发送验证码出现问题
  - 步骤:
    1. 用户访问注册页面
    2. 用户同意用户协议
    3. 用户正确填写姓名、邮箱、密码
    4. 点击发送验证码,出现网络错误、延迟或发送次数过多等情况
  - 预期结果: 系统提示相应错误信息, 用户需稍后重试发送验证码
- 场景 7: 验证码输入错误
  - 步骤:
    1. 用户按照正常流程操作,成功获取验证码
    2. 用户输入错误的验证码并提交
  - 预期结果: 系统提示 “验证码字段校验有错误”, 并高亮错误提示原因, 用户需重新输入验证码
- 场景 8: 激活链接相关问题
  - 步骤:
    1. 用户完成前面注册步骤, 系统发送激活链接邮件
    2. 出现以下几种情况:
    - 用户未收到邮件,点击 “未收到邮件” 选项, 系统提示 “发送次数过多（暂时锁定账户）”, 需等待解锁
    - 用户收到邮件, 点击激活链接, 但链接无效或过期
  - 预期结果:
    - 对于未收到邮件且发送次数过多的情况,系统提示相应信息并暂时锁定账户, 用户需等待解锁后再重新发送激活邮件
    - 对于链接无效或过期的情况, 系统提示 “链接无效 / 过期”, 用户需重新进行注册流程获取新的激活链接

通常情况下, 在工作中场景法通常用来进行需求评审与设计测试用例;

4.2.4 正交表法

正交表是一种基于统计学的实验设计工具, 用于在多因素多水平组合中, 通过有限次实验均衡覆盖所有可能组合, 即:

为了减少用例数目, 用尽量少的用例覆盖输入的两两组合

正交表的数学表达式为 L_n(q^s);

L 表示正交表
n 表示测试用例的总数
q 表示每个因素的取值数量(水平数)
s 表示因素的个数

如图所示, 该图为一个较为简单的正交表, 即**L₄(2³)**正交表, 其中L表示正交表, 4表示行号总共有四行, 即四次实验, 3表示有三纵列, 即最多允许安排的因素是3, 2表示主要的部分只有两种数字, 即因素有两种水平(1 || 2);

其中因素指对指标的影响条件, 通常是正交表中的一列;

水平位因素对应的可选项, 以上文中的1.1.1.1.2 输入规则为例, 虽然为必填项, 但站在用户的角度来看每个因素只有两个选择, 即为**“填 || 不填”**;

正交表的特点是:

“均匀分散, 整齐可比”
1. 每一列中, 不同的数字出现的次数相等;
  
  从上图可以看出, 在每一列中, 每个水平所出现的次数相同, 即数1与数2所出现的频率一致;
2. 任意两列中数字的排列方式齐全且均衡;
  
  从上图可以看出, 任意两列对应的排列组合分布均匀;

在测试过程中使用正交表法进行测试用例的设计, 通常具有以下优点:

精简测试规模

通过数学优化大幅减少冗余用例;
保证覆盖率

确保所有因素的两两组合至少被覆盖一次从而降低漏测风险;
发现交互缺陷

识别不同因素间的相互影响;
支持复杂场景

适用于多因素混合水平场景;

根据正交表的性质, 一般人很难通过手动设计出正交表, 因此在设计正交表时可以通过一些工具来完成;

4.2.4.1 通过工具设计正交表

在设计正交表时, 可以使用工具Allpairs设计正交表, 其设计流程为如下:

找到因素和水平
通过ALLpairs生成正交表
将因素和水平写入Excel表格中

在ALLpairs的目录下新建新的.txt后缀文本文件, 复制Excel中的因素和水平

保存并退出(Excel为临时使用, 可以不用保存, 文本文件需要保存)
使用ALLpairs命令生成正交表(假设文本文件名为test.txt)
allpairs.exe test.txt > orthogonal.txt
根据正交表编写测试用例

补充遗漏的重要的测试用例

以上文提到的1.1.1.1.2 输入规则的测试为例;

字段名称	必填性	长度/位数	格式要求	附加规则
姓名	必填	6~15字符	汉字/字母/空格	-
邮箱	必填	-	标准邮箱格式	格式错误时提示
密码	必填	6~15字符	字母+数字组合	两次输入不一致时提示
验证码	必填	6位数字	纯数字	邮箱发送,有效期5分钟

确定因素与水平

首先必填项目有四个, 那么对应的因素的个数就是四个, 分别为姓名, 邮箱, 密码和验证码;

其次是每个因素的水平有两个, 分别为填/不填;

使用ALLpairs生成正交表

确定了因素和水平数后即可以在Excel中开始设计该工具需要的因素与水平, 并将Excel中所填写的内容复制粘贴至.txt中, 并保存.txt文件;
在ALLpairs目录下打开cmd命令行, 并通过命令生成正交表;

对应的文件中所生成的文件中的内容的TEST CASES部分即为生成的正交表;

可将该部分复制到Excel表格中方便查阅;

同样采用复制粘贴的方式, 即复制对应的TEST CASES部分, 并粘贴到Excel的随机单元格中, 内容将自动展开为表格内容;

case	姓名	邮箱	密码	验证码	pairings
1	填写	不填写	不填写	填写	6
2	填写	填写	填写	不填写	6
3	不填写	不填写	填写	填写	5
4	不填写	填写	不填写	不填写	5
5	~填写	不填写	~不填写	不填写	1
6	~填写	填写	~填写	填写	1

该表格即为通过ALLpairs工具所生成的对应的正交表;

在该正交表的结果存在一个带波浪号的选项, 即"~填写", 该选项代表该位置的值与其他用例中的某个值组合等价;

通过该正交表所涉及的测试用例为如下:
1. 姓名填写, 邮箱不填写, 密码不填写, 验证码填写
2. 姓名填写, 邮箱填写, 密码填写, 验证码不填写
3. 姓名不填写, 邮箱不填写, 密码填写, 验证码填写
4. 姓名不填写, 邮箱填写, 密码不填写, 验证码不填写
5. 姓名填写/不填写, 邮箱不填写, 密码填写/不填写, 验证码不填写
6. 姓名填写/不填写, 邮箱填写, 密码填写/不填写, 验证码填写

但该正交表并不全面, 从整体的结果来看可以看出在该正交表中遗漏了较为重要的几个层面, 即全填写与全不填, 加上这两个用例后总数是8个测试用例;

因此在使用ALLpairs设计完正交表与通过正交表设计测试用例后, 需要继续对重要的测试用例补全;

原先需要设计的测试用例的个数为2⁴, 即16个, 而此处通过正交表所涉及出来的测试用例的结果为8个, 通过较少的用例来覆盖更多的可能性以提高测试的覆盖范围;

同时通过ALLpairs所设计的正交表与实际的正交表有稍微出入, 即不一定能完全的符合上文所提到的"正交表特点";

4.2.5 判定表法

判定表是一种用来表达逻辑判断的工具, 通过判断表能够将所有条件对应的结果较为清晰的表达出来, 它通过表格形式, 清晰展示不同输入条件下系统的预期行为;

假设一个需求如下
1. 无法通话与联网（同时禁用）
  
  话费欠费（无论流量/通话是否用尽）
  
  流量与通话时长 同时用尽（仅限话费正常时）
2. 仅无法联网（通话正常）
  
  流量用尽，但通话时长充足且话费正常
3. 仅无法通话（联网正常）
  
  通话时长用尽，但流量充足且话费正常
4. 功能正常
  
  话费正常，且流量/通话均未用尽
其中逻辑优先级为：话费状态 > 流量/通话组合状态

那么对应的判定表为如下:

Ps: 单纯举例, 并未写全

通常通过判定表设计测试用例的步骤为如下:

确认需求中输入条件和输出条件
找出输入条件和输出条件之间的关系
画判定表
根据判定表编写测试用例

以上述例子为例设计测试用例, 只需要根据所设计的判定表进行设计对应的测试用例即可, 即:
- 话费用尽, 流量用尽, 通话时长用尽, 无法通话与联网
- 话费用尽, 流量用尽, 无法通话与联网
- 话费用尽, 通话时长用尽, 无法通话与联网
- …