企业官网建设流程全解析

做测试这行久了，总会遇到一种让人心里发毛的情况：功能用例全部执行通过，测试报告一片绿，结果上线第二天客服群里就开始刷问题。我曾经跟进过一个订单履约模块，用例库里有三百多条功能点用例，等价类、边界值做得相当扎实，金额边界、数量上限、字段长度全都覆盖到了。上线后第三天，一笔订单卡在“已支付未发货”这个状态整整两天，用户付了钱，库存也扣了，就是没有生成发货单。定位下来发现，问题出在支付回调比库存扣减的确认消息早到了几秒，两个流程各自都没毛病，但凑在一条时间线上就断了。这类问题，功能点用例天生抓不到，因为它测的是“每个点对不对”，而线上事故往往出在“点与点之间那条路走不走得通”。场景法要解决的就是这件事：把用户、系统、外部依赖放在同一条时间线上跑一遍，看这条路由头到尾是否成立。下面我从场景法到底测什么讲起，把事件流怎么拆、用例怎么写、组合爆炸怎么收敛、落地时最容易在哪儿翻车，一条线讲透，适合刚接触用例设计的新人，也适合带团队做测试设计规范的老手对照自查。

1. 场景法在测什么：功能点清单之外的那条“路”

1.1 功能用例全绿却仍然出事的根因

功能测试的思维方式是“分解”——把一个系统拆成模块，模块拆成功能，功能拆成输入输出，然后逐个验证输入与输出的映射关系是否正确。这种方式效率高、可复用性强，但它有一个天然的盲区：它假定业务流程是一条直线，每一步都独立成立。真实系统的运行不是这样，它是多个角色、多个子系统、多个异步消息在同一条时间轴上交错推进，任何一个环节的时序、状态、前后依赖出问题，整条链路就断了。

我见过一个比较典型的例子：某后台系统的“批量导入”功能，单条数据导入的用例写得非常完整，字段校验、重复数据、超长文本全都有覆盖。但批量导入五百条时，系统采用分批提交，中途一条数据校验失败，前面已经落库的四百多条怎么处理？是全部回滚还是部分成功？回滚的话，已经触发的后续通知怎么撤回？这些问题在单条用例里根本不会出现，因为单条用例里没有“中途失败”这个概念。场景法的价值就在这里——它不关心单个字段填得对不对，它关心的是从起点到终点，这条路上每种可能的走法会撞到什么。

换个说法，功能用例是“点”的验证，场景法是“线”和“面”的验证。一个系统上线前，点必须全对，但只对点是不够的。业务方的真实诉求是“我要把这个事办成”，而不是“我要验证第十七条校验规则生效”。场景法就是站在“把事办成”这个视角重新组织测试。

1.2 基本流、备选流、异常流：三个不能含糊的概念

场景法的骨架是事件流，而事件流分三种，这三者的界限如果划不清楚，后面的用例设计一定是糊的。

基本流指的是一条业务从触发到结束最顺畅、最理想的路径，中间没有任何岔路、没有任何重试、没有任何人工干预。比如“用户下单—选择商品—提交订单—支付成功—系统生成发货单—仓库发货—用户签收”，一路绿灯走到底。基本流的特点是唯一性——同一个业务通常只有一条基本流，它是整个场景设计的主干。

备选流是由基本流上某个判断节点分出去的合法路径。注意“合法”这两个字，备选流不是错误，它是业务上允许的另一种走法。比如支付这个节点，用户可以选择余额支付、也可以选择货到付款；库存这个节点，可能有货直接发，也可能缺货转为预售。备选流的数量取决于业务规则里的分支条件有多少，每多一个判断节点，就多一组备选流。

异常流则是业务上“不该发生但可能发生”的路径，比如支付超时、库存扣减失败、第三方接口返回错误、消息重复投递、用户中途取消。异常流的关键不在于“发生了错误”，而在于“错误发生后系统怎么收场”——是回滚、是挂起、是重试、还是转人工。我个人的经验是，异常流最容易写漏，也最容易写得没有可执行性，因为它需要对系统的容错机制有足够了解，光看需求文档往往看不出来。

这三类流不是并列关系，而是树状关系。基本流是树干，备选流是从树干上分出去的枝，异常流是枝上或者干上可能出现的断点。设计场景时，思路应该是先把树干画出来，再一个节点一个节点地想“这里还能往哪走”“这里如果走不通会怎样”。

1.3 场景法、等价类、边界值到底怎么分工

经常有人问，既然有了等价类和边界值，为什么还要场景法？这不是替代关系，而是分工关系。等价类和边界值解决的是“单个输入域内的取值是否合理”，比如年龄字段输入负数和一千，系统能不能拦住；场景法解决的是“多个动作按某种顺序组合后，系统状态是否仍然正确”。

我一般这样安排：需求评审完，先做一遍场景梳理，把业务流程的骨架和分支定下来，这一步产出的场景清单就是测试的“地图”；然后针对每条场景里涉及的具体输入，再用等价类和边界值去补充数据设计。简单说，场景法决定“测哪些路”，等价类边界值决定“每条路上用哪些数据跑”。

举个具体的：支付场景里有一条备选流是“优惠券抵扣后实付金额为0”。场景法负责把这条流识别出来，等价类边界值负责设计优惠券金额和订单金额的取值组合——券额小于订单额、等于订单额、大于订单额，实付金额为0时是否需要走支付渠道。两者配合，才能既覆盖路径又覆盖数据。只做场景不做数据设计，用例执行时容易“跑通但没测透”；只做数据不做场景，就是前面说的三百条用例全部通过但链路照样断。

2. 从需求文档到场景清单：事件流拆解的四个动作

需求文档里通常写的是“系统应支持XX功能”“用户可以进行XX操作”，这是功能描述，不是场景描述。要把功能描述转成可直接执行的场景，我习惯分四步走，每一步都有明确的产出物，避免凭感觉发挥。

2.1 第一步：抓业务主干，先把基本流定死

基本流的确定不能靠猜，要从需求文档里找出“角色—动作—状态”这条主线。具体做法是：先列出参与这个业务的所有角色，包括用户、运营人员、后台系统、外部服务；再列出业务流转过程中状态发生变化的每一个节点；最后把角色和状态串起来，得到一条从触发到终态的最短路径。

以“退款”为例，主干是“用户发起退款申请—系统校验订单状态与可退金额—生成退款单—调用支付渠道退款—渠道返回成功—系统更新订单为已退款—通知用户”。这条主干里，每一个箭头两端都是一个状态变化，这就是后续挂分支的锚点。

这里有个容易犯的错误：把“系统校验”这一步写成一个抽象动作，不写清校验什么。校验动作如果不拆开，后面挂备选流和异常流时就无从下手。我的做法是把每个校验动作都翻译成“判断条件+两种结果”，比如“校验订单状态是否为已支付且未退款”，结果只有两个：是，继续；否，终止并提示。这个转换动作看起来笨，但它能让后面的分支推导变得非常机械，不容易漏。

另外，基本流里要明确标出哪些步骤是同步的、哪些是异步的。同步步骤出问题会直接阻塞用户，异常处理要即时反馈；异步步骤出问题往往延迟暴露，异常处理要考虑补偿和重试。这个区分在后面写异常流时会直接影响用例的断言设计。

2.2 第二步：每个判断节点都长出一条备选流

基本流定好之后，把它上面所有的判断节点圈出来，每个判断节点至少对应一条备选流。判断节点的来源有两类：一类是显式的业务规则，比如“订单金额满99免运费”；另一类是隐式的状态依赖，比如“只有待支付状态才能取消订单”。

我习惯用一张表来管理这个过程，列包括：节点编号、判断条件、条件为真走哪条、条件为假走哪条、是否是合法分支。这样做的好处是，备选流的数量和判断节点的数量严格对应，不会出现某个节点被跳过的情况。

表里 N4 这种“为假就终止”的分支要特别注意，它虽然是合法业务规则触发的，但业务终止了，后续所有节点都不再执行。这类终止型备选流在场景计数时容易被当成基本流的一部分忽略掉，实际执行时却是高频场景，尤其是地域限制、权限限制、资质限制这类规则，线上触发率很高。

2.3 第三步：异常流按“谁失败、在哪失败、失败后怎么办”补齐

异常流是最难写全的部分，因为它不在需求文档的主线描述里，往往散落在接口文档、错误码表、运维手册甚至代码注释里。我总结了一个三问法，对基本流和备选流上的每一个外部交互点都问三遍。

第一问：谁会失败？把所有参与方列出来——用户可能中途关页面，前端可能断网，后端服务可能超时，数据库可能连接池满，第三方渠道可能返回未知状态。每一个参与方都是一个潜在的失败源。

第二问：在哪一步失败？失败发生的时机不同，后果完全不同。支付回调在库存扣减之前失败和在之后失败，处理逻辑是两套。前者直接终止，后者必须回滚库存。所以异常流必须绑定到具体的步骤序号上，不能笼统写“支付异常”。

第三问：失败后系统怎么办？这是异常流的核心。可选的处置方式包括：立即回滚并提示、挂起等待人工介入、进入重试队列、降级走备用通道、记录异常并允许后续补偿。每一种处置方式都要有对应的可观测结果，否则用例没法判定通过与否。

举个具体例子。支付回调超时这条异常流，按三问法拆开：失败方是支付渠道，失败点是“调用渠道退款”这一步，处置方式是“系统将该笔退款单置为处理中，进入定时重试队列，重试三次仍失败则转人工”。对应到用例，断言就非常明确：退款单状态变为处理中、重试队列中有该单据、超过重试次数后生成人工工单。如果只写“支付异常时系统应正确处理”，这条用例执行时执行人多半会点一下看看没报错就打勾了，等于没测。

2.4 第四步：场景编号与用例映射，让每条路都可追溯

场景梳理完，如果不编号、不建映射，过两周就没人记得哪条用例对应哪条流了。我的做法是给场景一个固定格式的编号，比如SC-业务名-流类型-序号，基本流是SC-ORDER-B01，备选流是SC-ORDER-A03，异常流是SC-ORDER-E07。编号一旦定下来就进用例管理系统，用例标题里带上这个编号。

映射表的作用不只是好看。需求变更时，你能快速定位到“这个需求点影响了哪几条场景”；缺陷复盘时，你能反查“这个缺陷对应的场景当时为什么没设计出来”；做覆盖率统计时，你能算出“备选流覆盖了几条、异常流覆盖了几条”。没有这张表，场景法就退化成了一次性的脑暴，做完就散。

我一般要求映射表至少包含这几列：场景编号、场景名称、流类型、前置条件、触发动作、预期终态、关联用例ID、自动化脚本路径、最近执行结果。前六列是设计信息，后三列是执行信息，设计和执行放在一张表里，能有效避免“设计了但没执行”这种最常见的落地断点。

3. 实战拆解：一笔订单从下单到签收的场景设计全过程

光讲方法容易飘，拿一个完整的业务流程走一遍。这里用一个模拟的订单履约模块，需求描述大概是：用户选择商品提交订单，系统校验库存并锁定，用户选择优惠券后支付，支付成功后系统生成发货单，仓库拣货出库，物流揽收，用户签收后订单完成；支持缺货转预售、支持部分商品退款。这段需求描述很典型，看着清楚，其实藏了不少分支。

3.1 需求原文到业务流程的转译

先把需求拆成状态节点。下单前的状态是“购物车已选”，提交后进入“待支付”，支付成功后进入“待发货”，生成发货单后进入“已发货”，签收后进入“已完成”。中间还有一个“已取消”和“退款中”的旁支状态。把这些状态按流转顺序排开，基本流就出来了：待支付→已支付→待发货→已发货→已完成。

然后找判断节点。第一处是“校验库存”，结果是有货和无货。有货走锁定库存，无货走缺货转预售，这是一条备选流。第二处是“是否使用优惠券”，用了要走抵扣计算，不用按原价，这也是备选流。第三处是“支付结果”，成功走正常流程，失败或超时走异常流。第四处是“是否部分退款”，会影响发货单的生成范围。

这里有个细节值得单独说：需求里写“支持部分商品退款”，但没说退款发生在发货前还是发货后。这两个时机对系统的影响完全不同。发货前部分退款，需要重新计算发货单的商品明细；发货后部分退款，发货单不变，只走售后流程。这种需求模糊点，在场景梳理阶段就必须标出来找产品确认，不能带到用例设计里靠执行人临场判断。我在实际项目里见过因为这个问题漏测，导致发货单里包含了已退款商品，仓库照发，最后变成一笔糊涂账。

3.2 基本流用例的编写与断言设计

基本流用例看起来最简单，其实最容易写虚。很多人的写法是“正常下单，验证下单成功”，这种用例执行一百遍也发现不了问题。基本流用例的关键是把每一步的中间状态都写成断言，而不是只断言最终结果。

以“下单支付发货签收”这条基本流为例，我的断言清单大概是这样：提交订单后，订单状态为待支付、库存锁定记录存在且数量匹配、订单金额等于商品金额减优惠金额；支付成功后，订单状态变为已支付、支付流水号回写、锁定库存转为实扣；生成发货单后，发货单商品明细与订单明细一致、发货单状态为待拣货；签收后，订单状态为已完成、库存流水有出库记录。

这些断言里，库存锁定记录、支付流水号回写、发货单明细一致性这三项，是纯功能用例经常跳过的，因为它们不是“用户能看到的界面元素”。但恰恰是这些后台状态，决定了后面异常发生时能不能正确回滚。基本流用例写得够不够实，就看断言里有多少条是后台状态校验。

# 基本流用例的参数化骨架（pytest 示意） import pytest BASE_FLOW_STEPS = [ ("submit_order", {"status": "PENDING_PAY", "stock_locked": True}), ("pay_success", {"status": "PAID", "stock_deducted": True, "pay_no": "NOT_NULL"}), ("gen_delivery", {"delivery_status": "WAIT_PICK", "items_match": True}), ("sign", {"status": "COMPLETED", "stock_out_record": True}), ] @pytest.mark.parametrize("action,expected", BASE_FLOW_STEPS) def test_order_base_flow(action, expected, order_ctx): result = order_ctx.do(action) for field, value in expected.items(): assert result.get(field) == value, f"{action} 步骤的 {field} 不符合预期"

这段骨架的意义在于，每一步都带着期望状态往下走，哪一步开始偏离立刻能看出来，而不是等到最后看订单状态对不对。基本流用例的价值不是证明“能走通”，而是建立一条状态基线，后面所有异常流的回滚校验，都是跟这条基线比对。

3.3 备选流与异常流的用例补齐

备选流按前面那张节点表一条条补。库存不足转预售这条，用例要覆盖：提交订单后订单状态为待支付但标记为预售、库存不锁定、预计发货时间有值、支付成功后仍不触发发货单生成，而是等到库存补充后由定时任务触发生成。这条用例的断言重点在“不锁定库存”和“延迟生成发货单”两个否定性结果上，很多人写用例只写肯定性结果，否定性结果反而更能暴露问题。

优惠券抵扣这条备选流，要跟等价类结合。券额小于订单额、等于订单额、大于订单额三种情况，第三种在业务上通常是不允许的，需要校验系统拦截；第二种实付为0，要验证是否跳过支付渠道直接置为已支付，同时要验证支付流水号字段在这种情况下的处理——是留空、还是生成一个内部虚拟流水号。这种字段级的细节，需求文档一般不写，得靠设计时主动去想。

异常流按三问法展开，重点补这几条：支付回调超时，系统保留待支付状态并允许用户重新发起支付，重复发起时校验幂等；库存扣减在支付成功后失败，系统必须触发退款补偿并记录补偿流水；发货单生成时部分商品已退款，发货单只包含未退款商品；物流揽收后用户申请退款，走售后流程而不是直接退款。每一条都要写清触发方式、系统处置、可观测结果。

这里分享一个实操技巧：异常流的触发方式如果不好模拟，可以在测试环境用开关或者故障注入的方式人为制造。比如支付回调超时，可以在测试环境把回调地址指向一个延迟响应的模拟服务，让回调晚于超时阈值到达。这种“造错”的能力，比写好用例本身更重要，因为造不出错，异常流用例就只能停留在纸面上。

3.4 场景组合爆炸时的收敛策略

把所有判断节点和异常点组合起来，场景数量会迅速膨胀。四个判断节点、每个两种取值、再加五个异常点，理论组合轻松过百。全量执行不现实，必须有收敛策略。

我的收敛顺序是这样的：第一优先级是基本流，必测；第二优先级是终止型备选流，也就是会导致业务中断的分支，比如地址不可配送、资质不满足，这类线上触发率不低且影响直接，必测；第三优先级是涉及资金和库存的异常流，钱和货是最敏感的，必测；第四优先级是其他备选流的正常路径，选测；第五优先级是多个异常叠加的场景，比如支付超时同时库存扣减失败，这类场景概率低但后果重，按风险抽取两到三条做专项验证。

具体到组合方法，我不会用全组合，而是用成对组合加业务高风险组合。成对组合保证任意两个判断节点的取值组合都被覆盖到，能把大部分交互问题抓出来；业务高风险组合靠经验补充，比如“优惠券+部分退款”“预售+支付超时”这种业务上确实会碰到的叠加，虽然概率不高但一旦出问题处理链路特别复杂。这两种方法结合，场景数量通常能压到原来的三分之一左右，覆盖度却不打折扣。

4. 场景法落地时最容易翻车的五个地方

方法本身不难，难的是在真实项目节奏里把它执行到位。下面这五个坑，我几乎在每个团队都见过至少一次。

4.1 粒度过粗：一条用例塞了五件事

最常见的翻车方式是场景粒度失控。一条用例里写了“用户下单并使用优惠券支付成功后部分退款再重新下单”，执行人跑挂之后根本不知道是哪一步出问题，定位成本极高。场景用例的粒度标准应该是“一条用例只验证一条事件流的一个完整分支，且中途不引入新的分支判断”。

判断粒度是否合适的简单方法：看这条用例的失败原因能不能用一句话说清。如果失败后需要排查三个以上的可能原因，说明粒度太粗，要拆。反过来，如果两条用例的前置条件和执行步骤几乎一样，只有最后一个断言不同，那是粒度太细，可以合并成一条带多断言的用例。

粒度失控的深层原因往往是设计时偷懒，把“业务上会连着发生的操作”直接当成“一条场景”。业务上连着发生不等于测试上应该连着测。测试的目的是定位问题，不是复现用户的完整一天。

4.2 异常流写成“待补充”，最后永远补不上

我见过太多用例库里异常流那一栏写着“支付异常时系统应正确处理”“网络异常时给出友好提示”。这种写法的问题是，它没有可判定的预期结果，执行人无法判断通过还是失败，最后只能凭感觉打勾，或者干脆跳过。

异常流写不实的根因，是设计者对系统的错误处理机制不了解。需求文档只写正常流程，错误码表和兜底逻辑往往在开发脑子里。解决办法是在用例设计阶段就拉开发过一遍异常清单，让开发把每个外部调用的超时时间、重试次数、失败后的状态流转讲清楚，设计者当场记录成用例。这个动作看着费时间，但比上线后救火便宜太多。

另一个实用做法是给每条异常流用例强制要求三个字段：触发方式、系统处置动作、可观测证据。三个字段缺一个，这条用例就不算完成。可观测证据可以是数据库状态、日志关键字、监控指标、消息队列里的消息体，必须是执行人能实际查到的。

4.3 测试数据与场景两张皮

场景设计得再漂亮，数据造不出来照样跑不了。典型症状是：用例要求“库存扣减失败”，但测试环境库存服务一直正常，造不出失败；用例要求“用户已签收后申请退款”，但测试环境没有已签收的历史订单，每次都要手工造半天。

这个问题的解法是把数据准备纳入场景设计的一部分，而不是执行时临时想办法。我习惯在场景清单里加一列“数据准备方式”，标明这条场景的数据是靠接口预置、靠脚本批量生成、还是靠故障注入。对于需要异常状态的数据，提前跟开发约定测试环境的故障注入开关，或者准备一个可控制的挡板服务。

还有一类隐蔽的数据问题：场景之间互相污染。比如 A 场景锁定了某商品的库存，B 场景再去下单就失败了，执行人以为是缺陷，排查半天发现是数据没隔离。解决办法是每条场景用例声明自己依赖的数据范围和清理方式，能独立造数据就独立造，不能独立的做好执行顺序编排。

4.4 场景用例和自动化脚本各走各的

手工设计的场景用例和自动化脚本经常是两套东西，用例库里的场景描述很完整，自动化脚本里只覆盖了基本流。时间一长，回归全靠脚本，异常流就慢慢没人跑了。

我的做法是场景编号直接作为自动化用例的标识，脚本的方法名或者用例注解里带上SC-ORDER-E03这样的编号，做到双向可查。自动化覆盖不了的部分，在场景清单里明确标注“手工执行”，并注明手工执行的原因（比如需要人工审核、需要跨系统操作）。这样回归时能清楚知道哪些场景是脚本覆盖的、哪些必须人工补，不会出现“以为都跑了其实漏了一半”的情况。

另外，异常流的自动化优先级应该高于普通备选流。因为异常流手工执行成本高、容易漏、而且出问题后果重，恰恰是最值得投入自动化的一类。支付超时、库存扣减失败这类场景，用挡板服务模拟一次，之后每次回归都能稳定复现，投入产出比很高。

4.5 场景只做一次，不做维护

场景清单不是一次性文档。需求迭代、接口变更、新增外部依赖，都会让原有场景失效或者需要扩展。我见过团队在项目初期做了一轮场景梳理，之后再也没有更新过，半年后清单里的流程和实际系统已经完全对不上，等于白做。

维护的最小动作是绑定需求变更流程：每次需求评审，除了评估功能影响，还要评估场景影响，明确“新增几条场景、修改几条、废弃几条”。这个动作不复杂，但要固化到流程里，否则永远排不上优先级。

5. 让场景资产持续生效：评审、度量与增量维护

场景清单做完只是开始，要让它持续产生价值，得靠评审把关、靠度量发现问题、靠增量维护跟上变化。

5.1 场景评审会上真正该问的六个问题

场景评审容易开成走过场，大家对着清单点点头就过了。要让评审有效，得带着具体问题去问。我常用的六个问题是：这条业务最坏的情况下用户会损失什么？每个判断节点的所有取值是不是都至少有一条流覆盖？每个外部调用失败后系统的状态是不是可观测？有没有哪条流的预期结果是“无法判定”的？场景之间的数据依赖和清理方式写清楚了没有？最近三个线上缺陷分别对应哪条流，那条流现在有没有用例？

第六个问题最能暴露问题。如果线上缺陷对应不到任何一条已有场景，说明场景梳理存在盲区；如果对应到了但用例没执行，说明执行环节有断点；如果对应到了也执行了但没拦住，说明断言设计不到位。三种情况对应三种不同的改进方向，比泛泛讨论“覆盖够不够”有用得多。

评审还要拉上开发和产品。开发能指出哪些异常流在实现上是多余的，产品能指出哪些备选流业务上根本不允许出现。这两类信息靠测试自己猜，准确率很低。

5.2 用缺陷分布反查场景盲区

缺陷是场景设计最好的反馈源。我的习惯是每个迭代结束做一次缺陷归因，把缺陷分成三类：场景缺失（根本没有这条流）、场景存在但未执行、场景执行但断言不足。这三类的占比能直接反映团队在场景法上的短板在哪。

如果场景缺失占比高，说明梳理阶段对异常和分支的挖掘不够，要加强三问法的执行；如果未执行占比高，说明执行编排或者资源分配有问题；如果断言不足占比高，说明用例写得虚，要回头补可观测结果。我经手的一个团队，连续三个迭代里断言不足占比都超过一半，后来强制要求每条场景用例至少三条断言，且其中至少一条是后台状态校验，下一迭代这个比例就降下来了。

度量指标不用多，两三个够用：备选流覆盖率、异常流覆盖率、场景相关缺陷的逃逸率。前两个看设计广度，后一个看设计深度。数字不需要好看，需要真实，真实才能指导改进。

5.3 需求变更时场景清单的增量维护法

需求变更时，场景清单的更新要像改代码一样有章法。我的做法是先做影响分析：这次变更动了哪个状态节点、哪个判断条件、哪个外部依赖。动了状态节点，相关的基本流和所有经过该节点的备选流都要重新评估；动了判断条件，该节点对应的备选流组要增删；动了外部依赖，该依赖相关的异常流要全部重写。

变更记录我建议直接写在场景清单里，加一列“变更说明”，记录这条场景是哪次需求变更引入或修改的，关联的需求单号。这样做的好处是，半年后有人问“这条场景为什么这么设计”，能直接追溯到源头，不用靠回忆。

还有一个容易被忽略的点：废弃场景不要直接删掉，标记为废弃并保留。因为有些需求可能会回滚，有些场景可能在别的业务线复用，直接删掉之后想找回来很难。保留废弃场景的成本很低，一张表里多几行而已。

最后分享一个我在实际项目里用得比较顺的小习惯：每做完一轮场景梳理，我会挑三条自己最没把握的流，直接找开发对着代码走一遍，看实际实现和我的预期差在哪。这个动作花不了半小时，但经常能挖出需求文档里完全没提的隐式分支，比如某个字段为空时的默认处理、某个接口重试时的幂等判断。这些细节写进场景用例，往往就是后面拦住线上问题的那几条。场景法的功夫不在写用例的格式上，而在对业务链路和系统实现的理解深度上，理解到位了，用例自然就实了。