AI测试 AI 驱动的下一代测试平台
原文地址：https://www.yuque.com/testdevops/devops/gk2qrcocuu4hm0gf
测试瓶颈
现状： 研发代码从单日人均几百行 ----> 单日人均几千行
产能扩大数十倍，在消费者不增长的情况下，现有消费者不同等提高消费力度，那么就出现了产能过剩，而产研测里面最终结果就是测试应付不过来。
测试的主要工作 (约占 80%)：
- 用例编写
- 用例执行（造数 + 执行等）
问题思考：
- 当下测试用例的编写和维护是否依旧是必须？
if (是)
方案一：提高编写和维护的速度（编写加速已经做了）
方案二：需要推翻传统用例的模式
- “测试用例 “ 是否依旧需要靠人执行
if(否)
方案：UI+AI 执行方式（正在做）
问题：
1. 低效
2. 对于部分用例的检查，并非是最佳或者唯一方式
经典测试理念
金字塔模型明确告知我们：测试的投入越底层越快，成本越低，那我们为何不借用 AI 强代码能力，更多的做单元测试！
问题的解决方法
- 推翻旧的用例设计模式，找到更快，更轻，更好维护的方式
- 引入更多 AI+ 执行用例的方式
- 准守金字塔理念，做更多的底层测试
核心思想：可被 AI 执行的质量契约
一句话：用"质量契约"替代"测试用例"，作为质量保障的核心资产。
传统模式：需求 → 人/AI 写测试用例 → 人/AI 自动化执行用例 → 结果 新模式： 需求 → AI 生成质量契约 → AI 自主执行契约验证 → 结果
测试用例和质量契约的区别
测试用例 = 绑定实现的操作步骤，描述"怎么一步步去验证"
质量契约 = 不绑定实现的业务规则，描述"系统应该满足什么"
举个例子:
需求要求：手机号 11 位
测试用例设计：因为代码对测试是黑盒，会 10 11 12 位 3 个用例去验证边界值，还一堆异常的等价类如特殊字符等验证
新质量契约就是：手机号强规则：必须等于 11 位数字。
同时质量契约包含检查方法，具体怎么验证由 AI 自己初步判断，检查方法三种：
- 读代码（类单元测试）
- 接口调用（接口测试）
- UI 测试
读代码能确认就读代码，读不准就调接口，必须看页面就操作页面，可以是一种或者多种组合，允许用户修改检查方法。
整体架构
┌─────────────────────────────────────────────────────────────────┐
│ │
│ AI驱动的测试平台 │
│ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ QA 工作台 │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ 契约管理 │ │ 验证报告 │ │ 发版决策 │ │ │
│ │ │ │ │ 审查中心 │ │ │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ 契约执行引擎 │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────────────┐ │ │
│ │ │ AI 验证决策器 │ │ │
│ │ │ │ │ │
│ │ │ 拿到一条契约 → 读契约内容 → 判断用什么方式验证 │ │ │
│ │ └──────────────────┬──────────────────────────────────┘ │ │
│ │ │ │ │
│ │ ┌──────────┼──────────┐ │ │
│ │ ▼ ▼ ▼ │ │
│ │ ┌────────────┐┌────────────┐┌────────────┐ │ │
│ │ │ AI Agent: ││ AI Agent: ││ AI Agent: │ │ │
│ │ │ 代码走查 ││ 接口测试 ││ UI测试 │ │ │
│ │ │ ││ ││ │ │ │
│ │ │ 读代码 ││ 调API ││ 操作页面 │ │ │
│ │ │ 判断逻辑 ││ 验证数据 ││ 验证交互 │ │ │
│ │ └────────────┘└────────────┘└────────────┘ │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ 基础能力层 │ │
│ │ │ │
│ │ Skills· MCP· WorkFolw · 代码仓库接入 · │ │
│ │ 知识库(RAG) · AI+UI自动化等 │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ 集成层 │ │
│ │ │ │
│ │ GitLab · 飞书 · CI/CD · 接口平台 · 企微等等 │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
质量契约结构设计
核心设计：质量契约分两层
契约分为"用户层"和"执行层"：
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 用户层（AI生成 → QA审核） │
│ ════════════════════════ │
│ · 业务规则：系统应该满足什么 │
│ · 验证方案：最佳验证方式（代码走查/接口测试/UI测试） │
│ · 边界提示：需要特别注意的边界情况 │
│ │
│ AI从需求中提取契约时，同时推荐每条契约的最佳验证方案 │
│ QA审核：确认规则对不对、验证方案合不合理，可调整 │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 执行层（AI自动执行） │
│ ════════════════════ │
│ · 验证目标：具体哪个文件/接口/页面 │
│ · 验证逻辑：具体怎么判断对错 │
│ · 测试数据：具体用什么数据验证 │
│ │
│ 特点：由AI根据代码仓库自动补全、并把每次执行过程完整记录 │
│ │
└─────────────────────────────────────────────────────────────────┘
为什么要分层：
· QA关注的是"规则对不对"和"验证方案合不合理"
· 不需要关注"AI去读哪个文件、调哪个接口"这些执行细节
· AI生成契约时就包含最佳验证方案的推荐，QA只需审核确认
· 执行细节（具体文件路径、接口地址、测试数据）由AI在运行时自动补全
用户层：AI 生成、QA 审核的契约
AI 从需求中提取契约时，每条契约自带规则 + 最佳验证方案，QA 审核确认：
一条契约的用户层结构（AI生成的草稿，QA审核）：
┌─────────────────────────────────────────────────────────────────┐
│ │
│ QC-ORDER-003 │
│ ───────────────────────── │
│ 模块: 订单 > 优惠券叠加 │
│ 级别: P0 │
│ │
│ 规则: │
│ 当同时使用满减券和折扣券时，计算顺序为先满减后折扣。 │
│ 即: 最终金额 = (原价 - 满减额) × 折扣率 │
│ │
│ 验证方案（AI推荐）: │
│ 📖 代码走查: 后端计算逻辑是否符合先减后折 │
│ 🔌 接口测试: 接口返回的金额是否计算正确 │
│ 🖥 UI测试: 确认订单页的优惠明细和金额展示是否正确 │
│ │
│ 推荐理由: 涉及资金计算(P0)，代码走查确认逻辑顺序， │
│ 接口测试验证精度边界，UI测试确认页面展示一致性 │
│ │
│ 边界提示: │
│ · 满减后金额刚好为0时，折扣结果也应为0 │
│ · 中间结果出现3位小数时的精度处理 │
│ │
│ 来源: PRD-2026-0892 │
│ 关联缺陷: BUG-2025-1234（历史精度问题） │
│ │
│ ── QA审核操作 ── │
│ [✓ 通过] [✏ 修改规则] [✏ 调整验证方案] [+ 补充契约] │
│ │
└─────────────────────────────────────────────────────────────────┘
QA审核的焦点：
· 规则提取得对不对？有没有遗漏或歧义？
· 验证方案合不合理？AI推荐的方式够不够、有没有多余？
· 边界提示全不全？有没有AI想不到但QA经验能补充的？
QA不需要操心的：
· 具体代码文件路径（AI运行时自动定位）
· 具体接口地址（AI从Swagger/代码中自动找）
· 具体页面路由（AI从前端代码中自动找）
· 具体测试数据（AI根据规则和边界自动构造）
AI 推荐验证方案的决策逻辑：
AI根据契约的规则类型，自动推荐最佳验证方案：
┌─────────────────────┬────────────────────────────────────────┐
│ 规则特征 │ AI推荐的验证方案 │
├─────────────────────┼────────────────────────────────────────┤
│ 纯逻辑判断 │ 📖 代码走查 │
│ (阈值校验/权限/幂等) │ 读代码就能确认，最快最准 │
│ │ │
│ 数值计算 │ 📖 代码走查 + 🔌 接口测试 │
│ (金额/精度/分摊) │ 走查确认逻辑，接口验证精度边界 │
│ │ │
│ 涉及前后端联动 │ 📖 代码走查 + 🔌 接口测试 + 🖥 UI测试 │
│ (展示/交互/一致性) │ 三层验证，确保前后端一致 │
│ │ │
│ 纯交互行为 │ 🖥 UI测试 │
│ (实时刷新/动效/状态) │ 必须操作页面才能验证 │
│ │ │
│ 非功能性 │ 🔌 接口测试（压测/并发） │
│ (性能/并发/稳定性) │ 必须实际运行 │
└─────────────────────┴────────────────────────────────────────┘
AI还会参考：
· 契约级别：P0 倾向多种方式交叉验证，P2 一种就够
· 历史缺陷：关联过线上Bug的契约，加重验证力度
· 变更风险：涉及资金/安全的，推荐更完整的验证组合
不同类型契约的示例：
┌─────────────────────────────────────────────────────────────────┐
│ │
│ QC-ORDER-004 │
│ 模块: 订单 > 优惠券叠加 级别: P0 │
│ │
│ 规则: 最多同时使用3张优惠券 │
│ │
│ 验证方案（AI推荐）: │
│ 代码走查: 是否有叠加数量的校验逻辑 │
│ 推荐理由: 纯阈值校验，读代码一眼就能确认 │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ QC-ORDER-009 │
│ 模块: 订单 > 页面交互 级别: P1 │
│ │
│ 规则: 选择优惠券后，订单金额实时刷新，不需要手动触发 │
│ │
│ 验证方案（AI推荐）: │
│ UI测试: 选券后页面金额是否立即变化 │
│ 推荐理由: 交互行为，必须操作页面才能验证 │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ QC-ORDER-012 │
│ 模块: 订单 > 性能 级别: P1 │
│ │
│ 规则: 下单接口P99延迟 < 500ms │
│ │
│ 验证方案（AI推荐）: │
│ 接口测试: 压测验证响应时间 │
│ 推荐理由: 性能指标，必须实际运行才能测量 │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ QC-REFUND-003 │
│ 模块: 退款 > 券返还 级别: P0 │
│ │
│ 规则: │
│ 退款时优惠券未过期 → 返还给用户 │
│ 退款时优惠券已过期 → 不返还 │
│ │
│ 验证方案（AI推荐）: │
│ 代码走查: 退款逻辑中是否有券过期判断 │
│ 接口测试: 分别用未过期和已过期的券退款，验证返还行为 │
│ 推荐理由: P0资金相关，走查确认逻辑存在，接口验证实际行为 │
│ │
│ 边界提示: │
│ · 退款时刻券刚好过期（边界秒级时间差） │
│ │
└─────────────────────────────────────────────────────────────────┘
执行层：AI 自动生成的验证计划
当契约被触发验证时，AI 根据用户层契约 + 代码仓库，自动生成执行层：
QC-ORDER-003 的执行层（AI自动生成，QA可查看但不需要手写）：
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 验证点 1/3: 代码走查 │
│ │
│ AI定位的目标代码: │
│ order-service/src/.../CouponCalculator.java (第48-65行) │
│ order-service/src/.../OrderService.java (第112-130行) │
│ │
│ AI生成的验证逻辑: │
│ 检查 applyReduction() 是否在 applyDiscount() 之前调用 │
│ 检查最终计算公式是否为 (price - reduction) * discount │
│ 反例: price * discount - reduction │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 验证点 2/3: 接口测试 │
│ │
│ AI定位的目标接口: │
│ POST /api/v1/orders │
│ 前置: POST /api/v1/coupons/create (准备测试券) │
│ │
│ AI生成的测试数据: │
│ 组1: 原价200, 满100减10, 8折 → 预期(200-10)×0.8=152 │
│ 组2: 原价100.01, 满100减10, 8折 → 预期72.008→72.01(精度) │
│ 组3: 原价50, 满50减50, 5折 → 预期(50-50)×0.5=0→触发下限 │
│ 组4: 反例对照: 验证≠先折后减的结果 │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 验证点 3/3: UI测试 │
│ │
│ AI定位的目标页面: │
│ /order/confirm 确认订单页 │
│ 定位元素: .coupon-detail, .total-amount │
│ │
│ AI生成的操作序列: │
│ 1. 打开确认订单页 → 记录原始金额 │
│ 2. 选择满减券 → 检查金额变化 │
│ 3. 选择折扣券 → 检查金额=先减后折的结果 │
│ 4. 切换优惠券 → 检查金额实时刷新 │
│ │
└─────────────────────────────────────────────────────────────────┘
这些内容全部由AI自动生成。
QA可以在验证报告中看到AI用了什么方式验证，但不需要预先定义这些。
用户层和执行层的关系
┌────────────────────────────────────────────────────────────────┐
│ │
│ AI生成 → QA审核的 AI运行时自动补全的 │
│ (用户层) (执行层) │
│ │
│ ┌─────────────┐ ┌──────────────────────────┐ │
│ │ 规则: │ │ 目标代码: │ │
│ │ 先满减后折扣 │ │ CouponCalculator.java │ │
│ │ │──── AI ───→│ OrderService.java │ │
│ │ 验证方案: │ 运行时 │ │ │
│ │ 📖🔌🖥 │ 自动补全 │ 目标接口: │ │
│ │ │ │ POST /api/v1/orders │ │
│ │ 边界提示: │ │ │ │
│ │ 精度、0值 │ │ 目标页面: │ │
│ └─────────────┘ │ /order/confirm │ │
│ │ │ │
│ AI生成 + QA审核 │ 验证逻辑、测试数据... │ │
│ QA花 2 分钟确认 │ AI花 5 秒自动生成 │ │
│ └──────────────────────────┘ │
│ │
│ │
│ 完整链路： │
│ │
│ 需求/PRD │
│ → AI提取契约（含规则+验证方案+边界提示） │
│ → QA审核确认（调整规则/验证方案/补充边界） │
│ → 代码变更触发 │
│ → AI根据验证方案调用对应Skill执行 │
│ → 执行细节（文件/接口/页面/数据）AI自动补全 │
│ │
└────────────────────────────────────────────────────────────────┘
三种验证方式
代码走查 (code_review)
AI读取相关代码，判断实现是否符合契约规则
适合: 逻辑判断类（计算顺序、阈值校验、权限检查、幂等控制...）
接口测试 (api_test)
AI自动找到接口定义，构造数据，调用接口，验证响应
适合: 数值验证、状态变更、跨服务集成、精度边界
UI测试 (ui_test)
AI自动定位页面元素，操作浏览器，检查页面状态
适合: 交互行为、页面展示、实时刷新、按钮位置等
AI 运行时补充验证（长远计划）
除了契约中已有的验证方案，AI 执行过程中可以自主追加：
场景: 验证方案只有 📖代码走查
CodeReviewSkill 执行完毕
│
├── 置信度 ≥ 90% → 直接通过，不追加
│
├── 置信度 60-90% → AI自动追加 🔌接口测试 做二次确认
│
└── 置信度 < 60% → 标记待QA人工介入
AI追加验证不需要QA审批，是AI对自身验证结果的自我补强。
契约执行引擎设计
引擎整体流程
事件触发（MR提交 / 手动触发 / 定时触发）
│
▼
┌──────────────────────────────────────────────────────────────┐
│ Phase 1: 契约匹配 │
│ │
│ 输入: 代码变更Diff（或指定模块） │
│ 处理: AI分析变更影响范围 → 匹配受影响的契约 │
│ 输出: 待验证契约清单 │
│ │
│ 例: MR#892 改了CouponCalculator │
│ → 命中 QC-ORDER-001 ~ QC-ORDER-012 共10条契约 │
└──────────────────────────┬───────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ Phase 2: 执行计划生成（AI自动完成） │
│ │
│ AI读取每条契约的"用户层"（规则+验证方案+边界提示） │
│ + 代码仓库信息（代码、接口定义、前端路由） │
│ → 自动生成"执行层"（目标文件/接口/页面、验证逻辑、测试数据）│
│ │
│ 例: QC-ORDER-003 验证方案含 📖🔌🖥 │
│ → AI自动定位到: │
│ 📖 CouponCalculator.java + OrderService.java │
│ 🔌 POST /api/v1/orders + 4组测试数据 │
│ 🖥 /order/confirm 页面 + 操作序列 │
└──────────────────────────┬───────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ Phase 3: Skill 执行 │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Skill 调度器 │ │
│ │ │ │
│ │ 📖 验证方案含代码走查 │ │
│ │ → 调用 CodeReviewSkill │ │
│ │ │ │
│ │ 🔌 验证方案含接口测试 │ │
│ │ → 调用 ApiTestSkill │ │
│ │ │ │
│ │ 🖥 验证方案含UI测试 │ │
│ │ → 调用 UiTestSkill │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ 执行策略: │
│ · 同一契约的多个验证方式并行执行 │
│ · 不同契约之间并行执行 │
│ · 📖 最快(秒级)，优先出结果 │
│ · 📖 置信度不够时自动追加 🔌 补充确认 │
└──────────────────────────┬───────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ Phase 4: 结果聚合 │
│ │
│ 对每条契约，聚合所有验证结论: │
│ │
│ · 全部通过 → 契约验证通过 ✅ │
│ · 任一失败 → 契约验证失败 ❌ （标记哪种验证方式发现的） │
│ · 有不确定 → 标记待人工确认 ⚠ │
│ │
│ 生成验证报告 → 推送到审查中心 │
└──────────────────────────────────────────────────────────────┘
三个 Skill 的详细设计
┌─────────────────────────────────────────────────────────────────┐
│ │
│ CodeReviewSkill（代码走查技能） │
│ │
│ 输入: │
│ · 契约规则 + 边界提示（来自用户层） │
│ · 契约所属模块信息 │
│ │
│ AI自主完成: │
│ 1. 根据契约模块和代码变更Diff，自动定位相关代码文件 │
│ 2. 读取代码，结合知识库中的历史缺陷模式 │
│ 3. 判断代码逻辑是否符合契约规则 │
│ │
│ 输出: │
│ · 结论: pass / fail / uncertain │
│ · 证据: 代码位置 + 逻辑分析 │
│ · 置信度: 0-100 │
│ │
│ 示例: │
│ { │
│ "conclusion": "pass", │
│ "evidence": "CouponCalculator.java:52-53, │
│ applyReduction()先于applyDiscount()调用， │
│ 符合先满减后折扣规则", │
│ "confidence": 95 │
│ } │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ApiTestSkill（接口测试技能） │
│ │
│ 输入: │
│ · 契约规则 + 边界提示（来自用户层） │
│ · 契约所属模块信息 │
│ │
│ AI自主完成: │
│ 1. 根据模块自动找到相关接口定义(Swagger/代码注解) │
│ 2. 根据契约规则和边界提示，构造测试数据(通常3-10组) │
│ · 正常值 + 边界值 + 特殊值 + 历史踩坑值 │
│ 3. 如需前置数据，AI读代码理解依赖关系后自动准备 │
│ 4. 调用接口，用规则独立计算预期值，和实际响应对比 │
│ │
│ 输出: │
│ · 结论: pass / fail / error │
│ · 证据: 每组数据的请求/响应/预期vs实际对比 │
│ │
│ │
│ 示例: │
│ { │
│ "conclusion": "fail", │
│ "test_results": [ │
│ {"input": {"price":100.01, "reduction":10, "discount":0.8},│
│ "expected": 72.01, "actual": 72.008, │
│ "result": "FAIL", "detail": "中间结果未四舍五入"}, │
│ { ... "result": "PASS" }, │
│ { ... "result": "PASS" } │
│ ] │
│ } │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ UiTestSkill（UI测试技能） │
│ │
│ 输入: │
│ · 契约规则 + 边界提示（来自用户层） │
│ · 契约所属模块信息 │
│ │
│ AI自主完成: │
│ 1. 根据模块自动找到相关页面路由和前端代码 │
│ 2. 理解页面结构和元素定位 │
│ 3. 根据契约规则生成操作序列 │
│ 4. 通过Playwright无头浏览器执行操作，检查页面状态 │
│ (简单场景生成脚本执行，复杂交互用Browser-Use Agent直接操控) │
│ │
│ 输出: │
│ · 结论: pass / fail / error │
│ · 证据: 操作步骤 + 每步的状态检查 + 截图/录屏 │
│ │
│ │
│ 示例: │
│ { │
│ "conclusion": "pass", │
│ "steps": [ │
│ {"action": "勾选满减券", │
│ "check": "金额从200变为190 ✅"}, │
│ {"action": "勾选折扣券", │
│ "check": "金额从190变为152 ✅ (先减后折正确)"} │
│ ], │
│ "screenshots": ["step1.png", "step2.png"] │
│ } │
│ │
└─────────────────────────────────────────────────────────────────┘
三个Skill的共同特点:
· 输入都只需要"契约用户层"的信息（规则+边界提示+模块）
· "去哪找代码/接口/页面"由Skill自己根据代码仓库推断
· QA不需要告诉AI具体的文件路径、接口地址、页面路由
质量契约从需求到执行的完整链路
质量契约生命周期
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ 生成 │────→│ 审查 │────→│ 激活 │────→│ 运行 │
└────────┘ └────────┘ └────────┘ └────────┘
│ │
│ ▼
│ ┌────────┐
│ │ 反馈 │
│ └────┬───┘
│ │
│ ┌────────┐ ┌────────┐ │
└─────────│ 演进 │←──────|向量落库 |←───────┘
└────────┘ └────────┘
各阶段说明：
生成: 新需求/新PRD → AI自动提取契约草稿
审查: QA审查AI提取的契约，确认/修改/补充
激活: 契约进入活跃状态，代码变更时自动触发验证
运行: MR提交 → 匹配契约 → 调用Skills执行验证 → 出报告
反馈: 验证发现问题 → 确认Bug/更新契约/补充知识库
向量落库：版本结束后，归档质量契约
演进: 业务规则变化 → 修改契约 / 线上缺陷 → 新增契约
一个需求从提出到上线的完整流程
① 产品提交PRD（优惠券叠加功能）
│
▼
② AI 从 PRD 自动提取契约（含规则+验证方案+边界提示）
┌──────────────────────────────────────────────────┐
│ AI提取了12条契约，每条自带验证方案: │
│ │
│ QC-ORDER-003 先满减后折扣 │
│ 验证方案: 📖代码走查 + 🔌接口测试 + 🖥UI测试 │
│ 推荐理由: P0资金计算，需三层验证 │
│ │
│ QC-ORDER-004 最多叠加3张 │
│ 验证方案: 📖代码走查 │
│ 推荐理由: 纯阈值校验，读代码即可 │
│ │
│ ... 共12条契约 │
└──────────────────────────────────────────────────┘
│
▼
③ QA 审核契约
· 确认10条的规则和验证方案，没问题
· 修改1条规则（AI提取的精度规则不完整，补充了舍入方向）
· 调整1条验证方案（AI只推荐了代码走查，QA觉得应加接口测试）
· 新增1条契约（AI没提取到退款返券场景）
│
▼
④ 契约激活，进入待验证状态
│
▼
⑤ 开发完成，提交CICD
│ (CICD自动触发)
▼
⑥ 契约执行引擎运行（全自动）
· 影响分析 → 命中10条契约
· AI自动生成执行计划(定位代码/接口/页面)
· 📖 代码走查 → 全部
· 🔌 接口测试 → 全部
· 🖥 UI测试 → 全部
· 2个走查置信度不够 → AI自动补充接口测试
│
▼
⑦ 验证报告推到审查中心
┌──────────────────────────────────────────────────┐
│ MR#892 契约验证报告 │
│ │
│ ✅ 9条通过 ❌ 1条违反 │
│ │
│ 违反: QC-ORDER-003 │
│ 🔌接口测试失败: │
│ 原价100.01 + 满减10 + 8折 → 实际72.008 │
│ AI定位: CouponCalculator.java:82 精度未处理 │
│ │
│ [确认Bug →] │
└──────────────────────────────────────────────────┘
│
▼
⑧ QA 确认Bug，AI 自动创建缺陷单
│
▼
⑨ 开发修复，重新提交MR → CICD → 引擎再跑一遍 → 全部通过
│
▼
⑩ QA 在决策中心做发版决策
· 12条契约全部验证通过
· QA做了探索式测试+核心流程验证，无阻塞问题
· 结论: 可以发版
│
▼
⑪ 上线
平台功能设计
平台模块
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 模块一：契约管理 │
│ ─────────────── │
│ · 契约看板：按模块查看所有契约及其验证状态 │
│ · 契约编辑：创建/修改/归档契约的规则和验证意图 │
│ · AI提取：上传PRD → AI自动生成契约草稿(用户层) → QA审查 │
│ · 代码提取：指定代码仓库 → AI逆向提取业务规则为契约 │
│ · 批量导入：从已有测试用例中提炼契约（迁移用） │
│ │
│ 模块二：验证报告 & 审查中心 │
│ ─────────────── │
│ · 验证报告列表：每次CICD的验证报告 │
│ · 报告详情：每条契约的验证结论、AI证据、置信度 │
│ · 快速操作：确认Bug / 更新契约 / 标记忽略 │
│ · 历史追溯：某条契约的历史验证记录和通过率趋势 │
│ │
│ 模块三：发版决策 │
│ ─────────────── │
│ · 质量信号灯：聚合所有契约验证结果 │
│ · 契约覆盖率：变更代码被多少契约覆盖 │
│ · 未覆盖代码：哪些代码没有任何契约管控 │
│ · Go/No-Go 操作 │
│ │
│ 模块四：知识库 │
│ ─────────────── │
│ · 历史缺陷模式：供AI生成契约和验证时参考 │
│ · 系统上下文：服务依赖、数据库Schema等 │
│ · 每次确认的Bug自动沉淀为缺陷知识 │
│ │
│ 模块五：设置 │
│ ─────────────── │
│ · 仓库接入配置（GitLab/GitHub） │
│ · Swagger/接口文档接入 │
│ · 测试环境配置（API地址、前端地址） │
│ · LLM 模型配置 │
│ · Webhook/通知配置 │
│ │
└─────────────────────────────────────────────────────────────────┘
契约管理界面
┌─────────────────────────────────────────────────────────────────┐
│ 契约管理 │
│ │
│ 项目: [订单服务 ▼] [+ 新建] [AI从PRD提取] [AI从代码提取] │
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 下单流程 · 12条契约 · 覆盖率100% │ │
│ │ │ │
│ │ ┌──┬──────────────┬────┬──────────────┬────┬───────────┐│ │
│ │ │ │ 契约 │ 级别│ 验证方案 │状态│ 最近验证 ││ │
│ │ ├──┼──────────────┼────┼──────────────┼────┼───────────┤│ │
│ │ │01│ 金额精度2位 │ P0 │ 📖+🔌 │ ✅ │ 2h前 通过 ││ │
│ │ │02│ 金额计算公式 │ P0 │ 📖+🔌 │ ✅ │ 2h前 通过 ││ │
│ │ │03│ 先满减后折扣 │ P0 │ 📖+🔌+🖥 │ ✅ │ 2h前 通过 ││ │
│ │ │04│ 最多叠加3张 │ P0 │ 📖 │ ✅ │ 2h前 通过 ││ │
│ │ │05│ 金额下限≥0.01│ P1 │ 📖 │ ✅ │ 2h前 通过 ││ │
│ │ │06│ 折扣券互斥 │ P0 │ 📖+🖥 │ ✅ │ 2h前 通过 ││ │
│ │ │07│ 未登录不能下单│ P0 │ 📖 │ ✅ │ 2h前 通过 ││ │
│ │ │08│ 库存不足拦截 │ P0 │ 📖+🔌 │ ✅ │ 2h前 通过 ││ │
│ │ │09│ 选券金额刷新 │ P1 │ 🖥 │ ✅ │ 2h前 通过 ││ │
│ │ │10│ 互斥券自动取消│ P1 │ 📖+🖥 │ ✅ │ 2h前 通过 ││ │
│ │ │11│ 下单幂等 │ P0 │ 📖+🔌 │ ✅ │ 2h前 通过 ││ │
│ │ │12│ P99<500ms │ P1 │ 🔌 │ ✅ │ 2h前 通过 ││ │
│ │ └──┴──────────────┴────┴──────────────┴────┴───────────┘│ │
│ │ │ │
│ │ 📖=代码走查 🔌=接口测试 🖥=UI测试 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
│ 退款流程 · 8条契约 · 覆盖率87% │
│ └── ... │
│ │
│ 积分抵扣 · 8条契约 🆕 · AI提取待审查 │
│ └── ... │
│ │
└─────────────────────────────────────────────────────────────────┘
验证报告详情
┌─────────────────────────────────────────────────────────────────┐
│ 验证报告 · MR#892 · 优惠券叠加功能 │
│ │
│ 触发: MR合入 时间: 2026-02-27 10:32 总耗时: 67s │
│ 命中契约: 10条 通过: 9 失败: 1 │
│ │
│ ┌──── 失败项（需QA确认）────────────────────────────────────┐ │
│ │ │ │
│ │ ❌ QC-003 先满减后折扣 │ │
│ │ │ │
│ │ ├── 📖 代码走查: ✅ 通过 (置信度95%) │ │
│ │ │ 代码中调用顺序正确: applyReduction先于applyDiscount │ │
│ │ │ │ │
│ │ ├── 🔌 接口测试: ❌ 失败 │ │
│ │ │ 测试数据: 原价100.01 + 满减10 + 8折 │ │
│ │ │ 预期: 72.01 实际: 72.008 │ │
│ │ │ 原因: 中间计算结果未做精度舍入 │ │
│ │ │ 定位: CouponCalculator.java:82 │ │
│ │ │ │ │
│ │ └── 🖥 UI测试: ✅ 通过 │ │
│ │ 页面展示金额为72.01（前端做了格式化，掩盖了后端问题） │ │
│ │ │ │
│ │ AI分析: │ │
│ │ 代码走查发现逻辑顺序正确，但接口测试在精度边界场景 │ │
│ │ 发现中间步骤精度丢失。前端做了toFixed(2)格式化所以 │ │
│ │ 页面看不出，但后端存入数据库的值是错的。 │ │
│ │ │ │
│ │ ● 确认Bug → [创建缺陷单] │ │
│ │ ○ 不是Bug → [原因说明] │ │
│ │ ○ 需确认 → [转交] │ │
│ │ │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
│ ┌──── 通过项（折叠，可展开查看）───────────────────────────┐ │
│ │ ✅ QC-001 金额精度 · 📖95% · 🔌PASS .............. 7s │ │
│ │ ✅ QC-002 金额计算 · 📖80%→🔌补充→98% ........... 10s │ │
│ │ ✅ QC-004 最多叠加3张 · 📖96% .................... 2s │ │
│ │ ✅ QC-005 金额下限 · 📖93% ....................... 1s │ │
│ │ ✅ ... │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
技术架构
┌─────────────────────────────────────────────────────────────────┐
│ 技术架构 │
│ │
│ 前端: Vue3 + TypeScript │
│ · 契约管理界面、验证报告、决策面板 │
│ │
│ 后端: Java (Spring) │
│ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ 核心服务: │ │
│ │ · contract-service 契约CRUD、版本管理 │ │
│ │ · engine-service 契约执行引擎、Skill调度 │ │
│ │ · report-service 验证报告生成、审查流程 │ │
│ │ · knowledge-service 知识库管理、RAG检索 │ │
│ │ · integration-service 外部系统集成(Git/乐享/企微/飞书等) │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
│ AI层: │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ · LLM Gateway 多模型路由(GPT-4o/Claude/DeepSeek) │ │
│ │ · CodeReviewSkill 代码走查能力 │ │
│ │ · ApiTestSkill 接口测试能力 │ │
│ │ · UiTestSkill UI测试能力(Playwright，Agent Browser)│ │
│ │ · ContractExtractor 从PRD/代码提取契约 │ │
│ │ · ImpactAnalyzer 变更影响分析 │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
│ 数据: │
│ · PostgreSQL 契约、报告、项目配置 │
│ · Redis 缓存、执行锁 │
│ · Milvus 知识库向量检索 │
│ · MinIO 截图、录屏等测试产物 │
│ │
│ 部署: Docker Compose（初期）→ K8s（规模化后） │
│ │
└─────────────────────────────────────────────────────────────────┘
一句话总结
这个平台做的事：
需求 → AI提取质量契约（含规则+最佳验证方案） → QA审核确认
→ 代码变更自动触发 → AI按验证方案调用Skill执行（走查/调接口/操作页面）
→ 结果推给QA做最终判断
契约分两层:
用户层 = AI生成、QA审核的：业务规则 + 验证方案（📖🔌🖥）+ 边界提示
执行层 = AI运行时自动补全的：具体文件/接口/页面/测试数据
平台不管理"测试用例"。
平台管理"质量契约"——系统应该满足什么规则、用什么方式验证。
AI负责：从需求提取契约、推荐验证方案、执行验证、输出结论。
QA负责：审核契约和验证方案、确认AI结论、做发版决策。
「All right reserved, any unauthorized reproduction or transfer is prohibitted」
对
软件测试开发阿森
回复
软件测试开发阿森
回复
嗯， 我这比很多大厂更激进， 我把传统用例的设计也颠覆， 应该生成更适合 AI 去检查的用例，而不应该还像以前那样黑盒的用例设计思路。 这个很重要，这个可以少很多用例量。
让 AI 自主读代码、做接口和 UI 测试的话，有试过准确率和 token 消耗量吗？
大佬公司内实践了么？这看上去是 ai 生成的计划文档，看不出是总结还是规划
可以直接落实到地么
不太理解，ai 审查代码的话主要应该审查些什么内容呢，对于我的一个 case 他能找到对应的代码文件和方法吗，在这个过程中感觉就很容易出错啊，而且通篇 ai 来做应该很耗 token
这个方案很有前瞻性，很多大厂已经这样做了，完全可以实现，只是时间问题
对
layla735
回复
layla735
回复
你问问研发， 他们用 cursor codex cc 配合上 当前的 opus 4.7 , gpt5.5 等， 他们 AI 生成后多少代码能用， 这个比例值是巨高的， 那做功能模块都行，那让去检查某个功能点岂不是更容易？
对
软件测试开发阿森
回复
软件测试开发阿森
回复
嗯， 我这比很多大厂更激进， 我把传统用例的设计也颠覆， 应该生成更适合 AI 去检查的用例，而不应该还像以前那样黑盒的用例设计思路。 这个很重要，这个可以少很多用例量。
对
软件测试开发阿森
回复
软件测试开发阿森
回复
当然，这个是基于还有 QA 这个角色前提下的设计， 我都认为 这个角色很快都无了， 如果无了， 就没必要这个平台了，对吧。 看看 codex + chatgpt 5.5 这种组合， 已经能自己写代码， 部署，测试，修复 bug ，继续下个迭代， 跑个几天几夜都不带停的，直到最后把功能交付给你。