【软件测试】测试用例设计与编写详解

卜及中

8396人浏览 · 2025-08-12 12:49:53

卜及中 · 2025-08-12 12:49:53 发布

一、测试用例

1. 概念

测试用例（Test Case） 是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
设计测试用例原则一:

测试用例需要对预期输出或结果进行定义
什么是要素?在编写测试用例的时候，每个用例需要给出这些要素对应的信息。

2. 软件测试用例示例（登录功能）

用例编号	TC_LOGIN_001
标题	验证用户输入正确用户名和密码是否能成功登录
测试方式	手动测试
功能模块	用户登录模块
重要性	高
测试前提	1. 系统已正常启动 2. 已注册有效用户账号
测试环境	Windows 10，Chrome 116，后端服务已部署完毕
测试数据	用户名：`test_user` 密码：`correct_password123`
测试步骤	1. 打开登录页面 2. 输入用户名 `test_user` 3. 输入密码 `correct_password123` 4. 点击“登录”按钮
期望结果	成功跳转到系统首页，显示欢迎信息“欢迎 test_user”，并保存用户登录状态（如设置 Cookie 或 Token）

3. 为什么需要测试用例

为什么需要测试用例？不写测试用例可以进行测试吗?

测试中可能会遇到很多问题，诸如：

不知道是否较全面的测试了所有功能
测试的覆盖率无法衡量
对新版本的重复测试很难实施（即回归测试无法仅通过人工测试的方式进行历史功能的回归）
存在大量冗余测试影响测试效率

测试用例的出现就是解决这些问题。

二、写测试用例的思路

1. 基本思路

正确设计测试用例的思路：常规思维+逆向思维+发散性思维

设计测试用例原则二:

测试用例应覆盖有效和预期的输入情况，同时也要考虑无效和未预料到的输入情况。
检查程序是否“未做其应做的”是成功的一部分，而另一部分是确认程序是否“做了不应做的”。（这是上一条原则的必然结果）
在计划测试工作时，不能假设不会发现错误。

2. 设计思路步骤

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

一般可以根据软件测试的分类，在设计用例时以此为参考进行设计：

设计测试用例的万能公式：功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全测试。

功能测试

功能测试旨在发现程序与外部规格说明之间的差异。 外部规格说明是从最终用户角度对程序行为的详细描述。功能测试通常采用黑盒测试方法。在进行功能测试时，需要分析规格说明并提炼出测试用例。

在实际工作中或面试中，可能会遇到需求不明确的情况。此时，可以采取以下策略：
- 查阅其他相关文档，帮助理解产品需要完成的目标。
- 积极参与项目组会议（如需求讨论、设计讨论、计划讨论等），加深对产品的理解。
- 召集相关人员讨论整理的文档，经过评审后，这份文档可作为设计测试用例的依据。
- 对于已上线的产品，可以通过实际使用产品来了解需求，若有疑问，可咨询产品经理。
- 查看历史 bug，了解可能需要特别关注的地方。
界面测试
界面测试需要验证软件界面上的所有内容，确保其符合设计要求。具体要求包括：
1. 整体界面测试
  检查界面实现是否与设计图一致。
2. 界面元素测试
  验证界面上的各个元素是否按照设计进行正确展示和功能实现。
3. 控件操作验证
  确保用户对控件的操作能触发预期的响应，且控件行为符合设计要求。
性能测试
与功能测试的区别在于：
- 功能测试验证"软件是否做了"
- 性能测试评估"软件做得好不好"
易用性测试
易用性测试的目标是验证产品是否具备简单易上手的特点。测试人员作为新用户，在未接触或安装过该产品的情况下，能否迅速理解并适应产品的使用流程。
兼容性测试
软件部署依赖硬件和软件环境；如微信可以在PC端打开，也可以在移动端打开；移动端又分为I0S系统和Android系统，且市面上手机又有不同的品牌、不同的机型、不同的版本。

软件是否能够在不同的环境下正确运行需要测试人员进行验证。

选取标准：
- 优先选择使用当前产品top级别的机型进行测试；实际在企业中，后台是可以获取到使用产品的机型，并以报表的形式统计在后台，供产品人员或其他人员制定策略参考。
- 选择主流的浏览器/机型进行测试
安全测试
安全测试与性能测试一样，涉及广泛的领域。常见的安全问题包括：
- 隐私数据明文显示，存在泄露风险。
- 参数未进行严格校验，导致SQL注入漏洞。
- 越权操作，普通用户能够执行管理员权限的功能。

除了上述的测试，也有弱网测试、安装卸载和升级测试

弱网测试

弱网测试的目的就是尽可能保证用户体验，关注的关键点包括：

页面响应时间是否可以接受，关注包括热启动、冷启动时间、页面切换、前后台切换、首字时间，首屏时间等。
页面呈现是否完成一致。
超时文案是否符合定义，异常信息是否显示正常。
是否有超时重连。
安全角度：是否会发生dns劫持、登陆ip更换频繁、单点登陆异常等。
大流量事件风险：是否会在弱网下进行更新apk包、下载文件等大流量动作。

在这里插入图片描述

进行弱网测试时，需要借助工具构造弱网环境，一般可以使用fiddler进行。

安装卸载和升级测试

安装和卸载测试是软件测试的重要组成部分，主要用于验证软件能否正确安装、运行、升级和卸载，确保用户在使用过程中不会遇到安装失败、卸载残留等问题。

安装测试（Installation Testing）
目标：验证软件能否在不同环境下正确安装并正常运行。

测试类型	测试项
安装流程测试	- 安装向导是否清晰、易用 - 是否支持自定义安装路径 - 是否允许用户选择安装组件（如附加工具、插件等）
环境兼容性测试	- 不同操作系统（Windows/macOS/Linux）下的安装 - 不同系统版本（如Win10/Win11）下的兼容性 - 不同硬件配置（如磁盘空间、内存）下的安装
权限测试	- 普通用户权限下能否安装（是否需要管理员权限） - 安装过程中是否请求合理的系统权限
异常情况测试	- 安装过程中断（如强制关闭、断电）后能否恢复 - 磁盘空间不足时是否有提示 - 是否检测并提示冲突软件（如杀毒软件拦截）
多语言支持测试	- 安装界面是否适配不同语言 - 安装路径是否支持非英文字符
静默安装测试	- 是否支持命令行安装（如 `setup.exe /silent`） - 是否支持批量部署（如通过组策略）

2. 卸载测试（Uninstallation Testing）
目标：验证软件能否完全卸载，不残留文件或影响系统稳定性。

测试类型	测试项
卸载流程测试	- 卸载向导是否清晰、易用 - 是否提供卸载选项（如保留用户数据/完全卸载）
卸载完整性测试	- 卸载后是否删除所有安装文件 - 是否清理注册表（Windows）或配置文件（macOS/Linux） - 是否删除桌面快捷方式、开始菜单项
用户数据测试	- 卸载时是否提示保留用户数据（如配置文件、缓存） - 卸载后用户数据是否被误删
异常情况测试	- 卸载过程中断后能否恢复 - 卸载后是否影响其他软件运行
残留检测	- 使用工具（如 Revo Uninstaller、IObit Uninstaller）检查残留文件 - 手动检查注册表、临时文件夹是否清理干净

3. 升级测试（Update Testing）
目标：验证软件能否正确升级，不影响现有数据和配置。

检查增量升级（补丁更新）是否正常
检查大版本升级（如v1.0 → v2.0）是否兼容旧数据
升级失败时是否回滚到旧版本

三、设计测试用例的方法

根据上文的设计测试用例思路介绍，如果对一个水杯设计测试用例可以有：

在这里插入图片描述

1. 基于需求的设计方法

基于需求的设计方法也是总体设计测试用例的方法，工作中一般需要参考需求文档/产品规格说明书来设计测试用例。

测试人员接到需求之后，要对需求进行分析和验证，从合理的需求中进一步分析细化需求，从细化的需求中找出测试点，根据这些测试点再去设计测试用例。以该注册邮箱账号需求为例设计测试用例。

对于下面的需求：

在这里插入图片描述

如果要设计测试用例，需要以下两步骤：

明确需求中的功能点
- 账号注册、登录
结合测试思路进行设计：

2. 具体设计方法

等价类

上述设计的测试用例，存在用例还未完全设计完成，如：“姓名必填，6~15位的字符类型”；这样一个具体的需求如何设计测试用例?

测试的时候如果通过穷举法来测试6位、7位、8位…14位，15位是否测试通过，效率显然是很慢的；也不符合企业测试要求的。等价类法就是为了解决这类问题。

根据需求将输入（在特殊情况下可能涉及输出）划分为若干个等价类，并从每个等价类中选择一个测试用例进行测试。如果该测试用例通过，则认为该等价类的测试通过。通过这种方式，可以用较少的测试用例覆盖尽可能多的功能，解决了穷举测试的困难。

生活中的等价类案例：

因材施教的例子：

在理想情况下，教师应根据每个学生的具体情况，定制个性化的学习方案。但由于学生数量众多，教师无法一一顾及，因此只能将学生划分为几个大类：

优等生：重点强调知识面的拓展和综合能力的提升；
中等生：注重基础知识的巩固，查漏补缺；
差等生：优先掌握重点知识，暂时跳过难点。

这种做法相当于将输入（学生的学习能力）划分为不同的等价类，教师通过这几类学生制定合适的教学方案，虽然不能覆盖所有学生的个性化需求，但能够有效提升教学效率。

等价类划分思路：
由于输入的集合是无穷的，无法对所有输入值进行穷举，因此需要通过等价类划分来简化测试：

有效等价类：根据程序规格说明书，定义合理且有意义的输入数据集合。通过有效等价类可以验证程序是否实现了规格说明中的功能和性能要求。
无效等价类：根据需求说明书，定义不符合要求的输入数据集合。无效等价类的测试用例可以帮助检查程序对不合法输入的处理。

等价类设计测试用例的步骤：

确定有效等价类和无效等价类：明确哪些输入是合法的（有效等价类），哪些输入是非法的（无效等价类）。
编写测试用例：基于等价类设计具体的测试数据，确保每个等价类都有代表性的测试用例进行验证。

练习：根据边界值完善测试用例

假设有一个字段“姓名”，要求输入字符长度为6到15位。

有效等价类：
- 输入长度为6至15个字符，例如：10个字符
无效等价类：
- 输入长度小于6个字符，例如：1个字符
- 输入长度大于15个字符，例如：20个字符

对于每个情况：

长度测试：
- 6-15位：无错误提示
- 小于6位：提示错误
- 大于15位：提示错误

缺点：

等价类划分方法主要考虑输入域的分类，但未考虑输入域之间的组合情况。因此，在某些复杂测试场景下，还需要借助其他设计方法来补充和完善测试策略。

边界值分析法

边界值分析法是一种黑盒测试方法，重点测试输入或输出的边界值，通常作为等价类划分法的补充。在这种方法中，测试用例主要来自等价类的边界值。

日常语言中的“边界”漏洞： 举个例子，假设老师布置了寒假作业的要求：超过60分的同学，所有题目抄写1遍，低于60分的同学抄写3遍。而小明恰好得了60分，他就不需要写作业了，因为他“刚好”在60分的边界上。这种情况反映了日常生活中的“边界漏洞”，即没有明确处理边界值时可能会导致错误或不合理的行为。

边界值包含：

边界值：即输入的最小值或最大值。
次边界值：即接近边界的值，稍微小于或大于边界值。

示例：边界值分析

输入框长度为1-11：
- 边界值：1、11
- 次边界值：0、12
运动员的参赛项目为1-3项：
- 边界值：0项、1项、3项
- 次边界值：4项
查询页面有999行，每50行为一页：
- 边界值：输出0行、1行、50行、51行、999行
- 次边界值：50行、51行

练习：根据边界值分析法补充测试用例

姓名必填，6-15位字符：

有效等价类：
- 6-15位字符（例如：10个字符，6个字符，15个字符）无错误提示。
无效等价类：
- 小于6位：1个字符（提示错误），5个字符（提示错误）
- 大于15位：16个字符（提示错误），20个字符（提示错误）
边界值分析：
- 边界值：
  - 6位字符：无错误提示
  - 15位字符：无错误提示
- 次边界值：
  - 5位字符：提示错误
  - 16位字符：提示错误

正交法

通过等价类和边界值分析法，我们已补充了部分测试用例。目前，仍有一个场景的测试用例未完全覆盖——“只填写部分选项”。在这种情况下，我们如何设计测试用例呢？为了确保系统测试的全面性，通常我们会考虑排列组合方法。

假设有两个选项A和B，可以设计出四个测试用例：

都填写
都不填写
只填写A
只填写B

如果有三个选项A、B、C，则可以设计出8个测试用例。

例如，在当前场景中，有5个可选项：姓名、电子邮箱、密码、确认密码、验证码。按照排列组合原则，可以设计出32个测试用例（2^5）。

正交试验设计的目的是减少测试用例的数量，同时确保尽量少的用例覆盖所有可能的两两组合。通过这种方法，可以显著减少需要设计的测试用例数量。

正交试验设计（Orthogonal Experimental Design）是一种高效的多因素、多水平试验方法。它根据正交性原理，从试验因素的所有可能水平组合中，挑选出具有代表性的部分进行测试。通过分析这些测试结果，可以全面了解系统的表现，并找出最优的组合。正交试验设计能够高效、经济地进行试验，避免了传统测试方法中大量重复的无效测试。

正交表示例：
最简单的正交表是L(4)(2^3)，其含义如下：

“L”代表正交表；
“4”表示有4行，即进行4次试验；
“3”表示有3列，即最多可以安排3个因素；
“2”表示每个因素有2个水平。

在这里插入图片描述

正交表的构成：因素、水平数、行数

因素：对测试结果有影响的条件，通常对应正交表中的一列。
水平：每个因素的可选值。

正交表的性质：

每一列中的不同数字出现的次数相等。
任意两列中的数字排列方式齐全且均衡。

由于手动设计正交表比较复杂，通常可以借助工具来生成正交表。

正交法设计测试用例的步骤：

确定因素和水平：
- 例如，邮箱注册的因素可以包括：姓名、电子邮箱、密码、确认密码、验证码，每个因素有两个水平：填写和不填写。
生成正交表：
- 使用AllPairs工具生成正交表。具体步骤如下：
  - 将因素和水平写入Excel表格。
  - 在AllPairs目录下创建新的文本文件（如0714.txt），复制Excel中的因素和水平并粘贴到文本中，然后保存退出。
  - 使用AllPairs命令生成正交表：allparis.exe 0714.txt > 0714ig.txt（将生成的正交表数据保存在0714ig.txt文件中）。
根据正交表编写测试用例：
- 根据生成的正交表，在每个测试用例中填写对应的因素组合。
补充遗漏的测试用例：
- 根据实际情况，补充一些重要的、可能遗漏的测试用例。

以邮箱注册为例，使用正交法补全测试用例：

找到因素和水平：
- 因素：姓名、电子邮箱、密码、确认密码、验证码
- 水平：填写、不填写
用AllPairs工具生成正交表：
- a. 将因素和水平写入Excel表格。
- b. 在AllPairs目录下创建新的文本文件（如0714.txt），复制Excel中的因素和水平并粘贴到文本中，保存并退出。
- c. 使用AllPairs命令生成正交表：allparis.exe 0714.txt > 0714ig.txt（将生成的正交表数据保存到0714ig.txt文件中）。

在这里插入图片描述

之后根据正交表编写测试用例
补充遗漏的测试用例

在这里插入图片描述

注意：使用allparis生成的正交表可能与预期有出入，但不影响设计测试用例。

判断表法

为了确保测试覆盖全面，我们需要采用科学的方法来设计测试用例。需求中通常会包含各种不同的场景，而不同的输入组合可能会对应不同的输出结果。这种情况下，仅依靠等价类划分、边界值分析等方法，往往难以应对复杂的输入组合逻辑。

我们以如下需求为例：

用户输入的账号中如果包含 admin 字符，或是通过 内部链接 进入注册页面并点击提交注册按钮，则注册用户具有 管理员身份；
否则，注册用户为普通用户。

从该需求可以看出，不同条件的组合（如输入内容、进入页面的方式）共同决定了最终的结果。这时，传统的 正交法 可能无法很好地覆盖所有场景，而 判定表（Decision Table） 则是更合适的工具。*

判定表 是一种用于逻辑判断建模的工具，通过表格形式展示多个条件与其对应的动作之间的关系，能够系统地描述复杂的逻辑组合。形式如下：

在这里插入图片描述

通过这样的表格，可以把所有的输入条件与对应的结果一一列出，确保测试覆盖所有的有效路径。

将示例需求转化为判定表:

根据下面的步骤将刚刚的需求根据判定表进行编写测试用例，经过以下步骤：

确认需求中的输入条件和输出结果
找出输入与输出之间的对应关系
绘制判定表
根据判定表编写测试用例

确认输入条件与输出结果

输入条件：

条件项代号
账号是否包含 admin A
是否通过内部注册链接进入 B
是否点击注册按钮 C
输出结果：

输出项代号
成为管理员 1
非管理员 2
找出输入与输出之间的关系

通过需求分析，组合情况及其对应结果如下：

输入组合对应输出
A + C 管理员 (1)
A + B 非管理员 (2)
B + C 管理员 (1)
A + B + C 管理员 (1)
A + B (不点 C) 非管理员 (2)
只有 C 非管理员 (2)
无 A/B/C 非管理员 (2)

条件项	代号
账号是否包含 `admin`	A
是否通过内部注册链接进入	B
是否点击注册按钮	C

输出项	代号
成为管理员	1
非管理员	2

输入组合	对应输出
A + C	管理员 (1)
A + B	非管理员 (2)
B + C	管理员 (1)
A + B + C	管理员 (1)
A + B (不点 C)	非管理员 (2)
只有 C	非管理员 (2)
无 A/B/C	非管理员 (2)

绘制判定表

用例编号	A（账号包含 admin）	B（内部注册链接）	C（点击注册按钮）	输出：管理员（1）	输出：非管理员（2）
1	是	否	是	✅
2	是	是	否		✅
3	否	是	是	✅
4	是	是	是	✅
5	是	否	否		✅
6	否	否	是		✅
7	否	否	否		✅

根据判定表编写测试用例

测试用例编号	输入条件说明	预期输出
TC01	账号包含 `admin`，非内部链接，点击注册按钮	管理员身份
TC02	账号包含 `admin`，内部链接，未点击注册按钮	非管理员身份
TC03	账号不包含 `admin`，通过内部链接，点击注册按钮	管理员身份
TC04	账号包含 `admin`，内部链接，点击注册按钮	管理员身份
TC05	账号包含 `admin`，非内部链接，未点击注册按钮	非管理员身份
TC06	账号不包含 `admin`，非内部链接，仅点击注册按钮	非管理员身份
TC07	账号不包含 `admin`，未通过内部链接，未点击注册按钮	非管理员身份

场景法

在现代软件开发中，系统通常通过事件触发的方式来控制流程。事件触发的当下情景称为场景；而相同事件在不同的触发顺序和处理结果下，会构成一个事件流。

场景法（Scenario-based Testing） 是一种通过模拟真实使用场景来测试系统功能和业务流程的方法。这种方法可以帮助发现需求中未被明确描述或隐藏的问题，从而提升测试的全面性和有效性。

场景法的基本结构:

场景法通常由两部分组成：

基本流（Basic Flow）：用户在没有任何异常或干扰下完成的标准流程。
备用流/备选流（Alternative Flow）：在基本流程的某些阶段出现其他选择路径，例如用户的决策变化、异常情况等。

此外，还包括两种扩展场景：

异常场景（Exception Flow）：在流程中出现错误或系统异常时的处理方式。
假定场景（Assumed Scenario）：根据假设条件构建的可能发生但尚未明确的场景。

理解场景法 —— 以“逛街买衣服”为例

我们用一个简单的生活场景来帮助理解：逛街买衣服。

基本流（标准流程）

出发 → 到达服装店 → 选衣服 → 试穿 → 付款购买 → 离开

备选流（中间出现分支）
- 备选流1：试穿后不满意 → 继续寻找其他衣服
- 备选流2：价格太贵 → 寻找其他价格合适的衣服
- 备选流3：试穿多次仍未满意 → 放弃购买 → 改天再来
异常流（出现突发问题）
- 店铺未开门
- 忘带钱包
- 商品质量问题
假定场景
- 商场搞促销活动 → 意外发现喜欢的衣服 → 超出预算但仍决定购买

起点
 ↓
去服装店 ——→ 店铺没开门 → 改天再来（异常流）
 ↓
选衣服 ——→ 没有喜欢的款式 → 继续寻找（备选流）
 ↓
试穿 ——→ 不合身或价格贵 → 继续试/寻找替代（备选流）
 ↓
满意 → 付款购买 → 结束

该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。

典型的应用是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。

在这里插入图片描述

依然以账号注册的案例，根据场景法设计测试用例，步骤如下：

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

错误猜测法

错误猜测法（Error Guessing） 是一种基于经验、直觉和对被测系统的理解，主动推测系统可能存在缺陷，并设计相应测试用例的方法。

该方法强调测试人员对：

被测试系统的需求理解；
系统设计和实现细节的把握；
过往经验和直觉的积累。

错误猜测法的核心思想与当今流行的探索式测试（Exploratory Testing）基本一致，尤其适用于敏捷开发模式，在投入与产出方面表现出良好的性价比，因而被广泛应用于实践中。

类比示例：张三卖瓜

人们基于“经验”或“认知偏见”对行为结果的预判，正体现了错误猜测的本质。例如：

用例编号	错误猜测	对应测试关注点
用例1	张三这人不实诚，小心他缺斤少两	验证系统是否存在数据截断
用例2	张三这人粗心，小心他的瓜被压坏了	检查输入后是否有格式错误或逻辑错误
用例3	张三这人小气，小心不要把他惹哭了	验证边界条件、限制条件等处理是否严谨

这类猜测虽然没有严格逻辑推理基础，但基于经验可以有效发现隐藏问题。

错误猜测法在注册功能中的应用

以“邮箱账号注册功能”为例，我们可以基于经验推测用户最可能出错的地方，并设计测试用例。

示例测试点（错误猜测）
1. 邮箱字段中是否允许特殊字符或空格？
2. 密码中是否对大小写敏感？
3. 姓名中是否允许特殊字符（如 @、# 等）？
4. 注册后密码是否明文返回？是否存在信息泄露风险？
5. 重复提交注册表单是否会导致多次注册？
6. 非法邮箱格式（如缺少 @ 或域名）是否被正确拦截？
7. 注册成功后是否能直接登录？是否存在逻辑跳转错误？

四、试用例编写要求

笔试场景：需采用传统测试用例编写格式，包括以下要素：

用例编号	测试项	输入数据	操作步骤	预期结果
TC01	邮箱特殊字符校验	`user@exa mple.com`	输入邮箱并提交注册表单	显示“邮箱格式不正确”提示
TC02	密码大小写敏感性	`PassWord123`	输入密码并重复确认	系统识别大小写一致性
TC03	姓名特殊字符校验	`张@三`	填写姓名字段提交	显示“姓名中不能含特殊字符”
TC04	密码是否以明文显示	任意密码	查看前端密码输入框	密码以“***”或密文显示

面试场景：可通过思维导图或口头结构化表达，按如下路径讲解测试要点：

注册功能测试 →
  ├─ 邮箱校验 → 特殊字符、空格、格式错误
  ├─ 密码校验 → 长度、复杂度、大写敏感、明文显示
  ├─ 姓名字段 → 非法字符输入
  └─ 安全测试 → 明文密码、重复注册、跳转验证

1. 示例

基于上述的测试方法，可以为一个登录页面设计以下的测试用例：
在这里插入图片描述

2. zip/unzip 命令行功能

命令行中的 zip 和 unzip 命令可用于对文件进行压缩和解压缩操作。为确保其功能完整、性能稳定、用户体验良好，需要从多个维度设计系统性测试用例。

在这里插入图片描述

功能测试（Function Testing）

测试命令的基本功能是否正常，适用于各种文件类型和使用场景：

编号	测试内容	预期结果
F1	压缩普通的 `.txt` 文件	成功生成 `.zip` 压缩包
F2	压缩图片、视频、已压缩文件（如 `.jpg`, `.mp4`, `.zip`）	成功生成 `.zip` 文件
F3	压缩多个混合类型文件	所有文件成功压缩为一个 `.zip`
F4	压缩空文件夹	成功生成空内容的 `.zip` 文件
F5	输入错误命令或缺失参数（如未指定压缩文件名或源文件）	提示错误，命令失败
F6	使用不同参数（如 `-r`, `-q`, `-e` 等）	参数生效，行为符合预期

界面测试（UI / CLI Display Testing）

主要验证命令行中的输出提示是否合理、友好：

编号测试内容预期结果
UI1 压缩成功时的命令行提示信息提示清晰，内容准确、美观
UI2 压缩失败时的错误提示信息信息明确，便于用户排查问题
性能测试（Performance Testing）

主要关注大文件处理时的性能表现：

编号测试内容预期结果
P1 压缩文件大小超过 1GB 压缩成功，无崩溃或中断
P2 测试压缩 1GB 文件所需时间压缩时间控制在可接受范围（如 ≤ 60 秒）
兼容性测试（Compatibility Testing）

验证 zip 命令在不同操作系统平台的表现一致性：

编号测试内容预期结果
C1 在 Windows、Linux、Mac 上运行 zip 命令在不同系统中均可正常执行
易用性测试（Usability Testing）

验证命令是否易于使用，是否提供帮助文档等：

编号测试内容预期结果
U1 执行 zip --help 或 man zip 查看帮助文档显示命令的使用方法、参数说明清晰

编号	测试内容	预期结果
UI1	压缩成功时的命令行提示信息	提示清晰，内容准确、美观
UI2	压缩失败时的错误提示信息	信息明确，便于用户排查问题

编号	测试内容	预期结果
P1	压缩文件大小超过 1GB	压缩成功，无崩溃或中断
P2	测试压缩 1GB 文件所需时间	压缩时间控制在可接受范围（如 ≤ 60 秒）

编号	测试内容	预期结果
C1	在 Windows、Linux、Mac 上运行 `zip` 命令	在不同系统中均可正常执行

编号	测试内容	预期结果
U1	执行 `zip --help` 或 `man zip` 查看帮助文档	显示命令的使用方法、参数说明清晰

安全性测试（Security Testing）

验证命令在执行过程中是否存在安全隐患：

编号	测试内容	预期结果
S1	压缩过程中是否可能泄漏文件内容信息	无敏感信息泄漏，不暴露文件数据内容
S2	使用带密码压缩时（如 `zip -e`）	密码设置成功，解压前需输入密码