企业官网建设流程全解析

简介：面向软件测试初学者与需要系统练习用例设计的从业者，这份文档围绕测试用例的经典实例展开，梳理了用例编写的基本要点与黑盒测试的实操方法，可用于课堂练习、面试准备与日常测试用例编写参考。内容涵盖优秀用例应包含的十二项信息、B/S 结构登录功能的黑盒测试用例，以及等价类划分、边界值分析、错误推测、因果图和判定表驱动等方法的实例推演，如三角形类型判定、NextDate 函数日期范围和自动售货机投币逻辑的用例设计。资源为 1 个 doc 文件，压缩包约 329KB，体积轻巧，便于快速通读与打印标注。目前已有 4782 人学习下载，说明其对掌握用例设计思路具有较好的参考价值，读者可对照其中的实例模板，逐步建立从需求分析到用例覆盖的完整思路，减少漏测与重复设计。

1. 从一条没人敢照着执行的登录用例说起

软件测试用例的经典实例里，登录、三角形判定、NextDate、自动售货机这几个题目被反复引用，原因不是题材老旧，而是它们把「需求怎么翻译成可判定的预期结果」这件事暴露得最彻底。带过的项目里，最常见的翻车不是用例数量不够，而是写了几十条，换个人接手却根本不敢照着执行——预期结果写着「系统提示错误」，测试数据写着「正确用户名」，前置条件写着「已登录」，全是只有原作者才看得懂的暗语。这套方案面向三类人：要交课程设计或毕业设计的同学、要给团队从零建一份可复用用例库的从业者、以及需要把测试方案写进交付文档的工程师。先把字段和模板定死，再用黑盒方法把功能拆成可执行用例，最后用覆盖度自检和评审把质量兜住，三步走完，一份用例集才算立得住。

2. 用例字段的取舍：12 项信息怎么落成一份能评审的模板

一份用例集能不能被第二个人接手执行，取决于字段有没有把隐含信息写死。经典实例里给出的 12 项信息看着繁琐，实际逐条对下来会发现，真正需要人手写的只有八项左右，剩下的完全可以交给用例管理工具自动产生。这一章要解决的问题是：把 12 项字段按「谁产生、什么时候产生、缺失会出什么事」重新分一次类，落成一份团队里所有人都能照着填的模板，再补上用例编号和依赖关系的编排规则。模板定下来之后，后面所有方法论的产出都有地方安放。

2.1 12 项字段逐条拆解：哪些必须手写，哪些交给工具

软件或项目名称、版本号这两项常被当成形式主义省掉，实际是最容易埋雷的地方。用例库里同时存在 v1.2 和 v2.0 两套登录逻辑时，如果用例上不标版本，执行的人拿旧用例去测新版本，失败记录会直接冲进缺陷池，排查半天发现是版本错配。内部版本号通常建议带上构建号，取构建产物里的实际标识，而不是随手写个「最新版」。功能模块名的作用是组织用例树，它应该和需求文档的目录一一对应，这样需求一变，能顺着模块名把受影响的用例全部捞出来。

用例的简单描述写的是「这条用例要验证什么」，不是「怎么操作」。写成「验证用户名超长时输入框拒绝录入」比写成「输入一长串字符看会怎样」要有价值得多，因为前者在评审时能直接判断对错，后者只能靠执行者自己理解。参考信息填需求编号或设计文档的章节号，这项决定了后面能不能算出需求覆盖率——没有它，用例集就只是一堆散件。

依赖关系是最容易被漏掉、又最容易在持续集成里翻车的一项。「本用例依赖 TC2 和 TC4」这种话必须显式写出来，否则执行机单独跑 TC5 时一定失败，然后有人花半小时去查一个根本不存在的缺陷。前置条件是把依赖之外的所有执行前提摊开：账号是什么、权限开到哪一级、数据库里要先有什么数据、环境变量怎么配。前置条件写「已登录」是不合格的，写「使用 test 账号登录，该账号拥有普通用户权限、未绑定手机号」才算交代清楚。

用例编号需要一个稳定规则，软件简写加功能块简写再加序号，例如 ORD-LOGIN-001。步骤号、操作步骤描述、测试数据描述三列分开写，操作和数据不要揉在一句话里，因为同一套操作配不同数据往往就是好几条用例。预期结果是最重要的一项，也是最容易被写虚的一项，它必须能被断言：「提示：请检查用户名和密码的输入是否正确」是可判定的，「提示错误」不可判定。实际结果这一列在有缺陷管理工具时可以省略，工具会记执行结论。开发人员必须有，它决定了缺陷单指派给谁；测试人员可有可无，工具的执记录里天然带着。执行日期同理，交给工具打时间戳。

提示：12 项字段里，实际结果、测试人员、执行日期这三项如果还在用手写，说明用例库和缺陷管理工具是两张皮，越早打通越省事。

2.2 一份可直接套用的用例模板

把上面拆解的结果固定成表格，团队里所有人按同一份模板填，评审时才有共同语言。下表是字段级的填写规范，右侧给的是可以直接照抄的示例，示例里的项目名和账号都是虚构代称。

模板的价值不在表格本身，而在它把「写用例」这件事从自由发挥变成了填空。填不满的行就是需求没写清的地方，这比用例写得漂不漂亮重要得多。

2.3 用例 ID 与依赖关系的编排规则

编号规则里有一条铁律：序号一经分配不再复用。删掉的用例保留空号，编号就跳到下一个，宁可编号列表有洞，也不要让历史缺陷单里的 ORD-LOGIN-007 指向一条完全不相干的新用例。血泪经验是，早期为了编号好看做过一次重排，结果三个月后翻缺陷单，所有引用全成了黑匣子，只能靠提交时间猜当时测的是哪条。

依赖关系要按有向无环图来管，不允许出现循环依赖。常见的错误做法是把「已登录」做成一条独立的登录用例，然后让所有业务用例都依赖它，整棵依赖树变得又深又脆。通常的做法是把登录态、数据库初始数据这类共享前提做成测试夹具，在用例的前置条件里声明夹具名称，用例之间只保留真正的业务先后依赖，比如「提交订单」依赖「加入购物车」。这样单条用例可以独立执行，持续集成里跑增量用例才有意义。

依赖关系还有一层隐性作用：它标出了用例的执行顺序下界。评审时如果发现某条用例的依赖链超过三层，基本可以判定它的前置条件没拆干净，需要把中间状态用夹具直接构造出来，而不是靠一条条用例往上爬。

3. 黑盒用例实战：把 B/S 登录需求拆成 10 条可执行用例

登录功能是最适合拿来练手的被测对象：逻辑简单到不会让人分心，边界又足够多到能暴露问题。这一章用一个 B/S 结构的登录需求做完整推演，从需求句子一路拆到带编号的用例表，再补上原始用例集里缺失的那几条。之所以值得花一整章讲登录，是因为它把「需求怎么写、可测点怎么抽、预期结果怎么定」这条链路走得最完整，换成任何业务模块都能照搬这套动作。

3.1 从需求句子到可测点：输入、动作、输出三段拆法

拿到的需求描述是四句话：用户在地址栏输入地址后显示登录界面；输入用户名和密码点登录，系统自动校验并给出提示；用户名或密码任一未输入，系统给出提示；连续三次未通过验证时自动关闭浏览器窗口。这四句话直接抄进用例里没有意义，需要用「输入—动作—观察点」三段法逐句拆。

第一句的输入是地址，动作是访问，观察点是页面元素是否完整、是否与详细设计一致。这里能拆出至少三个可测点：元素存在性、元素布局、以及在不同浏览器下的渲染差异。原文设定的浏览器是 IE6.0 SP4，放到今天的项目里这个维度要换成一个兼容性矩阵，把主流浏览器版本列进去，而不是在每条用例里硬编码一个版本号。

第二句拆出两个分支：校验通过后的页面跳转，以及校验失败后的提示文案。分支一定要拆开写，不要用「或」连接，一条用例只验证一个结论，否则执行时通过了一半算不算通过，会变成扯皮。第三句至少要拆两条，缺用户名和缺密码是两种不同的输入组合，很多系统给出的提示文案并不相同。第四句是安全策略，拆出来的可测点包括：第三次失败后的提示、浏览器是否真的关闭、重新打开浏览器后失败计数是否重置、换一个用户名登录是否共享这个计数。

三段法走完一遍，你会发现需求里没写的东西比写了的还多。这不是需求文档的错，而是需求天然只描述主流程，异常流和状态残留必须由测试反过来提。

3.2 登录功能用例集逐条落地

按上面的可测点整理成用例表，下表是在经典实例基础上补全后的版本，增加了需求覆盖列和前置条件列，测试数据全部使用虚构账号。

补出来的 011 和 012 是原实例里最欠缺的部分：原文只写了「连续三次未成功系统提示」，既没说清第三次是否有独立提示，也没验证关闭浏览器之后的状态。001 到 010 覆盖的是功能正确性，011 和 012 覆盖的是状态机的收尾，两类用例的比例通常在 6:4 左右比较合适。

执行顺序上，005 依赖 002 和 004 的输入结果，其余用例都应该能独立执行。如果团队的自动化框架只能整表顺序跑，至少要在前置条件里写清楚依赖关系，别让执行的人自己猜。

3.3 安全校验原本的连锁设计：连续三次失败怎么测

连续三次失败这条需求，本质上是一个带状态的计数器，测试重点是计数的边界和重置条件，不是单纯验证第三次的提示文案。要测的组合包括：第三次失败与第四次尝试的分界、关闭浏览器重开后是否重置、更换用户名后计数是否跟着换、计数窗口是按会话算还是按 IP 算、以及计数达到上限后锁定多长时间。

第三条需求里「关闭浏览器」这个动作也很值得抠。窗口关闭是前端行为还是后端下发指令，决定了这条用例能不能自动化。如果只是前端检测到计数到达阈值就调关闭接口，那么绕过前端直接调登录接口就能无限试密码，这属于安全设计缺陷，应该在用例里显式提出来，而不是当成预期行为记一笔通过。通常的做法是把它拆成两条用例：一条验证前端窗口确实关闭，一条验证服务端在计数到达阈值后一段时间内拒绝该账号的登录请求，后一条才是真正守底线的。

另外，这类安全策略的提示文案往往是攻击者最先研究的东西。「用户名不存在」和「密码错误」分开提示，等于把账号是否注册这件事直接告诉了对方。如果产品的安全等级要求高，用例的预期结果就应该写成统一提示，并在评审时把这条作为一个必须确认的问题抛给产品负责人，而不是默认接受需求文档的写法。

4. 五种经典设计方法：从三角形到自动售货机的完整推导

方法论的章节最怕写成名词解释，读完知道有等价类这回事，真拿到需求还是不知道从哪下手。这一章把五种方法绑在五个具体题目上：三角形判定、NextDate 函数、排序程序、自动售货机、维修优先级判定。每个题目都从需求文本出发，推导出等价类表、边界取值表、因果图或者判定表，再落到用例。想抄作业的话，可以直接把这里的推导结构换成自己的业务模块。

4.1 等价类划分：三角形问题先列等价类表再写用例

题目要求输入三个整数 a、b、c 作为三边构成三角形，判定并输出一般三角形、等腰三角形或等边三角形。等价类划分的第一步不是写用例，是把输入条件里明说的和隐含的要求全部列出来：整数、三个数、非零、正数、两边之和大于第三边、两边相等、三边相等。这七条要求里，前四条是对单个输入的约束，后三条是对输入之间关系的约束。

先划分有效等价类并编号：编号 1 到 4 分别对应整数、三个数、非零、正数；编号 5 对应满足两边之和大于第三边；编号 6、7、8 分别对应 a=b、b=c、a=c 三种两边相等的情况；编号 9 对应三边全等。无效等价类从 10 开始：非整数、输入不足三个数、含零、含负数、不满足两边之和大于第三边，各占一号。

覆盖有效类的用例可以合并着写，一组数据同时命中多个编号：

无效类必须一条用例只覆盖一个编号，因为一旦两个错误同时出现，程序返回哪个错误信息是不确定的，用例就失去了判定力。T-06 到 T-10 分别给 a=1、b=2、c=5 验证非三角形，a=0 验证含零，a 取负数验证负值，a 取 3.5 验证非整数，只给两个参数验证数量不足。

写完表格，可以用参数化把这些用例固化下来，避免手工执行时漏项。下面是三角形判定的参数化脚本，用例数据和上面的表格一一对应：

import pytest def triangle_type(a, b, c): """被测函数：返回三角形类型或错误标识""" if not all(isinstance(x, int) for x in (a, b, c)): return "非整数" if a <= 0 or b <= 0 or c <= 0: return "含非正数" if a + b <= c or a + c <= b or b + c <= a: return "非三角形" if a == b == c: return "等边三角形" if a == b or b == c or a == c: return "等腰三角形" return "一般三角形" # 每条参数依次为：用例ID, a, b, c, 预期结果 CASES = [ ("T-01", 3, 4, 5, "一般三角形"), ("T-02", 4, 4, 5, "等腰三角形"), ("T-03", 4, 5, 5, "等腰三角形"), ("T-04", 5, 4, 5, "等腰三角形"), ("T-05", 4, 4, 4, "等边三角形"), ("T-06", 1, 2, 5, "非三角形"), # 1+2 <= 5，命中无效类 5 ("T-07", 0, 4, 5, "含非正数"), # 命中无效类 3 ("T-08", -3, 4, 5, "含非正数"), # 命中无效类 4 ("T-09", 3.5, 4, 5, "非整数"), # 命中无效类 1 ] @pytest.mark.parametrize("case_id,a,b,c,expected", CASES) def test_triangle(case_id, a, b, c, expected): assert triangle_type(a, b, c) == expected, f"用例 {case_id} 失败"

参数说明上，CASES列表的第一列是裸用例 ID，失败时 pytest 会把它带进断言信息，方便回溯到用例表；用例表里新增一行，这里补一行数据即可，两边保持同构。被测函数只是示例实现，真实项目里换成对接口的调用，判定逻辑不变。

4.2 边界值分析：NextDate 的取值边界与跨月进位

NextDate 函数输入年月日，输出下一天的日期。题目隐含的约束是月份取 1 到 12、日期取 1 到 31、年份取 1912 到 2050。边界值分析的取值方式是每个边界的下界减一、下界、下界加一、上界减一、上界、上界加一，六个点覆盖一个变量的完整边界。

月份这一维取 -1、1、2、11、12、13 六组，固定日期为 6 月 15 日、年份 2001，预期输出依次是超界、1 月 16 日、2 月 16 日、11 月 16 日、12 月 16 日、超界。日期这一维取 -1、1、2、30、31、32 六组，固定月份 6 月、年份 2001，预期输出是超界、6 月 2 日、6 月 3 日、7 月 1 日、超界、超界。年份这一维取 1911、1912、1913、1975、2049、2050、2051 七组，固定 6 月 15 日，中间几组正常加一天，两端越界报错。

最容易写错预期结果的是日期上界。6 月只有 30 天，输入 6 月 31 日时，程序是应该报「日期超界」还是进位成 7 月 1 日，取决于规格说明书怎么写，不取决于直觉。很多系统在这里采用的是先校验后进位，也就是 6 月 31 日直接判非法，那么预期结果就得写「输入日期超界」，而不是 7 月 1 日。原实例里这块的预期输出和输入对不上位，正是因为它把两个不同版本的行为混在一张表里了。碰到这种地方，正确做法是把问题登记成需求澄清项，等规格明确了再填预期结果，别自己拍板。

跨年同理：12 月 31 日的次日是次年 1 月 1 日，如果年份已经在上界 2050，那么这一次进位会直接触发年份越界，属于复合边界，得单独加一条用例。边界值分析只保证单变量的边界被覆盖，复合边界靠等价类和错误推测去补。

4.3 错误推测法：排序程序最该补的六种输入

错误推测法没有固定公式，靠的是对「程序哪里最容易崩」的直觉，而这种直觉是可以被结构化的。拿一个对线性表排序的程序做例子，最值得测的输入状态有这么几类：空表、只有一个元素、已经按正序排好、已经按逆序排好、全部元素相同、部分元素相同。

这六类输入分别对应六种典型的实现缺陷。空表能测出循环边界写成for i in 1..n的越界；单元素能测出交换逻辑里对相邻下标访问的错误；已排序输入能测出快速排序选最后一个元素做基准时退化成 O(n²) 的性能问题；逆序输入是对冒泡和插入排序最坏情况的考验；全部相同能测出三路快排分区不均导致的栈溢出；部分相同能测出稳定性丢失——排序后相同元素的相对顺序是否保持，这一条在很多业务里是硬要求。

再往下还能补两类：超长输入和含特殊值的输入。超长输入验证内存与递归深度，含负数、零、极大值的输入验证比较逻辑是否用了有符号比较。错误推测法的产出不需要覆盖所有可能性，它补的是等价类和边界值覆盖不到的「实现层面的坑」，所以用例描述里最好写清推测依据，否则评审时会被问「为什么想到要测这个」。

4.4 因果图：自动售货机的中间结点怎么设

自动售货机的规格是：投入 5 角或 1 元硬币，按下橙汁或啤酒按钮，相应饮料送出；若售货机没有零钱找，零钱找完红灯亮，此时投入 1 元并按下按钮，饮料不送出且退还 1 元；若零钱充足，红灯灭，送出饮料同时退还 5 角。

先把原因和结果编上号。原因五个：1 售货机有零钱找、2 投入 1 元硬币、3 投入 5 角硬币、4 按下橙汁按钮、5 按下啤酒按钮。结果五个：21 零钱找完红灯亮、22 退还 1 元、23 退还 5 角、24 送出橙汁、25 送出啤酒。

因果图的难点不在画图，而在中间结点怎么设。直接拿原因连结果，条件组合会纠缠在一起无法表达「投入 1 元且按下按钮」这种与关系，所以要引入中间结点：11 表示已投入 1 元且按下了饮料按钮，12 表示按下了橙汁或啤酒按钮，13 表示应当找 5 角且售货机有零钱，14 表示钱已付清。中间结点的作用是把「与」「或」「非」三种逻辑关系分层表达，让图能直接翻译成判定表。

转换成判定表之后，条件项是原因和中间结点的取值，动作项是五个结果的取值。这里要注意约束标记：投入 1 元和投入 5 角是互斥的，橙汁和啤酒按钮也是互斥的，判定表里这两组同时为真的列属于不可能组合，直接划掉，不必为它们写用例。不划掉的后果是表的列数按 2 的幂次膨胀，实际有效组合远少于列数。

4.5 判定表驱动：维修优先级的 8 种组合化简到 4 条规则

题目是：功率大于 50 马力、维修记录不全、已运行 10 年以上的机器，应给予优先维修处理。三个条件各取两个值，规则数是 2 的 3 次方等于 8，先把 8 条规则全列出来。

三个条件之间是「或」的关系，只要有一个为真就优先处理，所以规则 1 到 7 的动作完全相同，只有规则 8 是例外。化简的原则是：两条规则的条件项里只有一个条件取值不同、其余相同，且动作项完全一致，就可以合并，把那个不同的条件写成「—」。

先合并规则 1 和 2，运行年限条件取值不同、动作相同，合并为「功率大于 50 马力、记录不全、年限不限」。再和规则 3、4 合并，因为功率条件恒为 Y，记录和年限怎么取都优先，四条合成一条：功率大于 50 马力时直接优先处理，后两个条件写「—」。规则 5 和 6 同理合并成「功率不超 50、记录不全、年限不限」。剩下规则 7 和 8 无法再合并，因为动作不同。

最终得到 4 条规则：功率大于 50 马力则优先；功率不超且记录不全则优先；功率不超、记录齐全、运行超 10 年则优先；三者全不满足则作其他处理。化简的边界是动作项必须一致，不能为了减少行数把不同动作硬合并，那样判定表就失去了区分能力。用例表按化简后的 4 条规则写 4 条用例就够，每条用例的条件取值从规则行照抄，预期结果是动作列的文字。

5. 避坑与排查：用例评审里最容易翻车的五个点

评审会是用例集质量的最后一道闸门，但很多问题在会上是看不出来的，要等到执行阶段才炸。这一章列五个在项目里反复出现的坑，每条按现象、原因、解决三段写，遇到对应的症状可以直接按图索骥。

5.1 预期结果写成「提示错误」，执行时全靠猜

现象是用例执行到一半卡住，执行的人截图发群里问「这算通过吗」，一条用例来回拉扯十几分钟。原因在于预期结果只写了定性描述，没有落到可断言的字符串、状态码或者页面元素上。解决方式是把预期结果的填写规范写死：提示类结果必须带完整文案，页面类结果必须带关键元素，接口类结果必须带状态码和关键字段值。评审时抽查三条用例，凡是预期结果里出现「正常」「正确」「合理」这类词的，一律打回重写。

5.2 用例之间隐式依赖，单独执行必然失败

现象是持续集成里单跑某条业务用例失败，整表顺序跑却通过。原因是用例靠上一条用例留下的登录态或数据，前置条件里却没写。解决方式是要求所有共享状态通过测试夹具构造，用例的前置条件里声明夹具名称，用例之间只允许保留业务上的先后依赖。修复这类问题的成本集中在前期，一旦依赖链理顺，后面加用例的速度会快很多。

5.3 只覆盖有效等价类，无效类一条都没写

现象是线上出现一次越界输入直接白屏，翻用例库发现根本没测过。原因是划分等价类时只盯着正常输入，无效类列了名字却没编号没落用例。解决方式是等价类表配一张覆盖核对表，每个无效类编号后面必须挂上至少一条用例 ID，评审时逐号核对。无效类的优先级不一定高，但不能没有，尤其是涉及金额、数量、边界长度这类字段。

5.4 用例与需求描述冲突，没人认领

现象是评审会上执行人和开发吵起来，一方说按需求写的，一方说需求本身写错了。原因是需求描述和用例预期结果各按各的理解写，冲突没有被登记。解决方式是建一份冲突登记表，字段包括用例 ID、需求编号、冲突描述、裁决人、裁决结论，所有无法当场确认的点全部进表，等产品负责人拍板后再回填用例。最典型的例子就是登录连续失败后究竟该提示还是关闭窗口，需求里写关闭，用例里写提示，这种冲突不解决，用例集就是废的。

5.5 判定表规则爆炸，不化简直接落用例

现象是条件一多，判定表列数呈指数增长，评审时没人看得完，执行时大量用例重复。原因是跳过了化简步骤，把不可能组合和动作一致的组合都当成独立规则。解决方式是判定表先划掉互斥条件造成的不可能列，再按动作一致性合并规则，合并后再统计用例数。三个条件的表化简后通常只剩四到五条规则，条件涨到五个时，化简带来的收益会非常明显。

注意：这五条里，第 4 条最难在技术上发现，只能靠流程补。团队里如果没有人负责裁决需求冲突，用例写得再规范也会在执行阶段集体卡壳。

6. 验收与答辩：用例集怎么自检，评审会上被问到怎么答

用例集写完不等于交付完成，验收环节要回答两个问题：这份用例集覆盖了没有、可不可维护。自检建议做一张三列的表，左边列检查项，中间列合格标准，右边列证据。

这张表在答辩现场比任何描述都有说服力，因为它把「做了什么」变成了「凭什么说做完了」。评审会上最常被问的三个问题，回答思路也要提前准备。

第一个问题是「为什么这个功能只有十条用例」。不要回答「够了」，回答覆盖逻辑：这十条覆盖了几条需求、几个等价类、几个边界点，哪些异常流是主动判定为低优先级不测的、判定依据是什么。把「少」解释成「有依据的取舍」，比堆数量更有说服力。

第二个问题是「怎么保证用例长期可用」。回答结构维护机制：模块名与需求目录对齐、用例 ID 不复用、共享状态走夹具、需求变更时通过追溯表反向找用例。可以现场演示一遍从需求编号查到用例列表的过程。

第三个问题是「你用的是哪种设计方法」。不要报菜名，挑一个点讲透：比如三角形问题为什么无效等价类要一条用例只覆盖一个编号，因为多个错误同时出现时程序返回哪个错误不确定，用例就失去判定力。讲清一个推导过程，比罗列五种方法的名字有用得多。

从那以后我每次交用例集之前，都会强制走一遍那张自检表，尤其是「单条用例可独立执行」这一项——早期吃过一次亏，整表跑得通、单跑全红，排查了两天才发现是执行顺序在里面捣鬼。把自检表固化进流程，比事后返工便宜太多。希望帮到你。

本文还有配套的精品资源，点击获取