企业官网建设流程全解析

简介：这份资源面向软件测试初学者与需要巩固用例设计基础的从业者，系统整理了测试用例编写的经典实例，帮助解决用例要素不全、设计方法单一、场景覆盖不足等常见问题。包内共1个doc文档，约329KB，以文字与表格形式呈现，便于直接查阅和对照练习。内容围绕一份优秀用例应包含的软件名称、版本、模块、前置条件、用例编号、操作步骤、预期结果等要素展开，并给出B/S结构登录功能的黑盒测试用例表，涵盖用户名录入、密码校验、连续三次失败锁定等场景；同时收录等价类划分法（三角形判定）、边界值分析法（NextDate函数）、错误推测法与因果图法（自动售货机）等典型实例，配有等价类表与测试数据。已有4779人学习下载，适合作为课程作业、面试复习与日常编写用例时的参考手册。

1. 登录框背后那套用例设计逻辑，比你想的更值得拆

很多人第一次写测试用例，是从一个登录页面开始的：打开浏览器、输入账号密码、点登录、看跳不跳转。写完十来个场景就觉得“覆盖得差不多了”，结果上线后一个超长用户名把数据库字段撑爆，或者连续输错三次密码后系统直接白屏。这类问题不是靠手快点出来的，而是靠一套结构化的用例设计方法提前推演出来的。这份资源就是围绕“测试用例经典实例”整理的实战素材，核心价值在于把等价类划分、边界值分析、错误推测、因果图、判定表驱动这五种黑盒方法，分别落到登录、三角形判定、NextDate 日期计算、自动售货机、设备维修优先级五个具体场景里，给出可直接对照的用例表。它适合刚入行、需要一套能抄的模板来建立用例思维的新手，也适合带人时想找几个“小而完整”的案例做讲解的熟手。下面不按资料顺序念，而是按“怎么把这些实例变成你手里能跑的用例”来拆。

2. 先把用例骨架立住：12 个字段里哪几个真不能省

2.1 用例模板的字段取舍：预期结果和前置条件为什么排前两位

资料里列了 12 项用例应包含的信息，从软件名称、版本号、功能模块名，到用例编号、步骤描述、预期结果、开发人员、执行日期。字段看着多，但真正决定一条用例能不能被别人复现的，其实就三个：前置条件、操作步骤加测试数据、预期结果。前置条件写不清，执行的人就不知道“连续三次失败”是从哪个干净状态开始数的；预期结果写不清，用例就退化成“点一下看看”，出了问题也没法判定是 bug 还是设计如此。

我一般会把 12 项压成一张表来管理，字段名和用途对应如下，落到 Excel 或任意用例管理工具里都能直接建列：

提示：预期结果里不要写“系统正常”“提示正确”这类模糊词，要写到“提示文案为‘需要输入密码’，且页面停留在登录页”这种颗粒度，否则执行时全靠个人理解，用例就失去了复用价值。

2.2 登录用例的拆法：从 TC1 到 TC10 的依赖链怎么排

资料给的登录实例是 B/S 结构、黑盒用例、假设浏览器为 IE6.0 SP4，这个环境描述在今天看已经过时，但它示范的“场景拆分 + 依赖标注”思路完全不过时。它把登录拆成初始页面显示、用户名录入、用户名容错、密码录入、登录成功、空值校验、缺密码校验、密码错误、用户不存在、连续三次失败锁定共 10 条，其中 TC5 明确依赖 TC2 和 TC4 先完成输入。这种依赖链是串行用例的核心，排错了顺序，执行的人就会在“还没输入用户名”的状态下去点登录，然后误报一个 bug。

把这份实例迁移到自己的项目时，我一般按下面的顺序重排，并给每条补上前置条件：

TC1 初始页面显示 前置：浏览器已打开，地址可访问 步骤：地址栏输入登录页 URL，回车 预期：页面元素完整，用户名、密码输入框和登录按钮均可见，与设计稿一致 TC2 用户名录入-正常值 前置：停留在登录页 步骤：用户名输入已存在的账号 test 预期：输入框正常接收，无报错 TC3 用户名-超长容错 前置：停留在登录页 步骤：用户名输入 aaaaabbbbbcccccdddddeeeee（超过规定长度） 预期：输入到长度上限时系统拒绝继续输入，不出现截断后仍提交的情况 TC4 密码录入-正常值 前置：TC2 已完成 步骤：密码输入与 test 关联的正确密码 预期：密码以掩码显示，输入成功 TC5 登录成功 前置：TC2、TC4 已完成 步骤：单击登录按钮 预期：跳转至系统首页，会话建立 TC6 空用户名空密码 前置：停留在登录页，两个输入框均为空 步骤：直接单击登录 预期：登录失败，提示“请检查用户名和密码的输入是否正确” TC7 有用户名无密码 前置：仅输入用户名 步骤：单击登录 预期：登录失败，提示“需要输入密码” TC8 密码与用户名不匹配 前置：输入存在的用户名，密码填错 步骤：单击登录 预期：登录失败，提示“错误的密码” TC9 用户名不存在 前置：输入不存在的用户名和任意密码 步骤：单击登录 预期：登录失败，提示“用户名不存在” TC10 连续三次失败 前置：已连续两次登录失败 步骤：第三次输入错误凭据并提交 预期：提示“您没有使用该系统的权限，请与管理员联系”，并关闭当前窗口

这段不是代码，而是一份可以直接贴进用例表的文本骨架，重点是每条都带了前置条件和可判定的预期。TC10 的“自动关闭 IE”在今天的浏览器里通常表现为锁定账号或弹出阻断页，迁移时按实际产品行为改写预期即可，但“连续失败计数”这个测试点必须保留，它是安全类用例里最容易被漏掉的一条。

3. 五种黑盒方法落到具体场景：等价类、边界值、因果图怎么用

3.1 等价类划分：三角形判定题的输入条件怎么拆成有效无效两类

三角形判定是等价类划分的经典题：输入三个整数 a、b、c 作为边长，程序判定是一般三角形、等腰三角形还是等边三角形。资料把输入要求拆成七条隐含条件——整数、三个数、非零、正数、两边之和大于第三边、等腰、等边，然后分别列有效等价类和无效等价类。这个拆法的关键不在题目本身，而在于“从自然语言需求里把隐含约束一条条抠出来”的动作。

我照着这份实例整理成可执行的用例表时，会先列等价类编号，再让每条用例覆盖一组编号，避免“一条用例只测一个点”导致用例数量爆炸：

这里有个容易翻车的点：T6 的 1、2、3 满足“正数、整数、三个数”，但 1+2=3 不满足“两边之和大于第三边”，所以它落在无效等价类里，预期是“非三角形”而不是“一般三角形”。很多新手会把 1、2、3 当成有效输入去测，结果程序返回“非三角形”就误报 bug。等价类划分的价值就在于提前把这类边界外的组合标出来，让预期结果有据可依。

3.2 边界值分析：NextDate 的 month、day、year 三个变量怎么取点

NextDate 函数要求输入 month、day、year，输出下一天日期，隐含约束是 1≤month≤12、1≤day≤31、1912≤year≤2050。边界值分析的核心是取“边界上、边界内、边界外”三类点，资料给的用例表覆盖了 day 取 -1、1、2、30、31、32，month 取 -1、1、2、11、12、13，year 取 1911、1912、1913、1975、2049、2050、2051。这套取点的逻辑是：每个变量的最小值、最小值+1、正常值、最大值-1、最大值、最大值+1 各来一发，再组合出跨月、跨年、闰年这些特殊场景。

迁移到自己项目时，我一般先画一张变量边界表，再按“单变量越界优先、组合场景其次”的顺序生成用例：

单变量越界用例优先跑，比如 month=13、day=32、year=2051，预期都是“输入日期超界”；然后再跑组合场景，比如 2001.1.31 的次日应是 2001.2.1，2001.12.31 的次日应是 2002.1.1，2000.2.28 的次日应是 2000.2.29（闰年）。资料里 Test8 到 Test13 那组 day 取 -1、1、2、30、31、32 的用例，本质就是在验证“day 的边界处理有没有把 0 和 32 拦住”，而 Test14 到 Test19 那组 month 取 -1、1、2、11、12、13 的用例，验证的是月份进位逻辑。这套取点方法放到任何有数值范围输入的功能上都通用，比如分页参数 pageSize、金额上限、年龄字段，照着这张表套就行。

3.3 因果图与判定表：自动售货机和维修优先级两个场景的转换步骤

因果图法在资料里用自动售货机举例：投入 5 角或 1 元硬币、按橙汁或啤酒按钮，有零钱找时正常出货并退 5 角，没零钱时红灯亮、退 1 元、不出货。它先列原因（有零钱、投 1 元、投 5 角、按橙汁、按啤酒）和结果（红灯亮、退 1 元、退 5 角、出橙汁、出啤酒），再建中间结点（投 1 元且按按钮、按了任一饮料按钮、应找 5 角且有零钱、钱已付清），最后转成判定表。这个“原因→中间结点→结果”的三层结构，是把复杂业务规则拆成可枚举组合的标准动作。

判定表驱动分析法则用设备维修优先级举例：功率大于 50 马力、维修记录不全、运行超过 10 年，三个条件各取 Y/N，共 2×2×2=8 种规则，填完条件项和动作项后再化简合并相似规则。资料给的化简结果是 5 条规则，其中“维修记录不全”和“运行超过 10 年”在某些规则里用“-”表示无关项。这个化简动作是判定表法最容易被忽略的一步——不化简，8 条规则里有一半是重复的，用例数量虚高；化简后，真正需要执行的组合被压到最少。

把这两个场景的方法迁移到自己的业务上，我一般按四步走：第一步列全条件和动作，条件用 Y/N 表示取值，动作用 X 表示触发；第二步按 2 的 n 次方列出所有规则列；第三步逐列填条件项，从最后一行往上填，避免漏组合；第四步合并“动作相同且只有一个条件不同”的规则列，用“-”标记无关项。这套流程在优惠券叠加、权限组合、订单状态流转这类规则密集的功能上特别好用，比拍脑袋想场景靠谱得多。

4. 避坑与排查：用例设计里最容易翻车的五个地方

4.1 现象：用例执行时“预期结果”对不上，但开发说设计如此

原因：预期结果写的是测试人员自己的理解，没有回查需求文档或设计稿，导致用例和实际设计脱节。解决：每条用例的预期结果必须能追溯到需求条目或设计稿位置，追溯不到的要么补文档，要么标为“待确认”，不能凭感觉写。

4.2 现象：连续失败锁定用例每次都过，但线上还是出现锁定失效

原因：用例只测了“第三次失败后提示锁定”，没测“锁定后正确密码是否仍被拒绝”和“锁定状态是否有时效”。解决：安全类用例要覆盖锁定后的正向和反向两条路径，即锁定期间正确凭据应被拒绝、锁定到期后应恢复，只测触发不测恢复等于没测。

4.3 现象：边界值用例跑完没发现问题，上线后日期跨月出错

原因：只测了单变量边界，没测组合边界，比如 day=31 且 month=1 的跨月场景、year=2000 的闰年场景。解决：边界值分析要分两层，先跑单变量越界，再跑“边界值 + 业务规则”的组合场景，跨月、跨年、闰年这三类必须单独列用例。

4.4 现象：等价类用例数量越写越多，执行时间失控

原因：一条用例只覆盖一个等价类，没有做覆盖合并。解决：按资料里三角形题的做法，让一条用例覆盖多个有效等价类编号，无效等价类才单独拆，这样有效类用例数量能压到最少，无效类保证每个约束至少被命中一次。

4.5 现象：判定表化简后规则数对不上，执行时漏了组合

原因：化简时把“动作不同但条件相同”的规则也合并了，或者“-”标记用错位置。解决：化简只合并“动作完全相同且仅一个条件取值不同”的规则列，合并后回填一张规则覆盖检查表，确认每个原始规则都能被化简后的某条规则命中。

5. 把实例变成自己的用例库：一个可复用的落地技巧

资料里的五个实例，单独看是五道练习题，合起来其实是一套方法映射表：登录场景练的是“场景拆分 + 依赖标注”，三角形题练的是“从需求抠隐含约束”，NextDate 练的是“多变量边界取点”，自动售货机练的是“因果图转判定表”，维修优先级练的是“判定表化简”。我一般会把这五个场景各抽一条用例，改写成自己项目的真实字段，做成团队内部的“方法示例库”，新人入职先照着改三条，比看十页方法论管用。

具体做法是建一张三列对照表：左列写方法名，中列写资料里的原始场景和关键取点，右列写自己项目里对应的功能和参数。比如等价类那一行，原始场景是三角形三边，右列就填自己项目里的“注册年龄字段：有效类 18-60 整数、无效类小于 18、大于 60、非整数、空值”；边界值那一行，原始场景是 NextDate 的 month/day/year，右列就填“分页参数 pageSize：下界 1、上界 100、越界 0 和 101”。填完这张表，五种方法就各自有了一个可执行的落点，不用每次从零想场景。

这张表填完之后，还有一步验证不能省：拿其中一条改写后的用例，找一个没参与设计的同事照着执行一遍，看他能不能在不问你的情况下复现出预期结果。如果他要问“这个前置条件是什么意思”或者“预期结果到底看哪里”，说明字段还没写到位，回去补前置条件和预期结果的颗粒度。这个“陌生人可执行”检查，是我从几次用例交接翻车里总结出来的硬标准——用例不是写给自己看的，是写给下一个执行的人看的。

从那以后我每次整理用例库，都会强制走一遍“抽一条给没参与的人盲跑”的流程，跑不通就说明模板字段有歧义，先修模板再批量写。这套习惯坚持下来，用例的返工率明显下降，交接时也少了很多来回确认。希望这些拆解和踩坑记录，能帮你在下次写登录用例或者边界值用例时，少走一点弯路。

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