企业官网建设流程全解析

简介：围绕软件测试用例设计整理的经典实例合集，面向软件测试初学者与需要规范用例编写的测试人员，帮助解决用例要素不全、设计方法单一、缺少可参照范例等问题。内容从一份优秀用例应包含的项目名称、版本号、功能模块、前置条件、用例编号、操作步骤与预期结果等要素讲起，并给出可直接对照的黑盒登录功能用例表，覆盖用户名录入、密码校验、连续三次失败锁定等场景；同时展开等价类划分（三角形判定）、边界值分析（NextDate 函数）、错误推测法（排序程序）、因果图法与判定表驱动法（自动售货机）等经典例题的完整推导。压缩包内共1个doc文件，约329KB，为纯文档形式，便于打印或二次整理成用例模板。已有4782人学习下载，适合作为测试用例编写的入门参照与日常查阅手册。

1. 从一个登录页开始：为什么测试用例要先设计再执行

A同学做软件测试课程设计，拿到一个B/S登录页就写了三条用例：输入正确账号能进、输错密码有提示、不输入不能登录。导师看完只追问了一句：连续三次失败之后，你的用例还能复现吗？这一问就暴露了测试用例实例最常见的短板——只写正向路径，不写前置条件、边界数据和执行顺序。软件测试用例的经典实例不是背几个方法名，而是把用例字段、设计方法、执行证据串成一套可复现的方案。这套内容适合正在交测试课设、毕设的学生，也适合需要交付测试用例集的从业者：12项字段模板、登录TC1到TC10、三角形等价类、NextDate边界值、排序错误推测、售货机因果图、维修判定表，最后用覆盖矩阵做验收。

2. 用例规格设计：12项字段如何落成可维护的用例模板

用例写得多不等于写得好。一个测试用例实例能不能被另一个人在不问作者的情况下执行，取决于头部信息、前置条件、步骤数据和预期结果是否分离。原始材料给出12项字段，我一般把它们拆成五块：项目与版本、模块与描述、参考与依赖、前置条件、步骤与结果，再把开发人员和执行日期放到执行记录区。这样拆的好处是字段不打架，复制模板时也不会把旧项目的版本号带进去。

2.1 用一张头部表锁住项目、版本与模块

头部表负责回答“这是谁的用例、测的是哪一版、属于哪个模块”。项目名称、内部版本号、功能模块名、用例简单描述、参考信息这五项必须写在最上面，编号和人员信息紧随其后。编号规则不要带日期，也不要用“NO.1”这种一复制就冲突的写法。比较稳的格式是“项目简写-模块简写-三位序号”，例如某课程设计系统的登录模块写成 DEMO-LOGIN-001。版本号写内部版本号，不写“最新版”，因为“最新”过两周就不可复现。

这张表看着普通，但它解决了两个高频问题：一是回归时找不到用例对应哪条需求，二是缺陷单里写了“登录用例失败”却不知道是哪一个版本。编号一旦发布就不要复用，废弃用例保留并标记“停用”，新用例继续往后排。版本升级时复制整套用例，只改版本字段，不改编号，这样历史执行记录还能对上。

2.2 前置条件、依赖与步骤数据怎样拆开

前置条件必须写成可验证的事实，不写“系统正常”这种无法判定的句子。登录成功用例的前置条件通常包括：账号test已存在且未锁定、测试库可访问、浏览器会话已清理。依赖关系写用例ID列表，不写“先测TC2再测TC4”这种散话，因为执行人可能只拿到单条用例。步骤拆成三列：步骤号、操作描述、测试数据。每一步只做一个动作，测试数据单独列出来，后续做参数化或自动化时可以直接映射。

# 用例模板片段：字段名保持稳定，便于不同项目复用 id: DEMO-LOGIN-005 title: 登录-用户名和密码正确时进入系统 version: V1.2.0-内部 module: 用户登录 reference: REQ-LOGIN-05 preconditions: - 账号 test 已存在且未锁定 - 测试库可访问 depends_on: - DEMO-LOGIN-002 - DEMO-LOGIN-004 steps: - step: 1 action: 打开登录页 data: 入口地址 - step: 2 action: 输入用户名 data: test - step: 3 action: 输入密码 data: test - step: 4 action: 单击登录按钮 data: 无 expected: 页面跳转到系统首页，左上角显示当前用户名 test，登录按钮消失

这段模板里，preconditions和depends_on分开是有意为之：前置条件是环境事实，依赖是用例执行顺序。steps用数组而不是一段长文本，是为了后续导出到表格或自动化脚本时不丢步骤。expected只写一条可观察结果，如果预期包含多个检查点，拆成多条断言或备注。实际结果不写在用例正文里，交给缺陷管理工具或执行记录表，否则用例会被执行结果污染，下一次回归时看不出原始预期。

2.3 预期结果写成可观察事实

预期结果是用例里最不能省的一项。写“登录成功”四个字，执行人和开发能吵半小时：是跳首页还是弹提示？用户名显示在左上角还是右上角？写“提示错误”同样不够，必须写清提示文案、页面是否跳转、输入框是否保留。原始登录实例里已经给出比较好的写法，例如“系统登录失败，并提示：请检查用户名和密码的输入是否正确”，这类文案可以直接作为断言依据。文案会随版本变化时，预期结果写“提示信息包含‘请检查用户名和密码’且不跳转”，并在参考信息里挂文案编号。

执行日期和人员信息放在执行记录区，不放进用例正文。开发人员字段必须填，测试人员字段可选，但复核人最好留一个名字或代称。用例评审时先看头部表和预期结果，再看步骤，通常能发现一半问题。下一章用这套模板套登录功能，把TC1到TC10逐条落表。

3. 黑盒实例拆解：B/S登录功能的10条场景用例与数据表

登录功能是测试用例例子里最经典、也最容易被写薄的对象。原始实例以一个B/S结构的登录功能为被测对象，按黑盒方式设计，假设浏览器环境为IE6.0 SP4。今天复现时不必照搬旧浏览器，但环境字段必须写清，因为页面元素、输入长度限制和提示文案都可能随环境变化。黑盒测试不看代码，只看界面、提示和会话状态，所以用例的预期结果要落在可观察的页面事实和提示文案上。

3.1 被测对象与环境边界

原始功能描述有四条：用户在地址栏输入地址后显示登录界面；输入用户名和密码后系统自动校验并给出提示；用户名或密码任一未输入时给出提示；连续三次未通过验证时自动关闭IE。前三条是常规输入校验，第四条是状态型安全校验。状态型用例最容易污染后续用例，所以TC10必须独立账号、独立会话，执行后重置错误次数。测试数据至少准备六类：已存在账号test、与test关联的正确密码、超长字符串、空用户名、空密码、不存在的用户名。原实例里的超长数据“aaaaabbbbbcccccdddddeeeee”可以保留为示例，但更稳的做法是写“超过规定长度的字符串”，再在数据表里给出具体值。

环境边界要写进前置条件：浏览器类型与版本、入口地址、测试库、账号状态、会话是否清理。原实例假设IE6.0 SP4，今天在实验室统一浏览器上执行时，把环境字段替换掉即可，用例结构不变。需求写“自动关闭IE”时，用例预期就写关闭浏览器；如果当前系统改成退出登录或锁定账号，预期要跟着需求版本走，不能为了照抄旧例子而写一个系统根本不会发生的动作。这一点在答辩时特别容易失分：评委问“你的预期结果从哪里来”，答“从需求条目来”比答“网上例子这样写”稳得多。

3.2 TC1到TC10的用例表与执行顺序

下面这张表把原始实例的10条用例整理成可执行格式。步骤列做了压缩，实际模板仍按“步骤号、操作、数据”三列展开。依赖列只写ID，不写口头顺序。

执行顺序建议TC1→TC2→TC4→TC5→TC6→TC7→TC8→TC9→TC3→TC10。TC3放在中间也可以，但它会改输入框状态，执行后要清空。TC5依赖TC2和TC4的数据准备，所以前置条件里要写“账号test已存在且未锁定”。TC9的预期结果要特别说明：有些系统出于安全考虑，不区分“用户名不存在”和“密码错误”，统一提示“用户名或密码错误”。这时不能硬套原始实例的“用户名不存在”，而应在参考信息里挂需求条目，按当前需求版本写预期。用例忠于需求，不忠于旧例子。

3.3 连续失败与安全校验的用例隔离

TC10是整套登录用例里最需要隔离的一条。连续三次失败属于状态型校验，可能是会话级，也可能是账号级，还可能是IP级。前置条件必须写清是哪种，否则执行人换一台机器跑出来的结果就不一样。我一般单独准备一个账号，例如 lock_test，执行前确认错误次数为0，执行后通过后台或等待窗口期重置。执行记录表里记下执行时间、版本、实际结果和缺陷ID，实际结果不写回用例正文。这样下一轮回归时，TC5不会被TC10的锁定状态拖累。

黑盒登录用例的价值不在于条数多，而在于每条都能独立复现。TC1到TC10覆盖了页面显示、输入、成功、失败、状态校验五类场景，后面做自动化时可以直接按这张表参数化。下一章换三个更典型的输入类和规则类对象，把等价类、边界值、错误推测、因果图和判定表逐一套到用例ID上。

4. 设计方法落地：等价类、边界值、错误推测、因果图与判定表怎么组合

设计方法不是越全越好，而是看被测对象的输入结构和业务规则。输入范围明确的程序，优先等价类加边界值；业务规则由多个条件组合决定的，优先判定表或因果图；经验能预判的风险点，用错误推测补漏。下面五组实例分别对应三角形、NextDate、排序程序、自动售货机和设备维修优先级，每一组都落到具体用例或规则表上，避免只画图不产用例。

4.1 等价类划分：三角形程序的输入条件与有效/无效类

三角形程序要求输入三个整数a、b、c作为三边边长，判定一般三角形、等腰三角形或等边三角形。题目里给出和隐含的条件可以拆成七条：整数、三个数、非零数、正数、两边之和大于第三边、等腰、等边。等价类划分先把这些条件分成有效类和无效类，再让每条用例尽量覆盖多个有效类，无效类则一条用例只覆盖一个无效条件，避免一个输入同时触发多个错误导致定位困难。

覆盖有效类的用例可以直接沿用原始实例的五组数据：3、4、5输出一般三角形；4、4、5输出等腰三角形；4、5、5输出等腰三角形；5、4、5输出等腰三角形；4、4、4输出等边三角形。无效类至少补五条：1、2、3用于三角不等式边界失败；0、4、5用于含零；-1、4、5用于含负数；a、4、5用于非整数；4、5用于输入个数不足。每条无效用例只验证一个错误条件，预期结果写系统给出的具体提示或错误码。

import pytest def classify_triangle(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 a == c or b == c: return "等腰三角形" return "一般三角形" @pytest.mark.parametrize("a,b,c,expected", [ (3, 4, 5, "一般三角形"), # 有效类：能构成不等边三角形 (4, 4, 5, "等腰三角形"), # 有效类：至少两边相等 (4, 4, 4, "等边三角形"), # 有效类：三边相等 (1, 2, 3, "非三角形"), # 无效类：两边之和等于第三边 (0, 4, 5, "非正数"), # 无效类：含零 ]) def test_classify_triangle(a, b, c, expected): assert classify_triangle(a, b, c) == expected

这段代码的作用是把等价类表变成可重复执行的断言。parametrize里的每一行对应一条用例，expected就是预期结果。非整数输入在实际接口里通常返回参数校验错误，不一定走到classify_triangle内部，所以真实项目要把接口层校验和业务层校验分开写。代码不是用来替代用例表的，用例表仍然负责记录前置条件、执行环境和缺陷关联，代码只负责回归时快速验证。

4.2 边界值分析：NextDate的月份、日期、年份边界

NextDate函数隐含规定月份范围1到12、日期范围1到31、年份范围1912到2050。边界值分析不是只测最大值和最小值，而是对每个变量取min-1、min、min+1、正常值、max-1、max、max+1，其他变量保持正常值。正常值取year=2001、month=6、day=15，这样输出容易核对。原始实例的测试表比较乱，重新整理后更利于执行。

这张表里ND-10值得多说一句。规格只写day范围1到31，但6月只有30天，31日到底算“超出1到31”还是“输入日期超界”，取决于需求实现。更严格的做法是按月份校验并提示输入日期超界，比较粗的实现可能直接加一天输出7.1。用例预期必须跟需求走，不能两种都写“正确”。合格负责人通常还会补闰年边界：2000年2月28日、2月29日、3月1日，以及平年2月28日、3月1日。原始实例没列闰年，不影响这里把它作为补强项。

4.3 错误推测与因果图：排序表和自动售货机

错误推测法依赖经验，不需要完整需求模型也能先列风险点。排序程序的经典补漏项包括：空表、单元素、已排序、逆序、全部元素相同、部分元素重复。每条都对应一个容易翻车的实现假设。空表可能触发越界；单元素可能进入不必要的循环；已排序和逆序可能暴露比较方向写反；全部相同可能让某些去重逻辑误删数据。

自动售货机适合因果图。原因有五个：售货机有零钱找、投入1元硬币、投入5角硬币、押下橙汁按钮、押下啤酒按钮。结果有四个：零钱找完红灯亮、退还1元硬币、退还5角硬币、送出橙汁或啤酒。中间结点表示“投入1元且押下饮料按钮”“押下橙汁或啤酒按钮”“应当找5角且售货机有零钱”“钱已付清”。因果图画完后必须转判定表，否则图只是文档装饰。

这张判定表把“没有零钱找时投1元不退饮料”的规则显式写出来了。实际系统还可能出现投5角、无零钱、按按钮的情况，因为5角不需要找零，是否出货要看需求。因果图的价值就在于把这些组合逼出来，执行人不用靠猜。

4.4 判定表驱动：设备维修优先级规则

设备维修优先级的规则是：功率大于50马力、维修记录不全、已运行10年以上，满足任一条件就优先维修。三个条件各有两种取值，规则数是2×2×2=8。先列初始判定表，再合并相似规则。初始表能防止漏掉“全N”的情况，化简表适合执行和评审。

化简后，规则1到7可以合并为“任一条件为Y则优先处理”，规则8是“三个条件全N则其他处理”。这里要确认需求里的连接词是“或”还是“且”。原文是“功率大于50马力的机器、维修记录不全或已运行10年以上的机器”，按任一条件满足处理。如果需求改成“且”，判定表会完全不同，所以评审时要把连接词圈出来。判定表驱动分析方法最适合这种条件组合清晰、动作有限的业务规则。

4.5 方法组合与选型

一套测试用例集里不需要把所有方法都用一遍，但需要知道每个对象为什么选这个方法。登录功能用场景法拆TC1到TC10，再用等价类补空输入和不存在用户，用边界值补超长用户名；三角形用等价类加边界值；NextDate用边界值加闰年补强；自动售货机用因果图转判定表；设备维修直接用判定表；排序程序用错误推测补经验风险。

组合顺序一般是：先把需求拆成输入条件、业务规则和状态流程；再选主方法生成第一批用例；然后补无效等价类和边界越界；最后用错误推测补经验风险，用覆盖矩阵检查每条需求是否有用例ID对应。方法只是生成用例的手段，验收时看的还是用例能不能执行、预期能不能判定、缺陷能不能追踪。

5. 避坑与排查：测试用例落地时最容易翻车的5个点

测试用例集写出来只是第一步，真正翻车往往发生在执行、回归和答辩环节。下面五条是项目里最常见的坑，每条按“现象→原因→解决”拆开。它们不针对某个具体系统，登录、三角形、NextDate、售货机都用得上。

5.1 用例编号随版本漂移，执行记录对不上

现象：回归时缺陷单写着“TC5失败”，但用例表里TC5已经变成另一条用例，执行人找不到原始步骤。原因通常有两个：编号里带了日期或顺序号，复制模板时被批量替换；或者废弃用例的ID被新用例复用。解决方法是把编号做成稳定标识，项目简写-模块简写-三位序号，发布后不复用。版本变化只改版本字段，不改编号；废弃用例保留并标记“停用”，新用例继续往后排。执行记录里同时记用例ID和版本号，这样即使用例内容修订，也能追到当时执行的是哪一版。

5.2 预期结果写成“正常”“成功”

现象：执行人说通过了，开发说没通过，双方对着“登录成功”四个字争论。原因是预期结果不可观察，没有页面元素、提示文案或状态变化作为依据。解决方法是把预期结果写成可判定事实：跳转到哪个页面、显示哪个用户名、提示文案是什么、输入框是否清空、会话是否退出。文案会变时，预期写“包含某关键词”并挂文案编号。预期结果最好一条用例只写一个主断言，多个检查点放备注。这样缺陷单里贴一张截图就能对齐，不用靠口头解释。

5.3 前置条件和测试数据没有隔离

现象：TC10连续三次失败执行完，TC5再用同一个账号登录，直接进不去，执行人以为登录功能坏了。原因是共享账号和共享会话，状态型用例污染了后续用例。解决方法是给状态型用例独立账号，执行前确认错误次数为0，执行后重置；前置条件写清是会话级还是账号级限制；测试数据准备和清理写成固定步骤。登录、锁定、验证码、购物车结算这类对象都要做数据隔离。没有隔离的用例集，执行顺序一变，结果就不可信。

5.4 只测有效路径，无效等价类缺失

现象：用例覆盖率看着很高，上线后输入超长字符串页面卡死，或者输入零值程序崩溃。原因是只写了正向路径，无效等价类和边界越界没有落成用例。解决方法是先列等价类表，有效类可以合并覆盖，无效类至少每类一条；边界值补min-1、max+1和特殊月末。三角形程序补含零、负数、非整数、两边之和等于第三边；登录补空输入、超长输入、不存在用户；NextDate补月份越界、日期越界、年份越界。无效用例的预期结果要写具体错误提示，不写“报错即可”。

5.5 把设计方法当仪式，画了因果图不转判定表

现象：文档里有因果图、有等价类表，但用例表里找不到对应的用例ID，评审时说不清哪个方法覆盖了哪条规则。原因是方法没有落到用例，图成了装饰。解决方法是每张表后面跟一列“对应用例ID”，因果图转判定表，判定表每一列至少映射一条用例；等价类每个无效类至少映射一条用例；边界值每个越界点映射一条用例。答辩时打开覆盖矩阵，按需求条目指到用例ID，比讲十遍方法定义都有效。

6. 验收与答辩：用一张覆盖矩阵讲清用例集为什么够用

验收测试用例集时，我一般不先数条数，而是先看覆盖矩阵：需求条目、风险点、用例ID、设计方法、预期证据五列。答辩时间有限，先讲被测对象和主要风险，再打开矩阵指三处：登录连续失败用TC10覆盖状态风险，用户名超长用TC3覆盖边界风险，三角形无效输入用TRI-06到TRI-10覆盖等价类风险。评委听到“哪条需求对应哪条用例、预期结果在哪里”基本就能判断这套用例是不是拼凑的。

答辩时还要主动说清“哪些没覆盖、为什么”。例如闰年边界在原实例里没列，这版补了2000年2月29日；浏览器兼容只选实验室统一环境，不展开多浏览器矩阵；性能和安全渗透不在本次用例范围。把边界讲清楚，比假装全覆盖更容易获得认可。从那以后我每次交用例集前，都强制走一遍“需求条目→用例ID→预期结果可观察”的覆盖矩阵，哪怕只花二十分钟，也能把编号漂移和空泛预期提前挡掉。希望帮到你。

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