变更驱动回归测试：基于业务规则关联的用例选择与结果校验

自动化测试中有一种问题，比脚本运行失败更容易被忽略。

需求已经发生变化，自动化用例却还在按照旧规则执行。

比如某银行系统调整了转账限额，原来所有用户采用统一额度，现在改成根据用户等级分别配置。

研发完成了代码修改，自动化回归也顺利通过。但仔细检查后发现，原有用例仍然按照统一额度执行，没有覆盖不同用户等级的边界条件。

脚本执行成功了，测试却没有验证新的业务规则。

这类问题在订单、支付、权限、审批等业务中并不少见。

传统自动化测试主要解决“如何执行”，但需求变化之后，测试团队首先需要回答的是：

哪些测试用例受到影响？哪些场景需要补充？原来的断言还能不能使用？

随着 AI Agent、RAG 和知识图谱等技术逐渐应用于软件测试，一种新的技术思路是将需求变更分析、业务知识关联、回归用例选择和自动化校验组织到同一条工作链路中。

一、自动化回归为什么会出现覆盖失效？

自动化测试能够按照既定步骤重复执行，但无法天然保证这些步骤始终符合最新需求。

实际项目中，需求变更通常会带来三类问题。

第一类：测试覆盖失效。

业务新增了规则，测试用例却没有同步增加。

例如转账限额增加用户等级维度后，原来的统一限额测试就不足以覆盖新的场景。

第二类：测试断言失效。

脚本仍然按照旧规则判断结果。

即使执行通过，也不能说明新业务符合预期。

第三类：测试路径失效。

页面、接口或者业务流程发生变化，原有操作路径不再适用，导致自动化执行失败。

这三类问题需要采用不同的处理方式。

测试覆盖失效需要重新分析测试范围；断言失效需要更新验证规则；执行路径失效则需要调整操作流程和工具调用。

因此，回归测试不能只关注脚本执行成功率。

更重要的是建立需求变更与测试资产之间的关联，确保每次回归验证的都是当前业务规则。

二、如何定位需求变更影响的测试用例？

继续使用银行转账业务。

假设原来的转账规则是统一限额，新版本调整为普通用户、高级用户和企业用户分别配置不同额度。

这里的用户等级和规则仅用于测试设计举例，并非实际银行系统的业务规定。

面对这次变更，测试人员需要解决两个问题：

一是找出原有测试用例中涉及转账额度的内容。

二是根据新规则，补充不同用户等级对应的测试场景。

1. 通过 RAG 和知识关联识别变更范围

实际项目中，业务规则通常分散在需求文档、接口说明和历史测试用例中。

RAG 可以检索与当前变更有关的业务资料，帮助模型获取规则依据。

知识图谱则可以进一步组织业务实体之间的关系，例如：

转账需求 → 额度规则 → 用户等级 → 测试场景 → 自动化用例

当额度规则发生变化时，就可以沿着这些关系查找可能受影响的测试内容。

AI Agent 可以在此基础上执行需求差异分析、影响范围识别和回归用例推荐。

一个典型的处理流程是：

需求版本对比 → 业务规则识别 → 关联测试点 → 选择回归用例 → Agent 执行 → 断言校验与报告。

这里需要明确一点：

AI Agent 识别出的影响范围，应该先作为待验证的测试建议，而不是直接修改全部测试用例。

业务规则缺失、知识库版本滞后或者依赖关系不完整，都可能导致影响分析出现遗漏。

2. 根据新规则重新设计边界用例

假设新版本中，某类用户的单笔转账上限为 L 元，规则明确规定允许转账金额小于或等于 L。

金额最小单位为 0.01 元。

可以设计以下测试：

这些测试不只是为了增加用例数量，而是为了验证规则变更带来的新边界。

同时，还需要检查与额度校验有关的接口、权限及交易失败处理。

例如，超额转账被拒绝后，交易状态和资金数据是否符合业务规定。

从测试设计角度看，这比单纯要求 AI “生成20条转账测试用例”更有价值。

因为每条用例都有明确的业务依据和验证目标。

三、AI Agent 如何完成回归执行与结果校验？

识别出需要回归的测试场景之后，下一步就是自动化执行。

传统自动化通常由工程师提前编写脚本，通过 Playwright、Appium、Pytest 等工具完成操作。

AI Agent 可以在这些工具之上，增加任务理解、步骤规划和执行状态管理能力。

例如，测试目标是：

“使用普通用户账号，验证超出当前等级限额的转账请求会被正确拒绝。”

Agent 需要先读取对应的业务规则，确认测试环境与用户身份，再准备测试数据并调用自动化工具。

执行完成后，还需要检查实际结果。

整个过程可以分成三个部分。

1. Planning：规划执行步骤

根据测试目标确定前置条件、测试数据、操作顺序和预期结果。

对于连续操作，还需要保存接口返回值、订单编号等上下文数据。

2. Tools：调用测试工具

根据被测对象选择相应的自动化能力。

Web 页面可以使用 Playwright，移动端可以使用 Appium，接口测试可以使用 Pytest 等框架。

大模型负责组织任务，底层工具负责实际执行。

3. Observation：观察与校验结果

操作完成后，需要根据执行反馈判断下一步动作，并保存测试结果。

这里有一个非常重要的工程原则：

智能体完成操作，不等于测试通过。

页面显示“提交成功”，并不能单独证明后台业务处理正确。

接口返回 HTTP 200，也不能直接说明所有业务规则都得到了满足。

对于转账场景，除了页面提示，还应结合接口响应、交易状态和资金数据进行验证。

其中，业务关键断言应尽量采用明确、可复核的规则。

多模态模型可以参与页面视觉状态识别，但不应成为资金、权限等关键业务结果的唯一判断依据。

四、这些技术能力在实际测试系统中如何应用？

前面讨论的是变更驱动回归测试的技术方案。

在工程实践中，已经有测试平台将业务知识、用例生成、自动化执行和测试报告等能力集成到系统中。

例如，爱测智能化测试平台提供了测试用例生成、业务知识图谱以及 Web、App、接口测试智能体等功能。

从其产品演示资料中，可以看到两个具有代表性的场景。

1. 业务场景生成结构化测试用例

在银行转账业务案例中，系统将业务场景组织成结构化测试用例。

测试人员可以根据用例列表检查不同业务条件对应的测试内容。

这类能力主要解决测试用例设计与组织问题。

对于需求变更场景，还需要进一步结合规则版本和用例关联信息，验证是否能够正确识别受影响的测试内容。

2. 自动化执行与结果记录

在接口测试场景中，平台展示了测试步骤、请求日志和断言记录等信息。

对于 AI Agent 测试系统，这些执行证据非常重要。

当测试失败时，工程师需要判断究竟是任务规划错误、工具执行异常、测试数据问题，还是被测系统真正出现了缺陷。

完整的执行日志和断言记录，能够为问题复核提供依据。

需要说明的是，上述截图展示的是产品中不同环节的功能，不代表已经验证了完整的需求变更自动影响分析闭环。

五、如何评估 AI Agent 回归测试的实际效果？

企业引入 AI 测试方案时，不能只看一次演示是否成功。

更合理的方式，是选择一个真实业务模块，模拟需求变更，检查测试系统能否正确识别影响范围并完成回归。

建议重点关注四个指标。

例如，在隔离测试环境中，故意修改某个用户等级的额度判断逻辑，观察测试系统能否识别异常。

同时，可以对比传统自动化与 Agent 辅助测试在用例调整、脚本维护和失败定位方面的工作量。

评估时还应记录误报、漏报和人工干预情况，避免只统计最终执行成功次数。

对于交易、资金、权限等高风险业务，关键测试点和断言仍然需要人工评审。

总结

回归测试最容易被忽略的问题，不是脚本能不能运行，而是脚本验证的内容是否仍然符合最新业务规则。

RAG 可以帮助获取业务依据，知识图谱可以组织需求与测试资产之间的关系，AI Agent 可以参与变更分析、任务规划和自动化执行。

但这些技术并不能替代可靠的测试设计与结果校验。

对测试开发工程师来说，真正值得关注的是如何把需求、用例、自动化工具和执行证据连接起来，让测试体系能够持续适应业务变化。

每一次需求变更之后，都能找到需要验证的内容，并用可靠的证据确认结果，这才是回归测试需要解决的核心问题。

案例说明：本文技术分析及银行转账需求变更示例为独立整理，部分演示截图来自测吧（北京）科技有限公司爱测智能化测试平台产品资料。具体产品能力与实际效果需结合项目验证。