企业官网建设流程全解析

之前带测试团队做项目时，我经常面临一个很尴尬的情况：同一个登录功能，不同测试工程师写出来的用例质量差距非常大。有人写了八十条用例，结果核心的“账号锁定”场景没覆盖到；有人只写了二十条，却能精准命中所有高风险路径。问题不在于写得多还是少，而在于测试用例设计是否有一套系统的方法论支撑。

很多刚入行的测试同学把测试用例简单地理解为“步骤 + 预期结果”，写完就完事。但事实上，一份专业的测试用例设计，背后要回答几个核心问题：业务需求是否被完整拆解？异常路径是否被覆盖？用例是否可以高效执行和维护？不同优先级用例的比例是否合理？

这篇文章会围绕测试用例设计方法完整展开。无论你是刚入行的测试新人，还是已经带项目的测试负责人，都可以从中获得一套可落地的用例设计思路。

1. 测试用例设计到底在解决什么问题

1.1 什么是测试用例

测试用例（Test Case）是指为了特定测试目标而设计的一组测试输入、执行条件、操作步骤和预期结果的集合。

通俗地说，测试用例就是一份“操作说明书”，告诉执行者：在什么环境下，准备好什么数据，执行什么操作，最后应该看到什么结果。

一个完整的测试用例通常包含：

• 用例编号
• 所属模块
• 用例标题
• 优先级
• 前置条件
• 测试数据
• 操作步骤
• 预期结果
• 实际结果（执行时填写）
• 备注

1.2 为什么需要系统的用例设计方法

很多测试同学写用例时习惯“想到哪写到哪”，这种方式存在几个典型问题：

• 覆盖不完整：只测试正常路径，异常路径大量遗漏。
• 用例冗余：很多用例其实是重复的，只是数据不同。
• 可执行性差：步骤写得不够清晰，开发或新人执行时看不懂。
• 无法度量：说不清楚当前版本的测试覆盖率是多少，哪些需求点还没测。

而系统的测试用例设计方法，能帮你从“经验驱动”升级为“方法论驱动”。等价类划分、边界值分析、因果图、判定表、正交试验、场景法等经典方法，本质上都是对“如何从需求和逻辑中系统性找出测试点”这一问题的回答。

1.3 测试用例设计在研发流程中的位置

测试用例设计通常发生在测试计划制定之后、测试执行之前。测试人员需要先充分理解需求文档、原型图、接口文档，然后进行用例设计，再组织用例评审，最后才进入测试执行阶段。

用例设计的好坏直接决定了测试执行阶段的质量上限。如果用例本身覆盖不全，执行再认真也发现不了隐藏的缺陷。

2. 测试用例的构成要素与规范写法

2.1 核心要素拆解

先看一个模板：

2.2 用例标题的写法

用例标题不要写成“登录功能测试”，这太宽泛，无法指导执行。

推荐写法是：条件 + 操作 + 预期结果的浓缩。

例如：

• 验证输入正确的手机号和密码，点击登录后成功进入首页
• 验证手机号为空时，点击登录后提示“请输入手机号”
• 验证密码连续输错5次后，账号被锁定30分钟

2.3 测试步骤的粒度控制

测试步骤写得太粗，执行者会重复问；写得太细，维护成本又过高。

一个基本原则是：步骤粒度以“普通测试工程师不需要再询问细节就能独立执行”为标准。

举一个反例：

1. 打开登录页 2. 正常输入 3. 点击登录 4. 查看结果

这里“正常输入”是什么？手机号是多少？密码是多少？没人知道。

应该写成：

1. 打开登录页 http://demo.example.com/login 2. 在手机号输入框输入 13800138000 3. 在密码输入框输入 Abc123 4. 在验证码输入框输入 1234 5. 点击【登录】按钮 6. 观察页面跳转和提示

2.4 测试数据与前置条件的设计

前置条件必须满足两个要求：可复现、充分。

以登录功能为例，前置条件要写清楚：

• 测试环境地址
• 是否已有测试账号
• 账号的状态（正常、锁定、未激活等）
• 是否需要清理历史缓存数据

测试数据的设计要避免使用生产真实数据，优先使用专用的测试数据。涉及用户隐私和敏感信息时，必须脱敏处理。

3. 核心测试用例设计方法详解

这部分是全文的重点。下面逐一分析经典测试用例设计方法的使用场景、核心规则和常见误区。

3.1 等价类划分法

3.1.1 方法介绍

等价类划分法的核心思想是：把输入条件按照“是否对程序处理逻辑有相同影响”进行分组。同一等价类中的数据，程序的处理方式和结果是等价的，因此只需要从每个等价类中选取少量代表性数据进行测试。

等价类分为两类：

• 有效等价类：满足需求规格说明的输入数据。
• 无效等价类：不满足需求规格说明的输入数据。

3.1.2 示例

假设有一个订单金额输入框，需求规定：金额必须为大于0且不超过10000的数字，支持两位小数。

每个无效等价类都是一条独立的用例。

3.1.3 注意事项

有的测试同学只关注有效等价类，觉得无效输入“没必要测”，这是最大的误区。研发在写代码时，最容易漏掉的就是异常分支。无效等价类恰恰是发现这类问题的主力。

3.2 边界值分析法

3.2.1 方法介绍

边界值分析法是等价类划分法的补充。大量的软件缺陷集中在输入范围的边界附近，因为程序员在写判断条件时，最容易犯“大于等于写成了大于”“小于写成小于等于”之类的错误。

在边界值分析中，需要关注几个关键点：

• 上点：边界上的点。
• 离点：离边界最近的点。
• 内点：边界范围内的有效数据点。

3.2.2 示例

以上面的订单金额为例，要求金额在 0.01 到 10000 之间（包含边界值本身）。

边界值分析出的用例数据包括：

3.2.3 注意事项

边界值分析不仅要覆盖输入框的边界，也要覆盖列表分页的边界、时间范围的边界、字符串长度的边界等。一次事务里同时存在多个边界条件时，优先组合测试高风险边界。

3.3 因果图与判定表法

3.3.1 方法介绍

当输入条件较多、且条件之间有组合关系时，等价类划分和边界值分析就不够用了。此时需要使用因果图或判定表法。

因果图的核心步骤：

1. 分析需求中的输入条件（因）。
2. 分析需求中的输出结果（果）。
3. 画出输入和输出之间的逻辑关系（与、或、非、互斥等）。
4. 将因果图转换成判定表。
5. 为判定表中每一列设计一条测试用例。

3.3.2 示例：优惠券使用逻辑

需求描述：用户下单时，如果订单金额满100元且优惠券状态为可用，则允许使用该优惠券；如果订单金额不满100元，则提示“订单金额不足”；如果优惠券已过期，则提示“优惠券已过期”。

列出条件和动作：

条件桩：

• C1：订单金额 >= 100 元
• C2：优惠券状态为可用

动作桩：

• A1：允许使用优惠券
• A2：提示“订单金额不足”
• A3：提示“优惠券已过期”

判定表如下：

这个例子比较简单，因为“订单金额不足”和“优惠券过期”都可能成为动作，所以需要结合具体需求。实际项目中需求往往更复杂，可能存在“条件之间互斥”或“组合触发同一动作”的情况，这就需要仔细分析需求逻辑。

3.3.3 注意事项

判定表在需求逻辑比较复杂时非常有效，但如果条件太多（比如超过6个），判定表的行列数会爆炸式增长。这时可以先用正交试验法筛选组合，再对核心组合设计用例。

3.4 正交试验法

3.4.1 方法介绍

正交试验法源自统计学，核心思想是用少量有代表性的组合代表全量组合。它特别适合“多因素、多水平”的场景。

这里的因素（Factor）指条件，水平（Level）指条件的取值。

3.4.2 示例

假设一个查询功能有三个查询条件，每个条件有两个取值：

• 关键词：填了 / 没填
• 分类：选择了 / 没选择
• 排序方式：升序 / 降序

全量组合是 2 × 2 × 2 = 8 种，直观上还可以接受。但当条件继续增加时，全量组合会指数级增长。正交试验则用少量用例覆盖两两组合。

实际应用中，可以直接使用现成的正交表工具或在线生成器，减少手工计算的工作量。

3.4.3 注意事项

正交试验法适合参数组合场景，比如筛选条件、配置项、环境组合等。但要注意，正交试验法覆盖的是“两两组合”而非所有高阶组合。对核心业务的高阶组合，仍然要单独补充用例。

3.5 场景法

3.5.1 方法介绍

场景法关注用户的实际操作路径，而不是单纯的输入条件。

场景法中的两个核心概念：

• 基本流：用户正常完成业务操作的流程。
• 备选流：在业务流程中出现异常、分支或替代路径时的流程。

场景法的优势是贴近真实用户行为，特别适合端到端的业务流测试。

3.5.2 示例：电商下单流程

基本流：

用户登录 → 浏览商品 → 加入购物车 → 提交订单 → 支付成功 → 订单完成

备选流可能包括：

备选流1：用户未登录直接提交订单 → 跳转登录页 备选流2：购物车为空时提交订单 → 提示“购物车为空” 备选流3：支付超时 → 订单状态变为“待支付” 备选流4：库存不足 → 提示“商品库存不足” 备选流5：支付失败 → 提示支付失败，保留订单

每一个备选流从基本流的某个步骤岔开，并最终可能回归基本流。

3.5.3 注意事项

场景法设计用例时，不要只画流程就结束。还要明确每个场景的入口条件、数据准备、预期结果，以及场景之间是否存在依赖关系。

3.6 错误推测法

3.6.1 方法介绍

错误推测法依赖测试人员的经验和对产品历史缺陷的了解，主动猜测“哪里容易出问题”。

常见的高风险位置包括：

• 首次新增/首版上线的功能模块
• 历史缺陷集中的模块
• 频繁变更的业务逻辑
• 涉及金额计算、时间处理、并发操作的模块
• 第三方接口对接点
• 数据迁移、缓存更新、定时任务等场景

3.6.2 注意

错误推测法不是“瞎猜”，而是有依据的针对性测试。经验丰富的测试人员可以在等价类、边界值等方法覆盖之外，用错误推测法补充一组高价值用例。但它不能作为唯一的用例设计方法，必须与其他方法配合使用。

4. 完整实战案例：登录功能测试用例设计

接下来用一个完整的登录功能需求，把上面的方法串起来。这个例子覆盖了从需求分析、用例方法选择、到最终用例清单输出的全过程。

4.1 需求描述

业务需求：用户可以使用手机号和密码登录系统。

具体要求如下：

• 手机号必须是11位有效手机号，不能为空。
• 密码必须是6到16位的字母和数字组合，不能为空。
• 登录时需要输入4位数字验证码。
• 验证码有效期为5分钟，过期后需要重新获取。
• 手机号、密码、验证码任一校验失败，均给出明确错误提示。
• 连续5次登录失败，账号锁定30分钟。
• 账号锁定期内，即使输入正确信息也不能登录。

4.2 需求拆解与测试点分析

先把需求拆解为可测的功能点：

4.3 使用等价类划分法设计用例

手机号：

密码：

验证码：

4.4 使用边界值分析法补充用例

密码长度边界：

• 5位（低于下限）
• 6位（下限）
• 7位（下限内点）
• 15位（上限内点）
• 16位（上限）
• 17位（超过上限）

验证码过期时间边界：

• 4分59秒（未过期）
• 5分00秒（临界点）
• 5分01秒（已过期）

错误次数边界：

• 第4次失败（未触发锁定）
• 第5次失败（触发锁定）
• 锁定29分钟后（仍然锁定）
• 锁定30分钟整（解锁）
• 锁定30分钟零1秒（已解锁）

4.5 使用场景法补充业务流用例

场景分析：

4.6 完整用例示例（节选）

以“场景6：连续失败锁定”为例，看一个完整用例怎么写。

4.7 用例优先级划分建议

• P0（阻塞级）：核心正确性用例、数据安全用例，比如正常登录成功、输入正确密码但账号被锁定。
• P1（高优先级）：大多数业务功能用例，比如手机号格式错误、密码错误、验证码过期。
• P2（中优先级）：异常场景和边界场景，比如验证码包含字母、密码正好16位。
• P3（低优先级）：体验类、非功能类用例，比如界面提示文案的显示位置。

5. 测试用例的管理与评审

5.1 用例评审的必要性

很多团队没有用例评审环节，或者只是走过场。这导致问题是到了测试执行阶段才被发现，比如用例与需求不一致、用例覆盖缺失、用例步骤不可执行等。

一份专业的测试用例应当经过评审，主要评审维度如下：

• 需求覆盖：是否所有需求点都有对应的用例。
• 方法正确性：用例设计方法是否合理，边界值是否遗漏。
• 可执行性：步骤是否清晰，数据是否明确。
• 预期结果的准确性：预期结果是否可验证、无歧义。
• 冗余检查：是否存在大量重复或优先级不合理的用例。

5.2 测试用例与需求追踪矩阵

需求追踪矩阵（Requirement Traceability Matrix，简称 RTM）用于建立需求与测试用例之间的映射关系。

一个简化的 RTM 示例：

RTM 的价值在于：当需求发生变更时，可以快速定位受影响的用例；测试结束后，也可以用来输出测试覆盖率报告。

5.3 用例维护更新

测试用例不是一次性产物，而是需要持续维护的核心资产。

以下情况需要更新用例：

• 需求变更。
• 缺陷修复后暴露了新的测试点。
• 测试执行中发现用例本身设计不合理。
• 重构或优化了业务流程。
• 新增了异常场景或边界场景。

6. 常见问题与解决方案

7. 测试用例设计最佳实践

7.1 需求先行，业务理解优先

用例设计不是从写用例开始的，而是从理解需求开始的。在动手设计之前，需要先弄清楚：

• 这个功能面向什么用户？
• 核心业务价值是什么？
• 哪些路径使用频率最高？
• 哪些异常会带来最大的资损或安全问题？

只有把一个需求理解到位，才能高质量地拆解测试点。

7.2 多种设计方法结合，而不是只用一种

不同方法各有适用场景，所有输入框相关的功能，优先考虑等价类 + 边界值；多条件组合的业务逻辑，优先考虑判定表；核心用户操作链路，优先考虑场景法；参数组合过多的查询模块，优先考虑正交试验。

7.3 用“正向用例 + 负向用例 + 边界用例”三维结构组织用例

每设计一个功能模块的用例，都按三个维度检查：

• 正向用例：功能正常工作的路径。
• 负向用例：非法输入、异常操作、权限不足、数据不存在等。
• 边界用例：数据边界、时间边界、次数边界、数量边界。

7.4 测试数据与环境准备前置

测试用例设计完成后，还要同步准备测试数据和环境。不要把数据准备留到执行阶段才临时处理，尤其是涉及账号状态、订单状态、时间条件等特殊数据时，提前准备好可以大幅提升执行效率。

可以建立测试数据清单，设计用例时同步标注每条用例需要的数据准备动作。

7.5 为回归测试保留一份稳定的“核心用例集”

每个版本都跑全量用例是不现实的。建议在用例设计阶段就分层：

• 冒烟用例集：版本提测后的第一道关卡，耗时控制在15分钟以内。
• 核心功能用例集：覆盖主营业务流程，每轮测试必须执行。
• 回归用例集：版本上线前选择性执行。

7.6 用例设计要兼顾安全测试视角

在测试用例设计过程中，必须加入安全视角的用例。以下安全场景是设计用例时的必选项：

• 输入框提交 SQL 特殊字符和脚本内容，检查是否会被执行。
• 未登录状态直接访问需要鉴权的接口或页面。
• 通过修改请求参数尝试越权访问其他用户数据。
• 测试环境是否使用了脱敏数据，严禁将真实用户隐私数据用于测试。

7.7 自动化用例与手工用例分层规划

用例设计阶段就应该明确哪些用例适合自动化，哪些用例保留为手工执行。自动化用例适合以下特征：

• 脚本稳定，不频繁变更。
• 核心回归路径。
• 数据准备可控。
• 断言清晰，预期结果可程序化校验。

而涉及视觉体验、复杂交互、模糊判断的测试点，更适合保留为手工用例。

8. 一份可以直接使用的用例设计检查清单

在输出测试用例之前，用下面这份清单逐项自检，可以覆盖绝大多数常见遗漏项：

• [ ] 是否覆盖了需求中的所有正常流程？
• [ ] 是否覆盖了所有异常流程和非法输入？
• [ ] 是否分析过输入边界、长度边界、时间边界、次数边界？
• [ ] 是否覆盖了权限相关的场景（未登录、低权限、越权访问）？
• [ ] 是否覆盖了数据为空、数据不存在、数据重复的场景？
• [ ] 是否覆盖了第三方依赖异常（接口超时、返回错误）？
• [ ] 是否覆盖了并发操作（同时提交、重复点击）？
• [ ] 是否覆盖了数据一致性场景（事务中断、部分成功）？
• [ ] 每条用例是否都有明确且可验证的预期结果？
• [ ] 每条用例是否都有独立的编号和明确的优先级？
• [ ] 是否建立了用例与需求的追踪关系？
• [ ] 是否准备了执行所需的环境、数据和账号？

建议把这份清单保存下来，每次完成用例设计后逐项打钩。坚持一段时间后，会发现漏测率明显下降，用例评审时被挑出的问题也会越来越少。

测试用例设计是一项需要持续打磨的硬技能，而不是“会用工具写点步骤”那么简单。把方法用熟练，把清单变成习惯，任何功能到你手上，都能形成一张严密、高效、可执行的测试网。如果这篇文章对你有帮助，可以收藏备用，也欢迎在实际项目中实践后回来分享你的用例设计经验。