企业官网建设流程全解析

1. 场景法不是画流程图，是梳理业务价值的链路

先聊一个很多测试同学都踩过的坑：拿到需求文档之后，第一反应就是打开画图工具，把页面流程、接口调用、状态流转一条条画出来，画到一半发现分支越来越多，最后自己也看不清了。其实大家口中常说的场景法，本质不是“把流程画对”，而是“把业务价值链路跑通”。

我做了几年测试后发现，场景法的核心是三个词：主链路、备选链路、异常链路。主链路就是用户最常规、最顺畅地完成目标的那条路，比如下单支付成功；备选链路是用户在过程中遇到选择或可替代方案时走的路，比如余额不够切换到微信支付；异常链路是业务规则不满足、外部依赖失败、或者用户行为触发保护机制时不得不走的路，比如优惠券过期、库存不足、支付超时。

很多测试设计新手最容易犯的毛病，是把备选和异常混在一起，或者在异常场景里只写“系统报错”四个字就完事。实际上，所有的异常场景背后都应有一个“业务保护规则”或“系统兜底方案”，比如分布式系统里的幂等校验、超时补偿、库存预占释放。测试设计里真正有价值的部分，不是“报错”本身，而是报错之后系统是否进入了正确的兜底状态。

这里就要说到AI了。AI最擅长的事情之一，是从给定的需求文本里高速枚举可能性。过去人工写场景，一小时可能列十几个分支，还会有遗漏。让AI来枚举时，它能在几十秒内产出几十条链路，你只需要做筛选和合并。但前提是，你需要把需求里的“业务规则”喂得足够清楚，而不是把整篇产品文档直接丢给它。

1.1 场景法的底层逻辑：主链路、备选链路、异常链路

在讲AI怎么用之前，先把场景法基本功夯实一遍。场景法的起点是用户目标，不是系统功能。比如说一个注册功能，如果从功能出发，你会写“输入手机号、输入验证码、点击注册按钮”；如果从用户目标出发，你会写“用户想快速建立自己的账号身份，并在注册后进入主界面”。同样是写用例，后者的覆盖范围明显更宽更贴近真实用户使用习惯，因为它会驱动你想到：用户注册到一半退出怎么办，验证码发不出去怎么办，重复手机号怎么办，注册成功后第一次登录是不是能正常带出信息。

场景法一般按下面三步走：

• 第一步，识别触发事件。一个业务链路通常由一个用户动作触发，比如“提交订单”“申请退款”“修改密码”。触发事件决定了场景的起点。
• 第二步，列出主成功场景。沿着触发事件向后推演，假设每一步都顺利，得到主成功路径。
• 第三步，在每一步上反问“如果不成功会怎样”“有没有替代方案”“用户能不能反悔”。把这些问题展开，就得到备选和异常场景。

实际工作中，第三步是最消耗时间的。因为一个主场景通常有5到10个步骤，每个步骤都可能产生2到5个异常分支。人工枚举到后面很容易陷入“啊，这个我忘了”的状态。我在自己项目里统计过，人工写场景法时，漏得最多的是依赖外部系统超时、数据状态被并发修改、以及用户在中间流程关闭页面后重新进入这三类。

1.2 为什么AI能把场景法“卷”起来

AI在这里的真正价值，并不是“帮你写测试用例”，而是帮你把场景枚举的覆盖面拉满。用一个人工智能大模型来做发散思维，本质上比人脑做穷举更稳定，不会因为疲劳而漏项。

我自己实际测试过，把同一段“订单退款流程”的需求丢给AI和让组里两名资深测试同学各自列场景，结果很有意思：两名测试同学列出的场景各有侧重，一个更关注金额计算、一个更关注状态流转，但要合并起来才能达到AI单次输出的覆盖量。AI一次性把异常场景列得特别细，比如“退款原路退回失败后转为平台余额”“退款过程中订单已部分发货”“退款金额超过原支付金额”这些反直觉但业务上真实存在的场景，它全列出来了。

不过这里有个关键点：AI列出来的场景里，必然有一批是伪需求。因为它是基于语言概率来生成的，而不是基于真实的业务规则推演。所以你要做的不是无脑全收，而是拿着AI的输出清单，对照需求文档里的规则，逐条确认业务可行性。我用AI做场景法，本质上是把测试设计从“我来想”变成“我来审”。

具体操作上，我习惯先在提示词里让AI只输出场景列表，不输出测试步骤，这样可以把“发散”和“收敛”分成两轮，避免AI一上来就写具体操作步骤导致场景分类混乱。

2. 多条件岔路口：判定表是组合穷举的“压缩器”

场景法擅长纵向把业务链路拉通，但遇到横向的多条件组合时，场景法就不够用了。打个比方，场景法像是在地图上选路线，从一个城市走到另一个城市，主干道、小路、高速都给你列出来；但每条路上还有红绿灯、限高杆、收费闸口，这些条件互相组合出不同的通行规则，这时候就要靠判定表。

判定表的专业定义不讲了，直接用大白话来说：它就是一张把所有条件组合和对应动作画出来的表格。场景法的每一段主链路上，常常会有一个多条件岔路口，比如结算页面的优惠计算，同时受用户等级、优惠券类型、支付方式、是否使用积分这多个条件影响。如果用场景法去穷举这些组合，光场景列表就能列到上百条，而且没有条理。这时候把条件抽出来做判定表，就能把逻辑规则收敛到一起。

判定表最牛的地方，是它可以利用“条件组合化简”来大幅压缩用例数量。业务上大部分规则是存在条件冗余的，比如“用户登录后已支付订单的物流状态查询，与用户等级无关”，这时候在判定表里就可以把用户等级这个条件从对应规则中剔除。人工做判定表需要较强的逻辑抽象能力，而AI恰好很擅长从文字规则中提炼条件项和动作项，并且能主动提示哪些条件在特定组合下是冗余的。

2.1 判定表的原理与构造步骤

构造一张判定表，正常顺序是这样的：

1. 明确条件桩。把所有影响结果的条件列出来，每个条件定义好取值（有效等价类）。比如支付方式：微信支付、支付宝、余额支付；用户等级：普通、VIP；是否有可用的优惠券：有、无。
2. 明确动作桩。列出在这些条件下系统执行的动作，比如计算优惠金额、判断是否免运费、给出支付成功或失败提示。
3. 列条件组合。理论上，n个条件每个有m种取值，组合数就是m的n次方。实际操作中列组合时需先剪枝，把业务上不可能出现的组合（比如未登录用户绑定了VIP优惠券）剔除。
4. 填动作结果。根据业务规则，把每个组合对应的动作填进去。
5. 化简合并。如果两列或几列的条件取值不同，但动作完全一致，就可以合并成一列，不相关的条件用“-”表示。这一步是最核心的。

很多人用判定表时其实卡在第一步和第二步。因为需求文档里的业务规则经常写得零散，比如一句“VIP用户在付款页可选择专属折扣券”，没有明确说非VIP用户有没有这个入口。所以构造判定表之前，必须先做规则统一化，把需求里的“口语化规则”翻译成“条件-动作表达式”。

AI在第一步和第二步上的表现，某种程度上比很多初级测试工程师都要好。因为它阅读文字规则后，能自主识别出所有影响结果的可变因子，还能反向提问“如果两个条件同时满足时，优先级怎么处理”。我在提示词模板里加了一句“请先列出所有条件和规则，并标注规则来源”，AI就会在输出结果里精确到“根据需求文档第几章节的描述，得出此规则”，这样后续审核能省不少时间。

2.2 条件项太多时的优化策略

判断一张判定表是否合格，有一个很实用的标准：拿给不熟悉该业务的人看，看一眼就能理解规则；拿给开发看，开发能直接按表格实现逻辑。如果表格列数超过20列，或者单列条件超过6个，基本可以断定这张表不合格。

条件项太多时，优化策略通常有三个：

• 拆分判定表。如果一个业务逻辑里有10个条件，不要试图一张表画完。先找出业务上强相关的条件组合，拆成两张或更多张子表。比如支付结果通知有“支付金额”“支付渠道”“订单状态”“回调次数”四个条件，可以把回调处理单独拆出来，不混在主支付表中。

• 引入前置等价类。很多条件看起来可变，实际在业务上可以提前归类。比如“用户账户状态”有正常、冻结、注销三种，但冻结和注销用户根本进不了支付页，因此可以在判定表之前就把这两个条件项排除掉。方法是在测试设计前置条件里写明“仅正常状态用户方可进入结算流程”，判定表就不用为这两个状态额外开列。

• 主动设置约束规则。如果业务规则规定某些组合不可能出现，应在判定表里用约束标识直接标出，而不是仍然展开。最常见的是“登录方式”和“注册类型”之间的兼容性约束，很多平台第三方登录用户不能绑定某些支付方式，这些约束在需求里是隐含的，AI往往能主动识别出来。

我自己在使用AI生成判定表时，还会额外加一个要求：让AI标注每一列规则对应的测试用例优先级。因为判定表化简之后，仍然可能有十几列，如果每列都写用例，用例数量还是不少。请AI按“高风险、影响主流程、上线后最容易被用户感知”三个维度打优先级，就能直接要把回归测试重点圈出来。

3. 场景法与判定表如何协同

讲了这么多，有人可能会问：既然场景法和判定表都能覆盖测试场景，那我选一个不就行了？这里我再明确一下边界：场景法适合纵向拉链路、找流程断点；判定表适合横向切组合、理清规则矛盾。真正落到一个中大型模块的测试设计上，你要做的是把它们串联使用。

还是用一个实际例子来讲：用户在下单页提交订单，前端校验通过后请求后端，后端做库存预占、优惠计算、生成待支付订单，用户在收银台选择支付方式完成支付。这一个链路下来，主链路里至少有“提交订单”“支付”“支付结果通知”三个环节。如果用场景法，就是分别对每个环节拉主备异常链路；如果把“优惠计算”抽出来，就会看到它下面有“用户等级、优惠券、满减活动、会员积分”四个条件的组合，而这四个条件正好用一个判定表来覆盖。

所以我的实战操作顺序是：

1. 先用AI拉全链路场景，把主成功场景、备选场景、异常场景都列出来，形成一张场景总览表。
2. 从场景里识别“岔路口”节点，也就是哪些步骤存在多个条件共同决定结果。
3. 把岔路口单独拿出来，让AI构造判定表。
4. 把判定表中生成的典型规则再回溯到场景里，去补充边界场景。
5. 最后把AI输出的场景和判定表一起作为“测试基线”，再人工做一轮查漏补缺。

这套流程的价值，是让AI承担最消耗体力的枚举和整理工作，让人把精力花在审核和决策上。我在团队里推行这套做法后，业务复杂的模块测试设计效率大概能提升一倍，而且测试设计的可读性比以前拿Excel铺一大堆用例好得多，代码评审和用例评审时，开发也更容易理解测试背后的业务逻辑。

3.1 用一条支付订单链路把两种方法串起来

我把上面的方法具体展开一下，以“小程序商城下单支付”为例，把AI输出的场景法和判定表演示一遍。

先说场景法。需求核心规则大概是：用户浏览商品，加入购物车，提交订单，选择微信支付或余额支付，支付成功后生成发货单。部分用户有优惠券，优惠券分为满减券和折扣券；VIP会员享受额外折扣。

AI第一轮输出的主场景是：

1. 用户登录后从首页选择商品，进入详情页。
2. 点击“立即购买”，确认商品规格和数量。
3. 提交订单并进入收银台。
4. 选择支付方式，完成支付。
5. 系统生成支付成功回执，通知仓库发货。
6. 用户查看订单列表，看到物流信息。

备选场景AI输出的是：

1. 已登录用户从购物车入口提交订单，而不是从商品详情页直接购买。
2. 提交订单后余额不足，切换微信支付成功。
3. 优惠券在支付前过期，系统自动剔除并重算实付金额。
4. 用户取消订单，库存释放。

异常场景AI输出的是：

1. 提交订单时库存只剩1件，同一用户重复点击导致并发预占，其中一笔预占失败。
2. 支付请求已发出但回调超时，用户再次点击支付，系统命中幂等校验不重复扣款。
3. 支付成功但通知仓储系统失败，订单卡在“已支付待发货”状态，由定时任务补偿。
4. 用户支付时网络中断，前端展示支付中状态，后端实际未生成支付单。
5. 余额支付后，退款申请时余额账户已注销，需走人工退款。

这些场景列出来之后，可以发现绝大多数在需求文档里并没有写出具体分支，它们是基于主链路逐步追问得到的结果。但请注意，AI能列出来不等于规则真实存在，你还需要逐条回到产品和技术方案里确认。比如“支付回调超时后允许用户再次支付”这条，如果系统没有做接口幂等，那么再次支付可能产生重复订单，这种场景不能直接写成测试用例，而是要先作为问题抛给开发。

3.2 前后衔接：场景法找路径，判定表找组合

顺着上面这个例子，把“优惠计算”这个岔路口从场景里抽出来，单独做判定表。

条件桩我定义为四个：用户等级（普通/VIP）、优惠券类型（无/满减券/折扣券）、支付方式（微信支付/余额支付）、是否叠加VIP折扣（是/否）。动作桩定义为：计算优惠后金额、显示优惠明细、校验优惠券是否可用、计算最终实付金额。

AI生成的判定表，经过我调整后大概长这样（规则加以简化）：

这张表的合并逻辑是：普通用户不管选微信还是余额，“优惠计算”这件事本身的结构是一样的，所以支付方式列被合并成“任一”。但“余额不足”这个动作依赖支付方式，不能完全合并，因此在最后两列单独展开。判定表的化简就需要这种“先合并公共项，再单独拆出依赖项”的平衡。

实际使用中，我还会让AI额外输出“无效规则标注”，把业务上不成立的组合明确标出来，比如普通用户不满足满减门槛却使用满减券的情况。这类无效规则一般不写测试用例，但必须由测试设计明确排除，避免开发实现时出现逻辑漏洞。

4. 落地实操：AI提示词模板与迭代节奏

这一节我给出一套自己用了很久的提示词框架，以及完整的调用流程。这套方法不绑定具体AI产品，市面上的主流大模型都能用，关键是提示词的结构要稳定。

4.1 给AI喂需求时的输入包格式

不要直接把产品需求文档复制粘贴给AI就跑，那样输出的质量会很不稳定。我习惯先做一次“需求预处理”，把要用到的信息整理成一个结构化输入包，格式基本是：

1. 角色设定：告诉AI它是资深测试设计专家，擅长场景法和判定表，熟悉电商、金融、企业级系统的测试逻辑。
2. 业务背景：用三到五句话说明这个功能模块是什么、服务谁、核心业务目标是什么。
3. 业务规则清单：逐条列出硬性规则，包括前置条件、后置结果、异常处理方式。
4. 输出要求：明确要场景列表还是判定表，格式是Markdown表格，需要标注规则来源和优先级。
5. 约束条件：告诉AI不要编写测试步骤、不要生成测试数据、不要扩展需求中不存在的业务规则。

我把这个结构直接放在提示词开头，AI的输出稳定性明显比直接粘贴需求文档好得多。原因也很简单，大模型的回答质量依赖上下文结构清晰度。输入越结构化，输出越可控。

4.2 场景法提示词模板

下面是一份我实际使用且测试过多次的模板：

你是一名有8年经验的资深测试设计专家。请阅读以下业务需求，以场景法完成测试设计草稿，要求如下： 1. 只输出场景列表，不要编写测试步骤或测试数据。 2. 场景分为三类：主成功场景、备选场景、异常场景，请用Markdown表格输出。 3. 每个场景按“触发事件-前置条件-操作步骤-预期结果”进行概括描述，但不要展开到用例级别。 4. 请基于业务规则做逻辑推演，不要虚构需求中不存在的功能或规则。 5. 若某一场景在需求文档中没有明确规则支持，请单独标注“需与产品确认”，不要自行假设。 [业务需求] （此处粘贴需求预处理后的文本） [已知业务规则] （此处逐条列出规则）

这份模板的运行效果有几个特点：AI会主动对边界情况进行补全；对于规则不清楚的地方，它会用“需与产品确认”来隔离风险，而不是自作主张；场景列表结构稳定，后续人工审核时可以一条条对。

4.3 判定表提示词模板

判定表的提示词跟场景法不同，更强调条件枚举和规则推导：

你是一名熟悉复杂业务规则建模的测试设计专家。以下是某个业务模块的需求规则，请用判定表输出测试设计草稿，要求如下： 1. 先列出所有条件桩和动作桩，每个条件桩的取值集合要给出等价类划分说明。 2. 条件组合必须覆盖所有有效规则，对无效规则单独标注“无效组合”并说明原因。 3. 若条件数量过多，请主动拆分判定表，并在每个子表标题中说明拆分维度。 4. 请标注每条规则对应的动作结果，并依据业务影响程度给出用例优先级（高、中、低）。 5. 若某条规则在需求中没有明确描述，请标注“规则缺失”，不要擅自假设。 [业务需求] （此处粘贴需求预处理后的文本） [已知业务规则] （此处逐条列出规则）

这里有一个经验技巧：判定表提示词一定要要求AI输出等价类划分说明。因为很多AI在构造判定表时，会把每个条件的取值写得特别细，导致组合数量爆炸。比如“支付渠道”这个条件，它可能会列“微信支付-安卓、微信支付-iOS、支付宝-安卓、支付宝-iOS、余额支付”，但其实测试“支付渠道”时，很多时候不需要按端再拆一遍。如果你让它先把等价类写出来，再进行组合，组合数量会大幅下降，表的质量也会更高。

4.4 结果评审与二次迭代

我通常会把AI输出当作“一稿”，而不是最终结果。一稿出来后，我会拿着场景列表和判定表做两件事：

第一件事是逐条检查业务规则覆盖率。把需求文档里的每条已知规则编号，在AI输出里反向查找它体现在哪个场景或哪条规则中。确保没有规则被遗漏。

第二件事是把AI标注“需与产品确认”和“规则缺失”的条目收集起来，发给产品经理确认。这一步非常关键，因为AI列出的这些点，往往恰恰是需求文档里没说清楚、但开发实际实现时容易出问题的部分。用AI做测试设计的隐藏价值就在这里：它不仅能帮你写东西，还能反过来帮你揪出需求本身的问题。

我在实际项目中，曾经靠AI标出的一条“规则缺失”找到过一个重要的线上隐患。当时需求只写了“退款成功后优惠券退回”，但没写“退款后会员折扣是否恢复”。AI在判定表里把这个条件缺失明确标出来了，产品确认后补了规则，测试用例才据此补充，否则上线后用户退款再购买时价格就会出现错误。

整个流程中，费用相对可控，一次完整业务模块的测试设计，AI调用大概在10到20轮左右。相比人工写测试设计动辄一个下午甚至一整天，效率提升是非常明显的。

5. 实战中的坑与排查记录

最后分享一些实操里踩过的坑和解决方式，都是自己在项目中验证过的。

5.1 AI常见翻车现场

第一类翻车：场景冗余。AI会把同一条业务链路用不同措辞重复输出好几遍。比如“用户没有收货地址时点击提交订单”和“提交订单时选择的地址已被删除”，本质上是同一个异常分支。处理办法是让AI输出时把场景按“触发事件”去重，如果同一触发事件导致的预期结果相同，就合并成一条。

第二类翻车：规则臆造。畅所欲言模式下AI很容易脑补业务规则，例如在支付场景里擅自增加“支付金额不能超过银行卡单笔限额”之类的假设。如果需求文档里没有这条约束，就必须删掉。解决方法是提示词里强制要求“只基于需求文本推断，不得引用外部行业惯例”，并在评审时逐条比对来源。我见过不少测试同学被AI“带偏”，把根本不属于本期需求的场景写进用例，最后评审被开发直接驳回，既浪费时间又影响威信。

第三类翻车：异常场景流于表面。AI可能只写“系统报错并提示用户稍后重试”，没有深入到具体异常类型和系统状态。解决方法是要求AI对每个异常场景补充：异常发生前系统处于什么状态、异常发生后数据有没有残留、用户能不能重试、重试后系统是否还能继续原流程。把这些补上，异常场景才有真正的测试指导价值。

5.2 半自动协作工作流

用AI做测试设计，我最推荐的并不是“全自动让AI输出最终用例”，而是“半自动协作”：AI负责发散和穷举，人负责收敛和决策。

我的日常工作流大概是这样的：先用AI产出场景总览和判定表草稿，然后把结果导入到测试管理平台，用人工方式再逐条评审。评审通过后，再让AI根据评审后的场景和规则生成具体测试用例，这已经是第二轮的活儿了。如果直接把AI生成的原始结果导入平台执行，大概率会得到一批不可用的用例，因为AI写的步骤在细节上往往跟实际系统不完全一致，比如按钮名称、文案提示、顺序逻辑。

我还习惯在每一轮AI对话之后，把AI输出的结论复制到一个工作文档里，不让上下文无限累积。因为上下文越多，AI越容易在后面的轮次里参考前面已确认的内容，一旦前面的内容有错误，错误会被放大。用工作文档记录每一轮的中间结果，人工确认后再开启下一轮，这样整个过程是相对可控的。

关于如何判断AI输出质量是否合格，我自己的标准很简单：闭上眼睛想象一个真实用户操作这个功能，如果按你的测试设计能覆盖他的每一步操作和可能的反悔，同时开发按你的测试设计能确认“这个分支不会出这个错”，那这份测试设计就是合格的。达不到这个标准，就继续迭代，不要省那几轮对话时间。

最后想提醒大家一点：AI for Testing的本质不是让测试人员变懒，而是把精力从机械枚举中解放出来，放到更有价值的业务分析和质量决策上。我自己在实际项目中测试设计提效明显，真正花费时间最多的地方不是AI对话，而是拿着AI结果跟产品、开发逐条确认的过程。但这部分时间花得值，它会直接提升测试设计的准确性和评审效率。