简介：这份《测试用例编写指南》面向测试人员、技术管理团队成员及需要规范测试设计的从业者，针对用例编写凭经验惯性、颗粒度与详略不一、可读性差等痛点，提供一套可落地的统一规范。包内为单个 docx 文档，压缩包约 494KB，篇幅紧凑，便于随查随用。目前已有 551 人学习，说明其在测试设计场景中具有一定参考价值。文档按目的、适用范围、测试设计依据、编写步骤、编写要素、划分原则、编写要求、测试类型、设计方法、维护及风险建议组织，完整展开需求分析、业务流程分析、系统设计分析、用例编写与用例完善五步流程；同时说明需求路径、前置条件、操作步骤、预期结果、优先级、用例类型、用例属性、测试方式与执行次数等字段，并介绍等价类划分、边界值分析、状态迁移等方法，可直接用于团队模板统一、评审检查和新人补缺。

1. 用例颗粒度差三倍：这份 23 页的规范到底卡在哪

同一个项目，两个测试人员写出来的用例能差三倍：有人一个页面写一条，有人一个输入框拆五条，评审会上谁也说服不了谁，最后只能按资历拍板。这份《测试用例编写指南》.docx 处理的就是这个具体问题——把「凭惯性思考」变成「有章可循」。它把测试设计拆成需求分析、业务流程分析、系统设计分析、用例编写、用例完善五步，又把测试需求与用例的划分按前端功能、流程类、后台功能、批处理、后台流程、数据埋点、兼容性七类测试对象逐类钉死，最后落到操作步骤与预期结果的一对一、多对一、多对多对应规则。适合技术管理团队成员、测试负责人，以及刚开始接手用例设计、需要一套可对齐标准的从业者。我拆这份文档时关注最多的不是那些大框架，而是「用例编写注意点」里几个容易漏的分支对应关系，下面按实际落地顺序讲。

2. 五步法落地：从需求分析到用例完善的输入输出对照

这五步的价值不在于步骤本身，而在于每一步都明确写了输入、处理、输出三件事。绝大多数团队写用例出问题，是因为直接从「需求说明书」跳到「写用例」，中间两步被省略了，结果用例只覆盖了需求文档字面上写了的东西，没写的地方全是盲区。

2.1 需求分析：把业务需求拆成带检查点的测试需求

这一步的输入是业务需求说明书，处理动作是「按流程或功能分类」，输出是整理成测试需求，并把每一个需求细节列出来作为检查点。注意这里的措辞——输出的是测试需求，不是测试用例。这两者在文档里是分开定义的，测试需求回答「要验证什么」，测试用例回答「怎么验证」。

我一般的做法是：把需求说明书逐条编号，每条业务需求改写成一到多个可验证的陈述句，一个陈述句对应一个检查点。判断标准很粗暴——这个陈述句能不能用「是/否」回答。比如「系统支持用户注册」这种就没法验证，「手机号不符合 11 位时提交，系统提示格式错误且不写入用户表」就能验证。

这一步最常见的偷懒方式是直接把需求文档的章节标题抄成测试需求名称。章节标题是按文档结构组织的，不是按验证对象组织的，抄下来之后用例路径会非常乱，后面按目录批量执行、统计覆盖率都对不上。文档里对路径有明确规定：需求路径是「/项目名称/一级需求/二级需求/……/N 级需求」的形式，这个层级不是随便定的，它直接决定了用例在测试管理平台里的组织方式和执行粒度。

提示：需求描述字段要把针对该末级需求的所有检查点一一列出。检查点数量多到一屏放不下时，说明这个末级需求该往下再拆一层，而不是把检查点堆在一个描述里。

2.2 业务流程分析与系统设计分析：补需求文档没写的那两部分

第二步业务流程分析的输入是业务背景知识和被测系统/模块的业务流程，处理是整理主流程、备选流程、数据流向、关键判断条件，以及完成该操作的（非）必要条件，输出是「作为业务需求未提及、但需要覆盖验证的检查点」。这句话是整份文档里最容易被跳过、又最值钱的一句。

需求文档通常只描述主流程。备选流程、异常分支、数据流向中的中间状态，往往只在和开发口头沟通时才浮现。举个通用例子：某审批功能，需求写的是「支持审批通过和审批拒绝」，但实际业务流程里有「审批人离职后单据如何转交」「同一单据被两人同时打开如何加锁」「审批中途修改金额是否需要重新走流程」——这些都不是需求文档的字面内容，全部属于业务流程分析该输出的检查点。

第三步系统设计分析更偏技术侧。输入是概要设计、详细设计、接口设计及数据库设计文档，处理是针对系统为实现业务需求所做的主要改动点及影响范围做全面分析，输出是把改动功能支持的所有逻辑、以及对影响范围的回归测试加入测试需求检查点。这一步的产出直接决定了「关联性测试」和「回归测试」的范围——文档后面列测试类型时专门提了「针对不涉及代码改动但与被改动功能有依赖或调用关系的功能进行关联性测试」，这个范围不是拍脑袋圈的，是从设计文档的影响面分析里推出来的。

我的习惯是第三步一定要拿到数据库设计文档。前端提示信息可以靠点页面验证，但「前后端数据一致性」「后台数据存储结果」这类检查点，没有表名和字段名根本写不具体。后面讲预期结果编写要求时会看到，文档明确要求「如涉及后台数据存储/变更，应明确具体数据表记录和关键字段取值变化」——这句话如果没有数据库设计文档，写出来就是空的。

2.3 用例编写与完善：四种必须回炉的场景

第四步用例编写的输入是测试需求，处理是「尽量覆盖生产上的所有业务流程场景和系统逻辑分支，除了正向测试以外，加强对边界、异常等情况的关注」，输出要求用例类型覆盖功能正确性测试、边界测试、异常测试、接口测试、信息安全测试等。注意这里的关键词是「覆盖」而不是「写完」，判断标准是分支覆盖，不是数量。

第五步用例完善给出了四个触发条件：评审过程中发现用例有问题；系统新增功能或需求变更；测试过程中发现设计用例时考虑不周、存在遗漏点；系统出现生产问题、经分析为测试泄漏。前三条是常规维护，第四条才是真正拉开团队水平的地方。

生产问题倒推用例缺口这件事，很多团队做完就完了——修完 bug 上线，用例库纹丝不动，下次换个入口同样的逻辑再漏一次。我的做法是：凡是判定为测试泄漏的生产问题，必须在测试需求里新增一个检查点，在用例里新增或修改至少一条用例，并且在用例描述里留一句来源标记。这样半年后回头统计，能看出用例库的增长到底是被需求驱动的还是被事故驱动的，比例失衡就说明设计阶段的分析做得不够。

注意：第四步要求「用例类型覆盖功能正确性测试、边界测试、异常测试、接口测试、信息安全测试等」，这里的「等」不是省略号，是留给项目按自身技术栈补充的。带文件上传的系统要加文件类型与大小边界，带定时任务的系统要加批处理节点，不要只抄文档列的五类。

3. 要素与划分：六类测试对象切下去，颗粒度才收得住

颗粒度失控的根因通常不在写用例的人，而在划分原则没有被写死。文档把划分拆成两层——测试需求怎么划、测试用例怎么划，两层用不同的依据，混在一起谈就永远谈不拢。

3.1 十三个要素里哪几个必须写死

测试需求有 5 个要素，测试用例有 12 个要素。全列出来看着多，实际落地时按「必须写死」和「可以后补」分两类管理效率最高。

用例路径这条规则值得单独说。文档写的是「在需求路径的基础上增加需求名称」，也就是「/项目名称/一级需求/二级需求/……/N 级需求/需求名称/」。多一级、少一级，在测试管理平台里就会挂到错误的目录下，按需求统计覆盖率的时候直接算不出来。我见过有团队在这一层自己加了「模块」和「子模块」两级，结果和需求树对不上，做覆盖率报告时手工对齐花了两天。

3.2 测试需求划分：七类测试对象的切法

文档按测试对象分类给出了划分依据和划分方式，这张表是整份规范里最像「操作手册」的部分，可以直接抄进团队规范。

表外还有六条说明，其中三条直接决定颗粒度：

第一，一个功能的正常流程对应一个检查点，但一个功能中含多个正常场景或异常流程，必须分别列出多个检查点。第二，同一功能需要准备多份不同数据时，原则上分别列出多个检查点；如果针对同一操作需要同时对多份数据进行处理，可以单独列一个组合检查点。第三，同一功能的不同入口可以合并编写一个需求——这条是防止过度拆分的，两个入口走同一套后端逻辑，硬拆成两个需求只会让回归时重复执行。

3.3 测试用例划分：一条检查点对应一条用例的边界在哪

测试用例的划分原则基本是一句话：一个测试需求检查点对应一条用例。真正需要注意的是例外条款。

前端功能的例外最明确：页面要素检查、列表查询/分页/删除功能检查、表单新增/修改输入项检查，这三类可以按输入项数量酌情拆分。文档举的例子是「单条发送消息-新建在线发送任务输入项检查」单独成一条，说明输入项多的时候不强行塞进要素检查那条里。

后台功能的例外是「以下功能的测试点可考虑合并成一条用例：入参有效性检查」。这条很实用——一个接口十几个参数，每个参数的空值、超长、特殊字符如果各写一条，用例数会爆炸，而且执行时根本没人会逐条跑。合并成一条「入参有效性校验」，在操作步骤里把参数和输入值列清楚，执行效率高得多。

兼容性的划分方式值得单独看：按维度划分，每种维度的可细分项对应一条用例。按操作系统维度分成 iOS、Android 两条；按机型维度分成 iOS-iPhoneX、iOS-iPhone8 等，条数等于机型数量；按浏览器维度分成 UC、QQ 等，条数等于浏览器数量。这里的关键是「维度」要先定，不能一会儿按系统拆一会儿按机型拆，混着拆出来的用例没法做笛卡尔积统计。

最后一条是自动化用例与功能用例的关系：二者应匹配，若自动化用例不能完全覆盖功能用例，则将功能用例和自动化用例拆分成多个互补用例集。这句话的意思是——自动化用例只覆盖了主流程，剩下没覆盖的异常分支必须在功能用例集里单独存在，不能因为「有自动化了」就把这部分用例标记为已覆盖。

3.4 一份可导入的用例字段定义

文档里的表格模板落到测试管理平台，通常要转成结构化字段。下面这份 YAML 是我按文档里的要素定义整理的字段结构，字段名可以按平台调整，但层级和必填项建议保持一致。

# 测试用例字段定义，按《测试用例编写指南》要素整理 case: path: "/项目名称/一级需求/二级需求/需求名称/" # 用例路径 = 需求路径 + 需求名称，末尾保留斜杠 name: "登录接口-账户不存在" # 测试名称：能识别对象和检查点，不含操作步骤 description: "验证不存在的账户登录时的提示与日志" # 用例描述 precondition: # 前置条件，逐条列出，禁止引用其他用例 - "已存在有效账户 A，状态为正常" - "账户 B 未在系统中注册" steps: # 操作步骤，按序号排列，不写检查结果 - "1. 打开登录页，输入账户 B 和任意密码" - "2. 点击登录按钮" expected: # 预期结果，检查点完整列出 - "1. 页面提示账户或密码错误" - "2. 用户表无新增记录，登录日志表新增一条失败记录，result 字段为 FAIL" designer: "A同学" priority: "中" # 高 / 中 / 低 case_type: "报文接口类" # 流程类、功能点类、报表统计类、界面类、报文接口类、批处理、其他类 case_attr: "异常" # 正常 / 异常 test_method: "手工" # 手工 / 自动化 exec_count: 0 # 执行阶段回填

字段里最容易写错的是expected。文档的要求是：前端操作成功/失败要包含页面显示、提示信息、后台数据存储、前后端数据一致性检查；涉及后台数据存储/变更的要明确具体数据表记录和关键字段取值变化；后台系统测试和涉及信息安全的前端操作测试必须包含输出日志、后台数据存储结果检查。上面例子里的「登录日志表新增一条失败记录，result 字段为 FAIL」就是按这条要求补的，光写「提示账户或密码错误」在评审时一定会被打回。

用例数量上来之后，人工核对字段完整性不现实。我一般会挂一个轻量脚本在提交前跑一遍，卡住最常见的三类问题：必填字段为空、操作步骤和预期结果编号数量对不上、前置条件里出现了对其他用例名称的引用。

import json import re REQUIRED = ["path", "name", "precondition", "steps", "expected", "priority", "case_type"] def check_case(case: dict) -> list: problems = [] # 1. 必填字段非空检查 for field in REQUIRED: value = case.get(field) if not value or (isinstance(value, list) and len(value) == 0): problems.append(f"字段 {field} 为空") # 2. 步骤与预期结果的编号是否一致（多对多场景允许数量不等，但编号必须成对出现） step_ids = {re.match(r"(\d+)", s).group(1) for s in case.get("steps", []) if re.match(r"(\d+)", s)} exp_ids = {re.match(r"(\d+)", e).group(1) for e in case.get("expected", []) if re.match(r"(\d+)", e)} if step_ids and exp_ids and not exp_ids.issubset(step_ids | exp_ids): problems.append("预期结果编号在操作步骤中找不到对应") # 3. 前置条件不允许引用其他用例 for pre in case.get("precondition", []): if "用例" in pre and "执行" in pre: problems.append(f"前置条件疑似引用其他用例：{pre}") # 4. 操作步骤里不允许出现检查类动词 for s in case.get("steps", []): if any(k in s for k in ["检查", "确认", "验证"]): problems.append(f"操作步骤含检查动作：{s}") return problems if __name__ == "__main__": with open("cases.json", "r", encoding="utf-8") as f: cases = json.load(f) for idx, c in enumerate(cases, 1): for p in check_case(c): print(f"[case {idx}] {p}")

脚本里的四条规则对应文档里的四条硬性要求：REQUIRED列表按第 3.1 节的必填项裁剪，如果团队有额外必填字段直接往里加；编号校验处理的是多对多场景——文档允许操作步骤和预期结果多对多，但要求通过相同的编号反映对应关系，编号对不上就说明对应关系丢了；前置条件引用其他用例是明确禁止的，文档写的是「用例之间不允许相互依赖，例如：将其他用例作为前置条件」；操作步骤里出现「检查」「确认」「验证」这类词，本质是把检查结果混进了步骤，文档要求「操作步骤中不能包含检查结果」，这条用正则扫描比人工评审快得多。参数上没什么可调的，cases.json的格式按 YAML 那份结构转成 JSON 数组即可。

4. 步骤与结果的对应关系：一对一、多对一、多对多怎么落笔

这一块是整份文档里最细、也最容易在评审时吵起来的部分。文档把操作步骤和预期结果分支的对应关系拆成四类，其中三类允许、一类不建议，判定标准写得很清楚，照着套就行。

4.1 四种对应关系与判定标准

文档对「不建议使用」的两类给了明确理由：拆分后每条用例的失败原因唯一，执行时能直接定位问题；混在一起的用例一旦失败，得人工判断是哪一步哪一项出了问题，回归阶段的时间全耗在这上面。

4.2 拿「删除测试执行集」走一遍

文档用一个完整的业务场景把四类关系串起来了，这个例子值得逐条拆。

第一种，一种操作对应一个预期结果分支、分支内只有一个检查点：前置条件是「指定用户具备所选项目的测试负责人权限，指定项目的测试执行集中有已创建的测试轮次和分类目录，其中含未挂用例的分类目录」，操作是「进入测试执行管理页面，选择指定轮次一个未挂用例的分类目录点击删除」，预期结果是「可成功删除未挂用例的测试执行集」。这一条干净利落，失败就是删除功能坏了。

第二种，一个预期结果中含多个检查点：同样的删除动作，但目录下已经挂了未执行的用例。预期结果变成两条——「可成功删除已挂用例的测试执行集，包括分类目录和其下所有用例执行记录」和「测试用例管理列表的用例数据仍存在且为有效状态，不受执行集删除影响」。第二条就是典型的容易被漏掉的检查点：删除执行集不应该动到用例库本身的数据。这种跨模块的数据一致性检查，只靠需求文档是写不出来的，得靠系统设计分析阶段的表结构梳理。

第三种，多种操作对应一个预期结果分支：分别删除只有一级的分类目录、多级分类的根目录、多级分类目录下的子目录，三种操作对应同一个预期结果「可成功删除未挂用例的测试执行集」。这种合并是合理的，因为三者验证的是同一段删除逻辑，只是入参层级不同。

第四种，多种操作对应多个预期结果分支、一一对应：添加分类时，分类名称为空或空格 → 提示不能为空；分类名称为数字字母特殊字符组合 → 添加成功；分类名称前后中带空格 → 添加成功且空格可保存；分类名称超长 → 提示超长；分类名称重复 → 提示已存在。五种操作五个结果，用相同编号关联，这是异常测试的标准写法。

例子最后还有一句收尾：「针对以上添加成功的场景，应检查前端展示数据与后台 XX 表新增记录一致；添加失败的场景，应检查前端和后台无对应新增记录」。这句话把前面第四步系统设计分析的产出用上了——数据表名和字段名在这里必须写实，写成「后台表」等于没写。

提示：多对多用例里，预期结果分支的编号必须和操作步骤编号严格对齐。评审时第一眼就看这个，对不上基本直接退回，不用往下看内容。

4.3 优先级与测试类型的配套

优先级三档的划分依据是执行顺序，不是重要程度。文档的定义是：高（优先执行）对应确保系统基本功能及关键路径的用例，比如正常流程、页面元素正常输入测试；中（次级执行）对应确保系统功能完善的用例，比如异常流程、页面元素异常输入测试；低（最后执行）对应关于用户体验及其他较少使用或辅助功能的用例，比如页面元素显示测试。

这个分法和很多团队的习惯相反——不少团队把「页面元素显示」标成高优先级，理由是「用户第一眼就看到」。文档的逻辑是执行顺序优先：冒烟阶段跑主流程，主流程通了再跑异常，最后做界面细节。按这个顺序执行，如果主流程就挂了，后面的异常和界面用例根本不用跑，省下来的是整轮回归的时间。

测试类型一共列了十二类：功能测试、接口间测试、信息安全测试、关联性测试、回归测试、数据库测试、压力测试、操作友好性测试、效率测试、兼容性测试、数据移植测试、安装测试。用例类型字段里那七个分类（流程类、功能点类、报表统计类、界面类、报文接口类、批处理、其他类）是按测试对象分的，和这里的测试类型不是一回事，别混。前者决定用例挂在哪，后者决定用例验什么。

容易漏的是数据移植测试和安装测试。文档对数据移植测试的关注点写得很具体：迁移前后数据量一致性、数据库表结构变化、以及针对迁移后的数据进行业务逻辑回归测试。这三条在系统迭代更新时必须有对应用例，否则数据迁移出问题要到生产才暴露。安装测试则要求覆盖首次安装、升级、完整安装、自定义安装四种情况，并且核实安装完成后能正常运行——这条在纯 Web 项目里经常被忽略，但只要涉及客户端或私有化部署就跑不掉。

5. 评审被打回的五种情况：现象、原因与改法

用例评审的效率取决于退回理由是否具体。下面五条是我在实际评审里出现频率最高的，每条都按现象、原因、解决三段写，可以直接拿去当团队的评审检查项。

5.1 前置条件写成「依赖另一条用例」

现象：前置条件里出现「先执行用例 TC-0123」「在上一节用例执行成功的前提下」这类表述。原因是用例设计时按业务流程顺序写，把流程上的先后关系当成了前置条件。文档明确禁止：「用例之间不允许相互依赖，例如：将其他用例作为前置条件。」

改法是把依赖的那条用例的最终状态抽出来，写成数据准备描述。比如依赖「用户已注册成功」，就写成「已存在状态正常的用户 A，手机号 138xxxx，已完成实名认证」。这样任何一条用例都能单独执行，回归时不用按顺序跑全量。代价是要维护一份测试数据准备清单，但省下来的是执行阶段的排序成本。

5.2 操作步骤里混进了检查结果

现象：操作步骤写成「输入手机号，检查提示信息是否正确」「点击提交，验证数据已入库」。原因是写的人把「操作」和「断言」混在一个字段里了，脑子里是连贯的，落到文档就串了。文档的要求是「操作步骤中不能包含检查结果」，预期结果里也「不能包含操作步骤」。

改法是每条步骤只描述动作：入口在哪、输入什么、点哪个按钮、按什么顺序。所有「检查」「验证」「确认」开头的句子整段挪到预期结果里。第 3.4 节那个脚本的第二、四条规则就是扫这个的，提交前跑一遍比评审会上一条条念快。

5.3 预期结果只写「提示成功」

现象：预期结果栏里是「提示操作成功」「页面跳转正常」「数据保存成功」这种。原因是写的人默认「成功」是个已知状态，没意识到执行人和设计人对「成功」的理解可能不同。

改法是按文档要求补齐四件事：页面显示、提示信息、后台数据存储、前后端数据一致性。提示信息要写明确切文案或关键内容；涉及后台数据变更要写清表名和关键字段的取值变化；后台系统测试和信息安全相关的前端操作，必须包含输出日志和后台数据存储结果检查。举一个合格的写法：「页面跳转至列表页并提示『保存成功』；用户表新增一条记录，status 字段为 1，create_time 为当前时间；操作日志表新增一条记录，操作类型为 CREATE。」

5.4 多对多用例硬凑成一条

现象：一条用例里操作步骤有七步，预期结果有九条，编号还互相交叉。原因是设计时想着「反正都是测这个表单」，就合在一起了。

改法是按预期结果分支拆分。文档对这类用例的判断标准是「不建议使用」，理由前面说过——失败原因不唯一。拆完之后每条用例只验一个结论，执行记录里能直接看出是哪个检查点挂了，统计缺陷分布时也有意义。如果拆完发现用例数量涨得太多，回头看看测试需求是不是划得太细，在需求层合并比在用例层硬塞更合理。

5.5 优先级全填「高」

现象：一整批用例的优先级都是高，执行时没有先后，等于没有优先级。原因是设计人把「这条用例重要」和「这条用例先执行」当成一回事了。

改法是按文档的三档定义重新分：高对应基本功能和关键路径，也就是正常流程和页面元素的正常输入；中对应异常流程和异常输入；低对应界面显示和辅助功能。分完之后做一次抽样——如果高优先级用例占比超过一半，说明分档没起作用，需要重新过一遍。我的经验值是高三成、中五成、低两成比较接近实际执行节奏。

6. 设计方法组合：等价类、边界值、错误推测的排序技巧

文档列了六种设计方法，实际用的时候不是每次都全上，而是按被测对象的特征选两到三种组合。功能正确性测试是底座，任何用例集都必须先覆盖需求说明书里的各项功能正常实现，这一步不能省，也不能用异常用例替代。

在这之上，我一般的排序是：先等价类划分把输入域切开，再在切出来的每个类上取边界值，最后用错误推测补经验项。等价类的作用是压缩——把无限多的输入压成有限个有代表性的类，有效类和无效类各取一个；边界值是在压缩后的类上做加密，因为绝大多数 off-by-one 错误都发生在边界附近；错误推测则是补前两步覆盖不到的地方，文档举的三个例子很典型：分页场景（查询分页、文件分页）、金额四舍五入、前端限制长度与数据库字段长度不一致。

边界值这块文档给了一个具体的取法：刚刚小于、稍小于、等于、刚刚大于、稍大于边界值，在测试过程中输入一组合法数据/非法数据，集中在边界值附近选取。它举的例子是利率管理里利率浮动比例值的边界为 0——这种情况要取 -0.01、-0.001、0、0.001、0.01 这一组，而不是简单地取 -1 和 1。取「稍小于」和「刚刚小于」的区别在于，前者验证的是明显越界，后者验证的是临界精度，很多系统对前者有校验、对后者没有。

因果图分析用在输入条件有组合约束的场景。文档给的例子是登录页面的验证码、身份证、姓名、密码校验，以及 if a, b 这种条件组合。这类场景用等价类拆不开，因为问题不在于单个输入是否合法，而在于多个输入的组合是否被正确处理。落地时的做法是先把输入条件列成布尔变量，标出互斥和依赖关系，再枚举有效组合。

一个容易被忽略的点是，测试用例设计方法的产出要回填到测试需求里。文档在第三步系统设计分析里要求「将改动功能支持的所有逻辑、以及对影响范围的回归测试加入测试需求检查点」——等价类划分出来的无效类、边界值取的那一组临界值、错误推测出来的经验项，都应该先在测试需求里体现为检查点，再落到用例。顺序反过来的话，用例写完了回头补需求，路径会对不上，覆盖率统计也就失去意义了。

注意：异常测试的思路文档写得很直白——「模拟一名不了解产品操作的客户执行任意操作」。这句话比任何检查清单都好用，写异常用例卡住的时候，把自己当成第一次用这个系统的人，胡乱点一遍，漏掉的场景基本就出来了。

最后说一个我踩过的坑。早些年我带队做用例评审，习惯性先看用例数量，觉得数量上去了覆盖就到位了。有一次某模块写了三百多条用例，评审全过，结果上线后一个很基础的场景漏了——同一功能两个入口，只测了主入口。后来才发现问题出在测试需求划分阶段，两个入口被合并成了一个需求（文档里确实允许合并），但合并之后用例只覆盖了其中一个入口的操作路径，另一个入口在用例层面根本没有体现。从那以后我每次做需求合并，都强制在需求描述里把涉及的入口逐个列出来，用例写完再拿这份入口清单反向核对一遍，确认每个入口至少有一条对应用例。希望帮到你。

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