在线考试系统联合回归测试：试卷与考试模块的耦合验证实战

1. 为什么这一版回归测试要以“试卷管理+考试管理”作为联合验证对象

先说背景。这个项目是一个基于SpringAI的在线考试系统，后端核心业务其实可以拆成两条链：一条是出题与组卷链，对应题库、试卷管理、试卷发布；一条是考试执行链，对应考试创建、考生报名、答题提交、自动判分。两条链各自都有独立的功能模块，但真正到了实际使用的时候，它们是互相咬合的——试卷管理产生的“成品试卷”，是考试管理模块的输入；考试管理生成的“考试场次”，又反过来决定了试卷的可见时间、可用状态。因此在做回归测试的时候，如果只盯着单个模块做孤立验证，你会发现单模块全绿，联调一跑就崩。这一版回归测试文档，我在设计的时候就直接把试卷管理和考试管理作为联合验证对象，原因就是它们之间的耦合点比代码层面看起来要多得多。

再展开说一下SpringAI在这个系统里的角色。项目的定位是“基于SpringAI”，实际落地时SpringAI主要承担了两类职责：一类是智能组卷辅助，比如根据知识点难度分布自动生成试卷草稿；另一类是考试后的学情分析摘要，比如把成绩单转成自然语言描述。但必须说清楚，SpringAI的能力在考试系统里属于增强侧，真正的核心交易链路——试卷的创建、修改、发布，考试的开启、提交、判分——仍然是传统的关系型事务逻辑，这一点在回归测试中尤其重要。因为一旦有回归用例失败，你得首先判断问题出在SpringAI接入层，还是业务逻辑层，这个区分直接决定了排查路径。

这次回归测试的定位也很明确：不是从零开始验证功能正确性，而是验证“在已有功能基础上，经过一轮迭代改动之后，既有功能是否被破坏”。文档里的测试范围覆盖了试卷管理的完整生命周期，从创建试卷、添加题目、配置分值、设置可见性，到试卷的发布和下线；以及考试管理的典型流程，从创建考试批次、关联试卷、设置考试时间窗口、配置考生名单，到考生进入考试、提交答卷、系统自动判分。

适合看这篇内容的人，一个是准备做毕业设计或者项目实训的同学，他们最需要知道“联调回归”到底要测哪些点、怎么设计用例才不至于漏掉关键耦合；另一个是工作一到三年的后端开发，可能已经写了不少功能，但对“测试文档该怎么写得有业务深度”这件事还没有形成方法论。接下来我按实际执行顺序，把这一版联合回归测试的完整思路、场景设计、数据准备、踩坑记录和结论整理出来。

2. 联合回归的核心逻辑：先找到模块之间的“咬合点”

2.1 试卷状态与考试场次状态的状态机耦合

在做联合回归之前，第一步不是写用例，而是把两个模块之间的交互关系梳理清楚。试卷管理模块里，一张试卷的核心状态链路是：草稿 -> 已组卷 -> 已发布 -> 已下线。考试管理模块里，一场考试的核心状态链路是：草稿 -> 未开始 -> 进行中 -> 已结束。它们之间不是各自独立的两个状态集合，而是存在一组映射关系，我用一个表来展示：

在这个状态下，有一个特别容易踩坑的细节，在回归用例中我单独标记成了P0级场景：试卷已经发布，考试创建也引用了该试卷，然后试卷被下线了，这时一场原本已经创建好的考试还能不能正常开考？这个场景如果只做单模块回归，永远测不出来。因为试卷管理模块的单测只看“下线功能是否正常”，而考试模块的单测只关心“自己创建的考试是否正常”，只有走到联合层面，才会发现这里需要一个明确的业务裁定：已关联考试的试卷下线，不影响正在进行的考试场次；但未开始且未关联的考试，在开考前如果发现试卷已下线，系统应当在考试列表中给出明确的状态提示。

这块业务裁定最终在实现层定下的规则是：考试创建时把“试卷快照版本号”写入考试记录，而不是在考试进行中实时去读试卷表。这样即便试卷被下线、甚至被修改，已经生成的考试场次依然按照快照内容运行。这个机制本身不复杂，但它带来了一个回归测试上的要求——联合回归不仅要测功能行为，还要测快照数据是否在考试创建那一刻被完整固化。我在用例里专门设计了一个验证步骤：创建考试后直接在数据库里修改试卷的题目内容，然后观察已创建考试里的题面是否保持不变。

2.2 关联关系的完整性：考试引用试卷时的三种失败场景

第二个咬合点在“关联行为”上。试卷管理和考试管理之间有一个非常基础的操作——创建考试时选择试卷。看起来就是一个下拉框选择，但这里实际上需要对三种失败情况做回归确认：

第一种，考试引用了一张已经被逻辑删除的试卷。系统里试卷删除走的是逻辑删除，此时试卷在题库列表里不可见，但考试创建的搜索接口如果没做状态过滤，就会出现“能搜到、不能选”的幽灵数据。这个场景在回归中要用一条已经被删除的试卷ID去发起关联，确认返回结果是友好的提示而不是空指针异常。

第二种，同一张试卷被同一场考试重复关联。系统中试卷和考试的关系设计为一对一（一场考试只能有一张主试卷），但如果有批量导入考试的入口，防御没做好就可能出现重复关联。回归用例需要覆盖列表接口去重和数据库唯一索引两条防线。

第三种，跨租户引用问题。在线考试系统如果做了多租户隔离，那么A租户创建的试卷不能被B租户的考试引用。这个场景在回归中要模拟两个租户的数据交叉访问，确认数据权限过滤器在“试卷ID”这个维度上也生效了。很多团队做多租户隔离只做了“查询过滤”，没做“关联校验”，导致租户A的考试能引用租户B的试卷，这是个典型的跨模块回归盲区。

2.3 回归基线的建立：哪些功能点是必须每个版本都重复验证的

另外一个重要的设计思路是：回归测试不能变成“每次把全量手工用例跑一遍”，而是要基于历史缺陷分布建立一条回归基线。我整理了一下这个系统在过去迭代中出现缺陷频率最高的功能点，作为这一版联合回归的必测清单：

• 试卷分值配置保存后，重新打开编辑页分值是否回显正确
• 试卷中题目顺序调整后，组卷预览是否同步更新
• 考试时间窗口跨越自然日（比如22:00开始，次日02:00结束），判分结果归属日期是否正确
• 考生在考试时间截止后点击提交按钮，是否被正确处理（拒绝还是强制提交）
• 管理员中途修改考试时长，已进入考试的考生是否感知到变化
• 同一考生被分配到两场时间重叠的考试，系统是否在进入第二场时给出阻塞提示

这六条是历史Bug的高发区，也是试卷管理和考试管理数据交互最频繁的区域。每次回归测试，我都会先把这六条手工跑一遍，再根据当次迭代的代码改动范围去扩充测试点。如果一个版本迭代了“试卷支持富文本编辑器”，那么还需要追加一条“富文本内容在考试作答页是否正常渲染”的回归用例；如果迭代了“考试支持按班级批量导入考生”，就要追加“导入名单中考生去重校验”的用例。回归测试的精髓就在这——它不是一个固定不变的测试集，而是一个跟随迭代历史持续生长的缺陷防线。

3. 回归数据的构造策略与测试环境的准备细节

3.1 数据铺底：联合回归需要的最小数据集模型

回归测试和功能测试最大的区别在于：功能测试关心“功能是否存在”，回归测试关心“功能在数据积累到一定规模之后是否依然正确”。因此联合回归对数据准备的要求比单模块测试高得多。我在这一版执行前，花了小半天时间专门构造了一套最小但完整的回归基准数据。

先说基础数据。题库层需要三个知识领域各至少20道题，题型覆盖单选、多选、判断，而且每一道题都要标注难度系数。这套题库是给智能组卷用的，SpringAI的那个接口会根据知识点和难度分布来生成草稿试卷，回归时要验证的是：AI生成的草稿试卷分值总和是否等于试卷满分、题型分布是否符合预设比例、有没有出现同题重复引用。

试卷层需要准备三种状态的试卷各一份：一份草稿、一份已发布、一份已下线。为什么至少三份？因为考试管理模块的“选择试卷”接口，对这三种状态的试卷表现完全不同。草稿试卷必须不可选，已发布试卷必须可选，已下线试卷在新建考试时不可选但已有考试可正常运行。只用一份试卷是测不出这个逻辑的完整性。

考试层需要准备两场考试：一场“未开始”，一场“进行中”。未开始的考试用来验证试卷快照机制、考生名单确认、开考前的时间窗口校验；进行中的考试用来验证提交判分、时间截止处理、缺考记录生成、并发提交处理等等。另需一个“已结束”的场次，用于成绩发布和查询类接口的回归。

3.2 测试环境中的Pretest检查项

环境这块也要多说一句。联合回归对测试环境的要求是“数据可控+服务链路完整”，尤其是SpringAI相关的外部依赖必须可用。我在执行之前列了一个Pretest清单，每一条都直接决定测试结果是否可信：

• 数据库已恢复至基线备份，试卷表、考试表、考生答题记录表均为干净的已知状态
• 外部AI服务接口连通，智能组卷接口的token未过期且配额充足
• 定时任务无冲突——如果考场结束时需要跑一个自动判分的定时任务，要确认测试环境没有其他定时任务占用同一任务队列
• 文件存储服务可用——试卷如果支持附件上传（比如听力音频、图片题），需要确认存储桶权限正常
• 系统时钟准确——考试时间窗口的校验严重依赖服务器时间，这个环境问题在回归中容易被忽略，但一错起来所有时间边界用例全部失败

其中系统时钟这一点，我在之前的回归中就吃过亏。有一轮测试发现“考试时间已到但考生可以继续提交”的Bug，排查了半天，最后发现是测试环境服务器时间比真实时间慢了十分钟，根本不是代码问题。从那儿之后，Pretest清单里加入了NTP校验这一项。

3.3 构造时间边界场景：用SQL直接修正考试时间不再等待

回归测试中最费时间的就是时间类场景。一场考试如果设置的时间窗口是“明天上午9点到10点”，你不可能真的等24小时再去测“未开始”状态下的行为。我这边处理的办法是：先用后端的接口创建考试，然后用SQL直接修改数据库里的开始时间、结束时间和考试状态字段，把时间“拨”到需要的边界。

举个例子，要测“考生在考试开始前5分钟是否可以提前进入候考页面”，我先把考试的start_time设置为当前时间加5分钟，然后用考生账号去访问进入考试接口，确认系统返回“考试未开始”的提示。再测“考生在上次提交后超过截止时间30秒再次提交”，我把考试的end_time设置为当前时间减30秒，然后调提交接口，确认系统按“已截止”处理还是按“允许补交”处理。这种方式能极大缩短回归时间，但它要求测试人员对数据库表结构足够熟悉，能准确操作考试时间相关的字段。

另外还要注意，修改数据库时间字段之前，最好自己先确认接口层的时间是从数据库读取还是用Redis缓存。如果时间信息在Redis里有缓存副本，改数据库之后必须同步更新缓存，否则会出现“表和缓存不一致”导致的假失败。

4. 联合回归用例设计的逐层拆解

4.1 正向主链路用例：从创建试卷到自动判分的一整条流程

回归测试不能上来就测边界条件。我习惯的设计顺序是：先设计正向主链路用例，把系统的核心业务路径完整走通，确认主干没有问题，然后再围绕主干分叉出异常和边界用例。在这一版回归中，正向主链路我设计了一条完整的业务流：

1. 管理员登录系统，进入题库模块，录入8道题目（3道单选、2道多选、3道判断），每题设置知识领域、难度系数和分值
2. 调用SpringAI智能组卷接口，指定“数据结构”领域、难度比例（容易40%、中等40%、困难20%）、总分100分，让系统自动生成一份试卷草稿
3. 人工编辑抽检：把草稿中的一道题替换为另一道手动指定的题目，调整两道题的分值，然后保存试卷为“已组卷”
4. 发布试卷，确认试卷状态流转为“已发布”
5. 创建一场考试，命名为“回归测试专用场次”，关联刚才发布的试卷，设置考试时间为当前时间后一小时、考试时长60分钟、参考学生名单导入5名测试学生
6. 发布考试，确认考试状态为“未开始”
7. 切换一名考生账号，进入考试页面，确认能看到试卷题目，作答并提交
8. 管理员端确认该考生已经交卷，系统自动判分产出成绩，进入成绩列表
9. 对试卷管理端的“已发布试卷”执行下线操作，确认试卷状态流转为“已下线”，同时确认之前创建的那场考试在“已结束”列表里仍能正常查看成绩

这条主链路走通，意味着两个模块之间的核心接口没有出现破坏性回归。接下来再深入异常分支。

4.2 试卷生命周期中的异常回归用例

在试卷管理侧，我按“状态流转受阻”和“数据篡改防御”两个维度设计了异常用例。

状态流转受阻的第一类问题是“已发布的试卷能否被修改”。系统设计上是禁止直接编辑已发布试卷的，编辑入口必须隐藏，后端接口也要做状态校验。回归用例是：用管理员账号直接调编辑接口，传入一个已发布试卷的ID和新的题目JSON，确认接口返回“当前状态不允许修改”。同时检查前端编辑页的进入逻辑，确认已发布试卷在列表中不显示编辑按钮。

第二类问题是“已下线试卷的重新发布”。设计上，下线后的试卷允许重新发布，但重新发布前必须经过一次内容完整性校验（题目是否仍存在、分值配置是否完好）。回归用例是：对已下线试卷调用重新发布接口，确认校验通过后试卷状态恢复为“已发布”。如果中途有任何一道题被逻辑删除，接口应该返回具体是哪道题导致发布失败。

第三类是删除防御。一张已经被考试引用的试卷，无论处于什么状态，都不能执行物理删除。回归用例是：先删除一张未被引用的试卷，确认成功；再对已被引用的试卷执行删除，确认返回“存在关联考试记录，无法删除”的提示。这个用例的价值在于防住了一种常见的线上事故——管理员清理过期数据时，把还关联着历史考试的成绩单数据源头删掉了。

4.3 考试执行链路中的并发和时间边界回归用例

考试管理侧，回归用例的重心放在并发和时间边界上。并发场景有两个用例是必须做的：

第一个是同一考生重复提交。将考试状态调整为“进行中”，考生账号提交答卷后，网络侧模拟一次“超时重试”，看系统是幂等返回第一次的结果，还是抛出一条重复提交异常。正确设计是：提交接口必须有防重令牌或者提交记录唯一索引，第二次提交时直接返回“已提交成功，请勿重复操作”。

第二个是多人同时交卷时的性能表现。我用测试脚本模拟了30个考生同时在截止时间前10秒提交答卷，然后检查交卷接口的平均响应时间、数据库写入是否出现死锁、判分定时任务是否在预期时间内完成。这个用例对于考试系统来说尤其重要，因为真实考场中“临近截止时间集体交卷”是常规现象，而不是极端情况。

时间边界用例我拆成了四个点：

• 考试开始前5分钟：考生请求考试详情，应返回“未开始”倒计时
• 考试进行中：正常请求作答，应返回题目列表
• 考试截止时间点：正在作答页面提交，应正常收卷
• 考试截止后10分钟：补交请求，应被拒绝且记录异常日志

特别要说的是“截止时间点提交”这个边界。系统判断用的是服务器时间，但考生页面的倒计时是基于服务器返回的截止时间戳本地渲染的。如果考生本地时钟比服务器慢几秒，就可能出现“页面还显示剩余3秒，服务器已经截止”。正确的处理方式不是拒绝，而是以服务器收到请求的时间为准，只要请求在截止时间戳之后到达但试卷允许一个缓冲时长（比如30秒），就应该正常收卷。这个缓冲时长的配置在考试设置里是隐藏项，回归用例里需要用管理员接口找到它的默认值并验证。

4.4 SpringAI能力在回归中的专项检查

SpringAI相关的功能不是纯逻辑型业务，它的回归策略和传统模块不同——除了功能正确性之外，还需要关注模型输出稳定性和接口依赖异常。

智能组卷接口的回归，我设计了两组对比用例。第一组用同一份题库和同一组组卷参数请求两次，比较两次生成的试卷草稿在题目选择上是否有明显差异——如果 AI 模型更新了 prompt，可能会导致同样的参数产出两份完全不同的试卷，这会直接破坏“同一套配置组出稳定试卷”的用户预期。第二组故意传入一个不存在的知识领域名称，看接口返回的是结构化错误信息，还是模型无边界地编造出一个新知识点。实际测试中这种“AI幻觉”场景很容易出现——模型不知道“机器学习基础”这个知识点ID是什么，但会顺着prompt自然生成一个类似名称，导致脏数据进入试卷表。

考试后的学情分析摘要，回归重点则是输出的稳定性与安全性。系统调用SpringAI把成绩单转成一段文字评价，我要检查的包括：成绩为100分的学生，摘要中是否出现负面评价；成绩为0分但确实参加了考试的学生，摘要是否仍能生成而不是报错；学生姓名信息在摘要中是否被正确脱敏。这些用例其实不是传统意义上的“功能回归”，但它们恰恰是SpringAI接入后新引入的风险面，必须纳入回归基线。

5. 回归执行过程与缺陷追踪：这份文档背后的真实记录

5.1 执行顺序为什么被设计成“先数据完整性，再功能交互，最后AI能力”

到了实际执行环节，顺序也很有讲究。我反而不会把SpringAI相关用例放在最前面执行——虽然它们看起来是这个项目最“新”的部分，但正因为新，失败后的定位成本最高，如果把它排在前面且失败了，你会很难分辨到底是业务基线数据没准备好，还是模型接口本身有问题。

我的执行顺序是：

1. 先跑一遍数据完整性基线检查——把上面3.1节准备的基础数据做一次全量校验，确认每个测试实体（试卷、考试、学生、成绩）都处于预期状态
2. 再跑正向主链路——确认两个模块的核心交互没有断裂
3. 然后跑异常与边界用例——这部分是回归的重头，因为大多数迭代破坏性Bug都藏在异常分支里
4. 最后跑SpringAI AI能力专项——把智能组卷、学情分析这类依赖外部接口的用例放在最后，避免由于外部服务波动而干扰整轮回归的结论

这个顺序还有一个额外的好处：如果前两步跑挂了，那大概率是环境或者数据问题，此时没必要继续往下执行，直接修环境重新预热数据；如果前三步全部通过，AI能力跑挂了，那可以非常确信是外部接口链路的问题——搜索范围一下子就锁定了。

5.2 实际执行中发现的三个二级回归缺陷

这一轮回归一共执行了100多条用例，最终发现了三个二级缺陷，数量不算多，但每一个都有代表性。

第一个缺陷在“试卷下线后重新发布”功能上。按设计，重新发布前要校验试卷内所有题目是否仍处于有效状态，但实际发现校验只检查了题目是否存在，没有检查题目是否被停用（题目的有效状态标记为0）。也就是说，如果试卷里有一道题被管理员置为停用，重新发布依然能成功。线上表现就是：考生打开试卷，看到一道题显示“题目已失效”，整场考试直接受到影响。修起来很简单，重发接口里加一个题目状态==有效的过滤条件，但这无疑是个典型的回归盲区——单测数据里的题目全是有效的，所以从来没触发过。

第二个缺陷在考试提交的幂等控制上。提交接口已经有一个基于token的防重设计，但token的生成时机是“进入考试页面时”。如果考生进入页面后，浏览器长期挂着不操作，token在服务端过期了，此时提交答卷会触发token校验失败，但前端没有对401做专项处理，考生就卡死在提交页面。回归里我们模拟了这个场景，发现这是“前后端联调中的状态一致性问题”，单纯做模块测试很容易漏掉，但考试场景一定不能漏——因为真实考生中就是会有人开着页面发呆半小时。

第三个缺陷在学情分析摘要的数据脱敏上。成绩单里的学生姓名是明文，模型生成摘要时被带入了输出内容中。比如“张三同学本次成绩为85分，表现优秀”，按设计应该输出“该同学”而不是直呼其名。这个问题的严重性取决于系统所在机构的数据合规要求，但对于一个面向学生的系统来说，直出学生姓名显然是个需要处理的隐患。修复方式是在调用模型之前对输入字段做脱敏清洗，输出时再替换回来。因为摘要可能包含多位学生，替换逻辑需要做基于占位符的映射，不能简单做字符串替换，否则会引起姓名错误。

5.3 Bug的等级判定与回归结果评估逻辑

缺陷等级的划分在这一轮回归中也遇到了一个有意思的讨论：第二个缺陷（token过期导致提交失败）算P1还是P2？按影响面看，它只在“考生长时间停留页面”这个条件下触发，频率不算特别高；但按业务影响看，这会导致一场考试里某个考生彻底无法交卷，在监考老师看来就是“系统故障”，负面影响非常大。最终定级还是提到了P1，理由不是“发生频率”，而是“发生时用户无路可走”——没有任何绕过机制。这是一个很典型的回归测试判级思路：频率低但影响严重且有传播风险的缺陷，比频率高但容易绕过的缺陷更危险。

回归结论的评估，不应该只看“通过率多少”。我习惯用一个四象限来判断回归是否通过阻塞发布：

• 第一象限：P0/P1缺陷，且影响核心链路——必须修复后再回归，不允许带病发布
• 第二象限：P2缺陷，但绕过成本低，比如管理员手工调整某条配置即可恢复——可以记录Known Issue，排期修复
• 第三象限：P3级缺陷，属于体验优化层面——直接进Backlog
• 第四象限：用例设计本身不合理——不算缺陷，修正用例

这一轮回归没有一个缺陷落在第一象限，所以整体测试结论是“有条件通过”，第二个缺陷作为P1记录，但因为可以被管理员介入重置token状态，属于第二象限的可绕过风险，允许进入下一开发周期修复，但上线时要通知运维人员知晓这个风险点。

6. 复盘与改进：联合回归测试方案可以长期沉淀的地方

6.1 把联合回归的用例沉淀成可复用的自动检查集

做完整轮回归之后，我认为这个项目最值得沉淀的不是这100多条用例的执行结果，而是用例背后的回归基线数据。为了让下一轮回归不用重复造数据，我把这次构造的所有基础数据和边界数据做成了三份SQL脚本和一份JSON配置包：

• base_data_release.sql：包含题库、试卷、考试、学生等基础主数据，可直接恢复到测试环境
• boundary_time_data.sql：包含提前创建的多个时间窗口的考试场次，标记了每场的边界含义
• ai_prompt_case_config.json：存储智能组卷和学情分析专项回归的prompt参数和期望断言

这样一来，下一轮迭代如果只改了试卷模块的某个字段，我不需要手工重新准备一套数据，把这三份脚本执行一遍，再根据迭代内容增量构造少量数据，然后直接跑自动检查集即可。这才是回归测试能持续做下去的底层支撑——测试数据的复用能力，比用例数量更关键。

6.2 联合回归中的异步链路监控与日志追踪

还有一个必须做的复盘动作——补全异步链路的监控点。考试自动判分、学情分析摘要生成，这两个功能都不是同步返回结果的，它们走的是异步任务。在回归中，异步任务的问题往往不是功能不跑，而是跑得慢、失败后无感知、数据状态不一致。这一轮的学情摘要缺陷，本质上就是异步生成过程中对输入数据处理不当导致的。

这里有一个建议：在测试环境里，要确保异步任务的日志能和当前测试产生唯一关联标识。我这次的做法是，在考试提交时拿到了一个业务流水号，然后在日志链路里按这个流水号追踪判分和摘要生成的完整经过。如果你们项目还没有做全链路traceId，至少要在测试环境的日志系统里给每一个考试场次打上一个唯一标识，否则回归中异步任务出问题，你连排查入口都找不到。

6.3 下一轮回归前要补的用例缺口

最后记一下这轮回归结束后，我认为下轮必须补的用例缺口，也给大家作个参考：

一是数据迁移类回归。考试系统在正式环境中已经跑了一段时间后，历史考卷的格式可能和当前代码结构不一致，比如老试卷的题目数量、分值方式都和新版不同。下轮应当补一条“携带一批老数据跑考试主链路”的回归用例，确保系统向后兼容。

二是通知链路的回归。考试发布后，系统需要给考生推送通知（邮件或站内信）。这轮回归主链路里我有意没覆盖通知环节，因为通知是旁支功能，但说实话，真实考生能不能收到考试通知直接影响一场考试能否顺利开展，下一轮还是得纳入联合回归范围。

三是考试端异常断电/断网的恢复路径。当前测试用例都是理想网络环境的覆盖，没有设计“考生提交过程中断网重连后，本地缓存答卷与服务器状态不一致”的场景。这一块在考试系统里属于低频但高破坏的故障，从产品层面也需要明确行为预期。

这些缺口会直接作为下一轮回归测试的待办写入测试计划。做回归测试就是这样，每一轮都在和上一轮“赛跑”，只有把新路径不断纳入防线，功能迭代才不会让旧问题死灰复燃。

像我做了这几年组件工程和业务系统之后，最大的体会是——回归测试永远不是“跑一遍用例”那么简单，它更像是一次对系统记忆的整理：每一次执行，都能帮你重新确认这堆代码在你上一次改动之后，依然还认识它应该认识的人、记得它应该记得的事。如果你正在做考试系统、管理系统这一类的项目，不妨就把第一个模块的完整主链路和关键状态流转当作你的第一份回归基线，先跑通，再慢慢加厚它。