作者｜沙丘智库研究团队

来源｜沙丘社区（www.shaqiu.cn）

AI Coding正在加快软件研发的生产节奏。过去以周为单位完成的代码开发，正在被压缩到小时级甚至分钟级。当代码生产不再是主要瓶颈，测试、需求确认、问题归因和线上反馈开始更直接地影响整体交付效率，企业质量工程需要从局部测试提效转向研发全流程的持续反馈。

传统自动化测试主要依赖脚本、XPath、配置文件或录制回放，由测试人员预先定义操作路径、测试数据和断言规则。面对高频产品迭代、多端多机型适配和长链路业务流程，静态脚本容易失效，维护成本随覆盖范围快速增加；即使测试用例能够自动执行，“测什么”“如何规划路径”“失败原因是什么”等工作仍高度依赖人工。

测试智能体推动测试工作流从预设脚本执行升级为测试意图理解、自主规划、环境感知、动态执行、专业断言和失败归因，使质量保障从“自动执行已有用例”进一步走向“Agent理解测试目标并形成反馈闭环”。

沙丘智库通过深度研究腾讯、小红书、58同城等企业的测试智能体落地实践，旨在为其他企业提供参考。

▎案例1：腾讯测试智能体TestMate实践

腾讯面向AI Coding加速后研发瓶颈向测试与反馈环节转移的问题，构建测试智能体TestMate，将规格、感知、执行、记忆、断言、归因和可观测能力纳入质量闭环，探索持续反馈的下一代质量工程体系。

腾讯将Harness Engineering理解为一套控制系统。前馈控制由知识、规则、提示词、代码风格、质量策略和任务规范等Guides构成，在智能体执行前限定目标和行为边界；反馈控制由单元测试、接口测试、代码检查、行为测试、运行状态和线上信号等Sensors构成，在执行后提供验证结果、证据和改进方向。确定性反馈负责明确规则和固定步骤，推理型反馈负责理解复杂语义和不完整信息，两类能力共同形成持续校正的质量循环。

TestMate支持目标式探索和规格化输入两类模式。目标式输入只提供较抽象的任务目标，由智能体自行理解、规划和执行，适用于路径未知或希望发现意外问题的探索性测试；规格化输入则通过BDD、测试契约等方式描述前置条件、操作和预期结果，智能体按照既定规格执行，适用于常规回归与明确业务流程。两种模式分别保留智能体的探索空间与生产测试所需的可控性。

在GUI感知环节，TestMate采用多层互补策略：优先读取Web DOM、Android可访问树等结构化界面信息；结构化信息不足时，由视觉小模型补充环境描述；页面变化复杂或需要综合语义判断时，再调用多模态大模型。完成感知后，系统通过统一抽象将业务动作映射为Web、移动端等不同平台的点击、输入和滑动指令，在跨端复用与底层适配之间建立隔离。

测试智能体不仅需要完成操作，还要判断系统行为是否符合预期。TestMate将短期记忆、长期记忆和业务知识库分类管理，并针对不同断言选择确定性规则或大模型语义判断，保留执行步骤、状态、失败原因和验证证据。落地过程中，腾讯先以种子用例验证基础能力，再扩展同类任务，依次补偿用例可执行性、治理稳定性和优化效率，并通过Token消耗、单次成本、成功率和失败分布等可观测数据持续改进系统。

▎案例2：小红书GUI Agent工程落地实践

小红书传统UI自动化已经具备较高覆盖率，但脚本编写和维护仍需要资深测试人员。Android、iOS、鸿蒙及大量机型进一步放大了适配复杂度，产品迭代后静态路径容易被破坏。与此同时，测试执行仅占测试人员约一半时间，如果不能同时解决测试规划、用例设计和经验沉淀问题，单纯提高执行自动化率难以充分释放人力。

围绕执行稳定性和上下文管理两类问题，小红书采用三层分离方案。第一层根据PRD、代码或设计稿理解测试意图，分析要测什么以及风险点是什么；第二层结合页面功能描述和操作地图探索并生成可泛化用例；第三层只负责把具体用例稳定执行。上游Coding Agent承担探索和泛化，下游轻量GUI Agent接收尽量准确的自然语言用例，以较低成本完成执行。

这一分层将灵活性与确定性拆开处理。每一层只消费完成当前任务所需的上下文，并将产物传递给下一层，使任务逐步收敛。生成后的用例只需调用一次上游生成链路，后续会固化为脚本和执行文件；进入回归阶段后，系统主要消耗底层视觉小模型的执行成本，不再反复调用Coding Agent生成用例。

为了减少路径迷失、经验分散和上下文过载，小红书将测试知识集中到大仓，通过Markdown、Skill、分支和MR机制进行维护，并按测试专家、产品和具体需求划分知识生命周期。系统还构建了包含一千多个页面和数万条边的页面路径图谱：经过验证的确定路径优先使用，推测路径携带置信度，执行成功的路径经过审核后回写图谱，使真实测试过程持续转化为可复用资产。

2026年春节大促期间，小红书自动化用例覆盖率约为75%，AI生成用例占所有人工编写用例的比例约为92%，具体可执行覆盖率约为66%。在知识与路径持续沉淀后，存量用例和存量路径约达到95%，用例执行稳定性约达到98%。这一实践表明，企业落地GUI Agent不能只追求用例生成数量，还需要通过分层架构、知识治理和路径管控，把生成能力转化为稳定、可复用的自动化产能。

▎案例3：58同城客户端智能化测试实践

58同城质量团队长期使用传统UI自动化开展回归测试和线上巡检，但脚本维护成本高，对业务变化和多端差异的适配压力较大，整体通常只能覆盖全流程的40%至60%。在交易履约等百级步骤长链路中，纯ReAct方式还可能因上下文压缩、知识匹配偏差或模型推理波动，在执行数十步后偏离测试目标。

为兼顾路径确定性与页面适应能力，58同城将Plan模式和ReAct模式动态结合。业务地图和知识库为Plan提供完整业务路径，并在失败时为自愈提供依据；规划完成后，再由ReAct逐步观察当前页面、判断状态并执行操作。通过全局规划约束方向、局部推理处理变化，系统最终稳定性达到约85%。

客户端测试的核心不是让模型完全自由探索，而是用业务流程模板约束关键交易链路。系统优先匹配业务地图中的核心路径，无法匹配时再由知识库或大模型生成候选路径。模板中可以加入断言节点和参数化配置，先调用数据构造接口准备特定商品或业务数据，再执行消费侧流程，从而保证测试订单沿预期入口和场景生成，而不是随机选择一条能够完成操作的路径。

在设备执行层，58同城将Android、iOS和鸿蒙三端能力封装为Skills，统一提供点击、滑动、输入等基础操作，并允许业务线动态扩展定制能力。系统主要通过截图获取元素定位特征，在出现弹窗或元素识别失败时进入自愈流程；同时对上下文进行剔除和切片，只保留后续步骤所需信息，将单步反馈控制在5至8秒。

目前，该体系已用于回归测试、渠道包验证和生产巡检，并推广至4个BG、11个项目。约85%的稳定性已经能够支撑大量业务场景，Android、iOS和鸿蒙均支持远程调用；本地设备还可以无线注册到云端，由服务器统一调度多台设备并行执行。58同城的实践说明，测试智能体的规模化落地既依赖模型决策，也依赖业务流程模板、可复用Skills、多端适配和失败可回溯的工程闭环。


内容来源：沙丘智库，更多内容可前往【沙丘智库小程序】搜索查阅