已批准的业务规则交给 Agent，怎样设计覆盖分支的测试用例

已批准的业务规则交给Agent，适合先生成可审阅的测试用例，再由测试负责人确认覆盖范围。用例应写清前置对象、动作、观察和依据；只把原规则换成一个测试标题，仍会让执行者现场猜步骤。本文以预约业务展示设计方法，未执行目标软件。

标准答案从已确认行为来

规则来源要能指到条款和适用版本。若产品要求预约人数1至8、场地可用才允许提交，应分别保存人数条件、场地条件及成功观察。它们共同决定用例，不能让模型从常识补出重叠预约、优先提示等未确认规则。

设计时可先建立条件表，再分测试场景和具体用例。同一场景可能使用多个参数；一个用例也可能同时涉及两条规则。覆盖表因此记录对应理由，不只堆需求链接。条件未知时保留预期缺失，避免生成一个措辞完整却没有依据的Then。

官方机制说明1：Rule、Given/When/Then、Scenario Outline与Examples可以表达规则和具体示例，不自动证明业务规则正确。；官方机制说明2：parametrize可传入多组输入和预期，叠加参数可形成组合；不自动保证业务覆盖充分。

表达与参数化工具可以承载已定义预期，不能自动保证业务覆盖充分。现有测试管理工具若已经支持用例导入，助手只需按客户字段生成草案和覆盖关系，再交人审阅，不必另造执行系统。

三条样例怎样落到用例卡

合成输入1。 预约人数1至8且场地可用，输入8人可用

预期处置：生成边界有效用例及明确预期

合成输入2。 场地不可用且人数9，两个校验同时失败

预期处置：生成多条件用例并要求既定优先提示依据

合成输入3。 规则允许重复日期，但没有定义同人同场重叠预约

预期处置：列预期缺失，不能把自拟规则当标准答案

有效上限用例应有可用场地和合成申请人，输入8后观察允许提交的约定结果。两个条件同时失败时，要保留“人数9”和“场地不可用”，提出先显示哪类问题的待确认项，不能让模型选一个顺眼的错误提示。重复日期并不自动等于重叠预约被允许，它可能只是不同对象同一天的合法记录。

步骤和数据要能各自复用

用例卡可写前置R01场地、S01时段、申请人U01，动作为选择R01/S01、填写人数8、提交，预期引用获批允许提交口径。实际出现的预约号和提示由执行时填写。附件提供的是合成卡片，不是软件已生成的运行结果。

多条件失败案例则固定同样入口但使用人数9和不可用时段，候选预期只确认不得按有效输入正常提交；提示顺序保持待定。第三例列出重复日期规则与同人同场重叠之间的缺口，交产品澄清后再确定能否执行。这样用例集不会把待定规则包装成通过标准。

覆盖表如何帮助复核

先按规则查看是否有至少一个能反驳错误实现的用例，再按用例反查其输入是否真的触发对应条件。若一条用例写覆盖“不可用场地”，前置却是可用场地，关系应退回修正。只统计用例数，无法发现这种名义覆盖。

测试负责人还要区分本轮需要覆盖的行为与后续范围。某条件已批准排除，应保留排除依据，不必伪造一条通过记录；资料缺失则是未定而非排除。本文附件将规则条款、合成数据、预期、实际及证据位置分开，便于后续执行和产品复议。

采购讨论可用一小组已批准规则和既有用例格式，要求助手同时交出正常例、冲突例和无法给预期的例子。若它只会生成正常路径，增加篇幅也不能弥补边界处理能力。价值在于减少整理与映射工作，同时让测试判断仍有清楚依据。

用例草案的可用程度怎样判断

附件另列第一条用例的前置U01、R01、S01及选择、填写、提交步骤，让审阅者拿到实际卡片。预期仍回指批准规则，生成器不提供真实预约编号。第二条把两个不满足条件保留在同一输入中，用来讨论错误优先级，而不是拆成重复的两张正常路径卡。第三条给同人同场两个相交时段及明确时区，暴露尚缺的重叠规则，不能把相同日期误当同一时段。

下载本题合成输入与可填写工作表。附件保留实际结果、复核人和证据位置空栏。

知识问答验收的专门方法见相近旧文；性能证据可交压测报告只有平均响应，Agent 怎样整理能比较的性能测试证据处理，新增缺陷则送缺陷标题相似就能合并吗：Agent 怎样准备重复缺陷候选比较候选关系。在文档与数据处理专题挑选测试资料任务，向定制咨询提供批准规则和一份现有用例格式。