测试-用例篇

测试用例的概念

测试用例（Test Case）是为了实施测试而向被测试的系统提供的⼀组集合，这组集合包含：用例编号、标题、测试方式、功能模块、测试前提、测试环境、测试数据、操作步骤、预期结果等要素

设计测试用例的万能公式

思维方式：常规思考+逆向思维+发散性思维

1. 不仅考虑有效和预料到的输入情况，还考虑无效和未预料到的输⼊情况
2. 检查程序是否“未做其应该做的”仅是成功的一半，测试的另一半是检查程序是否“做了其不应该做的”

设计测试用例的万能公式：

• 功能测试：从产品功能出发，围绕核心业务逻辑与需求，验证功能是否完整、正确实现。不仅要确认功能 “能做”，还要覆盖正常操作（如合法输入下的功能触发）与异常操作（如输入为空、格式错误）场景，确保每一项功能都按预期执行，无逻辑漏洞
• 界面测试：肉眼能看到的软件可视化部分均属于界面，需对界面所有元素（大小、颜色、形状、位置、文字样式、材质等）进行全面验证。既要检查元素本身是否符合设计规范（无错位、重叠、颜色偏差），也要确认元素交互时的状态正常（如按钮点击有反馈、弹窗显示无遮挡），确保界面呈现与交互均无问题
• 性能测试：功能测试检查软件 “是否做了该做的事”，而性能测试重点测试软件 “做得好不好”。通常会模拟极端场景（如高并发、长时间运行、低网络带宽），验证软件的响应速度、稳定性、资源占用（CPU / 内存）等表现，确保软件在压力下也能正常工作，无崩溃、卡顿或数据丢失
• 兼容性测试：主要涉及不同版本的适配，包括软件版本、操作系统版本、浏览器版本、设备型号等；同时要覆盖数据兼容。比如软件新增 “邮箱登录” 功能后，需验证原 “手机号登录” 仍能正常使用，无冲突；还要测试数据格式 / 长度变化的适配性（如字符串变长、变短后，能否正常显示、存储，无截断或报错）
• 易用性测试：验证软件是否具备 “简单易上手” 的属性。从普通用户视角出发，检查操作流程是否符合使用习惯、关键步骤是否有清晰提示、误操作能否快速回滚，确保用户无需复杂学习，就能轻松完成核心操作，降低使用成本
• 安全测试：重点关注用户数据安全与系统权限控制：比如接口传输的用户数据需加密，防止泄露；存储的用户隐私信息（手机号、密码等）不能以明文形式保存；还要严格防范越权操作 —— 确保普通用户无法执行管理员权限的功能（如修改他人数据、访问管理后台），仅能操作自身权限范围内的内容

除了万能公式之外，还有一些比较常用的测试类型：弱网测试、安装卸载测试

弱网测试

弱网测试的核心目标是在网络带宽低、延迟高、稳定性差的场景下，尽可能保障用户体验不受严重影响，测试需重点关注以下关键维度：

1. 响应时间可接受性：验证各类操作的耗时是否在用户可容忍范围内，核心关注指标包括：热启动 / 冷启动时间、页面切换耗时、App 前后台切换响应速度、页面首字符加载时间、首屏完全渲染时间等
2. 页面呈现一致性：确认弱网环境下，页面所有元素（文字、图片、按钮等）的展示效果，与正常网络环境是否完全一致，无元素缺失、错位、加载失败（如图片裂图）等问题
3. 异常提示规范性：当网络请求超时或失败时，验证超时文案是否符合产品定义（如 “网络较慢，请稍后再试” 而非模糊提示），各类异常信息（如加载失败、连接中断）的显示样式、位置是否正常，能否清晰引导用户
4. 超时重连机制：检查系统是否具备自动重连能力 —— 当网络请求超时后，是否会触发自动重试（如接口请求重试、页面加载重试），且重连逻辑合理（无无限重试、重试频率过高导致资源浪费等问题）
5. 安全风险防控：从安全角度验证弱网场景下的潜在风险，包括但不限于：是否存在 DNS 劫持风险、用户登录 IP 是否因弱网频繁更换引发异常、单点登录（SSO）功能是否出现认证失效、会话异常等问题
6. 大流量动作管控：排查弱网环境下是否存在不合理的大流量操作，例如：是否会自动触发 APK 包更新、大文件下载（如视频、压缩包）等消耗大量带宽的动作，避免因弱网导致流量超额或操作长时间卡顿
7. 网络切换适配性：测试在弱网场景下进行网络制式切换（如 2G→3G、3G→4G、4G→5G，或移动网络与 WiFi 切换）时，App 能否平滑适配，无功能中断（如视频播放中断、页面加载卡死）、数据丢失（如表单输入内容丢失）等问题

可以借助工具来构造弱网，本文使用 Fiddler

1. 打开 模拟调制解调器速率，就是把 Simulate Modem Speeds 勾选上
   
2. 打开 Fiddler 脚本编辑器

按 ctrl+f 然后搜索 m_SimulateModem

表示当 m_SimulateModem 为 true 时，模拟调制解调器（Modem）的网络延迟，通过给请求 / 响应设置 逐包延迟（trickle delay），让网络传输变慢，模拟弱网环境：

• m_SimulateModem：是 Fiddler 中控制 “是否模拟调制解调器速率” 的开关变量（布尔值）。开启后，才会执行延迟逻辑
• request-trickle-delay：
  • 作用：控制上行数据（比如你向服务器发请求、传文件）的延迟
  • 逻辑：默认每上传 1KB 数据，就延迟 300 毫秒
• response-trickle-delay：
  • 作用：控制下行数据（比如服务器给你返回网页、接口数据）的延迟
  • 逻辑：默认每下载 1KB 数据，就延迟 150 毫秒

这里的数字是每 KB 的延迟时间，数值越大，传输相同大小的数据需要的总延迟越高，等效于 “网络速率越低”。增加数值后，浏览器 / APP 收发数据会 “被放慢”，能模拟 2G/3G 等弱网环境，测试应用在低速网络下的表现（比如页面加载是否卡住、超时提示是否合理）

安装卸载测试

针对需部署的软件，除核心功能验证外，软件的安装与卸载可行性及稳定性同样是关键测试维度，需重点覆盖以下场景：

• 安装测试
  • 基础安装验证：检查软件安装包是否能在目标环境（如指定操作系统版本、硬件配置）下正常启动安装流程，且安装完成后软件可正常启动、功能无异常（如无文件缺失、组件未注册等问题）
  • 卸载后重装验证：软件完全卸载后，重新运行安装包，确认能否正常完成安装，且安装后软件功能、配置初始化状态符合预期（无残留文件导致的安装失败或功能异常）
  • 重复安装验证：在软件已正常安装的前提下，再次运行安装包，验证流程是否符合设计预期（如提示 “已安装，是否覆盖 / 修复”“是否升级”，或禁止重复安装，且操作后软件无损坏、数据无丢失）
  • 版本更新安装验证：针对软件更新场景（如从低版本升级至目标版本），检查更新安装包能否正常运行，更新后软件功能兼容、数据平滑迁移，且无旧版本文件残留导致的冲突问题
• 卸载测试
  • 完整安装后卸载验证：软件正常安装并可正常使用后，通过官方卸载渠道（如控制面板、软件自带卸载程序）触发卸载，确认卸载流程可完整执行，且卸载后目标路径下无残留文件、注册表无残留项（若有设计允许的配置保留需求，需符合预设规则）
  • 安装中断后卸载验证：在安装流程执行过程中（如文件复制中、组件注册中）手动中断安装（如关闭安装程序、断网、断电后恢复），之后触发卸载操作，验证能否成功清理已安装的部分文件 / 组件，避免残留文件占用资源或影响后续操作（如再次安装）
  • 卸载 - 安装 - 卸载循环验证：模拟用户反复操作场景，即 “安装→卸载→重新安装→再次卸载”，验证每一轮安装、卸载流程均能正常执行，且多次循环后无环境污染（如残留文件堆积、系统配置紊乱），软件功能不受影响
  • 卸载中断后续卸载验证：在卸载流程执行过程中（如文件删除中、注册表清理中）手动中断卸载（如关闭卸载程序、强制结束进程），之后再次触发卸载操作，确认流程可继续执行直至卸载完成，且最终无残留文件或异常状态

具体的设计方法

等价类划分法

等价类划分法是一种重要的黑盒测试用例设计方法，用于解决输入集合无穷性导致的穷举测试难题。其核心思想是：将程序的输入域划分为若干个等价类，从每个等价类中选取一个代表性测试用例。如果该用例测试通过，则认为其代表的整个等价类测试通过，从而以较少的测试用例实现较充分的功能覆盖

等价类的分类

• 有效等价类：符合需求规格说明书要求的、合理且有意义的输入数据集合。通过有效等价类测试可验证程序是否实现了规格说明中规定的功能和性能
• 无效等价类：不符合需求规格说明书要求的输入数据集合。通过无效等价类测试可验证程序对异常输入的处理能力

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

1. 分析需求，确定有效等价类和无效等价类的具体范围
2. 为每个等价类设计代表性测试用例，明确测试数据和预期结果

实例：“6~15 位的字符类型” 的测试用例设计：

• 有效等价类：
  • 长度为 6 位的字符
  • 长度为 15 位的字符
  • 长度为 6~15 位之间的字符（如 8 位、10 位）
• 无效等价类：
  • 为空值（未输入）
  • 长度小于 6 位（如 1 位、5 位）
  • 长度大于 15 位（如 16 位、20 位）
  • 业务场景对 “字符类型” 的限定（如纯数字、纯特殊符号）

用例编号	输入数据	等价类类型	预期结果
TC01	6 位字母（如 “abcdef”）	有效等价类（边界值 6 位）	输入有效
TC02	10 位字母数字混合（如 “abc1234567”）	有效等价类（中间值）	输入有效
TC03	15 位字符（如 “abcdefghijklmno”）	有效等价类（边界值 15 位）	输入有效
TC04	空值（未输入）	无效等价类（必填校验）	提示 “这个为必填项”
TC05	5 位字符（如 “abcde”）	无效等价类（长度不足）	提示 “长度需为 6~15 位”
TC06	16 位字符（如 “abcdefghijklmnop”）	无效等价类（长度超限）	提示 “长度需为 6~15 位”
TC07	纯数字（如 “123456”）	无效等价类（不符合业务限定）	提示 “格式不对”
TC08	特殊符号（如 “@#$%^&”）	无效等价类（不符合业务限定）	提示 “格式不对”

等价类划分法的局限性

等价类划分法仅考虑单个输入域的分类情况，未涉及多个输入域的组合关系，可能遗漏因输入组合导致的缺陷。因此，在实际测试中，通常需要与边界值分析法、判定表法等其他测试用例设计方法结合使用，以提高测试覆盖率

边界值分析法

边界值分析法是一种黑盒测试方法，聚焦于对输入或输出的边界值开展测试 。在软件测试里，它常作为等价类划分法的补充手段，测试用例源于等价类的边界情况，以此挖掘边界处可能存在的软件缺陷

边界值由边界值与次边界值共同构成，次边界值的确定依赖于边界值所属等价类（有效或无效）：

• 若边界值属于有效等价类的数据，那么次边界值为无效等价类中的边界数据
• 若边界值属于无效等价类的数据，那么次边界值为有效等价类中的边界数据

举个实例辅助理解：

有效范围	边界值	次边界值
有效范围是 [6,15]（闭区间，6 和 15 为有效边界 ）	边界值：6、15（有效）	次边界值：5、16（无效）
有效范围是 (6,15)（开区间，6 和 15 为无效边界 ）	边界值：6、15（无效）	次边界值：7、14（有效）

通过这样针对边界及次边界的测试，能更全面检验软件在数据临界处的处理逻辑，降低因边界情况考虑不足引发的问题风险

正交法

通过等价类划分与边界值分析方法，我们已补充部分测试用例，但 “填写部分选项” 场景的用例仍待完善。这里的 “部分选项” 有明确界定 ——既不是所有选项都填写，也不是全部不填写，仅指填写部分选项而其余留白的情况

针对这类场景，若采用全排列组合保障覆盖率，会产生大量冗余用例。例如含 A、B 两个选项时，全量状态需覆盖 “都填写”“都不填写”“仅填 A”“仅填 B” 4 种组合（对应组合数 $2^2$ ）；3 个选项则需 8 种（对应 2³）。即便在 “部分选项” 场景中剔除全填与全不填的情况，随着选项增多，用例数量仍会呈指数级增长，不仅会大幅增加测试执行成本，还可能因冗余用例降低测试效率

而​​正交试验设计（Orthogonal Experimental Design）​​能有效解决这一矛盾。需要明确的是，正交法本质上是从​​所有可能的输入组合（全量组合）中​​，依据​​正交性原则​​，筛选出一组​​具有代表性的少量测试用例​​，其核心价值在于 ​​“用最少用例覆盖关键组合（尤其是两两交互）”​​。该方法​​并不局限于全量或部分场景​​，其适用范围取决于具体的业务需求与测试目标

因此针对 “填写部分选项” 场景，我们可按以下逻辑操作：先借助正交法（如通过 allpairs 工具）生成覆盖因素两两组合的最小用例集（并非 “全量组合”，而是用最少用例覆盖关键交互的正交表），再通过人工筛选剔除表中 “全填”“全不填” 的用例，仅保留 “部分填写” 的核心组合

这种基于正交表的设计，既能通过分析核心测试点掌握系统处理逻辑、定位最优交互规律，又能在严控用例数量的同时，充分保证 “填写部分选项” 场景的测试覆盖完整性，高效且经济实用

下面这个是 L${}^{12}$(2${}^{11}$)

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

• 因素：指对结果产生影响的条件，在正交表中通常以列表示
• 水平：指每个因素对应的可选项（即因素的取值或状态）
• 行数：指正交表中包含的独立实验（或测试）的次数

正交表具有两个核心性质：

• 每一列中，不同数字（代表不同水平）出现的次数相等
• 对于任意两列，这两个因素的​​所有可能水平组合（有序对）都会出现，并且每种组合出现的次数相等​​

基于这些性质，正交表很难通过手动设计完成。利用正交法设计测试用例的步骤如下：

1. 明确场景中的因素和对应的水平
2. 使用 allpairs 工具提取正交表的核心一部分（即两两组合均衡）：
   • 将梳理好的因素和水平整理到 Excel 表格中
   • 在 allpairs 工具目录下创建文本文件（如 new.txt），将 Excel 中的因素和水平内容复制粘贴到文本中并保存
   • 执行命令 “allpairs.exe new.txt> xxx.txt” 生成测试用例
3. 根据业务需求与测试目标调整测试用例

以邮箱注册场景为例，采用正交法补全测试用例的过程如下：

1. 找到因素和水平

确定因素：姓名、电子邮箱、密码、确认密码、验证码
确定水平：每个因素的水平均为 “填写” 和 “不填写”

2. 使用 allpairs 工具提取正交表的核心一部分

将因素和水平写入Excel表格中

在 allparis 同级目录下创建文本文件 测试.txt，复制Excel中的因素和水平，直接粘贴到 测试.txt 中保存并退出(不要有其他操作)

使用 allparis 命令生成测试用例：打开cmd，目录是 allparis 所在的目录。输入命令allpairs.exe 测试.txt > ret.txt（将生成的测试用例放入 ret.txt 文件中），建议不要提前创建 ret.txt 文件，可能生成失败

这里放的就是 allpairs 工具生成的测试用例了

3. 根据业务需求与测试目标调整测试用例

判定表法

判定表是清晰表达逻辑判断的工具，能将所有条件组合及其对应的结果直观呈现 。相较于正交法（更侧重多输入间均衡组合覆盖，难以精准适配这种条件 - 结果强关联、需明确逻辑判断的场景 ），判定表法可针对性梳理条件与结果的逻辑关系，解决 “不同组合操作对应不同结果” 的测试需求，确保测试用例完整覆盖各类场景，形如：

通过该图，可以把所有条件对应的结果清晰的表达出来

比如用户注册场景需求：用户输入的账号中包含 “admin” 字符，或者通过内部链接进入注册页面，提交注册按钮后成为管理员身份；反之（不满足 “账号含 admin 字符” 且不满足 “通过内部链接进入” ），无管理员身份 。此需求中，不同条件组合会产生不同结果，正交法⽆法解决这样的问题，需精准设计测试用例覆盖各类情况

基于判定表法设计测试用例的步骤

（一）确认输入条件和输出条件

• 输入条件：
  • 条件 1：账号中是否包含 “admin” 字符（是 / 否 ）
  • 条件 2：是否通过内部链接进入注册页面（是 / 否 ）
• 输出条件（结果）：
  • 结果：是否成为管理员身份（是 / 否 ）

（二）找出输入条件和输出条件之间的关系

梳理逻辑关系：只要满足 “条件 1 为是” 或者 “条件 2 为是” ，输出结果就是 “成为管理员身份（是）” ；只有当 “条件 1 为否” 且 “条件 2 为否” ，输出结果才是 “无管理员身份（否）”

（三）画判定表

	条件 1（账号含 admin）	条件 2（内部链接进入）	结果（管理员身份）
用例 1	是	是	是
用例 2	是	否	是
用例 3	否	是	是
用例 4	否	否	否

说明：行代表不同测试用例场景，列分别对应输入条件和输出结果。通过罗列条件的不同组合，清晰呈现对应结果

（四）根据判定表编写测试用例

测试用例编号	输入条件 1（账号是否含 “admin” 字符）	输入条件 2（是否通过内部链接进入注册页面）	操作步骤	预期结果
测试用例 1	是	是	提交注册按钮	成为管理员身份
测试用例 2	是	否	提交注册按钮	成为管理员身份
测试用例 3	否	是	提交注册按钮	成为管理员身份
测试用例 4	否	否	提交注册按钮	无管理员身份

通过上述步骤，利用判定表法可系统、全面地设计测试用例，覆盖需求中的各类场景，提升测试的有效性与完整性，助力保障软件功能符合设计预期

场景法

在软件测试中，场景法是一种贴合用户实际操作逻辑的测试用例设计方法 —— 由于现代软件多依赖 “事件触发” 控制流程（如点击按钮、输入内容、页面跳转等），不同事件的触发顺序、处理结果会形成多样 “情景”，场景法正是通过模拟这些情景，将孤立的功能点串联成完整业务流程，既覆盖常规操作，也捕捉意外分支，让测试更贴近真实使用场景

场景法的核心是梳理 “常规路径” 与 “意外分支”，用 “故事化” 思路理解更清晰：

• 基本流：流程的 “主线剧情”，即用户按理想流程完成操作的完整路径（比如电商购物：选商品→加购→结算→付款→生成订单 ），是流程的核心骨架，代表最顺畅的操作逻辑
• 备选流：流程的 “支线 / 突发剧情”，指常规路径中可能冒出的特殊情况（像加购时商品缺货、付款时余额不足 ）。这些情况会在基本流的某个 “节点”（如选商品、付款环节 ）切入，可能让流程暂停、跳转，甚至直接终止
• 场景类型：基于 “主线 + 支线” 的组合，场景分 4 类，覆盖不同故事走向：
  1. 正常场景：只有主线剧情，无意外（顺利选商品→付款→完成购物 ）
  2. 备选场景：主线 + 可解决的支线（商品缺货→换规格→继续购物 ），流程能回归主线
  3. 异常场景：主线 + 导致流程终止的意外（付款时余额不足且无其他支付方式→放弃购物 ），直接结束故事
  4. 假定推测场景：主线 + 低概率但可能发生的意外（结算时提示库存不足→刷新后恢复库存 ），考验系统应对特殊情况的能力

简单说，场景法就是把软件流程编排成 “故事”，基本流是 “主线”，备选流是 “支线 / 突发状况”，场景就是 “主线 + 支线” 的完整故事线，重点考验对 “用户可能遇到的所有剧情” 的发散思考

场景法之所以实用，是因为它精准弥补了传统测试的漏洞，带来 3 大核心价值：

• 贴近真实操作：不孤立测试单个功能（比如只测 “支付按钮”，却不管 “支付断网后咋重试” ），而是模拟用户完整操作路径，能发现实际使用中才会暴露的问题
• 覆盖更全面：既抓常规流程，也不放过异常、低概率场景（像 “充值成功但没到账” 这类流程漏洞 ），大幅降低漏测风险
• 用例易落地：场景化描述像 “讲故事”，测试人员不用反复啃需求文档，看 “故事” 就能明白 “测什么、怎么测”，执行效率更高

总之，场景法的核心是 “以用户视角梳理流程，用情景覆盖所有可能”，尤其适合电商购物、支付、登录等 “多步骤、多分支” 的业务流程测试

错误猜测法

错误猜测法是测试人员基于对软件需求和设计实现的理解，结合经验与直觉推测潜在缺陷并设计测试用例的方法，其以经验直觉为主导（需熟悉软件的业务逻辑、技术实现以及同类软件的常见缺陷）、与探索式测试思想一致且在敏捷开发中投入产出比高，但存在难系统化、过度依赖个人能力的局限

邮箱账号注册场景：场景法 + 错误猜测法设计测试用例

以 “邮箱账号注册” 功能为例，先通过场景法梳理核心流程，再结合错误猜测法补充 “常见异常点”

基本流：进入注册页→输入邮箱账号→输入密码→输入姓名→点击 “发送验证码”→输入验证码→点击 “注册”→注册成功

结合错误猜测法补充的 “高频缺陷点”（特殊字符处理、大小写校验、密码明文 / 密文、数据格式异常等），设计测试用例如下：

用例编号	测试模块	前置条件	测试步骤	预期结果	优先级
01	邮箱账号格式校验	注册页可正常访问，未输入过待测试邮箱	输入含空格的邮箱，点击 “下一步”	页面弹出 “邮箱格式错误” 提示，无法进入密码输入步骤	高
02	密码格式校验	已输入合法邮箱，进入密码输入页	输入密码 “123”，点击 “下一步”	页面弹出 “密码应大于8位且包含数字和大小写字母” 提示，无法进入姓名输入环节	高
03	密码明文 / 密文显示	进入密码输入页，页面加载正常	输入密码 “Test123456”，观察输入框显示形式；点击 “显示密码” 图标，再次观察	密码默认以 “・” 或 “*” 等密文显示；点击 “显示密码” 后切换为明文，再次点击恢复密文	高
04	姓名特殊字符校验	已完成邮箱、密码输入，进入姓名输入页	输入含特殊字符的姓名（如 “张 #三”“李 * 四”），点击 “发送验证码”	若允许特殊字符：正常发送验证码；若禁止：弹出 “姓名不可包含 #、* 特殊字符” 提示，不发送验证码	中
05	验证码过期处理	已完成邮箱、密码、姓名输入，且已发送验证码	等待验证码过期（如需求设定 10 分钟过期），输入过期验证码，点击 “注册”	页面弹出 “验证码已过期，请重新获取” 提示，可点击 “重新发送验证码” 获取新验证码	中

zip/unzip 命令行程序测试用例

• 功能测试

  • 基础文件：对.txt 格式文件执行压缩，验证压缩包生成完整性及解压后内容一致性
  • 特殊格式：测试图片（.jpg/.png）、视频（.mp4/.avi）、嵌套压缩包（.zip）的压缩效果，确保格式兼容
  • 混合文件：选取不同类型文件（文档 + 媒体 + 压缩包）批量压缩，验证压缩包包含所有文件且解压完整
  • 空文件：执行压缩命令，验证能否生成压缩包，且解压后仍为空白文件
  • 异常命令校验
  • 参数功能验证
  • 基础解压：验证合法压缩包解压后文件内容、格式、结构与源文件一致
  • 损坏文件：对篡改 / 未完成下载的压缩包解压，验证 “文件损坏” 提示有效性
  • 文件冲突：测试目标目录存在同名文件时的处理逻辑（提示覆盖 / 直接覆盖 / 跳过）

• 界面交互测试

  • 成功命令行提示是否美观
  • 报错命令行提示是否友好
  • 编码兼容：中文文件名 / 路径在提示中需正常显示无乱码

• 性能测试

  • 能处理大文件且在合理的时间范围内
  • 多文件批量性能

• 兼容性测试

  • 操作系统兼容性
  • 工具版本兼容性
  • 文件系统兼容性

• 易用性测试

  • 帮助文档可用性
  • 命令语法易用性
  • 交互友好性

• 安全性测试

  • 文件内容保密性
  • 恶意文件处理安全性
  • 路径穿越防护
  • 权限安全性