一个业务模块改了，Agent 怎样提出有依据的回归测试范围

业务模块改了以后，Agent可以根据已确认变更、依赖关系和历史用例提出回归范围。关键产物是每条入选或待定用例的理由，而不是把所有用例都列成“建议回归”。它从既有测试资产选择本轮范围，与从规则新建用例是两项工作。

先写改了哪种行为

变更说明最好到业务条件和受影响组件，而非只有“优化预约”。取消规则变化，可能触及名额重新可约和提醒展示；日期控件变化，可能跨多个业务模块。先列直接行为、共享组件和声明不变部分，再按已有关系寻找用例。

关系来源需要保存。产品说某流程共用日期控件，与代码负责人确认的实际共用范围，不应无区别混在一起。只有局部资料时，结论也限于该范围；没有搜到关联不等于没有受影响业务。

官方机制说明1：工作项表达需求，Epic/Feature聚合场景；本文的切分与缺口检查是拟设计方法。；官方机制说明2：计划手工测试、用户验收、探索测试及反馈是不同测试活动，配置、运行与用例各有对象。

工作项和测试计划提供资产组织方式，本题的选择理由和风险分组是拟定制设计。已有平台能维护关系时可直接利用，助手负责解释变更内容和发现映射空白，而不是另建一套同义编号。

合成输入1。 预约取消规则变化，用例集中有取消后再次预约和提醒展示

预期处置：列两类受影响用例，解释规则与下游关联

合成输入2。 公共日期控件升级，但只提供预约模块用例

预期处置：标跨模块依赖缺口，不宣称覆盖其他系统

合成输入3。 仅帮助文案拼写修正，未改业务条件

预期处置：列文案与布局核对候选，回归范围由测试确认

取消后再次预约检查名额行为，提醒展示检查下游用户观察，它们因不同理由进入候选。公共日期控件的例子则暴露资料范围不足，不能只回归预约就声称跨模块覆盖。纯拼写修正仍可以核文字和布局，但是否需要业务路径全量回归，应结合实际修改而不是统一套最高等级。

必选表列直接改变的已确认行为及现有验证；候选表列间接依赖或需负责人判断的路径；缺映射表列已知受影响对象却没有对应用例的位置。分类口径由测试负责人确认，不能把模型建议直接写成最终测试计划。

排除也要给理由。某用例与变更名称相似，但实际验证的是另一个独立流程，可以说明不纳入本轮候选；理由应回到业务对象和实现关系，不能仅靠关键词不重合。反向核对时，从变更每一条影响找用例，再从每条用例问它究竟检查什么。

选择清单先保存计划状态，实际执行、环境和观察随后独立填写。若发现现有用例预期已随批准变更失效，先交产品更新标准，不应为了通过率沿用旧答案；也不能直接抄新实际表现当预期。

定制交付可以先读取一项小变更与一组用例资产，测试负责人逐项审查建议的入选、排除和未知。好的结果能够指出哪些关系需要人工补充，而不仅给出高覆盖承诺。本文附件的关系和候选均为合成，未运行回归，也未据此批准发布。

附件CH1连接取消后重约与提醒展示，选择理由分别为名额可用和下游观察；CH2只取到预约日期用例，其他模块留为缺映射；CH3只列文案和布局候选。三类范围由测试负责人决定，不按模型排序自动执行。

如果负责人删除一个候选，需要记录它不适用的业务理由。若后来补了共享组件关系，再把相应测试列进新范围，旧选择仍可回查。这样团队能够解释本轮为何测这些，而不是用一份不断增长、永不删除的全量列表冒充精准分析。

范围表中的待定项也应有接收窗口，例如共享日期控件的其他使用模块由组件负责人补资料。它是明确补件任务，不会因尚未找到用例而被计为通过。

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