企业官网建设流程全解析

简介：《测试用例编写指南》面向软件测试人员、测试设计初学者及技术管理团队成员，针对用例编写凭惯性思考、颗粒度与详细程度不一、可读性和覆盖度不足等问题，提供一套可落地的方法框架。压缩包内为1个docx文档，约494KB，围绕用例编写注意点组织内容，涵盖测试设计依据、需求分析到用例完善的五步流程、用例标题与前置条件/操作步骤/预期结果等要素模板、测试需求与用例划分原则、测试类型，以及等价类划分、边界值分析、状态迁移等常用设计方法，并单列编写要求、用例维护和风险建议。文档目录按目的、适用范围、步骤、要素、划分、方法、维护等章节展开，便于按主题查阅、团队内复用和查漏补缺。已有553人学习，适合希望统一用例规范、提升测试设计质量的读者参考。

1. 从"凭惯性写用例"到统一口径：测试用例编写指南要解决的是什么

同一个需求交给两个测试人员，产出的用例能差出一个量级：有人三条写完，有人三十条还没覆盖到异常分支；有人把操作步骤塞进用例名称，有人预期结果只写一句"页面显示正常"。评审会上争的不是对错，是口径。这份测试用例编写指南针对的正是这件事——把测试设计从个人经验拉回到统一规则，让用例编写注意点成为白纸黑字的条目，而不是老员工口口相传的玄学。它适合要交付一套可评审、可复用、可交接用例体系的团队，也适合做测试方向毕设、课设，需要拿出一份完整测试设计文档的人：指南里的步骤、要素、划分原则、设计方法四块拼起来，本身就是一份能直接照着填的骨架。

2. 测试设计依据与五步链路：从需求分析到用例完善怎么串起来

测试设计做不好，多数时候不是用例写得差，而是输入就不全。指南把依据和步骤放在最前面，逻辑很直白：你手上有什么料，决定你能写出多深的用例。料不全，后面所有技巧都是在补窟窿。

2.1 四类输入决定用例的天花板

指南列出的设计依据有五项，我把它们归成四类，因为它们补的是不同的缺口：

前三类是可归档的静态材料，第四类需要主动去拿。我一般的做法是在需求评审后单独约开发聊二十分钟，只问三个问题：这个功能改动涉及哪几张表、有没有复用老接口、哪些分支是这次不做的。这三个答案会直接变成后面第三个步骤的输入，也会变成用例里"预期结果"那几行的底气。UI 之所以要"基本成型"，是因为界面要素检查本身也是用例的一部分，页面要素、栏位文案、弹窗提示如果都还没定，写出来的界面类用例只能推倒重来。

需要提醒的是，这五类输入不是并列关系，而是有优先级的。需求说明书是基线，设计文档是深度，业务沉淀是补漏，开发交流是校准。只拿到需求说明书就开始写用例，写出来的东西大概率是"需求的自然语言翻译"，覆盖不到系统逻辑分支。

2.2 五步链路：每一步的输入、处理、输出都要能交出去

指南把编写过程拆成五步，每步都明确了输入、处理、输出。这个结构看起来朴素，实际是整份文档里最值钱的部分，因为它让过程可检查——任何一步的输出，都能被下一个人拿去接着干。

第一步的关键动作是"分类"，不是"抄写"。把需求按流程或功能切开，切完再看每个末级节点下面挂了几条检查点，检查点数量对不上需求复杂度，基本就是漏了。第二步是很多人跳过的环节，直接拿需求文档开写，结果主流程写得挺细，一到"如果审批被驳回怎么办""如果中途撤单数据往哪走"就卡壳。第三步最容易被低估：一个字段的长度从 20 改成 50，功能测试用例可能一条都不用改，但关联性回归要覆盖所有读取这个字段的页面和接口，这类检查点只能从设计文档和影响范围分析里来。

第四步的产出不是"能跑通就行"的用例，而是分类型的用例集合。指南明确要求覆盖功能正确性、边界、异常、接口、信息安全这几类，这句话翻译成执行动作就是：每写完一批正向用例，回头对每个输入项问一遍——最大值是什么、空值怎么处理、非法字符给什么提示、接口层有没有做二次校验。第五步放在流程末尾，是因为用例从来不是一次写完就冻结的交付物。

提示：五步的输出物要能落到同一个地方。测试需求、检查点、用例三级结构如果分散在文档、表格、脑图里，后面做覆盖率统计和回归筛选时会非常难受。

2.3 业务流程分析和系统设计分析：两个专门用来"补漏"的步骤

这两步在很多团队的实操里被合并成"看看代码改了啥"，但指南把它们拆开，是有道理的。业务流程分析补的是"业务上必须验证、但需求文档没写"的检查点：数据从哪来、往哪去、关键判断条件有几个分支、完成这个操作的前置条件是什么、非必要条件缺了会怎样。系统设计分析补的是"技术上必须验证、业务上不关心"的检查点：接口的入参校验、数据库表的字段约束、缓存与落库的一致性、批处理的执行顺序。

举个具体场景。一个后台的通知转历史任务，需求文档写的是"将超过 N 天的通知数据转移到历史表"。只做需求分析，用例大概只有一条：转移成功。加上业务流程分析，会补出"转移过程中新产生的通知是否被误转""转移后前台查询是否还能查到""分页查询在转移前后总数是否一致"。再加上系统设计分析，会补出"历史表与主表结构是否一致""转移失败的批次是否回滚""任务重跑是否产生重复数据"。这三层叠加后，一条需求变成七八条用例，覆盖深度完全不同。

2.4 用例完善的四个触发时机

指南列了四种必须回头改用例的场景：评审过程中发现用例有问题；系统新增功能或需求变更；测试执行过程中发现设计时考虑不周、存在遗漏；系统出现生产问题，经分析属于测试泄漏。

前两条是被动触发，后两条是主动信号。第三条最值得重视——测试执行阶段发现用例设计遗漏，说明检查点拆分时漏了分支，这时候改完用例要顺手回看一下同批次的用例有没有同类问题，否则同一个坑会以不同形式反复出现。第四条是复盘动作，生产问题的根因如果落在"用例没覆盖"，那就不只是补一条用例的事，还要判断是划分原则的问题还是设计方法没用对，前者改结构，后者改方法。

3. 用例要素与划分颗粒度：需求层级怎么拆、用例怎么合并

用例写不规范，八成不是态度问题，是模板没约束住。指南把要素和划分原则放一起讲，其实在解决两个层次的事：单条用例该长什么样，一批用例该切多细。

3.1 字段清单：测试需求 5 项，测试用例 12 项

测试需求侧有五个字段：需求路径（层级）、需求名称、需求描述、设计人、关联系统。其中需求路径是结构主干，格式是"/项目名称/一级需求/二级需求/……/N 级需求"；需求描述要做的不是概括，而是把针对这个末级需求的检查点一条条列出来。测试用例侧字段更多：用例路径、测试名称、用例描述、前置条件、操作步骤、预期结果、设计人、优先级、用例类型、用例属性、测试方式、执行次数。

把这些字段落成结构化的东西，比在 Word 里画表格靠谱得多。下面这份 YAML 是导入用例管理平台时的单条用例结构，字段与指南一一对应：

# 单条测试用例的结构化描述，字段顺序与指南中的要素清单一致 case: case_path: "/项目名称/业务管理/财务报表/财报模板管理/新增模板/" # 用例路径 = 需求路径 + 需求名称 test_name: "新增模板-模板名称输入有效性检查" # 名称只描述对象和检查点，不写操作步骤 description: "验证模板名称在空、超长、重复、含特殊字符时的处理" # 用例描述，说明这条用例想证明什么 precondition: | 1. 指定用户具备该项目的测试负责人权限； 2. 该项目下已存在名为"月报模板"的模板记录。 # 前置条件完整列出，不允许引用其他用例 steps: | 1. 进入模板管理列表页，点击"新增模板"； 2. 模板名称分别输入：空、纯空格、超长字符串、已存在的"月报模板"； 3. 其余必填项填写合法值，点击"保存"。 expected: | 1-2. 系统提示名称不能为空/超长/已存在，保存失败，检查前端与后台无新增记录； 3. 保存成功，前端列表展示与后台模板表新增记录的关键字段一致。 # 检查点完整列出，含落库校验 designer: "用例设计人" priority: "中" # 高：主流程与正常输入；中：异常流程与异常输入；低：界面显示与辅助功能 case_type: "功能点类" # 流程类/功能点类/报表统计类/界面类/报文接口类/批处理/其他类 case_attr: "异常" # 正常 / 异常 test_method: "手工" # 手工 / 自动化 exec_times: 1

几个参数值得单独说。case_path之所以要在需求路径后面再接一级需求名称，是为了让用例在平台上按目录树展开时能直接按需求聚合，做覆盖率统计时不用再做字符串匹配。priority三档不是随手标的，它决定了执行顺序：冒烟和主流程走"高"，异常与边界走"中"，界面显示、文案、辅助功能走"低"。一个项目排期被压缩时，先砍哪一批用例，答案就在这个字段里。case_type里的"报文接口类"和"批处理"是两类特别容易被混进"功能点类"的对象，一旦混进去，接口的入参校验和批处理的重跑逻辑就会被当成普通页面功能测，深度立刻掉一档。

注意：执行次数这个字段看起来可有可无，但对需要重复执行的场景（比如批处理任务在不同数据量下的表现）有用，写 1 和写 3 在回归排期时是两个工作量。

3.2 按测试对象分类的划分策略

指南把测试对象分成七类：前端功能（新增菜单、菜单功能修改）、业务流程、后台功能（新增或修改的单功能、接口）、批处理、后台流程、数据埋点、兼容性。每类的划分方式不一样，这是整份文档里最实用的对照表：

这张表解决的是"颗粒度不一致"这个老大难。前端功能天然适合按页面要素拆，因为界面检查点多且互相独立；业务流程天然适合按场景分支拆，因为分支之间是互斥的；批处理和后台流程必须按步骤拆，否则一个长链路用例失败了，根本定位不到是哪一步出的问题。

3.3 合并还是拆开：几条判定线

指南在划分原则后面给了几条说明，我把它整理成可以直接对照的判定线：

• 同一项目要区分多系统或多需求时，把系统名或需求名提为一级需求，原来的层级整体下沉一级。
• 需求描述必须把末级需求的检查点一一列出；检查点太多就把末级需求再拆一层，不要堆在一个需求里。
• 同一功能的不同入口，可以合并成一个需求，但用例层面通常还是要分开，因为入口不同，前置条件和页面要素检查不同。
• 一个功能的正常流程，对应一个检查点；一个功能里有多个正常场景或异常流程，分别列检查点。
• 同一功能需要准备多份不同数据时，原则上分别列检查点；如果一次操作要同时处理多份数据，才合并成一个组合检查点。
• 同一个需求检查点对应多种操作步骤时，合并成一条用例，但要把所有步骤详细列出。
• 自动化用例和功能用例要匹配；自动化覆盖不全时，拆成互补的多个用例集，不要用自动化用例"顶替"功能用例。

最后两条是很多团队踩过的坑。把多种操作步骤合并成一条用例，前提是这些步骤指向同一个预期结果；如果每条步骤的预期结果不同，合并后就变成"多对多"，失败时没法判断是哪一步的问题。至于自动化用例和功能用例的关系，比较稳妥的做法是：功能用例负责"该测什么"，自动化用例负责"能自动跑的那部分"，两者做映射而不是做替换，映射表里标清楚哪条功能用例没被自动化覆盖。

4. 编写要求与分支对应关系：名称、前置条件、步骤、预期结果、优先级

要素定义的是"有哪些字段"，编写要求定义的是"每个字段写到什么程度"。这两者的差别，就是一份能看和一份能用的差别。

4.1 测试名称与前置条件：可识别、不互相依赖

测试名称要简洁易懂，通过名称就能识别测试对象和检查点，不包含具体操作步骤和逻辑。像"放款失败-合同冻结"这种写法是合格的：对象是放款，检查点是合同冻结导致的失败。不合格的写法是"进入放款页面，选择合同，点击提交，查看是否失败"——这已经是操作步骤了，名称里塞步骤，列表一拉出来全是流水账，检索和统计都没法做。

前置条件有三条硬要求：有特殊账号权限要求、需要数据准备或前置操作的，必须完整列出；用例之间不允许相互依赖，不能把另一条用例当作前置条件；前置条件要写到"另一个人拿着这份条件能独立搭出环境"的程度。

第二条是血泪经验。用例 A 依赖用例 B 先执行，B 一旦失败，A 就变成"阻塞"，一条链上的用例全军覆没，执行报告上分不清是产品的问题还是用例设计的问题。正确做法是把 B 的关键结果直接写成 A 的前置数据准备步骤，哪怕描述重复一点，也比互相绑死强。

4.2 步骤与预期结果的三种对应关系

指南把操作步骤和预期结果的分支关系归成一对一、多对一、多对多，并且明确：多对多要用相同的编号反映对应关系，原则上不允许出现一对多。这套规则听起来抽象，落到表格上就很直观：

一对多之所以被禁，是因为它没法验收。一个步骤点下去出现三种可能的结果，说明这个步骤本身包含了未拆干净的判断条件，要么拆步骤，要么拆用例。多对多的编号关联则是实操里最常用的技巧，比如"模板名称输入空、超长、重复"三步分别对应三条提示，步骤编号 1-2-3，预期结果也写 1-2-3，评审的人一眼能对上。

还有两条容易忽略的对称要求：操作步骤里不能包含检查结果，预期结果里不能包含操作步骤。"点击保存，检查是否提示成功"这种写法把动作和断言混在一起，执行的人不知道到底该点几次；"点击保存后提示保存成功"出现在预期结果里是对的，出现在步骤里就越界了。

4.3 预期结果要检查到什么深度

预期结果是整条用例里最容易被写虚的字段。指南给的要求是分层递进的：

前端操作成功或失败，要包含页面显示、提示信息、后台数据存储、前后端数据一致性检查；涉及后台数据存储或变更的，要明确具体数据表和关键字段的取值变化；提示信息要明确关键检查内容，不能只写"给出合理提示"；后台系统测试和涉及信息安全的前端操作测试，必须包含输出日志和后台数据存储结果的检查；一个预期结果分支包含多步骤时，先把步骤按序列出，再用编号把检查点和它依赖的步骤关联起来。

把这几条落到实处，一条"新增模板"用例的预期结果大概是这个密度：页面提示"保存成功"；列表页新增记录出现在首行，字段值与输入一致；后台模板表新增一条记录，状态字段为有效、创建时间为当前时间；操作日志表新增一条操作记录。四句话，覆盖了前端显示、前后端一致、落库、日志四个层面。

写不到这个密度，测试执行时就会出现"看起来成功了就过了"的情况，而这正是生产问题最常见的来源——前端提示成功但后台没落库、落库了但字段截断、字段对了但日志没记。指南把日志检查单独拎出来，是因为涉及权限、金额、审批这类敏感操作时，日志是唯一的追溯依据。

4.4 优先级三档的实际判据

优先级分高、中、低，指南给的判据是：

• 高（优先执行）：确保系统基本功能及关键路径，比如正常流程、页面元素的正常输入。
• 中（次级执行）：确保系统功能完善，比如异常流程、页面元素的异常输入。
• 低（最后执行）：用户体验相关、较少使用或辅助功能，比如页面元素显示检查。

这个分法和很多人的直觉相反——不少人会把"界面显示检查"当成必测项标成高优先级。但对排期紧张的迭代来说，主流程跑不通是灾难，按钮文案错位不是。优先级字段的真正用途是排期被砍时的取舍依据，标错就等于把取舍权交出去了。一个实用的校准方法：每次回归结束后，统计一遍高优先级用例的失败率，如果高优先级用例通过率 100% 而生产上还是出了问题，那说明优先级标错了或者检查点漏了。

4.5 测试类型与设计方法的配对使用

指南列了十二类测试：功能、接口间、信息安全、关联性、回归、数据库、压力、操作友好性、效率、兼容性、数据移植、安装。设计方法列了六种：功能正确性、异常、边界值、等价划分、错误推测、因果图分析。

这两组东西要配对用，不能指望一种方法覆盖所有类型。功能正确性测试打底，保证需求说明书里的功能都有对应用例；异常测试模拟一个不了解产品的用户乱点，重点在非法类型、不符合要求的数据、长度溢出，典型场景是前端限制长度与数据库字段长度不一致；边界值测试盯住刚刚小于、等于、刚刚大于这几个点，像利率浮动比例的边界值 0 这种就是标准用例；等价划分把有效和无效输入各分成若干等价类，避免为同一类输入写十条重复用例；错误推测靠经验，分页场景、金额四舍五入这类地方历史上出问题最多；因果图分析处理输入条件的组合约束，登录页的验证码、身份信息、密码校验就是典型的多条件组合场景。

对应到测试类型上：接口间测试主要靠等价划分加异常测试，关注模块间数据输入输出的一致性；数据库测试靠设计文档加边界值，关注表结构、字段长度、调用关系；关联性测试和回归测试靠影响范围分析，用例本身不复杂，难的是圈定范围；压力测试和效率测试靠数据量级划分，重点在跨表查询这类操作；数据移植测试关注迁移前后数据量一致性、表结构变化、迁移后的业务逻辑回归。

5. 避坑与常见问题排查：五条最容易翻车的地方

规则写得再细，落地时还是会走样。下面这五条是按"现象、原因、解决"整理的高频问题，基本覆盖了用例评审里被挑出来的大部分毛病。

第一条：用例名称写成操作流水账。现象是列表里一拉，几十条用例名全是"进入 XX 页面点击 XX 按钮查看结果"。原因是写的人把名称当成了步骤的压缩版。解决办法是定一条硬规则：名称只允许"对象-检查点"两段式，写完回头看一眼，凡是出现"点击""进入""查看"的一律打回重写。这条规矩坚持两周，整个用例库的可读性会明显上一个台阶。

第二条：用例之间互为前置条件。现象是执行时一条失败，后面一串全变阻塞，报告上全是"未执行"。根因是图省事，把上一条用例的执行结果直接当成了下一条的前提。解决方式是把依赖数据写成前置条件里的准备步骤，宁可描述重复，也不让用例之间产生执行顺序依赖。评审时专门查一遍前置条件字段里有没有出现用例编号，有就改。

第三条：只测正向流程，边界和异常靠临场发挥。现象是功能用例一大堆，异常用例零星几条，生产上出的问题全是"输入超长""重复提交""并发操作"。根因是写用例时脑子里跑的是正常路径。解决办法是在第四步之后强制加一轮"输入项扫描"：把每个页面的输入项列出来，逐个问空值、超长、特殊字符、重复、类型不符这五类问题，扫出来的检查点直接补进测试需求。这一步做完，异常用例的数量通常会翻倍。

第四条：预期结果只写"操作成功"，后台数据没人核。现象是用例执行全绿，上线后对账不平、数据错位。根因是预期结果停留在界面层，没有落到表和字段。解决方式是在模板里把预期结果拆成固定四段：页面显示、提示信息、落库记录与关键字段、日志。哪一段不适用就写"不涉及"，但不允许留空。这条改动看着机械，实际是把"前后端数据一致性"这个抽象要求变成了可勾选的检查项。

第五条：用例只增不删，需求变更后不同步。现象是回归集越滚越大，跑一遍要三天，里面还有大量已经下线的功能。根因是没有把用例当成活文档维护。解决办法是把指南里那四个完善时机挂到流程节点上：评审通过后、需求变更单关闭时、每轮测试结束后、生产问题复盘后，各做一次用例同步，该作废的标作废而不是删除，保留追溯链路。作废状态这个字段看着小事，真出问题时能查到"这条用例是什么时候、因为什么被停用的"，比翻聊天记录强得多。

6. 验收与答辩：怎么证明这套用例体系真的落地了

一套用例规范最容易变成"文档写完就归档"。要证明它真的在跑，验收时不能只看文档厚度，得看数据。我一般会从三个角度切：结构完整性、覆盖对应关系、维护留痕。

结构完整性可以直接查。假设用例落在测试管理平台的test_case表里，用一条 SQL 就能把字段缺失的情况拉出来：

-- 统计当前迭代内字段缺失的用例分布，用于验收用例规范执行情况 SELECT t.module_name AS 模块, COUNT(*) AS 用例总数, SUM(CASE WHEN t.precondition IS NULL OR TRIM(t.precondition) = '' THEN 1 ELSE 0 END) AS 缺前置条件, SUM(CASE WHEN t.expected_result IS NULL OR TRIM(t.expected_result) = '' THEN 1 ELSE 0 END) AS 缺预期结果, SUM(CASE WHEN t.priority NOT IN ('高','中','低') THEN 1 ELSE 0 END) AS 优先级异常, SUM(CASE WHEN t.case_type IS NULL THEN 1 ELSE 0 END) AS 缺用例类型 FROM test_case t WHERE t.project_id = '当前项目' -- 替换为实际项目标识 AND t.status = '有效' -- 只统计有效用例，作废的不计入 GROUP BY t.module_name ORDER BY 用例总数 DESC;

这条查询的输出可以直接当验收材料：哪个模块的缺前置条件比例最高，哪个模块的优先级标注不规范，一眼能看出来。参数上，status = '有效'这个条件不能省，否则作废用例会把统计口径带偏；module_name换成需求路径前缀也可以，看你平台上的目录结构怎么存。

覆盖对应关系看的是测试需求和用例有没有一一挂上。检查方式很简单：把当前迭代的测试需求清单和用例清单按需求路径做左连接，找出"有需求但没用例"的节点。这类空节点通常集中在异常分支和回归范围上，正好对应第 5 章第三条和第五条的问题。我见过一个项目，左侧需求树 200 多个末级节点，右侧用例覆盖率不到 60%，缺口全在"影响范围回归"这一类上，靠这条检查一次性暴露出来。

维护留痕看的是变更记录：这一轮有多少条用例被修改、多少条被作废、作废原因是什么。如果一轮迭代下来修改数是 0，不是用例写得完美，而是没人维护。

至于答辩或评审现场，比较有效的讲法不是逐条念文档目录，而是拎一条真实业务链路走一遍：从需求文档里挑一个功能，现场展示它怎么经过业务流程分析补出备选流程检查点、怎么经过系统设计分析补出接口和落库检查点、最后怎么落成一条带前置条件和四段式预期结果的用例。讲完这一条，评审的人对整套方法的理解会比看十页目录深得多。如果能再补一句"这条链路对应的生产问题历史上出过几次、现在被哪条用例挡住了"，说服力就到位了。

从那以后我每次交付用例规范，都会强制走一遍"一条链路 + 一条 SQL + 一张覆盖缺口表"的验收动作，不看完这三个东西不签字。规范本身不难写，难的是让它一直在跑。希望这套结构能帮到你。

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