智能测试规模化落地

智能测试规模化落地

模型能理解需求、生成步骤、分析结果，却不一定能把一次测试跑完。决定智能测试能否规模化的，往往是模型之外的能力：稳定操作设备、配置环境、取得测试数据、调用业务平台、验证结果，以及让这些能力进入日常研发流程。可以把模型的生成、理解和推理能力视为“大脑”，把可调用、可恢复、可观测的工程能力视为“手脚”。

先定位瓶颈：不要把工程缺口误判成模型问题

接上模型或 API 后效果仍不理想，常见原因是执行链路不完整：模型知道下一步要做什么，却无法连接设备、准备账号、调整开关或读取数据库；即使能执行，也未必能判定结果是否正确。更换更强的模型无法自动补齐这些条件。

定位问题应从真实用例和执行数据开始：哪些用例失败最多，失败发生在场景识别、操作、环境准备还是结果验证？优先补影响面最大的缺口，再复测转化率和成功率。单点 Demo 在演示环境里能跑通，只证明一个场景可行，不能代替真实回归用例的覆盖与稳定性。

GUI Agent：把“看、想、做、验”接成闭环

GUI 测试不能只统计 Agent 会不会点击。一个用例同时包含场景（模型需要看懂的界面）和操作（模型需要做出的动作）；任一维度不支持，整条用例就可能无法转化。可把用例分为完全可转化、部分可转化、已有其他自动化覆盖而无需转化、暂不可转化四类。

一次场景与操作交叉盘点给出的结果是：可转化约20%、部分可转化约1%、无需转化约9%、暂不可转化约70%。这组比例反映的是该批用例的分类，不应推广为通用成功率。暂不可转化的用例又指向几类具体缺口：配置与业务平台、抓包和日志等工具、设备环境，以及登录、冷启动、上下滑、长按、双击等基础操作适配。70% 的价值在于指出下一步该补什么。

工程实现上，平台能力层把白名单、开关、Push、Mock、账号与 RN 预加载等接口前置；核心执行循环把自然语言任务拆成子任务，用视觉信息理解界面、生成动作，再通过 ADB 执行；质量层负责子任务断言、失败归因和重试。只让模型输出点击序列，没有环境控制和独立验证，很难形成可靠闭环。

“找朋友”功能测试展示了完整路径：用例平台生成指令和实验、设备、用户参数；测试计划触发引擎；Agent 注入变量，按需配置 RN 预下载、测试环境、AB/开关、业务平台和 Mock；随后执行交互、生成报告并清理环境。执行阶段把子任务循环成“看截图 → 想动作 → 做操作 → 验结果”，失败时回到质量层，而不是无条件继续点击。案例中的 17 个子任务和所加载的 Skill 数量是具体实现细节，不能直接当作所有 GUI 用例的成本或效果。

服务端测试：从“夹心自动化”走向全链路

服务测试的深层瓶颈是“夹心自动化”：AI 可以调用中间的几个接口，但前面仍需人工改配置、拨 AB 开关、准备多角色账号，后面还需人工查数据库、验证缓存和 MQ 消息。手工测试和一次性脚本因此都难沉淀为可复用能力。

KATFlow 将需求文档或代码变更作为输入，让推理层负责理解需求、拆解目标、选择工具、判断结果；AI Infra 提供配置、账号、数据库、网络接口、缓存、消息队列和文件等系统能力；数据构造侧提供场景数据检索、生成与校验。输出不止是生成的用例或代码，还包括执行报告、缺陷清单和可回归资产。

整个流水线分成八个阶段：项目初始化、用例生成、质量门禁、上下文补全、规范加载、测试类生成、执行与验证、报告交付。把阶段和能力分开，有利于在生成代码前拦截低质量用例，而不是等执行失败后再反复修补。门禁要检查接口是否真实存在、断言是否对应真实返回值，以及枚举或配置是否与仓库一致。

工程能力被封装成 Skill：例如修改配置和 AB 开关、准备登录账号、查询数据库、检查缓存或 MQ。每个 Skill 内给出调用示例、输入和结果约束，让模型按需调用，避免把每个平台的私有接口硬编码进提示词。这里的关键不只是“能调接口”，还包括权限边界、环境隔离、幂等、结果校验和失败后的清理。

复杂测试数据还需要持续积累。做法是先扫描仓库建立结构化索引，运行时检索已有方法与数据构造模式，需求结束后把新增方法增量写回索引，再通过索引、代码与文档的一致性检查防止失效。图中列出的候选覆盖、Token 节约、去重与腐化发现比例属于该方案展示的阶段性指标，应按实际查询集和统计口径复核。

电商售后“申请即退”案例进一步说明这条链路：输入需求和代码变更，生成用例并通过门禁，结合仓库规范生成测试类，执行后把新数据构造方法纳入可复用资产。案例展示了 24 个用例逐一检查、18 个有效用例导入、发现 7 个缺陷，以及总耗时估算从 4 人日降至 2 人日；这些是该案例的展示结果，不能直接推断其他业务的平均收益。

智能压测：让分析接上真实链路数据

季度例行压测重复劳动多：链路拓扑、限流阈值和隔离策略分散在多个平台，方案每次要重新收集；压测中还要人工反复核对风险，报告也容易漏掉下游影响。模型能分析这些信息，但只有通过 OpenAPI 等接口取得当前数据，才能形成可信的方案与报告。

压测助手用模型理解链路、解释结果、提出建议；通过 MCP 连接的接口获取三级链路拓扑、限流阈值、隔离策略和系统监控数据。方案生成阶段逐接口检查策略与阈值，并提前提示可能的限流风险；报告阶段结合压测 QPS 与预期 QPS 判断容量目标、排查未达标是否由下游引起，给出建议的最优 QPS 和不同可用区的流量均衡情况。阈值调整、最终容量判断和风险接受仍需要人工把关。

流程重塑：让能力在正确的时间自动进入

单点工具齐备之后，还需要改变需求与测试的交接方式。新的路径从需求创建和待预评审开始，经过待排期、待测试、测试完成；需求或变更状态触发模型介入，自动识别风险、生成和分级用例，按分类唤起服务测试或 GUI 测试，并在完成时自动下发检查清单。

用例分为资金类、核心类和普通类：资金类由 QA 守住关键路径；核心类和普通类更多交给研发与 AI 自测。这里的“测试左移”并非把人工判断全部移走，而是把重复执行、准备与流转前置，把 QA 的精力集中到高风险评估、规则制定和关键链路签收。若只是加入更多工具，却仍靠人工逐项触发、收集和分派，规模化收益会受流程瓶颈限制。

用统一口径判断下一轮该补什么

不同类型智能测试应使用不同指标，避免把“生成了多少”误写成“测试有效”。一组线上统计以 2026 年第二季度数据的均值为口径，但不同指标仍要分别核对样本范围、分母和对照组。

可复用的迭代顺序是：看执行数据 → 找最大能力缺口 → 把能力封装成 Skill → 接入流程 → 再看数据。更远的方向是让测试能力进入研发 Coding Agent 的循环，使问题在代码阶段被发现并回传；把状态驱动的协作推广到更多业务；让 QA 更多承担 Agent 开发、效果评估和业务质量专家的角色。前提始终是可验证的执行链路与清楚的责任边界。