AIAgent赋能工业级CI/CD：构建智能自愈的自动化测试体系

原创于 2026-07-04 16:15:19 发布 · 155 阅读

本内容遵循CC 4.0 BY-SA版权协议

1. 项目概述：当AIAgent遇上工业级CI/CD

最近在搞一个挺有意思的项目，核心是把AIAgent架构塞进我们团队的自动化测试流程里，目标是打造一个能自我学习、自我优化的工业级CI/CD集成方案。听起来有点玄乎？其实说白了，就是让测试流程“活”起来。传统的自动化测试脚本是死的，写好了就固定了，遇到UI稍微改个按钮位置、API字段名变一下，脚本就挂了，维护成本高得吓人。而AIAgent，你可以把它理解成一个有“脑子”的测试工程师，它能理解测试意图，根据应用的变化动态调整测试策略，甚至能自己发现一些我们没预料到的边界情况。

这个方案的驱动力很直接：研发效能和产品质量的双重压力。现在应用迭代快得飞起，一周一个版本是常态，靠人工点点点或者维护一堆脆弱的脚本，根本跟不上节奏。我们需要一个更智能、更健壮的“守门员”，在代码提交、构建、部署的每一个环节自动把关。AIAgent正好能扮演这个角色，它基于大语言模型（LLM）的理解和生成能力，结合传统的自动化测试框架（如Selenium、Playwright、Appium），形成了一套感知-决策-执行的闭环。这不仅仅是“自动化”，更是“智能化”的测试。

这套方案适合谁？首先是那些已经建立了基础CI/CD流水线，但被自动化测试脚本的脆弱性和高维护成本困扰的团队。其次，是对质量有更高要求，希望测试能覆盖更多场景、发现更深层次问题的中大型项目。当然，如果你对AI如何落地到具体工程实践感兴趣，这也是一个绝佳的观察窗口。接下来，我会拆解我们是如何设计这个架构，并把它无缝集成到工业级CI/CD流程中的，里面有不少踩坑经验和实操细节。

2. 核心架构设计与组件选型

2.1 AIAgent测试核心架构拆解

我们的AIAgent测试架构不是凭空造轮子，而是在经典的三层架构思想上进行的智能化演进。整体上可以分为 感知层、决策层、执行层 ，外加一个 记忆与学习层 构成闭环。

感知层 负责“看”和“听”。它的输入是多模态的：既包括传统的测试用例描述、需求文档（PDF/Word）、API接口文档（如Swagger），也包括通过Selenium、Playwright等工具实时捕获的应用程序UI截图、DOM树结构、网络请求日志，甚至是测试执行过程中的终端日志。这里的关键是，我们需要将这些非结构化的、多源的信息，转换成AIAgent能够理解的“上下文”（Context）。我们大量使用了像 mcp （Model Context Protocol）这类协议或自定义的适配器，将不同来源的数据标准化后喂给决策层。

决策层 是AIAgent的“大脑”，通常由一个或多个大语言模型驱动。它接收来自感知层的丰富上下文，然后进行推理和规划。它的核心任务包括：

测试用例生成与理解 ：根据需求变更或代码Diff，动态生成或调整测试步骤。例如，看到提交日志说“修改了登录按钮的CSS类名”，大脑会理解这属于UI变更，并决策需要更新哪些UI自动化测试脚本的定位器。
测试路径规划 ：面对一个复杂的业务流程，大脑会决定最优的测试执行顺序，或者当某个测试步骤失败时，规划备选的验证路径。
异常诊断与修复建议 ：当测试失败时，大脑会分析错误日志、截图对比等信息，判断失败原因是脚本问题、环境问题还是真实的缺陷，并尝试生成修复脚本或给出明确的排查建议。

执行层 是“手”和“脚”。它接收决策层发出的具体、可执行的指令（例如：“使用XPath //button[@data-testid='submit'] 点击”，“调用 /api/v1/login 接口并验证响应状态码为200”）。这一层与我们熟悉的自动化测试框架强绑定，比如用Selenium执行Web操作，用Requests库发送API请求，用Appium操控移动端。决策层下发的指令会被翻译成对应框架的底层代码并执行。

记忆与学习层 是让AIAgent变“聪明”的关键。它就像一个持续更新的知识库，记录了历史测试结果、常见的失败模式、修复方案、以及应用自身的特性（如哪些模块不稳定、哪些数据是测试专用的）。每次测试执行后，无论是成功还是失败，相关的上下文、决策和结果都会被结构化地存储起来。这些数据用于微调决策层的模型（或优化提示词工程），使得AIAgent在下一次遇到类似场景时能做出更准确、更高效的决策，实现闭环优化。

注意：在工业级场景中，我们通常不会在每次测试中都调用昂贵的GPT-4级别的模型。一种实用的架构是“大小模型结合”：轻量级、本地部署的小模型（或经过精调的专用模型）处理高频、确定性的决策（如元素定位）；而复杂、需要深度推理的任务（如失败根因分析）才交由云端大模型处理。这需要在成本、速度和准确性之间做好权衡。

2.2 关键组件与技术选型解析

选型决定了方案的可行性和后期维护成本。以下是我们在核心组件上的选择与思考：

AIAgent框架/平台 ：
- LangChain / LlamaIndex ：如果你的团队有较强的AI工程化能力，希望有最大的灵活性，这两个框架是首选。它们提供了丰富的工具链（Tools）、记忆（Memory）和智能体（Agent）抽象，可以自由地组合感知、决策、执行模块。但上手成本和维护复杂度较高。
- 商用AIAgent平台（如Codiumate、Test.ai） ：对于想快速启动、AI能力储备不足的团队，可以考虑成熟的SaaS或私有化部署平台。它们提供了开箱即用的视觉识别、自愈测试等功能，集成相对简单，但定制能力受平台限制，且可能有持续的费用。
- 我们的选择 ：基于可控性和长期演进的考虑，我们采用了 LangChain + 自定义工具 的方案。LangChain作为智能体编排的核心，我们围绕它开发了针对我们业务系统的专用“工具”，比如“查询订单状态工具”、“生成测试用户数据工具”。
自动化测试框架 ：
- Web UI测试 ： Playwright 是我们的首选。相比Selenium，它支持多浏览器（Chromium, Firefox, WebKit），自动等待机制更智能，录制和代码生成功能强大，且执行速度更快。它的 page.screenshot() 和 page.content() 能完美地为感知层提供输入。
- API测试 ： Pytest + Requests / HTTPX 是经典组合。结构清晰，夹具（fixture）机制非常适合管理测试生命周期和数据。我们将API测试也封装成LangChain的“工具”，供AIAgent调用。
- 移动端测试 ： Appium 依然是跨平台移动端自动化的主流选择。虽然配置稍复杂，但其“一次编写，多端运行”的理念和广泛的社区支持无可替代。
- 桌面端/其他 ：根据具体技术栈选择，如 PyAutoGUI 用于传统桌面应用。
大语言模型（LLM）集成 ：
- 云端模型 ： OpenAI GPT-4/GPT-3.5-Turbo 、 Anthropic Claude 3 、国内的通义千问、文心一言等。它们能力强大，适合复杂的推理和生成任务。关键是要设计好 系统提示词（System Prompt） ，将AIAgent的角色、职责、可用的工具、输出格式严格定义清楚。
- 本地模型 ：为了降低成本和处理敏感数据，我们也在探索使用 Llama 3 、 Qwen 等开源模型在本地部署。结合 LangChain 的 LLM 接口，可以轻松切换不同的模型提供商。对于测试结果分析、日志总结等相对简单的任务，70亿参数的模型在专用显卡上已经表现不错。
- 我们的策略 ：采用混合模式。日常的测试用例生成和简单决策使用经过精调的本地小模型或GPT-3.5-Turbo；对于复杂的失败分析和探索性测试规划，则使用GPT-4或Claude 3。
上下文管理与向量数据库 ：
- AIGent需要“记忆”。我们将历史测试用例、产品文档、错误解决方案等文本资料进行切片和向量化，存入 向量数据库 ，如 ChromaDB （轻量，易于集成）或 Pinecone （云端托管，性能好）。当AIAgent遇到问题时，它可以先从向量库中检索相似的历史案例和解决方案，这大大提高了决策的准确性和效率。

3. 工业级CI/CD流水线集成实战

设计好架构只是第一步，如何让它像流水线上的机械臂一样，在CI/CD流程中稳定、高效、无人值守地工作，才是真正的挑战。

3.1 流水线阶段设计与AIAgent触发机制

我们基于GitLab CI/CD（其他如Jenkins、GitHub Actions原理相通）设计了一套集成方案。核心思想是： AIAgent不是替代现有流水线阶段，而是增强它们 。

代码提交阶段（Pre-commit / Push Hook） ：
- 触发：开发者向特性分支推送代码。
- AIAgent动作 ：调用“代码变更分析工具”。该工具利用 git diff 获取代码变动，结合LLM分析这些变更可能影响哪些功能模块（例如：“修改了 UserService.login 方法” -> “可能影响登录流程”）。
- 输出：生成一份“受影响测试用例建议列表”。这份列表会以评论的形式自动提交到Merge Request中，提醒开发者和评审者关注相关测试。这实现了测试左移。
合并请求（Merge Request）阶段 ：
- 这是AIAgent活动的 主战场 。我们配置CI流水线在MR创建或更新时自动运行。
- 阶段一：智能测试用例选取与生成 ：
  - AIAgent根据“代码变更分析”的结果，从已有的测试用例库中 智能选取 相关的用例。同时，对于全新的功能点，它可以基于MR描述和修改的代码文件， 尝试生成 新的、基础的测试用例代码骨架（需要人工审核确认）。
- 阶段二：自适应测试执行 ：
  - 流水线启动一个包含AIAgent服务的测试执行环境（Docker容器）。
  - AIAgent接管测试执行。它不仅仅是按顺序跑脚本。例如：
    - 执行一个UI测试时，如果发现按钮的定位器失效（元素找不到），它会自动尝试其他定位策略（如通过文本内容、邻近元素等），并 记录这次修复 到知识库。
    - 遇到一个API测试失败（返回500错误），它会分析响应体，判断是测试数据问题还是服务端bug。如果是数据问题，它可能调用“数据清理与重建工具”后重试。
  - 所有执行过程、决策日志、截图都会被详细记录。
构建与部署后阶段（Post-deployment） ：
- 触发：代码合并到主分支并成功部署到预发或生产环境后。
- AIAgent动作 ：执行 关键业务流冒烟测试 。与MR阶段的测试不同，这里的测试更关注核心业务流程的畅通性，且测试数据会直接使用类生产环境数据（在安全合规的前提下）。AIAgent可以处理环境差异带来的微小变化。

3.2 关键配置与代码示例

以GitLab CI/CD为例，一个简化的 .gitlab-ci.yml 配置可能如下所示：

stages:
  - analysis
  - test
  - deploy
  - post-deploy

# 阶段1：代码变更智能分析
code_change_analysis:
  stage: analysis
  image: python:3.11-slim
  script:
    - pip install -r requirements-agent.txt
    - python ai_agent/change_analyzer.py --diff ${CI_COMMIT_SHA} --target-branch main
  artifacts:
    paths:
      - affected_tests.json
    when: always

# 阶段2：AIAgent驱动的智能测试
ai_agent_tests:
  stage: test
  image: mcr.microsoft.com/playwright/python:v1.40.0
  services:
    - name: chromedp/headless-shell:latest
  variables:
    LLM_API_KEY: $OPENAI_API_KEY # 密钥通过CI/CD变量注入
  script:
    - pip install -r requirements-agent.txt -r requirements-test.txt
    # 启动AIAgent服务，并传入变更分析结果
    - python ai_agent/orchestrator.py --config ci-config.yaml --affected-tests affected_tests.json
  artifacts:
    paths:
      - test-results/
      - agent-logs/
    reports:
      junit: test-results/junit-report.xml # 产出标准格式报告，方便GitLab展示
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

# 阶段3：部署与部署后测试
deploy_to_staging:
  stage: deploy
  script: 
    - ./deploy.sh staging
  environment:
    name: staging
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

smoke_test_staging:
  stage: post-deploy
  image: python:3.11-slim
  script:
    - pip install -r requirements-agent.txt
    - python ai_agent/smoke_runner.py --env staging --critical-flows flows/critical.json
  dependencies:
    - deploy_to_staging
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

AIAgent核心协调器（orchestrator.py）的简化逻辑：

import asyncio
from langchain.agents import initialize_agent, AgentType
from langchain.chat_models import ChatOpenAI
from tools.ui_test_tool import UITestTool
from tools.api_test_tool import APITestTool
from tools.diagnose_tool import DiagnoseTool
from memory.vector_store import VectorStoreMemory

class TestOrchestrator:
    def __init__(self, config):
        self.llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0, api_key=config.llm_key)
        self.tools = [UITestTool(), APITestTool(), DiagnoseTool()]
        self.memory = VectorStoreMemory.from_config(config)
        
        # 初始化LangChain智能体
        self.agent = initialize_agent(
            tools=self.tools,
            llm=self.llm,
            agent=AgentType.STRUCTURED_CHAT_ZERO_SHOT_REACT_DESCRIPTION, # 适合复杂工具调用
            verbose=True,
            memory=self.memory,
            handle_parsing_errors=True # 重要：优雅处理解析错误
        )
    
    async def run_test_suite(self, affected_tests):
        """执行测试套件"""
        for test in affected_tests:
            prompt = f"""
            作为QA AI助手，请执行以下测试任务：{test['description']}。
            测试类型是：{test['type']}。
            已知的应用入口点是：{test['entry_url']}。
            请规划步骤并执行，如果遇到失败，请尝试诊断并修复。
            """
            try:
                # AIAgent开始思考并调用工具执行
                result = await self.agent.arun(prompt)
                log_result(test['id'], 'SUCCESS', result)
            except Exception as e:
                log_result(test['id'], 'FAILURE', str(e))
                # 可以触发告警或更复杂的重试机制
                if is_critical(test):
                    notify_developers(test, e)

if __name__ == "__main__":
    orchestrator = TestOrchestrator(load_config())
    affected = load_affected_tests()
    asyncio.run(orchestrator.run_test_suite(affected))

3.3 环境隔离与资源管理

工业级集成的核心是稳定性，而稳定性离不开好的环境管理。

测试环境容器化 ：使用Docker Compose或Kubernetes定义一套完整的测试环境，包括被测应用、数据库、缓存、以及AIAgent服务本身。确保每次流水线启动的环境都是全新的、一致的。
AIAgent服务化 ：不要将AIAgent逻辑直接写在CI脚本里。应该将其构建为一个独立的微服务（或容器镜像），通过REST API或消息队列接收测试任务。这样便于升级、扩缩容和监控。
资源配额与限流 ：LLM API调用是核心成本点。必须在AIAgent服务层和CI流水线层设置严格的限流策略。例如，为每个MR的测试任务设置Token消耗上限和最大调用次数，防止异常情况导致巨额账单。
测试数据管理 ：这是最容易出问题的地方。AIAgent在执行中可能需要创建、修改数据。必须使用独立的测试数据库，并在每次测试套件执行前后进行数据快照恢复或使用事务回滚。我们专门为AIAgent开发了“测试数据工厂”工具，让它能按需生成合规且隔离的数据。

4. 核心挑战、解决方案与避坑指南

在实际落地过程中，我们遇到了不少坑，也总结出一些让方案更稳健的经验。

4.1 稳定性挑战：LLM的“幻觉”与不可控输出

问题：LLM可能会生成看似合理但完全错误的操作指令（幻觉），或者输出的格式不符合工具调用的要求，导致整个流程中断。

我们的解决方案 ：

严格的输出结构化（Output Parsing） ：强制要求LLM的回复必须遵循严格的JSON Schema。LangChain的


   StructuredOutputParser

和Pydantic模型是绝配。我们为每一个工具调用结果和最终答复都定义了清晰的结构。

from pydantic import BaseModel, Field
from langchain.output_parsers import PydanticOutputParser

class TestAction(BaseModel):
    tool_name: str = Field(description="要调用的工具名称")
    tool_input: dict = Field(description="工具的输入参数")
    reasoning: str = Field(description="选择此工具的原因")

parser = PydanticOutputParser(pydantic_object=TestAction)
prompt = PromptTemplate(
    template="...请按以下格式回复：\n{format_instructions}\n...",
    input_variables=["..."],
    partial_variables={"format_instructions": parser.get_format_instructions()}
)

工具设计的原子性与容错性 ：把工具设计得尽可能原子化和健壮。例如，“点击登录按钮”工具内部会封装多种定位策略和重试机制，即使AIAgent传递的定位器稍有偏差，工具本身也能尝试纠正。工具执行失败时，必须返回结构化的错误信息，而不是抛出异常导致智能体崩溃。
人工审核回路（Human-in-the-loop） ：对于AIAgent 新生成 的测试用例或 建议的重大修复 ，不直接应用到主流程。而是将其作为草案，通过CI流水线的报告或MR评论展示出来，必须由人工审核确认后才能合并或执行。这是一个关键的安全阀。

4.2 执行效率与成本控制

问题：AIAgent的“思考”过程（调用LLM）耗时较长，且API调用成本不菲，可能导致测试流水线时间从几分钟拉长到几十分钟。

我们的优化策略 ：

分层决策与缓存 ：
- 高频操作本地化 ：将元素定位策略、常见的页面对象映射等知识，通过精调小模型或甚至规则引擎（如XPath/CSS选择器优先级规则）来实现，避免每次都问LLM。
- 结果缓存 ：对于相同的测试上下文和指令，将其哈希后作为键，将LLM的决策结果缓存起来（例如使用Redis）。下次遇到相同情况直接使用缓存，极大减少LLM调用。
测试用例的智能筛选 ：不是每次MR都跑全量测试。AIAgent分析的“受影响测试用例列表”必须精准。我们结合代码静态分析（影响范围）和历史测试失败关联数据，对列表进行优先级排序，优先运行风险最高的测试。
设置超时与回退机制 ：为每个LLM调用设置严格的超时时间（如10秒）。如果超时或连续失败，则自动回退到预设的、传统的自动化测试脚本执行路径，保证流水线至少能以传统方式完成。

4.3 效果衡量与持续改进

如何证明AIAgent带来了价值？我们建立了几个核心指标：

测试脚本维护成本 ：统计每周因UI/API变更而需要手动修复的测试脚本数量，观察其下降趋势。
缺陷逃逸率 ：衡量流入生产环境的缺陷中，有多少本应在AIAgent增强的测试阶段被发现。这个指标需要长期跟踪。
测试执行通过率的稳定性 ：对比引入AIAgent自愈能力前后，同一套测试用例在非代码变更情况下的通过率波动情况。
平均故障诊断时间（MTTD） ：从测试失败到明确根因（是bug、环境问题还是脚本问题）的平均时间，看是否因AIAgent的辅助分析而缩短。

我们定期（如每两周）回顾这些指标，并分析AIAgent的决策日志。对于频繁出现误判或低效决策的场景，我们会将其作为“反面教材”加入到向量知识库中，或者用于优化系统提示词和工具设计，实现真正的持续学习。

5. 典型问题排查与实战技巧

在实际运行中，你会遇到各种稀奇古怪的问题。这里记录几个典型案例和解决思路。

5.1 问题：AIAgent陷入循环或执行无关操作

现象：在测试一个购物车流程时，AIAgent不断重复“点击商品详情页”和“返回列表页”的动作，就是不执行“加入购物车”。

排查：

检查决策日志，发现LLM每次生成的下一步动作都是“查看更多商品信息”。
分析感知层输入：发现提供给LLM的页面截图或DOM中，“加入购物车”按钮虽然存在，但可能被其他元素遮挡或状态为“禁用”（灰色），而我们的UI工具没有将这个状态信息（如 disabled 属性）有效地传递给LLM。
检查提示词：提示词中是否缺乏对“当前任务目标”的强约束？是否没有明确告诉AI“你的最终目标是成功加入购物车”？

解决：

增强感知层 ：修改UI测试工具，在捕获页面信息时，不仅抓取元素定位器，还要抓取其关键状态属性（如 enabled/disabled , visible/hidden , text ），并将其作为上下文的一部分清晰地传递给决策层。
优化提示词 ：在系统提示词中强化任务导向和约束。例如：“你当前的核心任务是完成‘将商品A加入购物车’的测试。请忽略无关的页面探索，专注于识别和操作与‘加入购物车’直接相关的元素。如果核心元素不可操作，请分析原因并报告。”
设置步骤限制 ：在智能体配置中，强制设置单个任务的最大步骤数（如20步），防止无限循环。

5.2 问题：LLM API调用超时或频次限制导致流水线失败

现象：CI流水线频繁在AIAgent测试阶段失败，日志显示“API Timeout”或“Rate Limit Exceeded”。

排查：

检查流水线并发数：是否同时有多个MR触发流水线，导致对LLM API的并发请求超过限制？
检查单个任务复杂度：是否某个测试场景过于复杂，导致AIAgent需要与LLM进行多轮对话（消耗大量Token和时间）？
检查网络稳定性：CI/CD运行环境到LLM服务提供商的网络是否存在波动？

解决：

实现队列与限流 ：在AIAgent服务前增加一个任务队列（如Redis Queue）。CI流水线将测试任务放入队列后立即返回成功，由后台Worker按可控的速率消费队列，执行任务并异步回写结果。这样既避免了CI超时，也控制了API调用频率。
任务拆分与简化 ：将复杂的端到端测试拆分成多个原子性的子任务。让AIAgent分别处理每个子任务，减少单次交互的复杂度和Token消耗。
配置重试与降级 ：在LLM客户端配置指数退避的重试机制。对于非关键路径的LLM调用（如测试结果的美化总结），可以设置失败后静默跳过，不影响核心测试逻辑。
使用更稳定的模型 ：对于要求高稳定性的生产流水线，可以考虑使用响应更稳定、速率限制更高的模型版本，或者部署私有化的模型服务。

5.3 问题：测试数据污染与依赖

现象：AIAgent执行测试时，因为使用了被其他测试修改过的数据，导致断言失败。或者，它创建的数据没有及时清理，影响了后续的测试。

排查：

检查测试数据隔离策略：是否每个测试套件或流水线运行都有独立的数据空间？
检查AIAgent的“数据工具”：它创建数据时，是否使用了唯一标识（如UUID）？清理数据时，是否能够精准地清理自己创建的部分？

解决：

强制数据隔离 ：为每条CI流水线分配一个唯一的执行ID（如 CI_PIPELINE_ID ）。所有AIAgent创建的数据，都打上这个ID作为标签。测试数据工厂在生成数据（如用户邮箱、订单号）时，也必须嵌入这个ID。
```
def create_test_user(pipeline_id):
    username = f"test_user_{pipeline_id}_{uuid.uuid4().hex[:8]}"
    email = f"{username}@example.com"
    # ... 调用API创建用户
    return username
```
实现数据生命周期管理 ：在AIAgent测试任务开始前，通过数据库夹具或API调用，准备基准测试数据。任务结束后，无论成功与否，都必须触发一个清理环节，删除所有带有本次 pipeline_id 标签的数据。这个清理环节最好做成一个独立的、高优先度的后台任务，确保执行。
教导AIAgent ：在系统提示词中明确告知AIAgent关于数据污染的严重性，并指导它优先使用“数据工厂工具”来获取干净的数据，而不是去操作可能被污染的数据。

6. 进阶优化与未来展望

当基础流程跑通后，可以考虑一些进阶优化来进一步提升效能。

视觉回归测试的集成 ：将AIAgent与视觉差分工具（如 pixelmatch 、 Applitools ）结合。AIAgent不仅可以执行功能操作，还可以在关键步骤后触发截图，并与基线图进行对比。当发现视觉差异时，AIAgent可以初步判断这是预期的UI更新还是缺陷，将可疑的差异报告给人工审核，大大减轻人工进行视觉回归测试的负担。

基于测试历史的预测性分析 ：利用记忆层积累的海量测试执行数据（成功/失败、耗时、资源消耗），训练一个预测模型。这个模型可以在代码提交后，预测本次变更可能导致哪些测试用例失败、失败的概率有多大，从而动态调整测试集的优先级和资源分配，实现更智能的测试资源调度。

多智能体协作测试 ：对于复杂的分布式系统，可以设计多个具有不同专长的AIAgent协同工作。例如，一个“前端智能体”负责UI交互，一个“API智能体”负责后端接口验证，一个“数据智能体”负责检查数据库状态。它们通过一个“协调员智能体”进行任务分发和信息同步，模拟真实的跨职能团队测试场景。

最后一点个人体会 ：引入AIAgent到自动化测试，不是一个一蹴而就的“替换”项目，而是一个“增强”和“演进”的过程。不要试图一开始就让它接管所有测试。从最痛的点开始（比如最脆弱的UI登录测试），让它解决一个具体的小问题，积累成功案例和团队信任。同时，管理好预期，它目前更像一个不知疲倦但需要严格指导和监督的初级测试工程师，它的价值在于处理重复、模糊和动态变化的场景，解放人力去做更有创造性的测试设计和探索。整个过程中，人的经验、判断和审核，依然是保证质量不可替代的最后一道防线。

标签

#AIAgent #CI/CD #自动化测试