实习结束了，我用 Agent 搭建测试平台帮助部门提高了效率

实习结束的时候，我交付的不是几份测试报告，而是一套能持续跑、能复用用例、能把失败原因整理出来的 Agent 测试平台。它把部门原来需要人工整理、人工执行、人工截图、人工复盘的一部分黑盒回归流程，压缩成了“选择需求、生成/复用用例、自动执行、自动归因、人工确认”的闭环。

这篇我不写公司名，也不会写业务细节。数据和模块名都做了脱敏处理，但是口径保留：我负责的核心链路里面，P0/P1 场景的回归准备时间从原来的半天到一天，降到通常 30 分钟以内；主流程冒烟从人工 2 到 3 小时，变成平台 20 分钟左右出第一版报告；新需求测试用例沉淀率从“测完散落在文档里”，变成每次执行都能进入用例库、缺陷库和失败样例库。

我真正的收获不是“我用了 Agent”。而是我第一次把 Agent 放进一个有历史包袱、有多人协作(外委+内部)、有发布压力的测试流程里，逼自己处理数据准备、环境隔离、用例版本、失败归因、报告可信度和人工确认这些问题。

我接手的不是新项目，而是一个业务很重的老平台(架构很乱，公司内部人员，公司外包人员，甚至还有其他项目组的开发)

前两周我主要在熟悉部门的系统架构、业务名词、发布流程和测试流程。这个阶段不适合急着写代码。老平台最难的地方不是技术栈，而是业务隐含规则太多。

一个按钮能不能点，取决于用户角色、流程状态、历史配置、上游审批结果、下游任务是否创建成功。很多页面看起来只是表单，背后实际串着多个接口和异步任务。

第三周开始，我被安排介入一个老平台的新需求测试开发。需求本身不算夸张，但它改到了核心流程。原来的测试方式大概是：

需求评审后，测试同学整理测试点
根据历史 Excel / 文档翻旧用例
手工准备账号、权限、测试数据
人工执行页面和接口检查
截图、贴日志、写测试结论
失败时找开发一起看接口、日志和数据库状态
上线前再做一轮主流程回归

这个流程能工作，但成本很高。最痛苦的是重复劳动：同样的登录、建单、审批、状态流转、结果校验，每次新需求都会再测一遍。不同同学写用例的粒度也不一样，导致后面复用很困难。

我一开始的任务只是补新需求相关测试。但做了几天后，我发现如果只补几条用例，实习结束后价值会很快消失。真正值得做的是把“这次测试中反复出现的动作”抽出来，做成一个能继续被部门使用的平台。

我先明确边界：Agent 不直接替代测试同学

我没有把目标定成“让 Agent 自动测试一切”。这个说法听起来厉害，实际很不可靠。

我给平台定的边界是：

Agent 负责:
理解需求文本和历史用例
拆测试点
匹配已有用例
生成候选用例和执行计划
调用自动化工具执行
整理失败证据和初步归因

确定性程序负责:
接口调用
UI 操作
断言
数据准备
权限校验
报告生成
任务调度

测试同学负责:
确认测试范围
审核高风险用例
判断业务语义是否正确
确认缺陷是否成立
决定是否放行

这条边界很关键。Agent 最适合处理语义上模糊、文本很多、需要归纳的部分；不适合直接承担“这个发布能不能上”的责任。

所以平台不是一个会自己乱点页面的机器人，而是一套带 Agent 的测试工作台。Agent 帮我把需求、接口、页面、历史用例和失败日志串起来，真正执行和判断仍然落在可验证的测试脚本、断言和人工确认上。

平台的核心目标是减少三类浪费

我没有一上来追求覆盖率数字，而是先问测试流程里最浪费时间的地方在哪里。

第一类浪费是用例准备。每次新需求都要重新翻历史文档，找哪些主流程受影响，哪些边界要测，哪些角色要覆盖。很多知识在测试同学脑子里，很少沉淀成结构化资产。

第二类浪费是重复执行。P0 主流程每次都要测，但人工执行容易疲劳，截图和记录也不稳定。某些步骤并不难，只是长、繁琐、依赖前置状态。

第三类浪费是失败复盘。自动化脚本失败后，如果只给一个红色结果，测试同学还要自己翻接口响应、页面截图、日志片段和数据库状态。失败不等于缺陷，可能是环境、数据、权限、脚本或真实代码问题。

我做的平台就围绕这三件事：

需求进入后，Agent 帮忙拆测试点和匹配历史用例
执行时，平台用 pytest / Playwright 跑接口和 UI 场景
失败后，Agent 读取结构化证据，给出可审查的归因建议

它不是替代测试流程，而是把流程里最容易重复、最容易漏、最容易记不清的部分固定下来。

技术选型：用成熟测试工具做执行层，Agent 只做编排和归因

平台没有选择“让大模型直接控制浏览器自由探索”。2026 年 2 月这个时间点，已经有很多 Agent 工具能操作浏览器或电脑，但在公司测试平台里，我不敢把它作为主执行路径。

原因很简单：测试需要可重复。今天点这一步，明天也要点这一步；失败时要知道是哪个 selector、哪个接口、哪个断言。让模型直接看页面再决定点哪里，演示很好看，但回归测试不稳定。

所以执行层我选成熟工具：

接口测试:
pytest + requests/httpx + 参数化数据

UI 冒烟:
Playwright，使用 locator、trace、截图和视频

报告:
Allure Report + 自定义 Markdown 摘要

调度:
公司已有 CI / 定时任务入口，平台只做任务编排和结果归档

后端:
Python FastAPI，负责用例管理、任务触发、结果查询和 Agent 编排

存储:
关系型数据库保存用例、任务、执行记录、失败样例和需求映射

Agent:
工具调用 + JSON Schema 输出 + RAG 检索历史用例和接口说明

这些工具都不是新鲜玩具。pytest 的 fixture 和参数化适合处理测试数据组合，Playwright 本身支持现代 Web E2E 测试、并行执行、trace 和 HTML report，Allure 适合把测试步骤、附件和结果展示给非开发同学看。

Agent 层不直接决定“测试是否通过”。它只生成候选计划、候选用例、失败摘要和归因建议。最终通过与否由断言和人工确认决定。

平台架构：四层，尽量让每层可替换

我把平台拆成四层。

┌──────────────────────────────────────────┐
│  测试工作台                                │
│  需求选择 / 用例审核 / 执行报告 / 失败归因  │
└──────────────────────────────────────────┘
                    │
┌──────────────────────────────────────────┐
│  Agent 编排层                              │
│  拆测试点 / 匹配用例 / 生成计划 / 归因建议  │
└──────────────────────────────────────────┘
                    │
┌──────────────────────────────────────────┐
│  测试执行层                                │
│  pytest 接口测试 / Playwright UI 冒烟       │
└──────────────────────────────────────────┘
                    │
┌──────────────────────────────────────────┐
│  资产与证据层                              │
│  需求、接口、用例、数据、日志、截图、trace   │
└──────────────────────────────────────────┘

这样拆的好处是，Agent 不是平台的唯一核心。即使某天换模型，下面的用例库、执行器和报告仍然能工作。即使 Agent 暂时不可用，测试同学也可以手动选择用例执行。

我没有把平台做成“聊天框”。聊天框很灵活，但测试平台需要结构化输入输出。用例、任务、报告、失败记录都必须能查询、能复用、能统计。

Agent 的输出也必须是结构化的，例如：

{
  "test_points": [
    {
      "title": "不同角色提交后状态流转正确",
      "risk": "P0",
      "related_cases": ["case_102", "case_118"],
      "missing_cases": ["异常审批回退后再次提交"]
    }
  ],
  "execution_plan": {
    "reuse_cases": ["case_102", "case_118"],
    "generate_candidates": ["异常审批回退后再次提交"],
    "needs_human_review": true
  }
}

这让平台可以检查字段、存数据库、展示给测试同学审核，而不是只能把一段自然语言粘到文档里。

第一阶段：把历史用例和需求说明变成可检索资产

平台最开始不是写 Agent，而是整理资料。

部门里已经有很多历史用例，但形态不统一：有 Excel，有文档，有测试报告，有 issue 评论，还有一些只存在于自动化脚本里的逻辑。Agent 如果直接读这些杂乱资料，很容易把旧规则和新规则混在一起。

我先做了一个轻量的用例模型：

用例标题
业务模块
风险等级
前置条件
测试步骤
测试数据
预期结果
关联接口
关联页面
自动化状态
最近执行结果
维护人

不是所有历史资料都能完整填满这些字段，但先统一结构，后面才能复用。

然后我做了两类检索。

第一类是关键词和元数据检索。比如按模块、接口名、页面名、风险等级、执行状态过滤。这部分不需要大模型，普通数据库查询和文本搜索就够。

第二类是语义检索。需求描述经常不会写历史用例里的原词，比如需求写“撤回后再次提交”，旧用例写“驳回重提”。这时向量检索能帮助找相似用例。但我没有只相信向量分数，最终展示时仍然会给出来源和匹配理由。

这一阶段最直接的效果是：测试同学不用从多个文档里翻旧用例。输入需求描述或模块名，平台能先列出可能相关的 P0/P1 用例和缺口。

第二阶段：把接口黑盒测试做成可参数化执行

老平台的很多核心逻辑通过接口体现。UI 只是入口，真正要验证的是状态、权限、流程流转和下游任务是否创建。

我没有一开始就写大量 UI 自动化。UI 自动化很直观，但维护成本也高。对于核心业务，我先把接口黑盒测试做起来。

接口用例设计成三层：

业务场景:
用户从创建到提交到审批到完成

接口步骤:
login -> create -> submit -> approve -> query_status

断言:
响应码、业务码、状态字段、关键数据落库结果、下游任务状态

pytest 的 fixture 很适合处理前置数据。比如测试用户、权限、基础配置、临时单据都可以做成 fixture。参数化则用来覆盖不同角色、不同流程配置、不同异常输入。

我写了一套用例 DSL，不复杂，大概是：

case_id: case_102
title: 主流程提交后状态正确
risk: P0
steps:
  - tool: api.login
    as: user_a
  - tool: api.create_order
    data: fixture.basic_order
  - tool: api.submit
  - tool: api.query_status
assertions:
  - path: $.status
    equals: SUBMITTED
  - path: $.nextNode
    equals: APPROVE

执行器把它转成 pytest case。这样测试同学不用每次写 Python，也能维护一部分标准黑盒用例。

Agent 在这里的作用不是“自动发请求”，而是根据需求生成候选 DSL，再由人审核。审核通过后进入用例库。这样用例资产会随着需求累积，而不是测完就散。

第三阶段：UI 冒烟只覆盖真正必要的路径

UI 自动化我做得比较克制。

我没有把所有页面操作都自动化。老平台页面多、表单多、权限多，如果全面铺 UI case，维护成本会很快超过收益。

我只选了几类 UI 冒烟：

登录和角色切换
核心入口是否可达
P0 主流程页面能否完成提交
关键按钮权限是否符合角色
核心列表和详情页能否正常打开

Playwright 的 locator、auto-waiting、trace、截图和视频对这类场景很有用。失败时不仅有断言错误，还能看到页面停在哪一步。

UI case 采用 Page Object 的简化版本，把页面操作封装起来：

LoginPage.login()
HomePage.openModule()
OrderPage.fillBasicInfo()
OrderPage.submit()
DetailPage.expectStatus()

这样业务用例不会被 selector 淹没。页面改版时，也尽量只改 Page Object。

Agent 在 UI 层主要做两件事。

第一，根据需求判断是否需要 UI 冒烟。如果只是后端字段校验变更，不一定要跑 UI；如果入口、权限、页面状态有变化，就加入 UI 场景。

第二，失败后读取 Playwright trace、截图名称、控制台错误和接口响应摘要，给出初步归因。例如是按钮不存在、接口 500、等待超时、权限不符合预期，还是测试数据没准备好。

第四阶段：失败归因比自动执行更有价值

自动化测试跑红以后，如果只是生成一个红色报告，价值只有一半。

我把失败分成几类：

环境失败:
测试环境不可用、登录失败、依赖服务超时

数据失败:
前置数据缺失、状态不符合预期、账号权限不对

脚本失败:
selector 失效、断言写错、fixture 没清理

接口失败:
HTTP 错误、业务码异常、字段缺失

业务回归:
核心状态流转、权限、下游任务不符合预期

执行器会把证据结构化保存：

失败步骤
请求参数脱敏摘要
响应状态码和业务码
关键字段 diff
页面截图
Playwright trace
pytest traceback
相关日志片段
历史同类失败

Agent 读取这些证据，输出归因建议：

{
  "failure_type": "data_failure",
  "confidence": "medium",
  "reason": "前置单据状态为 DRAFT，但用例预期从 APPROVING 开始执行审批",
  "evidence": ["step_03.query_status", "fixture.order_state"],
  "suggested_action": "重新生成审批前置数据，或检查 fixture 清理逻辑"
}

我要求归因必须引用证据，不能只写“可能是环境问题”。如果证据不足，就输出“不确定，需要人工确认”。

这部分实际提效很明显。以前自动化失败后，测试同学要自己翻日志。现在平台先把失败类型和证据整理出来，人工只需要确认是否成立。

Agent 生成用例时，我加了三道闸

让 Agent 生成测试用例很容易，难的是不要生成一堆看起来合理但没法执行的用例。

我加了三道闸。

第一道是 schema。Agent 必须输出固定字段：前置条件、步骤、测试数据、预期结果、风险等级、可自动化程度。字段缺失就不能入库。

第二道是可执行性检查。比如步骤里引用的接口必须存在，测试数据 fixture 必须能生成，断言字段必须来自接口响应或页面状态。否则用例只能作为人工测试建议，不能进入自动化队列。

第三道是人工审核。P0/P1 用例必须由测试同学确认。Agent 可以建议“这个需求影响 P0 主流程”，但不能自己把风险等级定死。

这样做会牺牲一些自动化速度，但换来可信度。部门使用测试平台，最怕的是自动生成一堆垃圾用例，最后大家不信它。宁可慢一点，也要让每条入库用例能解释来源和执行条件。

平台实际跑起来后的提效口径

我把效果分成四类统计，避免只说“效率提升很多”。

第一，回归准备时间。

以前新需求评审后，测试同学通常要花半天到一天整理影响范围和历史用例。平台上线后，输入需求描述和模块信息，Agent 会先给出相关 P0/P1 用例、缺口和建议执行计划。人工仍然要审核，但准备时间通常能压到 30 分钟以内。

第二，执行时间。

核心主流程原来人工冒烟大概需要 2 到 3 小时，而且中间容易被打断。平台把接口主流程和少量 UI 冒烟拆开跑，常规场景 20 分钟左右能出第一版结果。复杂数据准备或环境不稳定时会更久，但至少报告和证据自动归档。

第三，失败复盘时间。

以前一次失败可能要测试、开发一起看半小时，才能判断是环境、数据还是代码问题。平台做结构化证据和 Agent 初步归因后，常见数据问题和脚本问题能在几分钟内定位。真正需要开发介入的失败，也能带着请求、响应、截图和日志过去，而不是只说“我这里点不动”。

第四，用例资产沉淀。

实习结束前，我把新需求相关的核心用例、历史 P0 用例和这段时间发现的失败样例统一放进平台。脱敏后统计，平台沉淀了几十条可复用主流程/接口用例、上百个参数化检查点，以及一批失败归因样例。数量不是最重要的，重要的是它们能继续被跑、继续被改、继续被统计。

如果用一句话概括效果：测试同学没有少做判断，但少做了大量重复查找、重复执行和重复整理证据的工作。

当然也要避免“为了展示效果”而夸大 Agent 能力

Agent项目最容易写成“用 AI 大幅提升效率”。这句话很危险，因为上手用过就会明白其中的限制。

所以我在平台里刻意保留几个限制。

第一，Agent 不直接修改正式用例。它生成候选，用例入库需要审核。

第二，Agent 不判断发布是否通过。它只整理证据和建议，放行仍然是测试负责人决定。

第三，Agent 不直接访问生产数据。测试数据来自测试环境和脱敏 fixture，敏感字段在进入日志和模型上下文前会过滤。

第四，Agent 不自由执行 SQL 或 shell。它只能调用平台注册的工具，例如检索用例、读取接口说明、触发测试任务、查询脱敏日志摘要。

第五，所有 Agent 输出都保存版本。包括模型版本、提示词版本、用例版本、执行任务 ID 和引用证据。出了问题能复盘。

这些限制让平台少了一点“自动化魔法”，但更像真实能用的系统。

我遇到的第一个坑：历史用例本身并不可靠

一开始我以为只要把历史用例喂给 Agent，它就能帮忙复用。实际很快发现，历史用例质量差异很大。

有些用例只写“验证审批通过”，没有前置条件，没有角色，没有预期状态。有些用例已经过期，页面和接口都改过。还有些用例是针对历史 bug 的临时检查，不能当成当前规则。

如果不清洗，Agent 会把旧规则当成新规则，把模糊用例生成得更正式。这样反而危险。

我后来给用例加了状态：

active:
当前可用，可以参与推荐

candidate:
新生成或未审核，只能作为建议

deprecated:
历史遗留，不参与自动推荐

manual_only:
可人工参考，但不可自动执行

Agent 检索时只能优先使用 active 用例。引用 candidate 或 deprecated 用例时，必须在结果里标出来。这一点很重要：RAG 不是把所有资料塞进去，而是要知道资料的可信度。

第二个坑：测试数据比测试步骤更难

测试里，步骤通常能写清楚，数据才是最难的。

同一个接口，在不同用户、不同状态、不同配置下行为完全不同。测试数据如果不可控，脚本就会 flaky。Agent 生成再漂亮的步骤，如果前置数据不稳定，执行照样失败。

我专门做了测试数据层：

基础字典数据:
相对稳定，由环境初始化维护

账号和角色:
固定测试账号，权限变化有版本记录

业务单据:
通过 API 创建，执行后清理或标记

异常数据:
单独 fixture，不和正常主流程混用

fixture 会返回结构化对象，而不是让用例自己拼参数。这样断言能引用同一份数据，失败时也能知道数据从哪里来。

Agent 生成用例时，不能随便编数据。它只能从 fixture catalog 里选择已有数据模板，或者生成“需要新增 fixture”的建议。新增 fixture 仍然要人工审核。

这个设计减少了很多不稳定失败。测试平台真正难的不是让脚本跑起来，而是让它下周、下个月还能跑。

第三个坑：自动归因不能太自信

Agent 做失败归因时，很容易写得像结论。

比如接口返回 500，它可能说“后端服务异常”。这句话太粗。500 可能来自真实 bug，也可能是测试数据不合法、环境依赖挂了、权限 token 过期。

我把归因输出改成三段：

已确认事实:
接口 /api/submit 返回 500，响应 traceId 为 xxx

可能原因:
上游配置缺失，或服务端未处理当前状态

建议动作:
先用 traceId 查服务日志；如果日志显示 NullPointer，再提交缺陷

并且要求 confidence 只能是 low、medium、high。高置信度必须满足明确证据，例如“同一 fixture 重跑 3 次稳定失败，且接口业务码与历史缺陷一致”。

这样 Agent 不会把猜测包装成结论。测试同学也更愿意相信它，因为它知道什么时候该说“不确定”。

第四个坑：平台要融入已有流程，而不是另起炉灶

一开始我想做一个完整的新平台，从需求到用例到报告都在里面。后来发现这不现实。

部门已经有自己的需求管理、缺陷流转、CI、发布流程。如果我做一个全新的入口，大家需要额外维护一套东西，实习生离开后很可能没人用。

所以我把平台定位成“测试工作台”，而不是替代现有系统。

需求来源:
从现有需求文档或需求编号导入摘要，不替代需求平台

执行入口:
接入已有 CI / 定时任务，不替代流水线

缺陷流转:
生成缺陷草稿和证据包，不直接替代缺陷平台

报告:
输出 Allure / Markdown / 链接摘要，方便贴回现有流程

这让落地阻力小很多。测试同学不用迁移工作习惯，只是在原流程里多了一个能帮忙准备和归因的工具。

我负责的具体工作

如果把工作拆开，我主要做了这些：

1. 梳理测试流程和 P0/P1 主链路
2. 设计用例数据模型和风险等级字段
3. 整理历史用例，做状态标记和结构化入库
4. 搭建 FastAPI 后端，提供任务、用例、报告接口
5. 封装 pytest 接口执行器和 fixture 管理
6. 封装 Playwright UI 冒烟执行器
7. 设计 Agent 工具注册、JSON Schema 输出和证据引用规则
8. 做 RAG 检索历史用例、接口说明和失败样例
9. 接入报告生成，把截图、trace、日志摘要归档
10. 做失败归因分类和人工确认流程
11. 写平台使用文档和交接说明

其中最难的不是某一段代码，而是把这些东西接成闭环。

只写 pytest 脚本，无法解决用例沉淀；只做 Agent，无法保证执行稳定；只做报告，无法减少准备时间。平台有价值，是因为它把需求、用例、执行、证据、归因和复用连起来了。

我怎么证明平台真的有用

我没有只拿一次演示证明效果，而是用几个口径持续看。

执行口径:
任务数、用例数、通过率、失败类型分布、平均执行时间

用例口径:
新增候选用例、审核通过用例、废弃用例、复用次数

归因口径:
Agent 初步分类和人工最终分类的一致率

效率口径:
需求测试准备时间、失败定位时间、回归执行时间

一致率这件事很重要。Agent 归因如果经常错，测试同学会很快不用。实习后期我抽样对比了一批失败记录，常见数据问题、环境问题、脚本问题的分类准确度已经能支撑日常辅助；业务缺陷判断仍然保留人工确认。

我也记录误判。比如有一次 Agent 把接口失败归因成数据问题，实际是后端对某个边界状态没有兼容。这个失败样例后来进入了归因样例库，用来提醒 Agent 不要只看前置状态，还要看服务端业务码和历史缺陷模式。

平台要持续变好，不能只记录成功。

一次真实执行链路长什么样

平台稳定后，一个新需求进入测试时，流程大概是这样。

测试同学先把需求摘要、影响模块、开发分支和预计上线窗口录进去。平台不会直接开始跑，而是先做影响分析：根据需求文本检索历史用例、接口说明、页面入口和过去缺陷。Agent 会生成一份候选测试范围，包括建议复用的 P0/P1 用例、可能需要新增的边界用例，以及不建议自动化的人工检查点。

这一步输出后，测试同学会审核。比如 Agent 认为某个权限场景是 P1，但测试同学知道这次需求没有改权限逻辑，就可以把它从本次执行计划里移除。反过来，如果测试同学发现 Agent 漏掉了一个下游通知场景，也可以手动加入。

审核通过后，平台进入执行阶段。接口用例先跑，因为它们速度快、定位也更清楚。如果接口主流程失败，平台通常不会继续跑依赖这个状态的 UI 冒烟，而是先进入归因。这样可以避免 UI 层因为前置接口失败产生一堆连锁红色结果。

接口通过后，再跑 UI 冒烟。UI 冒烟不是为了验证所有业务细节，而是确认入口、权限、关键按钮和页面状态没有被破坏。Playwright trace 会被保存，截图和视频只在失败或需要人工确认时保留，避免报告附件过大。

执行结束后，平台生成三份结果：

给测试同学看的摘要:
本次执行范围、通过/失败情况、建议关注点

给开发同学看的证据包:
失败步骤、请求响应、traceId、截图和日志摘要

给平台自己的资产:
用例执行记录、失败分类、归因是否被人工采纳

这个流程里，Agent 每一步都没有单独决定最终结论。它像一个整理员和分析助手，把信息从各处拉到一起，减少测试同学在文档、日志、报告和页面之间来回切换的时间。

我觉得这比“让 Agent 自动点完所有页面”更实际。真实部门里，大家不缺一个会表演的机器人，缺的是一个能把证据整理清楚、能在发布前节省时间、能让失败少扯皮的工具。

权限和数据安全是平台能不能被接受的前提

测试平台接触的东西很多：账号、测试数据、接口响应、日志、截图、需求描述。只要其中一部分包含敏感信息，就不能随便丢给模型。

我做了几层限制。

第一，Agent 只能看到脱敏摘要。接口请求里的手机号、身份证、真实姓名、token、cookie、内部 ID 等字段，在进入 Agent 上下文前会被替换成占位符。保留字段结构，但不保留敏感值。比如 phone: "138xxxx0000" 会变成 phone: "<PHONE>"。

第二，工具权限固定。Agent 不能自由查数据库，也不能执行任意 SQL。它只能调用平台提供的工具：检索用例、读取接口说明、查询执行结果、读取脱敏日志摘要、生成候选用例。需要更深的日志或数据库排查时，由测试或开发同学手动确认。

第三，报告分级。测试摘要可以给多人看，失败证据包只给相关人员。包含截图、trace 和接口响应的附件，不会直接进入公开群消息，而是保存在平台里，通过链接和权限访问。

第四，模型输出不直接写入正式资产。Agent 生成的用例、归因、缺陷草稿都带 candidate 状态。只有人工确认后，才会变成正式用例或正式缺陷记录。

这几条限制让平台少了一点“自动”，但换来了部门同学的信任。测试系统一旦被认为会泄露数据、乱写用例、乱报缺陷，就很难继续推广。安全边界不是上线前补的，它从设计第一天就要存在。

我怎么处理环境不稳定和 flaky 用例

测试平台最怕 flaky。一次通过、一次失败，最后大家会觉得自动化不可信。

我把 flaky 分成几类处理。

第一类是环境依赖。比如测试环境服务重启、下游 mock 不稳定、缓存未刷新。这类失败不能直接算业务缺陷。平台会检查健康接口、登录接口和基础配置，如果基础环境不满足，就把任务标成环境失败。

第二类是数据污染。老平台测试经常依赖状态流转，如果上一次执行没有清理干净，下一次就可能失败。我给业务单据加了执行批次号和测试标记，尽量让每次任务的数据可追踪。无法删除的数据，也会进入“已使用”状态，避免重复拿来当前置数据。

第三类是 UI 等待。页面异步渲染、接口慢、按钮状态延迟，都会让 UI 脚本不稳定。Playwright 自带 auto-waiting，但业务状态等待仍然要写清楚。我尽量不用固定 sleep，而是等待明确状态，例如按钮可见、接口返回、列表出现目标记录。

第四类是断言过宽或过窄。断言过宽会漏 bug，断言过窄会误报。比如只断言“接口成功”太宽，断言完整响应对象又太容易被无关字段影响。我通常只断言关键业务字段、状态流转字段和下游任务字段。

平台会记录重复失败。如果同一个用例在相同环境下连续失败，优先看业务或脚本问题；如果同一个用例在短时间内一会儿过一会儿失败，就进入 flaky 列表，需要单独处理。flaky 用例不会被用于发布阻断，除非人工确认。

这部分工作很琐碎，但它决定平台能不能长期用。自动化测试的信任不是靠一次全绿建立的，而是靠失败时能解释、误报时能修正、用例不稳定时能隔离。

和我之前写的 Agent 研究怎么接上

这次实习刚好把我之前研究的东西串起来了。

我之前写过 Agent 运行时、工具沙箱、评测台、Planner、Code Agent、多 Agent。实习里没有把这些概念原样搬进去，但思想是一样的。

运行时对应任务状态：需求分析、用例生成、执行中、归因中、待确认、已归档。

工具沙箱对应 Agent 能调用的工具：检索用例、查询接口说明、触发测试、读取脱敏日志，不能任意读库、任意跑命令。

评测台对应失败样例库：每次误判都能变成后续回归样例。

Planner 对应执行计划：先跑接口 P0，再跑 UI 冒烟，再根据失败类型决定是否扩大范围。

Code Agent 的经验也有用：不要相信漂亮解释，要看 diff、日志、测试和证据引用。

这让我感觉之前的学习没有停在文章里。真正进公司做事时，这些底层理解能直接影响设计选择。

最终的价值是什么呢？

如果只说“我会用 Agent”，价值不大。现在会用 AI 工具的人很多。

我觉得这次实习真正体现价值的地方有四个。

第一，我没有停在执行任务，而是识别了流程里的重复成本。原本安排我做新需求测试，我最后交付的是能复用到后续需求的平台。

第二，我没有滥用 Agent。执行层用 pytest、Playwright、Allure 这些成熟工具，Agent 只放在适合它的位置：拆解、匹配、生成候选、归因建议。

第三，我重视证据链。每条用例、每次执行、每个失败归因都要能追到来源。这样平台不是一个神秘黑盒，而是可复盘的测试系统。

第四，我考虑了交接。实习项目最怕人走系统停。我把用例模型、执行器、Agent 工具、报告结构和使用文档都整理出来，确保后续测试同学能继续用、继续改。

对我来说，我希望这篇文章传达的不是“我做过一个 AI 项目”，而是：我能把 AI Agent 放进真实工程流程，知道哪里该用模型，哪里必须用确定性程序，哪里需要人工确认，最后还能用指标证明它确实减少了团队负担。

和测试同学、开发同学协作时，我学到的东西

这个项目不是我一个人关在角落写出来的。真正推动它可用的，是我不断拿中间版本给测试同学和开发同学看。

测试同学最关心的不是架构，而是“这个结果我能不能信”。所以我每次展示都尽量不展示 Agent 聊天过程，而是展示用例从哪里来、为什么推荐、怎么执行、失败证据在哪里。后来我发现，测试同学愿意使用平台，往往不是因为它“智能”，而是因为它让她少翻文档、少截图、少重复解释。

开发同学最关心的是失败证据是否够定位。只说“接口失败”没有用。带着请求摘要、响应业务码、traceId、日志片段、复现步骤过去，沟通成本就低很多。有几次平台生成的证据包虽然没有直接判断出根因，但让开发很快定位到具体服务和具体异常，节省了来回问问题的时间。

我也被指出过不少问题。比如早期报告把 Agent 的归因放得太靠前，看起来像最终结论。测试同学提醒我，应该先展示事实，再展示建议。后来报告结构改成“执行事实、失败证据、可能原因、建议动作”，可读性明显好很多。

还有一次，开发同学指出我把某个字段的变化当成失败，但实际上这个字段是非稳定字段，不应该进入断言。这个反馈让我重新审视断言设计：不是字段越多越好，而是要断言真正代表业务正确性的字段。

这些协作让我意识到，平台价值不在于我单方面觉得好用，而在于它能嵌入不同角色的工作。测试要用它准备和复盘，开发要用它定位，负责人要用它判断风险。每个角色看到的报告重点都不一样。

我对“提效”的理解也变得更具体

以前说提效，我会想到“节省多少时间”。这次实习后，我觉得提效至少有四层。

第一层是执行提效。自动跑接口和 UI 冒烟，确实能减少人工重复操作。

第二层是准备提效。历史用例、需求影响和 P0/P1 场景能自动推荐，减少测试前的资料查找时间。

第三层是沟通提效。失败时自动整理证据包，让测试和开发围绕同一份事实讨论，而不是各自截图、各自猜。

第四层是资产提效。每次新需求都会沉淀用例、失败样例和归因记录。后面的需求可以复用前面的工作，而不是从零开始。

如果只做到第一层，平台价值有限。很多自动化脚本刚写完很有用，过几个月没人维护就废了。只有做到第四层，平台才会越用越厚。

所以我在复盘里没有只写执行时间减少。执行时间是最容易看到的指标，但资产沉淀才是长期价值。实习生能留下的东西不应该只是一个脚本目录，而应该是一套后续同学还能继续使用的机制。

怎么解释这个Agent项目

如果有人问“你这个 Agent 测试平台到底难在哪里”，我不会先讲模型。我会先讲测试流程。

难点一是业务规则隐含在历史用例和人工经验里，不能直接靠模型生成。我的处理是先结构化用例资产，再让 Agent 检索和匹配。

难点二是自动化执行必须稳定，不能依赖模型自由操作。我的处理是接口用 pytest，UI 用 Playwright，Agent 只生成计划和候选用例。

难点三是失败归因容易胡说。我的处理是所有归因必须引用结构化证据，并保留人工确认。

难点四是部门落地需要兼容现有流程。我的处理是不替代需求、缺陷和 CI 平台，而是输出能贴回现有流程的报告和证据包。

如果问“你的贡献和普通测试开发有什么区别”，我会回答：普通测试开发更多是在当前需求下补用例、跑回归；我做的是把需求、用例、执行、报告和失败归因串成可复用平台，让后续需求可以继续复用这套机制。

如果问“Agent 带来的实际价值是什么”，我会回答：它主要减少测试准备和失败复盘的人工成本，而不是替代断言和人工放行。模型负责语义归纳和证据整理，确定性工具负责执行和判断。

这类回答能经得起追问，因为每个点都能落到实际设计上。

还有哪些没做完

这个平台不是完美的。

第一，自动生成用例的质量仍然依赖历史资产。如果历史用例缺失，Agent 只能给建议，不能凭空知道业务规则。

第二，UI 自动化覆盖还不够广。为了控制维护成本，我只覆盖了核心冒烟路径，复杂页面交互仍然主要靠人工测试。

第三，归因对业务缺陷的判断还比较保守。它能很好地整理证据，但是否构成缺陷，仍然需要测试和开发确认。

第四，平台还没有做到跨项目通用。它的用例模型和工具封装带有部门业务特点，迁移到另一个平台需要重新适配。

这些限制我都写进了交接文档。一个系统能不能长期用，不取决于它发布时说得多好，而取决于后面的人知不知道它的边界。

实习结束后，我对 Agent 测试的理解变了

实习前，我更关注 Agent 本身：模型怎么规划，工具怎么调用，评测怎么做。

实习后，我更关注 Agent 放进流程后的责任边界。

测试平台不是为了让 Agent 显得聪明，而是为了让测试流程更稳定。真正重要的是：

用例能不能复用
执行能不能重复
失败能不能复盘
报告能不能被信任
误判能不能回流成样例
人工能不能在关键点接管

Agent 只是其中一个组件。它可以让需求拆解更快，让历史用例更容易找，让失败归因更省时间。但它不能替代测试设计、业务判断和发布责任。

这次实习让我第一次感受到，把一个技术点做成团队工具，难度和写 demo 完全不同。demo 只要跑通一次，平台要面对每天的环境波动、历史包袱、不同人的使用习惯和交接成本。

也正因为这样，这个项目比单纯写一个 Agent 更有价值。它让我从“会做 Agent”往前走了一步，开始理解怎么让 Agent 在真实部门里产生稳定收益。

后续如果继续做，我会补三件事

第一，补更系统的用例质量评分。现在用例入库主要靠字段完整性和人工审核，后面可以增加覆盖维度、历史失败命中、复用次数和误报率，让用例库自己有质量指标。

第二，补更严格的 Agent 归因评测。把人工确认后的失败分类做成固定评测集，每次改提示词、换模型、改日志摘要规则，都跑一遍回归。

第三，补跨需求影响分析。现在主要从需求描述匹配历史用例，后面可以接入接口调用关系、页面入口、配置项和历史缺陷，帮助测试同学更早发现“这个需求可能影响哪些看起来无关的流程”。

这些都不是一两天能做完的功能，但方向很清楚：让测试资产越用越厚，让 Agent 越用越有边界，让每次失败都能变成下一次更快定位的材料。

实习结束时，我最满意的不是平台跑通了多少条用例，而是它留下了一套能继续滚动的机制。需求会变，页面会改，模型会升级，但用例、证据、归因和回归样例会持续积累。

这才是我理解的“提效”：不是一次演示节省了多少分钟，而是把一类重复问题从人的记忆里搬到系统里，让后面每个人都少踩一点同样的坑。

参考技术

• Playwright 文档：用于 Web 端到端测试、浏览器自动化、trace 和报告。
• pytest fixtures 文档：用于测试前置数据、fixture 复用和参数化测试组织。
• OpenAI Agents / Responses API 时间线：2025 年已经有面向 Agent 构建的 Responses API 和 Agents SDK，本文中的 Agent 编排思路与这类工具能力一致，但平台执行层不依赖模型直接控制浏览器。