企业官网建设流程全解析

测试用例设计方法，说到底是在设计“如何发现问题”

干测试这些年，我面试过不少人，也让别人面过。有一个问题几乎每次都会出现：给你一个登录页面，你怎么设计测试用例？看起来简单，能完整答出等价类、边界值、场景法的人不少，但能把用例设计得既有覆盖度又有优先级，还能讲清楚“为什么这么设计”的人，真的不多。

这说明一个事实：测试用例设计这件事，入门容易，做深难。难不在于你会背多少种方法，而在于你面对一个真实需求时，能不能快速判断“这里该用边界值，那里该用场景法，这个组合需要用判定表”，以及在时间和成本的压力下，怎么取舍。

这篇内容我想把测试用例设计中真正有价值的东西梳理一遍。面向刚入行的测试新人，也面向写了两三年用例但总觉得是在“拼数量”的朋友。我会按照从思路到方法、从案例到工具的顺序来讲，最后聊聊现在很火的AI生成测试用例，我用过一段时间，感想很多，一并写出来。

1. 先想清楚：测试用例设计到底在解决什么问题

1.1 用例设计不是“写用例”，而是“拆需求”

很多新手拿到需求文档，第一反应是赶紧把功能点列出来，一条条变成用例。比如“用户注册”功能，写出“输入正确的手机号”“输入错误的手机号”“输入正确的密码”“输入空密码”……这种拆法不能算错，但你会发现用例越写越多，却不知道哪些是重点，哪些其实重复了，哪些关键场景压根没覆盖。

我在实际工作中最深的体会是：测试用例设计的本质，是把一个模糊的、人说的话，转变成一个明确的、可验证的、机器能执行的结构化描述。这个过程真正考验的是你对需求的理解能力，而不是打字速度。

所以每接到一个需求，我做的第一件事从来不是打开用例管理工具，而是先拿一张白纸，回答问题：

• 这个功能给谁用？用户在哪一步触达它？
• 核心流程是什么？有多少条分支路径？
• 哪些数据会发生变化？变化前、变化后各是什么状态？
• 失败的情况下，系统应该给出什么反馈？
• 有哪些约束条件来自业务规则，哪些来自技术实现？

这些问题想明白了，用例设计方法才有用武之地。等价类也好、边界值也好，本质上都是在回答这些问题中的某一类。

1.2 方法要解决的四类问题

我把测试用例设计要解决的问题总结成四类，你做任何功能测试都可以用这个框架来对照：

第一类是“数据怎么选”。一个输入框能接收的数据范围是无穷的，你不能把所有值都测一遍。需要从无数的输入中挑出有代表性的一小部分，这就是等价类划分和边界值分析干的事。

第二类是“条件怎么组合”。多个输入条件、多个前置状态放在一起，会产生非常多的组合。比如搜索功能有“关键词”“筛选分类”“排序方式”三个条件，每个三四个选项，排列组合就几十种。人工穷举不现实，判定表法和正交试验法就是干这个的。

第三类是“流程怎么走”。用户不会按测试人员的思路点按钮，他们会乱点、会跳步、会中途放弃。场景法能帮你覆盖真实的用户操作路径，而不是孤立的单点功能。

第四类是“哪里容易出错”。前面几类方法是基于逻辑推导的，但软件的很多问题藏在经验里。哪些字段在真实业务中经常出问题，哪些操作会触发经典的Bug，这就是错误推测法的价值。

理解了这四类问题，你就不会迷茫了。拿到需求先判断它属于哪种情况，然后选择合适的工具，而不是把所有方法都堆上去。

1.3 为什么不能靠“感觉”设计用例

刚入行的时候，我的leader跟我说过一句话：测试用例的价值不在数量，而在覆盖逻辑。靠感觉写用例，你今天能想到的点，明天可能就想不到了；你在这个项目积累的经验，换个项目就不适用了。但方法不一样，方法是一种可复用的思维框架，它不依赖某个人的灵光一现。

还有一层原因，凡是靠“感觉”产出的东西，都很难被评审和量化。用例写完了，代码覆盖率是多少，需求覆盖情况如何，有没有遗漏，这些都要有标准。标准从哪里来？就是从设计方法推导出来的，等价类覆盖完整没有、边界值选点对不对、分支组合全不全，都可以逐项检查。

所以我一直强调，测试用例设计不是“写作”工作，而是“设计”工作。设计的核心是结构化思维，这也是这篇文章想帮你建立的最重要的能力。

2. 核心设计方法逐个拆解：什么时候用、怎么用、怎么避坑

2.1 等价类划分：把无限输入变成有限代表

等价类划分是我认为最基础、也最容易被低估的方法。它的核心思想是：把输入条件按照“是否触发相同类型的处理逻辑”分成若干类，从每个类中取一个代表值进行测试。如果同一类里的一个值通过了，可以合理推断该类的其他值也会通过。

举个例子，一个“年龄”输入框，要求是18到60岁的整数。从等价类角度，你可以划出有效等价类“18到60之间的整数”，无效等价类可以有“小于18的整数”“大于60的整数”“非整数”“非数字字符”“空值”。注意，无效等价类往往不止一个，因为系统对不同类型无效输入的处理逻辑可能完全不同。

这里有一个新手常犯的错误：把“非数字字符”和“空值”归为一类，觉得反正都是报错。但实际上，很多系统对这两类输入走的代码分支是不同的，比如非数字字符可能在前端就拦截了，空值可能到后端才校验。设计用例时，每一条独立的校验规则，都应该对应一个独立的等价类。

我把设计时的重点整理成一个简单的操作流程：

• 第一步，找出所有输入条件。不管是用户输入的、系统带出的还是接口传入的，都列出来。
• 第二步，给每个输入条件划分有效和无效等价类。划分依据不是“正确/错误”这种模糊概念，而是“处理逻辑是否相同”。
• 第三步，为每个等价类编写一个用例。有效等价类组合成正向用例，无效等价类一定要单独设计用例，一条用例只覆盖一个无效等价类，否则你无法判断是哪个条件导致的报错。
• 第四步，补充所以需要验证的边界值，这部分交给下一个方法处理。

注意：无效等价类的用例必须单独写。别为了省事把多个无效条件放在一条用例里，一旦测试失败，你无法定位是哪个条件触发了Bug，排查成本翻倍。

2.2 边界值分析：Bug最喜欢在边界安家

如果只让我选一种投入产出比最高的用例设计方法，我选边界值分析。几乎所有程序员在处理“小于等于”“大于等于”“区间内”这类逻辑时，都会用<=、>=、>、<这一组运算符，而运算符写错一个符号，Bug就出现在边界上。

边界值选点有一个经典的口诀：上点、离点、内点。以上文年龄输入框“18到60”为例：

• 上点：刚好在边界上的点，即18和60。
• 离点：离边界最近的那个点。18的离点是17，60的离点是61。
• 内点：边界范围内的任意一点，比如30。

这里需要注意，不同资料对“离点”的定义有差异，有的说“离点就是边界外最近的点”，有的说“离点包括边界两侧最近的点”。我在实际工作中采用的标准是：如果是闭区间，上点本身要测，边界外最近的那个点也要测；如果是开区间，则要测开区间边界外最近的那个点以及边界内最近的点。归根到底，你要保证两个东西：边界这两个值本身，以及边界两侧紧挨着的这两个值，都进入用例。

边界值分析不是只能用在数字上。字符串长度有边界，列表条数有边界，文件大小有边界，时间范围有边界。凡是能标注出上限、下限、最大值、最小值的地方，都是边界值分析发挥作用的地方。

实际项目中，边界值往往和等价类配合使用。先划分等价类，然后从每个等价类内部挑边界上的代表性数据来测。比如密码“8到20位”，等价类定完以后，8、7、9、20、21这五个值是必测的。

2.3 判定表与因果图：多条件组合不再靠穷举

当被测功能有多个输入条件，而且这些条件之间存在逻辑关系时，比如“条件A成立且条件B成立时才执行操作X”，等价类和边界值就不够用了。这时我会用判定表。

判定表的构造逻辑很清晰：列出所有条件，列出条件的真假组合，列出每个组合下应该触发的动作，然后每一列就是一条用例规则。以“登录功能”为例，三个条件——用户名是否存在、密码是否正确、账号是否锁定，每个条件有“真/假”两个取值。理论上组合数是2的三次方等于8种，列出所有组合后，每条规则对应一个预期结果：登录成功、提示用户不存在、提示密码错误、提示账号锁定。

这个例子里有8种组合，看起来不多，但条件一旦增加到六七个，组合数就是指数级爆炸。这时候就需要把不相干的条件合并。判定表本身有一个处理技巧：如果某些组合不论条件怎么变，动作都一样，就可以用“无关”标记，并合并对应的列。

因果关系图是判定表的图形化前置步骤，它通过画因果图来分析条件之间的约束关系，然后把图转成判定表。实际工作中我很少画因果图，大部分项目直接用判定表就够了，因为画图这件事本身也要耗费时间。但当你面对的是复杂的业务规则系统，比如保险产品定价、营销活动优惠叠加，因果图能帮你理清条件之间的“与、或、非”关系，值得一试。

在设计判定表用例时，我强烈建议你用表格工具来做，Excel或者在线表格都行，列一个“条件+动作”的矩阵，一列一列地检查。这样做出来的用例表，评审的时候特别清楚，别人一眼就能看出你的逻辑是否完整。

2.4 场景法与流程图法：从用户视角把流程走通

单独的功能点测完了，不代表功能能用。用户不会只做“输入正确用户名和密码”这一件事，他们会从入口进来，经过一连串操作，再到结果。这条完整的路径，靠等价类和边界值是覆盖不了的，必须用场景法。

场景法的基础是事件流。一个业务功能的基本流程（Happy Path）是主事件流，分支、失败、异常处理、重试、取消都属于备选事件流。每个事件流都是场景，每个场景都需要被测试覆盖。

我用一个电商平台“提交订单”来举例。主事件流是：选择商品→加入购物车→结算→填写收货地址→提交订单→支付成功→生成订单。备选事件流包括：购物车中的商品库存不足、地址未填写、支付超时、支付成功后回调通知失败、订单生成后用户取消支付。每个备选事件流都对应不同的系统行为，比如库存不足要提示并锁定库存还是直接拦截。

画流程图是场景法落地的好工具。不需要用什么专业软件，画图工具里把方框和箭头拖一拖，主流程一条线，分支用不同颜色的线标出来，异常情况用虚线标出来，流程就清楚了。画完图你再去写场景用例，几乎不会漏。这也是我发现很多老测试的习惯，先画图再写用例，结构化思维一目了然。

场景法还有一个变体叫流程图法，它在场景法的基础上更强调每一步的输入、输出、状态变化，适合在系统状态复杂的项目中配合状态迁移图使用。

2.5 正交试验法：组合爆炸时的“偷懒”方案

条件多、每个条件取值也多，全排列组合数量巨大，这种时候正交试验法是标准答案。它的核心思想是：从全量组合中挑选出具有代表性的组合进行测试，这些组合之间保持“均匀分散、齐整可比”的特性。

具体的操作是这样的：先确定因素和水平。继续用搜索功能举例，三个因素——关键词类型、筛选分类、排序方式，每个因素有3个水平。全量组合是3×3×3等于27种。如果做成正交表，L9(3⁴)，四列三水平，选其中的三列，只需要9组测试组合，覆盖率能保住大部分。

实际项目里，正交试验法的执行门槛在于查表。网上能搜到标准正交表，L4、L8、L9、L16、L25、L27这些常用表都很好找。你要做的是把因素和水平对应到表里去。

有一个经验：先判断组合之间的业务逻辑是否有强相关性。如果很多组合本身在业务上就不成立，比如“寄件人和收件人是同一个人”的某些组合，那么用正交表之前先排除无效组合，再套正交表，能节省不少无效用例。

2.6 错误推测法：靠经验补刀，但别只靠它

错误推测法看起来很玄，因为它没有严格的推导逻辑，完全依赖测试人员的经验和对系统实现方式的了解。我自己的理解是：它不是一种独立的设计方法，而是前面所有方法的补充。

哪些地方容易出Bug？我的个人清单里包括：

• 输入超长字符、含特殊符号、Unicode字符，比如表情符号。
• 连续快速提交，比如双击提交按钮。
• 网络中断后恢复，比如弱网下提交请求。
• 分页数据的边界页，比如只有一页数据时翻页、最后一页删掉最后一条数据。
• 权限边界，比如非管理员访问管理页面。
• 数据被其他操作并发修改，比如两个人同时编辑同一条记录。
• 删除操作之后的状态，比如删除当前正在浏览的商品分类。
• 缓存和刷新，比如修改配置后不刷新页面直接操作。

每做一个项目，我都会把在项目里发现的经典Bug记录到一个“常见缺陷清单”里。到了下一个项目，拿着这个清单去对照需求，看有没有类似场景。这套清单才是错误推测法的真正载体，也是测试经验和价值的沉淀。

提醒一句：错误推测法只能作为补充手段。别把宝全押在这上面，它的覆盖率是不确定的，必须建立在等价类、边界值、场景法这些确定性方法的基础上。

3. 从需求到用例：一次完整的用例设计实操

3.1 项目背景与需求拆解

方法讲完，我们走一遍真实流程。我拿一个最常见的“用户注册”功能来演示，因为大家都有业务直觉，不需要额外解释背景。

假设需求是这样描述的：用户通过手机号和密码注册。手机号必须是中国大陆11位手机号，密码为8到20位，必须包含字母和数字。注册时需勾选“我已阅读并同意用户协议”，勾选后才能点击注册按钮。手机号已注册时提示“该手机号已被注册”。注册成功后自动登录并跳转到首页。

需求不长，但信息量不小。我拿到手会先画一个简单的思维导图，把需求拆成几个维度：

• 页面交互：手机号输入框、密码输入框、协议勾选框、注册按钮，每个控件是否有默认状态、最大长度限制、格式校验时机。
• 业务规则：手机号格式、密码规则、协议必选、手机号唯一性校验。
• 异常流程：手机号已注册、网络异常、服务端返回错误。
• 成功流程：注册成功、自动登录、跳转首页。

3.2 测试点与用例编号设计

拆解完以后，列出测试点清单，这是写用例前的最后一步。我习惯用表格来整理：

用例编号也很重要。我比较推荐的编号规则是“模块名-ST-功能名-序号”，比如REG-ST-001表示注册功能正向用例第一条，REG-AT-003表示注册功能备选用例第三条。编号规则一旦定下来，全组统一，后面追踪需求和统计用例数量都会方便很多。

3.3 用例设计过程演示

下面用实际用例来演示方法怎么落到具体场景中。先看正向用例，覆盖手机号、密码、协议都合法的成功路径：

然后看边界值用例。密码是8到20位，必须包含字母和数字，边界点就是8位、20位、7位、21位。单独列出这些用例：

再看无效等价类。手机号可以划分出：非11位数字、含非数字字符、非13X/15X等号段但满足11位（如果是通过正则校验）、空值。密码可以划分出：全数字、全字母、不含数字、不含字母、空值。这些各占一条用例，每条只覆盖一个无效条件。

3.4 用例评审与维护

用例设计完了不等于工作结束。我团队里有一条强制规范：用例必须经过评审才能进入执行阶段。评审时重点看三件事：逻辑是否正确、覆盖是否完整、优先级是否合理。

评审的形式不复杂，拉着开发和产品，过一遍用例，尤其是涉及业务规则的地方，开发能提前告诉你哪些校验在服务端做、哪些在前端做，产品能确认预期结果是否与需求一致。这个环节很值得投入时间，因为发现问题越早成本越低。

用例上线之后也要持续维护。功能迭代了，用例要同步更新；线上发现漏测的Bug，要回溯是哪一步设计遗漏了，然后补用例。我用一个简单的Excel来追踪“线上漏测Bug与用例补充记录”，每补一条就标记一下，到季度复盘的时候，这一份记录比任何报告都有说服力。

4. 常见问题与排查技巧实录

4.1 用例设计中最常踩的坑

第一个坑是“用例写成了操作说明”。这是新手最常见的问题，每条用例只写“输入手机号和密码，点击登录，系统正常跳转”，没有数据、没有预期结果、没有边界覆盖。这种用例不叫测试用例，叫操作手册。好的用例应该能让人照着执行，不需要动脑就能知道该输入什么、看到什么才算通过。

第二个坑是“用例之间重复度高”。一个功能写了上百条用例，仔细一看很多步骤一样，只是输入数据略有差别。这种情况本质上还是不知道用等价类去归类，把大量冗余数据当成了用例。解决办法很简单，先划分等价类，同一类的代表值只要一个。

第三个坑是“只关注正向流程”。新手写用例天然倾向于把“能跑通”的路径写得很全，但异常、分支、中断、失败恢复这些场景经常漏掉。实际工作中恰恰是这些异常路径最容易出Bug，而且一旦出了就是生产事故级别的。我有一次在生产环境遇到一个支付回调重复处理的Bug，复盘时发现用例设计里压根没有“支付成功后回调通知重复触发”这个场景，因为大家默认回调只触发一次，这个教训让我后来每条用例设计都强制追问一句：这条路径失败会怎么样？

第四个坑是“不评估优先级”。所有用例一律“高”优先级。结果就是真正重要的用例插不了队，低价值的用例又占据了执行时间。我个人的经验是一个功能200条用例里，真正高优先级的可能只有40条，高优先级用例应该覆盖核心功能和重大风险，中优先级覆盖次要功能，低优先级是一些边缘组合和体验问题。

4.2 用例无法覆盖的盲区

有些东西靠用例设计是覆盖不了的，这里一并说明，避免你走入死胡同。第一类是性能问题，单条用例验证的是功能和逻辑，并发、峰值、资源消耗这些要靠性能测试方案。第二类是真实环境下的数据质量问题，测试环境的数据太干净，生产环境有大量历史脏数据，用例设计时可以考虑兼容脏数据，但不可能穷尽。第三类是总体的用户体验，用例是分步骤验证功能，整体流程是否顺畅、页面响应是否及时，需要全局视角来审视。

认识到方法有边界，反而能让你更高效地分配精力。测试的核心能力在于决策：把有限的测试资源分配到最容易出错的地方。用例设计能力只是这个决策能力的一个支撑。

5. 用AI生成测试用例：实测经验与边界

5.1 AI生成用例的真实水平

最近AI生成测试用例的话题非常火，热搜词里就有LangChain自动生成测试用例、Cursor自动生成测试用例、AI生成测试用例邮箱不提太多，很多人问我到底靠不靠谱。我用了一段时间，包括直接让大模型写用例，也包括试试LangChain这类框架自动生成，我的结论是：AI生成的用例，当草稿用很好，当最终交付物不合格。

举一个实测的例子。我把注册需求复制给大模型，让它生成测试用例，它给的输出里有等价类、边界值、场景分支，格式规范，甚至还有优先级和前置条件。看起来像模像样，但仔细看就会发现一些问题。比如它把“手机号已注册”的提示语写成了“该手机号已被注册”还是“该号码已存在”，它无从判断，只能编一个，而实际提示语必须和产品文档完全一致，这在用例里是硬性要求。

再比如，AI经常把无效等价类合并，一条用例里同时输入了错误手机号和不含数字的密码，然后断言“注册失败”。这样的用例逻辑上是通的，但一旦执行失败，你无法判断是手机号校验拦截了还是密码校验拦截了。这就是我在前面提到的“一条用例只覆盖一个无效条件”的原则，AI不经过训练是不会主动遵守的。

5.2 如何设计提示词让AI产出高质量用例

AI不是不能用，关键在你怎么用。我摸索出一套“喂给AI的用例设计提示词”格式，效果明显改善，分享给你参考：

• 第一步，提供足够的上下文。把需求描述、业务规则、已知的接口行为都给它。信息越完整，AI生成的用例越贴近实际。
• 第二步，明确要求它使用哪些设计方法。如果你想让它生成等价类用例，就明确说“请按等价类划分方法，区分有效等价类和无效等价类”。
• 第三步，定义用例格式。告诉它用例要包含编号、标题、前置条件、操作步骤、预期结果、优先级这些字段，并且给出一个示例模板。
• 第四步，要求它标注优先级，同时让它自检：“请检查每条无效等价类是否独立成用例。”

我实际用过的提示词模板大概是这样的：

你是一名资深测试工程师。请为以下需求设计测试用例。 需求：用户通过手机号和密码注册。手机号必须是中国大陆11位手机号， 密码为8到20位，必须包含字母和数字。注册时需勾选“我已阅读并同意 用户协议”，勾选后才能点击注册按钮。手机号已注册时提示 “该手机号已被注册”。 要求： 1. 分别使用等价类划分法、边界值分析法、场景法设计用例。 2. 每条用例包含：用例编号、用例标题、前置条件、操作步骤、预期结果、优先级。 3. 无效等价类的每条用例只能覆盖一个无效条件。 4. 用例覆盖产品需求中所有提示语，提示语内容必须与需求完全一致。 5. 请自检是否存在遗漏的边界点和分支场景。

这样生成出来的用例，可参考性已经相当高。我再做一遍人工评审，补充数据和修正提示语，基本就能用了。

5.3 AI用例的局限性与人工兜底

我用着用着，逐渐摸清了AI用例设计的三个边界。第一，AI对“隐性需求”没有感知。比如“注册成功后自动登录”，这个状态跳转的逻辑AI能写出来，但“自动登录”对后续“个人中心刷新用户信息”的影响，AI不会主动推导。第二，AI对“业务价值的优先级”判断不准。它不会知道支付功能比个性签名功能重要，优先级都是按它训练数据里的“通用常识”来标，对具体项目不够准确。第三，AI不具备“怀疑精神”。用例设计的一个重要环节是质疑需求本身，“这个提示语不合理”“这个地方的业务规则有歧义”，AI会顺着需求描述往下写，不会提出异议。

所以我的建议是：把AI定位成一个“高效的用例设计助理”，让它在你的审核下产出一版草稿，然后你对每一个字段、每一条预期结果、每一个优先级做审阅。一个有意思的现象是：让AI生成用例反而比从零开始写用例更难偷懒，因为AI的产出常常看起来很完善，若你下意识地不加质疑地接受，反而容易踩坑。这一点特别值得留意。

5.4 工具与流程建议

工具选择方面，如果你只是在写单点的功能用例，直接用ChatGPT或国内的大模型对话产品就行，不需要搞复杂的框架。它的用法就是对话式地把需求贴进去，让它按你的格式输出。如果你有批量需求，比如一个版本迭代有几十个接口、几十个页面，那可以考虑LangChain这类框架，它能批量处理需求文档、提取字段、按模板生成用例，再配合一些脚本自动填入用例管理工具。但这里要注意，LangChain的能力边界取决于你输入的需求文档质量，文档不清晰，AI生成的东西只会更模糊，这一点和人工测试一样。

我的建议流程是：需求评审完成→人工梳理测试点和业务规则→用AI批量生成草稿用例→人工逐条评审修正→评审通过后入库执行→版本迭代后AI增量生成新模块用例。

这套流程我走了几个月，整体的感受是：AI最大的价值不是替你做判断，而是帮你在攒“第一版”的时候节省大概40%到60%的机械时间，真正决定用例质量的仍然是你对业务的理解和对设计方法的熟练程度。

最后说一点个人体会

测试用例设计这门手艺，越往后做越有味道。最初你靠背方法，写出来的用例四平八稳但没什么灵魂，就像按菜谱做菜，味道不会差但也不会惊艳。干了两三年，接触过的项目多了，踩过的坑多了，你会开始主动问“哪里最容易出错”，这时候用例就不只是需求说明书的分行版本，而是真正服务于“找Bug”这个目的的工具。

如果你现在还处于“用例写得不太像样”的阶段，我给你一个具体的建议：找一个你最近测试的功能，把它的用例全部翻出来，对照这篇文章里的方法，逐一检查哪里有遗漏、哪里是冗余、优先级是否合理。改完以后你会发现，好的用例不是更多的用例，而是每一条都有它存在的理由。这个感觉找到了，测试用例设计这关就算真正过了。