简介这份《测试用例编写指南》面向测试人员、技术管理团队成员及需要规范测试设计的从业者针对用例编写凭经验惯性、颗粒度与详略不一、可读性差等痛点提供一套可落地的统一规范。包内为单个 docx 文档压缩包约 494KB篇幅紧凑便于随查随用。目前已有 551 人学习说明其在测试设计场景中具有一定参考价值。文档按目的、适用范围、测试设计依据、编写步骤、编写要素、划分原则、编写要求、测试类型、设计方法、维护及风险建议组织完整展开需求分析、业务流程分析、系统设计分析、用例编写与用例完善五步流程同时说明需求路径、前置条件、操作步骤、预期结果、优先级、用例类型、用例属性、测试方式与执行次数等字段并介绍等价类划分、边界值分析、状态迁移等方法可直接用于团队模板统一、评审检查和新人补缺。1. 用例颗粒度差三倍这份 23 页的规范到底卡在哪同一个项目两个测试人员写出来的用例能差三倍有人一个页面写一条有人一个输入框拆五条评审会上谁也说服不了谁最后只能按资历拍板。这份《测试用例编写指南》.docx 处理的就是这个具体问题——把「凭惯性思考」变成「有章可循」。它把测试设计拆成需求分析、业务流程分析、系统设计分析、用例编写、用例完善五步又把测试需求与用例的划分按前端功能、流程类、后台功能、批处理、后台流程、数据埋点、兼容性七类测试对象逐类钉死最后落到操作步骤与预期结果的一对一、多对一、多对多对应规则。适合技术管理团队成员、测试负责人以及刚开始接手用例设计、需要一套可对齐标准的从业者。我拆这份文档时关注最多的不是那些大框架而是「用例编写注意点」里几个容易漏的分支对应关系下面按实际落地顺序讲。2. 五步法落地从需求分析到用例完善的输入输出对照这五步的价值不在于步骤本身而在于每一步都明确写了输入、处理、输出三件事。绝大多数团队写用例出问题是因为直接从「需求说明书」跳到「写用例」中间两步被省略了结果用例只覆盖了需求文档字面上写了的东西没写的地方全是盲区。2.1 需求分析把业务需求拆成带检查点的测试需求这一步的输入是业务需求说明书处理动作是「按流程或功能分类」输出是整理成测试需求并把每一个需求细节列出来作为检查点。注意这里的措辞——输出的是测试需求不是测试用例。这两者在文档里是分开定义的测试需求回答「要验证什么」测试用例回答「怎么验证」。我一般的做法是把需求说明书逐条编号每条业务需求改写成一到多个可验证的陈述句一个陈述句对应一个检查点。判断标准很粗暴——这个陈述句能不能用「是/否」回答。比如「系统支持用户注册」这种就没法验证「手机号不符合 11 位时提交系统提示格式错误且不写入用户表」就能验证。这一步最常见的偷懒方式是直接把需求文档的章节标题抄成测试需求名称。章节标题是按文档结构组织的不是按验证对象组织的抄下来之后用例路径会非常乱后面按目录批量执行、统计覆盖率都对不上。文档里对路径有明确规定需求路径是「/项目名称/一级需求/二级需求/……/N 级需求」的形式这个层级不是随便定的它直接决定了用例在测试管理平台里的组织方式和执行粒度。提示需求描述字段要把针对该末级需求的所有检查点一一列出。检查点数量多到一屏放不下时说明这个末级需求该往下再拆一层而不是把检查点堆在一个描述里。2.2 业务流程分析与系统设计分析补需求文档没写的那两部分第二步业务流程分析的输入是业务背景知识和被测系统/模块的业务流程处理是整理主流程、备选流程、数据流向、关键判断条件以及完成该操作的非必要条件输出是「作为业务需求未提及、但需要覆盖验证的检查点」。这句话是整份文档里最容易被跳过、又最值钱的一句。需求文档通常只描述主流程。备选流程、异常分支、数据流向中的中间状态往往只在和开发口头沟通时才浮现。举个通用例子某审批功能需求写的是「支持审批通过和审批拒绝」但实际业务流程里有「审批人离职后单据如何转交」「同一单据被两人同时打开如何加锁」「审批中途修改金额是否需要重新走流程」——这些都不是需求文档的字面内容全部属于业务流程分析该输出的检查点。第三步系统设计分析更偏技术侧。输入是概要设计、详细设计、接口设计及数据库设计文档处理是针对系统为实现业务需求所做的主要改动点及影响范围做全面分析输出是把改动功能支持的所有逻辑、以及对影响范围的回归测试加入测试需求检查点。这一步的产出直接决定了「关联性测试」和「回归测试」的范围——文档后面列测试类型时专门提了「针对不涉及代码改动但与被改动功能有依赖或调用关系的功能进行关联性测试」这个范围不是拍脑袋圈的是从设计文档的影响面分析里推出来的。我的习惯是第三步一定要拿到数据库设计文档。前端提示信息可以靠点页面验证但「前后端数据一致性」「后台数据存储结果」这类检查点没有表名和字段名根本写不具体。后面讲预期结果编写要求时会看到文档明确要求「如涉及后台数据存储/变更应明确具体数据表记录和关键字段取值变化」——这句话如果没有数据库设计文档写出来就是空的。2.3 用例编写与完善四种必须回炉的场景第四步用例编写的输入是测试需求处理是「尽量覆盖生产上的所有业务流程场景和系统逻辑分支除了正向测试以外加强对边界、异常等情况的关注」输出要求用例类型覆盖功能正确性测试、边界测试、异常测试、接口测试、信息安全测试等。注意这里的关键词是「覆盖」而不是「写完」判断标准是分支覆盖不是数量。第五步用例完善给出了四个触发条件评审过程中发现用例有问题系统新增功能或需求变更测试过程中发现设计用例时考虑不周、存在遗漏点系统出现生产问题、经分析为测试泄漏。前三条是常规维护第四条才是真正拉开团队水平的地方。生产问题倒推用例缺口这件事很多团队做完就完了——修完 bug 上线用例库纹丝不动下次换个入口同样的逻辑再漏一次。我的做法是凡是判定为测试泄漏的生产问题必须在测试需求里新增一个检查点在用例里新增或修改至少一条用例并且在用例描述里留一句来源标记。这样半年后回头统计能看出用例库的增长到底是被需求驱动的还是被事故驱动的比例失衡就说明设计阶段的分析做得不够。注意第四步要求「用例类型覆盖功能正确性测试、边界测试、异常测试、接口测试、信息安全测试等」这里的「等」不是省略号是留给项目按自身技术栈补充的。带文件上传的系统要加文件类型与大小边界带定时任务的系统要加批处理节点不要只抄文档列的五类。3. 要素与划分六类测试对象切下去颗粒度才收得住颗粒度失控的根因通常不在写用例的人而在划分原则没有被写死。文档把划分拆成两层——测试需求怎么划、测试用例怎么划两层用不同的依据混在一起谈就永远谈不拢。3.1 十三个要素里哪几个必须写死测试需求有 5 个要素测试用例有 12 个要素。全列出来看着多实际落地时按「必须写死」和「可以后补」分两类管理效率最高。所属对象要素是否必须写死说明测试需求需求路径是「/项目名称/一级需求/…/N 级需求」决定目录结构测试需求需求名称是对测试对象的简短描述测试需求需求描述是逐条列出检查点是后续用例的源头测试需求设计人否可后补但评审前必须填测试需求关联系统是跨系统项目不填会导致回归范围漏掉测试用例用例路径是需求路径 需求名称多一级都不行测试用例测试名称是能直接识别测试对象和检查点测试用例前置条件是有权限/数据/前置操作的必须完整列出测试用例操作步骤是入口、输入要素、按钮、任务、顺序测试用例预期结果是检查点完整列出含数据存储与日志测试用例优先级是高/中/低三档作为执行顺序依据测试用例用例类型是流程类、功能点类、报表统计类、界面类、报文接口类、批处理、其他类测试用例用例属性是正常 / 异常测试用例测试方式否手工 / 自动化可在排期时补测试用例执行次数否执行阶段回填用例路径这条规则值得单独说。文档写的是「在需求路径的基础上增加需求名称」也就是「/项目名称/一级需求/二级需求/……/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, encodingutf-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 字段为 1create_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 这种条件组合。这类场景用等价类拆不开因为问题不在于单个输入是否合法而在于多个输入的组合是否被正确处理。落地时的做法是先把输入条件列成布尔变量标出互斥和依赖关系再枚举有效组合。一个容易被忽略的点是测试用例设计方法的产出要回填到测试需求里。文档在第三步系统设计分析里要求「将改动功能支持的所有逻辑、以及对影响范围的回归测试加入测试需求检查点」——等价类划分出来的无效类、边界值取的那一组临界值、错误推测出来的经验项都应该先在测试需求里体现为检查点再落到用例。顺序反过来的话用例写完了回头补需求路径会对不上覆盖率统计也就失去意义了。注意异常测试的思路文档写得很直白——「模拟一名不了解产品操作的客户执行任意操作」。这句话比任何检查清单都好用写异常用例卡住的时候把自己当成第一次用这个系统的人胡乱点一遍漏掉的场景基本就出来了。最后说一个我踩过的坑。早些年我带队做用例评审习惯性先看用例数量觉得数量上去了覆盖就到位了。有一次某模块写了三百多条用例评审全过结果上线后一个很基础的场景漏了——同一功能两个入口只测了主入口。后来才发现问题出在测试需求划分阶段两个入口被合并成了一个需求文档里确实允许合并但合并之后用例只覆盖了其中一个入口的操作路径另一个入口在用例层面根本没有体现。从那以后我每次做需求合并都强制在需求描述里把涉及的入口逐个列出来用例写完再拿这份入口清单反向核对一遍确认每个入口至少有一条对应用例。希望帮到你。本文还有配套的精品资源点击获取