通用服务测试 AI 化实践从 AI 友好框架到两阶段流水线一、写在前面高变更密度业务的服务端测试长期被三件事卡着脖子。变更密集。一个迭代里多个业务模块的接口往往同时在改单纯靠 Code Review 经验回归漏测风险高。Case 编写成本高。一条标准的 TestNG Case从读懂 PRD 到补齐数据准备、清理、断言。知识孤岛。需求在需求管理平台技术方案在协作文档/知识库代码在代码托管平台历史用例在测试仓库——人需要在四五个系统间反复切换才能写出一条像样的 Case。我们沿着一条核心思路推进让 AI 把跨系统上下文串起来AI 总结梳理测什么再让 AI 把它翻译成可执行的代码怎么测。最终落成了一条两阶段 AI 流水线阶段角色输入输出一需求分析 Agent需求文档 技术方案 代码变更变更分析报告 测试点清单测什么二代码生成 Agent测试点 测试框架 历史 Case测试方案 Case 代码怎么测目前框架已覆盖多个核心业务模块累计数百个自动化 Case。单接口 Case 编写从平均20 分钟降到 8 分钟以内复杂需求涉及多模块联动的编写工作量从5~10 人天降到 3 人天以内。但在讲这两阶段之前我想先讲一件容易被忽视的事这套链路能跑通的真正前提不是模型多强而是测试框架本身就是AI 友好的设计。二、大前提测试框架的 AI 友好设计我们沉淀出一套 AI 友好的测试框架核心设计原则如下。2.1 沉淀 AGENT.md给 AI 一份说明书在仓库根目录放一份AGENT.md面向 AI 的项目说明把构建命令、模块结构、目录约定、技术栈、命名规范、单 Case 启动方式全部写清楚。AI 编码 Agent 启动时自动读取从此不再需要在 prompt 里反复解释项目背景。2.2 统一入口消除歧义框架只保留test-case-start模块下的 Spring BootTestNgRunner作为唯一入口。所有 Case 统一走mvn test -pl test-case-service -Dtest...或平台 Web UI 触发。模型只需记住一种调用方式。2.3 严格四层 TestBase 体系TestDataBase抽象基类 │ 提供用户标识/设备标识/请求标识 生成、登录注册、Cookie 管理 │ ├── {Module}TestBaseModuleATestBase / ModuleBTestBase / ModuleCTestBase ... │ 提供各域服务 IP 初始化Parameters Optional │ │ ├── {Domain}TestBaseDomainXTestBase / DomainYTestBase ... │ │ 提供领域参数构造buildSkuFull / buildSkuOrder / InfoOrderMQBody ... │ │ │ │ └── 具体 *Test 类CalcOrderTest / OrderUsableDiscountsTest ...每层职责明确AI 写新 Case 时只需找到对应领域的TestBase继承即可。2.4 三套辅助类TestData / DataHelper / MockData每个业务模块对应三个辅助类职责严格分离类型示例职责规则{Module}TestDataModuleATestData、DomainXTestData只定义常量业务 ID、活动 ID、POI ID、枚举类内禁止包含任何方法{Module}DataHelperModuleADataHelper、BudgetDataHelper只提供静态方法Redis库存/限频/资格、DB数据查改删/流水日志禁止定义数据常量{Module}MockDataModuleAMockData只生成 Mock 数据算法 Mock、外部服务 Mock 响应与 TestData/DataHelper 解耦三套类的分工让 AI 有了确定的选择路径查数据 → TestData操作 Redis/DB → DataHelperMock 外部依赖 → MockData这几乎消灭了臆造方法名的问题。2.5 API Client 标准化com.example.test.apis.*下每个接口一个 Client 类全部继承ApiV2Base签名、加密、Header 注入由基类统一处理。AI 只需三步固定模式XxxApi.getInstance().ipgetTestHost();// 1. 指定服务地址JSONObjectrespXxxApi.getInstance().call(params);// 2. 发送请求Assert.assertEquals(resp.getString(code),SUCCESS);// 3. 校验返回2.6 公共常量收敛文件作用ServerIpDaily所有 daily 环境服务 IP 的单一事实源conf/Config.xml平台默认参数channel、device info、用户标识 等common/constants/BizTypeConstants业务类型常量common/constants/CategoryConstants类目 ID 常量common/constants/StatusConstants状态枚举common/constants/ParamsConstants公共默认参数adcodeDefault / appVersionDefaultAI 引用时直接import static不会再硬编码或臆造。2.7 强制六段注释模板每条 Case 头部强制写出六段注释测试目标 → 测试场景 → 前置条件 → 测试步骤 → 预期结果 → 关键验证点把人类的设计逻辑显式落进代码。它既是规范也是 AI 下一次召回时的高质量训练语料。关键结论框架做到 AI 友好后同一份 prompt 同一个模型Case 编译通过率达到91%。框架设计的 ROI 远高于 prompt 调优。三、阶段一AI 分析测什么3.1 输入来源输入来源内容需求文档需求管理平台工作项PRD 正文 验收标准 关联的协作文档/知识库技术方案协作文档 / 知识库接口契约、时序图、新增/修改 DDL代码变更代码平台 MRchanged files diff仅 src/main 业务层 提交说明需求分析 Agent 的核心优势是通过内部 MCP 工具如list_changed_files、searchCodeWiki、query_workitem_detail、get_changed_file_diff等直接读到第一手数据不需要手动复制粘贴。3.2 调用流程协作文档/知识库代码平台 MR项目协作平台需求分析 Agent测试同学协作文档/知识库代码平台 MR项目协作平台需求分析 Agent测试同学给定 工作项 ID CR IDquery_workitem_detailPRD 正文 验收标准get_merge_request_changed_file_diff全量 diff 文件列表抓取关联技术方案接口契约 / DDL语义对齐 风险打分变更分析报告 测试点清单3.3 Prompt 模板节选# 角色定义 你是一位专业的 Java/Go 代码变更分析与服务端测试专家。 核心职责 - 代码变更深度分析语法结构、实现逻辑、调用关系 - 服务端接口测试方案设计与用例编写 - 多仓库复杂变更场景的影响评估 # 一、任务执行流程严格按序执行不可跳步 ## Phase 1获取变更单详情 **输入**: crId **动作**: 调用接口查询变更单详细信息 **输出解析规则**: - repo: 从 branchUrl 中解析仓库名称 - sourceBranch: 从 branchUrl 中解析分支名 - detailUrl: 直接提取 ## Phase 2获取变更文件列表 **动作**: 对比 sourceBranch 与 master 分支 **输出**: 变更文件列表含路径 ## Phase 3分支处理条件分支 IF 文件列表为空: 1. 在 repo 中搜索 sourceBranch 的已合并 MR → 获取 mergeRequestId 2. 通过 mergeRequestId 查询 MR 变更文件列表 3. 逐文件获取 diff对比 master ELSE: 直接逐文件获取 diff对比 master **校验点**: 每次工具调用后验证返回数据非空且格式正确异常时立即报告并停止。 # 二、变更分析要求五阶段递进分析 ## 阶段 1项目上下文建立 **目标**: 建立项目认知基线 执行动作 1. 查阅项目 CodeWiki 文档 2. 查阅需求文档如有 3. 查询项目知识库 4. 理解项目架构、代码组织结构、命名约定 5. 识别业务领域关键概念和术语 **注意**: 领域术语可能有特殊含义如 checkIn/checkOut 在不同业务中的含义差异必须结合上下文确认。 ## 阶段 2逐文件变更分析 **目标**: 对每个 diff 文件进行四维度分析 | 维度 | 分析内容 | |------|---------| | 代码变动点 | 精确标注新增/删除/修改的代码行及行号 | | 字段语义 | 推断新字段的业务含义结合注释和文档确认 | | 方法逻辑 | 描述涉及方法的功能、输入输出、实现逻辑 | | 调用关系 | 构建方法间、模块间的调用图谱 | **约束**: 忽略 _test.go 文件关键结论必须引用具体 文件路径:行号。 ## 阶段 3业务流程与数据生命周期分析 **目标**: 理解数据的完整生命周期 分析要点 - 数据从创建到消费的完整链路 - 数据流转中的状态变化 - 兜底逻辑和默认值处理 - 数据校验与转换节点 ## 阶段 4影响范围评估 **目标**: 多维度评估变更影响 影响分析树 ├── 影响的接口哪些 API 被修改URL 方法 ├── 影响的业务类型哪些业务场景受影响 ├── 影响的数据状态哪些状态流转被改变 └── 影响的具体字段哪些字段被新增/修改/删除 ## 阶段 5综合总结 **目标**: 结构化归总 - 按仓库分类变更内容 - 分析仓库间依赖和交互关系 - 整理 仓库 → detailUrl 映射 # 三、输出物 1变更分析评估报告 **格式**: Markdown **结构严格按序**: 1. 变更基本信息 2. 变更概述基于阶段 1 的项目认知 3. 变更文件详情分析基于阶段 2、3 4. 调用链路分析 5. 深度技术分析 6. 风险评估分级P0/P1/P2 7. 边界条件挖掘 8. 生产环境适配考量 9. 测试要点按优先级排序 10. 风险总结和建议 11. 变更链接汇总 # 四、测试用例设计三核心原则 七阶段流程 ## 三核心原则 | 原则 | 说明 | |------|------| | 前置条件分析 | 明确被测接口的数据准备链路哪些接口需要先调用、什么顺序 | | 完整业务链路 | 每个用例必须包含前置接口/条件 → 被测接口 → 验证结果 | | 三层覆盖策略 | 主流程 边界条件 异常场景缺一不可 | ## 七阶段执行流程 ### 阶段 1知识准备 - 基于变更分析阶段 1 的项目认知理解业务场景和规则 - 基于变更分析阶段 4 的接口维度确定被测接口集合 ### 阶段 2前置条件分析每个接口必答 对每个被测接口必须明确回答以下 4 个问题 Q1: 需要先调用哪些接口来准备测试数据 → 列出所有必需前置接口及其作用 Q2: 数据依赖关系是什么 → 绘制依赖链接口A → 接口B → 接口C → 区分强依赖必须和弱依赖可选 Q3: 哪些前置条件是必需的哪些是可选的 → 必需缺少则无法执行测试 → 可选用于构造特殊场景 Q4: 前置接口失败时被测接口应如何处理 → 验证异常处理和降级策略 ### 阶段 3完整业务链路设计 对每个接口按以下模板设计 ┌──────────────────┐ ┌──────────────┐ ┌──────────────────┐ │ 前置接口(数据准备) │ → │ 被测接口 │ → │ 验证结果 │ └──────────────────┘ └──────────────┘ └──────────────────┘ **示例**: 测试优惠选择功能 前置用户登录 → 优惠列表查询 → 订单详情获取 被测选择接口 验证返回结构检查 优惠金额计算 活动优先级判定 测试价格计算功能 前置活动配置 → 用户身份确认 被测报价接口 验证是否命中优惠 优惠金额 总金额正确性 ### 阶段 4三层覆盖策略 | 层次 | 说明 | 设计要点 | 示例 | |------|------|---------|------| | 主流程 | 正常业务场景 | 最常见的用户使用路径 | 正常登录→正常选择→正常下单 | | 边界条件 | 临界值场景 | 最大值、最小值、阈值临界点 | 金额0、数量1、版本阈值 | | 异常场景 | 错误处理场景 | 空值、超时、非法参数 | 负数金额、空token、超时响应 | ### 阶段 5服务交互验证 验证清单 ├── 下游服务返回的数据结构是否正确 ├── 上游服务最终命中的规则是否符合预期 ├── 返回结构完整性如 data.alternativeDiscounts ├── 优先级逻辑如 特价活动 其他优惠 └── 状态流转可用/不可用列表 ### 阶段 6测试数据规范 **强制要求**: 使用具体、可量化的测试数据。 ✅ 正确 - 普通补贴 10 元 叠加券 4 元 vs 返现补贴 10 元 - 特价补贴 8 元 vs 追价补贴 3 元 叠加券 4 元 - clientVersion5.2.0阈值 5.0.0时的行为差异 ❌ 禁止 - 测试优惠组合的 PK 逻辑模糊 - 测试不同版本的行为无具体值 - 测试金额计算逻辑无具体数据 ### 阶段 7用例知识融合 生成用例时必须结合 - 项目知识库中的业务规则 - 代码中的注释说明 - 文档中的约束条件 # 五、输出物 2测试用例文档 **格式**: Markdown.md **文档结构**: markdown # 测试用例文档 ## 接口 A: [接口名称] - **接口 URL**: [具体URL] - **接口方法**: [GET/POST/...] ### 正常场景 #### 前置条件 - 配置[具体配置项如满减/折扣/补贴/活动] - 登录[用户身份要求] - 数据准备[需要调用的前置接口及参数] #### 测试用例 | 用例编号 | 优先级 | 场景描述 | 测试数据(请求参数) | 预期结果 | |---------|--------|---------|-------------------|---------| | TC-A-01 | P0 | ... | {...} | ... | ### 边界场景 [同上结构] ### 异常场景 [同上结构] ## 接口 B: [接口名称] [同上结构] ## 风险与注意事项 - [风险点1] - [风险点2] # 六、全局约束强制执行 | 约束项 | 规则 | |--------|------| | 文件过滤 | 忽略所有 _test.go 文件 | | 代码引用 | 关键结论必须引用 文件路径:行号 | | 业务术语 | 使用业务领域专业术语不可自造术语 | | 完整链路 | 每个测试用例包含完整的前置条件和验证步骤 | | 优先级定义 | P0核心功能必须通过P1重要功能P2边界/异常 | | 数据具体性 | 测试数据必须具体可量化禁止模糊描述 | | 执行顺序 | 严格按步骤顺序执行不可跳步 | | 异常处理 | 工具调用失败时立即报告并停止 | | 知识融合 | 用例生成必须结合知识库、代码注释、文档 | # 七、最终自检清单生成输出前必须逐项确认 - [ ] 是否分析了业务语义字段在业务中的真实含义 - [ ] 是否梳理了完整的数据生命周期创建/流转/使用/销毁 - [ ] 是否明确了每个接口的前置接口数据准备链路 - [ ] 是否设计了完整业务链路前置 → 被测 → 验证 - [ ] 是否覆盖了三层主流程 边界条件 异常场景 - [ ] 是否引用了代码依据文件路径:行号 - [ ] 是否使用了正确的业务术语 - [ ] 是否忽略了单元测试文件 - [ ] 测试数据是否具体可量化 - [ ] 输出格式是否符合指定结构3.4 产出示例以「某业务修改动态规则描述」为例Agent 一次性产出两份文档先给一份高位的变更分析评估报告再给一份落地的测试用例文档。两份文档都是 Markdown可直接贴进工作项或协作文档评审。文档一变更分析评估报告示意图变更分析评估报告样例文档二测试用例文档示意图测试用例文档样例到这一步测试同学要做的只有一件事审校测试点。体感是80% 直接可用15% 微调5% 误报——而误报里有一半反向暴露了 PRD 的不严谨反推需求收敛。四、阶段二告诉 AI怎么测4.1 两步走先方案后代码最早我们让需求分析 Agent 一把梭直接出 Case 代码效果不好。框架细节是项目独有的模型对*TestBase层级、TestData/DataHelper/MockData分工没有先验一次性生成几百行代码人 Review 时被语法细节抓走忽略测试逻辑。阶段二拆成两个显式动作Step 1— 生成自然语言测试方案前置操作 / 步骤 / 断言方便人审Step 2— 方案确认后生成Case 代码走标准继承 标准 Client 六段注释通过失败通过测试点清单(测什么)代码生成 Agenttest-case 框架AGENT.md 框架历史 Case语义召回 Top-K自然语言测试方案人工 Review代码生成 Agent写 Case 代码mvn test 编译*Test.java 落盘4.2 上下文组装代码生成 Agent 启动时自动读AGENT.md获取项目骨架额外组装变更分析评估报告 测试点清单 自动化框架仓库召回的历史 Case。System Prompt 核心约束对应框架设计原则你是测试框架下的测试方案设计师与代码作者。铁律如下 1. 继承基于 {Domain}TestBase如 DomainXTestBase不得创建新基类 2. 数据常量从 {Module}TestData 取禁止硬编码 3. 操作Redis/DB 调用 {Module}DataHelper 静态方法 4. Mock从 {Module}MockData 取 5. 接口复用 apis.* Clientextends ApiV2Base禁止裸 OkHttp 6. IP从 getTestHost() / ServerIpDaily 取 7. 注释每条 Case 六段注释目标/场景/前置/步骤/预期/验证点 8. 不确定TODO(原因) 占位绝不臆造 9. 顺序先产出自然语言方案确认后再写代码4.3 中间产物自然语言测试方案示意图自然语言测试方案样例人 Review 只需读 30 行文字关注业务覆盖是否完整机器消费时每一句直接映射 Java 语句。写完后代码生成 Agent 自动跑mvn test编译/断言失败即回退到方案层重审。五、踩过的坑与最佳实践5.1 框架设计决定 AI 上限框架的AI 可理解程度直接决定 AI 生成代码的质量上限。入口统一、继承清晰、常量收敛、文档齐备——这四点做到位编译通过率可以稳定在 90% 以上。反之prompt 写得再好也是徒劳。5.2 三套辅助类是关键脚手架最初把数据常量、Redis 方法、Mock 构造揉在一个类里AI 无从判断用哪个方法。职责分离后选择路径确定查数据 → TestData操作数据 → DataHelperMock → MockData。几乎消灭了臆造方法名。5.3 上下文不是越多越好PRD 5 万字 diff 3000 行一股脑塞进去模型抓错重点。引入变更切片器按包路径白名单过滤 diff按章节锚点切 PRD控制在 8k token 以内召回率反而更高。追求相关上下文而非长上下文。5.4 测试方案用自然语言试过 YAML/JSON 中间层人被缩进干扰模型被压抑漏覆盖。自然语言格式与六段注释天然对齐模型生成代码时几乎是翻译工作量。5.5 让模型学会说不知道强制TODO(原因)占位后编译返工率从 28% → 6%。模型显式标注不确定远好过编一个看似合理但不存在的方法名。5.6 不要省略 Code ReviewAI 生成的 Case 仍走标准 MR 流程。CI 门禁任何 AI 生成的 Case 必须有人类 Reviewer 1不允许AI 写、AI Review、AI 合并闭环。
【AI应用】通用服务测试 AI 化
发布时间：2026/6/10 8:22:23
通用服务测试 AI 化实践从 AI 友好框架到两阶段流水线一、写在前面高变更密度业务的服务端测试长期被三件事卡着脖子。变更密集。一个迭代里多个业务模块的接口往往同时在改单纯靠 Code Review 经验回归漏测风险高。Case 编写成本高。一条标准的 TestNG Case从读懂 PRD 到补齐数据准备、清理、断言。知识孤岛。需求在需求管理平台技术方案在协作文档/知识库代码在代码托管平台历史用例在测试仓库——人需要在四五个系统间反复切换才能写出一条像样的 Case。我们沿着一条核心思路推进让 AI 把跨系统上下文串起来AI 总结梳理测什么再让 AI 把它翻译成可执行的代码怎么测。最终落成了一条两阶段 AI 流水线阶段角色输入输出一需求分析 Agent需求文档 技术方案 代码变更变更分析报告 测试点清单测什么二代码生成 Agent测试点 测试框架 历史 Case测试方案 Case 代码怎么测目前框架已覆盖多个核心业务模块累计数百个自动化 Case。单接口 Case 编写从平均20 分钟降到 8 分钟以内复杂需求涉及多模块联动的编写工作量从5~10 人天降到 3 人天以内。但在讲这两阶段之前我想先讲一件容易被忽视的事这套链路能跑通的真正前提不是模型多强而是测试框架本身就是AI 友好的设计。二、大前提测试框架的 AI 友好设计我们沉淀出一套 AI 友好的测试框架核心设计原则如下。2.1 沉淀 AGENT.md给 AI 一份说明书在仓库根目录放一份AGENT.md面向 AI 的项目说明把构建命令、模块结构、目录约定、技术栈、命名规范、单 Case 启动方式全部写清楚。AI 编码 Agent 启动时自动读取从此不再需要在 prompt 里反复解释项目背景。2.2 统一入口消除歧义框架只保留test-case-start模块下的 Spring BootTestNgRunner作为唯一入口。所有 Case 统一走mvn test -pl test-case-service -Dtest...或平台 Web UI 触发。模型只需记住一种调用方式。2.3 严格四层 TestBase 体系TestDataBase抽象基类 │ 提供用户标识/设备标识/请求标识 生成、登录注册、Cookie 管理 │ ├── {Module}TestBaseModuleATestBase / ModuleBTestBase / ModuleCTestBase ... │ 提供各域服务 IP 初始化Parameters Optional │ │ ├── {Domain}TestBaseDomainXTestBase / DomainYTestBase ... │ │ 提供领域参数构造buildSkuFull / buildSkuOrder / InfoOrderMQBody ... │ │ │ │ └── 具体 *Test 类CalcOrderTest / OrderUsableDiscountsTest ...每层职责明确AI 写新 Case 时只需找到对应领域的TestBase继承即可。2.4 三套辅助类TestData / DataHelper / MockData每个业务模块对应三个辅助类职责严格分离类型示例职责规则{Module}TestDataModuleATestData、DomainXTestData只定义常量业务 ID、活动 ID、POI ID、枚举类内禁止包含任何方法{Module}DataHelperModuleADataHelper、BudgetDataHelper只提供静态方法Redis库存/限频/资格、DB数据查改删/流水日志禁止定义数据常量{Module}MockDataModuleAMockData只生成 Mock 数据算法 Mock、外部服务 Mock 响应与 TestData/DataHelper 解耦三套类的分工让 AI 有了确定的选择路径查数据 → TestData操作 Redis/DB → DataHelperMock 外部依赖 → MockData这几乎消灭了臆造方法名的问题。2.5 API Client 标准化com.example.test.apis.*下每个接口一个 Client 类全部继承ApiV2Base签名、加密、Header 注入由基类统一处理。AI 只需三步固定模式XxxApi.getInstance().ipgetTestHost();// 1. 指定服务地址JSONObjectrespXxxApi.getInstance().call(params);// 2. 发送请求Assert.assertEquals(resp.getString(code),SUCCESS);// 3. 校验返回2.6 公共常量收敛文件作用ServerIpDaily所有 daily 环境服务 IP 的单一事实源conf/Config.xml平台默认参数channel、device info、用户标识 等common/constants/BizTypeConstants业务类型常量common/constants/CategoryConstants类目 ID 常量common/constants/StatusConstants状态枚举common/constants/ParamsConstants公共默认参数adcodeDefault / appVersionDefaultAI 引用时直接import static不会再硬编码或臆造。2.7 强制六段注释模板每条 Case 头部强制写出六段注释测试目标 → 测试场景 → 前置条件 → 测试步骤 → 预期结果 → 关键验证点把人类的设计逻辑显式落进代码。它既是规范也是 AI 下一次召回时的高质量训练语料。关键结论框架做到 AI 友好后同一份 prompt 同一个模型Case 编译通过率达到91%。框架设计的 ROI 远高于 prompt 调优。三、阶段一AI 分析测什么3.1 输入来源输入来源内容需求文档需求管理平台工作项PRD 正文 验收标准 关联的协作文档/知识库技术方案协作文档 / 知识库接口契约、时序图、新增/修改 DDL代码变更代码平台 MRchanged files diff仅 src/main 业务层 提交说明需求分析 Agent 的核心优势是通过内部 MCP 工具如list_changed_files、searchCodeWiki、query_workitem_detail、get_changed_file_diff等直接读到第一手数据不需要手动复制粘贴。3.2 调用流程协作文档/知识库代码平台 MR项目协作平台需求分析 Agent测试同学协作文档/知识库代码平台 MR项目协作平台需求分析 Agent测试同学给定 工作项 ID CR IDquery_workitem_detailPRD 正文 验收标准get_merge_request_changed_file_diff全量 diff 文件列表抓取关联技术方案接口契约 / DDL语义对齐 风险打分变更分析报告 测试点清单3.3 Prompt 模板节选# 角色定义 你是一位专业的 Java/Go 代码变更分析与服务端测试专家。 核心职责 - 代码变更深度分析语法结构、实现逻辑、调用关系 - 服务端接口测试方案设计与用例编写 - 多仓库复杂变更场景的影响评估 # 一、任务执行流程严格按序执行不可跳步 ## Phase 1获取变更单详情 **输入**: crId **动作**: 调用接口查询变更单详细信息 **输出解析规则**: - repo: 从 branchUrl 中解析仓库名称 - sourceBranch: 从 branchUrl 中解析分支名 - detailUrl: 直接提取 ## Phase 2获取变更文件列表 **动作**: 对比 sourceBranch 与 master 分支 **输出**: 变更文件列表含路径 ## Phase 3分支处理条件分支 IF 文件列表为空: 1. 在 repo 中搜索 sourceBranch 的已合并 MR → 获取 mergeRequestId 2. 通过 mergeRequestId 查询 MR 变更文件列表 3. 逐文件获取 diff对比 master ELSE: 直接逐文件获取 diff对比 master **校验点**: 每次工具调用后验证返回数据非空且格式正确异常时立即报告并停止。 # 二、变更分析要求五阶段递进分析 ## 阶段 1项目上下文建立 **目标**: 建立项目认知基线 执行动作 1. 查阅项目 CodeWiki 文档 2. 查阅需求文档如有 3. 查询项目知识库 4. 理解项目架构、代码组织结构、命名约定 5. 识别业务领域关键概念和术语 **注意**: 领域术语可能有特殊含义如 checkIn/checkOut 在不同业务中的含义差异必须结合上下文确认。 ## 阶段 2逐文件变更分析 **目标**: 对每个 diff 文件进行四维度分析 | 维度 | 分析内容 | |------|---------| | 代码变动点 | 精确标注新增/删除/修改的代码行及行号 | | 字段语义 | 推断新字段的业务含义结合注释和文档确认 | | 方法逻辑 | 描述涉及方法的功能、输入输出、实现逻辑 | | 调用关系 | 构建方法间、模块间的调用图谱 | **约束**: 忽略 _test.go 文件关键结论必须引用具体 文件路径:行号。 ## 阶段 3业务流程与数据生命周期分析 **目标**: 理解数据的完整生命周期 分析要点 - 数据从创建到消费的完整链路 - 数据流转中的状态变化 - 兜底逻辑和默认值处理 - 数据校验与转换节点 ## 阶段 4影响范围评估 **目标**: 多维度评估变更影响 影响分析树 ├── 影响的接口哪些 API 被修改URL 方法 ├── 影响的业务类型哪些业务场景受影响 ├── 影响的数据状态哪些状态流转被改变 └── 影响的具体字段哪些字段被新增/修改/删除 ## 阶段 5综合总结 **目标**: 结构化归总 - 按仓库分类变更内容 - 分析仓库间依赖和交互关系 - 整理 仓库 → detailUrl 映射 # 三、输出物 1变更分析评估报告 **格式**: Markdown **结构严格按序**: 1. 变更基本信息 2. 变更概述基于阶段 1 的项目认知 3. 变更文件详情分析基于阶段 2、3 4. 调用链路分析 5. 深度技术分析 6. 风险评估分级P0/P1/P2 7. 边界条件挖掘 8. 生产环境适配考量 9. 测试要点按优先级排序 10. 风险总结和建议 11. 变更链接汇总 # 四、测试用例设计三核心原则 七阶段流程 ## 三核心原则 | 原则 | 说明 | |------|------| | 前置条件分析 | 明确被测接口的数据准备链路哪些接口需要先调用、什么顺序 | | 完整业务链路 | 每个用例必须包含前置接口/条件 → 被测接口 → 验证结果 | | 三层覆盖策略 | 主流程 边界条件 异常场景缺一不可 | ## 七阶段执行流程 ### 阶段 1知识准备 - 基于变更分析阶段 1 的项目认知理解业务场景和规则 - 基于变更分析阶段 4 的接口维度确定被测接口集合 ### 阶段 2前置条件分析每个接口必答 对每个被测接口必须明确回答以下 4 个问题 Q1: 需要先调用哪些接口来准备测试数据 → 列出所有必需前置接口及其作用 Q2: 数据依赖关系是什么 → 绘制依赖链接口A → 接口B → 接口C → 区分强依赖必须和弱依赖可选 Q3: 哪些前置条件是必需的哪些是可选的 → 必需缺少则无法执行测试 → 可选用于构造特殊场景 Q4: 前置接口失败时被测接口应如何处理 → 验证异常处理和降级策略 ### 阶段 3完整业务链路设计 对每个接口按以下模板设计 ┌──────────────────┐ ┌──────────────┐ ┌──────────────────┐ │ 前置接口(数据准备) │ → │ 被测接口 │ → │ 验证结果 │ └──────────────────┘ └──────────────┘ └──────────────────┘ **示例**: 测试优惠选择功能 前置用户登录 → 优惠列表查询 → 订单详情获取 被测选择接口 验证返回结构检查 优惠金额计算 活动优先级判定 测试价格计算功能 前置活动配置 → 用户身份确认 被测报价接口 验证是否命中优惠 优惠金额 总金额正确性 ### 阶段 4三层覆盖策略 | 层次 | 说明 | 设计要点 | 示例 | |------|------|---------|------| | 主流程 | 正常业务场景 | 最常见的用户使用路径 | 正常登录→正常选择→正常下单 | | 边界条件 | 临界值场景 | 最大值、最小值、阈值临界点 | 金额0、数量1、版本阈值 | | 异常场景 | 错误处理场景 | 空值、超时、非法参数 | 负数金额、空token、超时响应 | ### 阶段 5服务交互验证 验证清单 ├── 下游服务返回的数据结构是否正确 ├── 上游服务最终命中的规则是否符合预期 ├── 返回结构完整性如 data.alternativeDiscounts ├── 优先级逻辑如 特价活动 其他优惠 └── 状态流转可用/不可用列表 ### 阶段 6测试数据规范 **强制要求**: 使用具体、可量化的测试数据。 ✅ 正确 - 普通补贴 10 元 叠加券 4 元 vs 返现补贴 10 元 - 特价补贴 8 元 vs 追价补贴 3 元 叠加券 4 元 - clientVersion5.2.0阈值 5.0.0时的行为差异 ❌ 禁止 - 测试优惠组合的 PK 逻辑模糊 - 测试不同版本的行为无具体值 - 测试金额计算逻辑无具体数据 ### 阶段 7用例知识融合 生成用例时必须结合 - 项目知识库中的业务规则 - 代码中的注释说明 - 文档中的约束条件 # 五、输出物 2测试用例文档 **格式**: Markdown.md **文档结构**: markdown # 测试用例文档 ## 接口 A: [接口名称] - **接口 URL**: [具体URL] - **接口方法**: [GET/POST/...] ### 正常场景 #### 前置条件 - 配置[具体配置项如满减/折扣/补贴/活动] - 登录[用户身份要求] - 数据准备[需要调用的前置接口及参数] #### 测试用例 | 用例编号 | 优先级 | 场景描述 | 测试数据(请求参数) | 预期结果 | |---------|--------|---------|-------------------|---------| | TC-A-01 | P0 | ... | {...} | ... | ### 边界场景 [同上结构] ### 异常场景 [同上结构] ## 接口 B: [接口名称] [同上结构] ## 风险与注意事项 - [风险点1] - [风险点2] # 六、全局约束强制执行 | 约束项 | 规则 | |--------|------| | 文件过滤 | 忽略所有 _test.go 文件 | | 代码引用 | 关键结论必须引用 文件路径:行号 | | 业务术语 | 使用业务领域专业术语不可自造术语 | | 完整链路 | 每个测试用例包含完整的前置条件和验证步骤 | | 优先级定义 | P0核心功能必须通过P1重要功能P2边界/异常 | | 数据具体性 | 测试数据必须具体可量化禁止模糊描述 | | 执行顺序 | 严格按步骤顺序执行不可跳步 | | 异常处理 | 工具调用失败时立即报告并停止 | | 知识融合 | 用例生成必须结合知识库、代码注释、文档 | # 七、最终自检清单生成输出前必须逐项确认 - [ ] 是否分析了业务语义字段在业务中的真实含义 - [ ] 是否梳理了完整的数据生命周期创建/流转/使用/销毁 - [ ] 是否明确了每个接口的前置接口数据准备链路 - [ ] 是否设计了完整业务链路前置 → 被测 → 验证 - [ ] 是否覆盖了三层主流程 边界条件 异常场景 - [ ] 是否引用了代码依据文件路径:行号 - [ ] 是否使用了正确的业务术语 - [ ] 是否忽略了单元测试文件 - [ ] 测试数据是否具体可量化 - [ ] 输出格式是否符合指定结构3.4 产出示例以「某业务修改动态规则描述」为例Agent 一次性产出两份文档先给一份高位的变更分析评估报告再给一份落地的测试用例文档。两份文档都是 Markdown可直接贴进工作项或协作文档评审。文档一变更分析评估报告示意图变更分析评估报告样例文档二测试用例文档示意图测试用例文档样例到这一步测试同学要做的只有一件事审校测试点。体感是80% 直接可用15% 微调5% 误报——而误报里有一半反向暴露了 PRD 的不严谨反推需求收敛。四、阶段二告诉 AI怎么测4.1 两步走先方案后代码最早我们让需求分析 Agent 一把梭直接出 Case 代码效果不好。框架细节是项目独有的模型对*TestBase层级、TestData/DataHelper/MockData分工没有先验一次性生成几百行代码人 Review 时被语法细节抓走忽略测试逻辑。阶段二拆成两个显式动作Step 1— 生成自然语言测试方案前置操作 / 步骤 / 断言方便人审Step 2— 方案确认后生成Case 代码走标准继承 标准 Client 六段注释通过失败通过测试点清单(测什么)代码生成 Agenttest-case 框架AGENT.md 框架历史 Case语义召回 Top-K自然语言测试方案人工 Review代码生成 Agent写 Case 代码mvn test 编译*Test.java 落盘4.2 上下文组装代码生成 Agent 启动时自动读AGENT.md获取项目骨架额外组装变更分析评估报告 测试点清单 自动化框架仓库召回的历史 Case。System Prompt 核心约束对应框架设计原则你是测试框架下的测试方案设计师与代码作者。铁律如下 1. 继承基于 {Domain}TestBase如 DomainXTestBase不得创建新基类 2. 数据常量从 {Module}TestData 取禁止硬编码 3. 操作Redis/DB 调用 {Module}DataHelper 静态方法 4. Mock从 {Module}MockData 取 5. 接口复用 apis.* Clientextends ApiV2Base禁止裸 OkHttp 6. IP从 getTestHost() / ServerIpDaily 取 7. 注释每条 Case 六段注释目标/场景/前置/步骤/预期/验证点 8. 不确定TODO(原因) 占位绝不臆造 9. 顺序先产出自然语言方案确认后再写代码4.3 中间产物自然语言测试方案示意图自然语言测试方案样例人 Review 只需读 30 行文字关注业务覆盖是否完整机器消费时每一句直接映射 Java 语句。写完后代码生成 Agent 自动跑mvn test编译/断言失败即回退到方案层重审。五、踩过的坑与最佳实践5.1 框架设计决定 AI 上限框架的AI 可理解程度直接决定 AI 生成代码的质量上限。入口统一、继承清晰、常量收敛、文档齐备——这四点做到位编译通过率可以稳定在 90% 以上。反之prompt 写得再好也是徒劳。5.2 三套辅助类是关键脚手架最初把数据常量、Redis 方法、Mock 构造揉在一个类里AI 无从判断用哪个方法。职责分离后选择路径确定查数据 → TestData操作数据 → DataHelperMock → MockData。几乎消灭了臆造方法名。5.3 上下文不是越多越好PRD 5 万字 diff 3000 行一股脑塞进去模型抓错重点。引入变更切片器按包路径白名单过滤 diff按章节锚点切 PRD控制在 8k token 以内召回率反而更高。追求相关上下文而非长上下文。5.4 测试方案用自然语言试过 YAML/JSON 中间层人被缩进干扰模型被压抑漏覆盖。自然语言格式与六段注释天然对齐模型生成代码时几乎是翻译工作量。5.5 让模型学会说不知道强制TODO(原因)占位后编译返工率从 28% → 6%。模型显式标注不确定远好过编一个看似合理但不存在的方法名。5.6 不要省略 Code ReviewAI 生成的 Case 仍走标准 MR 流程。CI 门禁任何 AI 生成的 Case 必须有人类 Reviewer 1不允许AI 写、AI Review、AI 合并闭环。
