# AI Agent（如 OpenClaw）如何彻底重构测试人员的工作内容


最近一直在思考如何在测试过程中使用openclaw等AI agent工具来提升测试效率。

直接用AI写用例一直是各个大厂关注的重点，各家也有了一定的突破，可以预见在不久的将来，一些通用用例的编写和执行是可以交给AI去完成的。

不过复杂业务场景下的用例编写和执行还是需要人工参与比较好。

这是因为

- AI对复杂业务场景的理解可能不如测试领域的业务专家；
- 测试策略的制定和把控最好需要有经验的测试人员进行介入，否则方向错了，做的越多，错的越多；
- 如果AI在复杂业务场景下的验证工作出了问题，那就找不到人背锅了；

所以我忽然意识到，与其苦苦追求提升测试效率，不如思考一下如何去提升测试人员整体的日常工作效率。

因为毕竟编写用例以及执行用例只是日常工作的一部分。

如果除了这两部分之外的其他杂事和重复工作的完成效率提升了，那么测试人员的整体输出也会有显著的变化。

## 测试人员的一天

大部分测试人员的**典型一天**可能是这样的。
![](2026-03-05-12-14-18.png)

### 早晨启动阶段（9:00–10:30左右）

- 开电脑 → 查看/回复邮件、钉钉/企业微信（经常一早上要回几十条）
- 参加**站会/早会/Scrum Daily**（10–15分钟）：汇报昨天做了什么、今天计划做什么、阻塞困难以及卡点是什么
- 查看**Bug管理系统**（Jira、禅道、Tapd）：自己昨天提的Bug有没有被开发修复/重开/驳回
- 拉取**最新构建/提测包**，部署或更新测试环境，如果环境被开发玩坏了，还要求助🙏开发进行修复
- 快速过一遍**需求变更/新提测单/hotfix说明**，评估影响范围

### 上午核心测试阶段（10:30–12:30 / 13:30–17:00）

最占时间的部分，通常占一天50–70%：

- **执行测试用例**（手动为主，自动化为辅）
  - 跑冒烟测试/核心路径验证（新版本可能需要）
  - 按优先级逐条执行详细用例
  - 探索式测试（ Exploratory Testing）：随便点一点、试试各种组合、测试一下弱网、看看暗黑模式、有多设备就换设备跑一下
  - 接口测试（Postman/JMeter/自己写脚本）
- **发现Bug → 复现 → 提Bug单**
  - 截图/录屏/日志/复现步骤/写清楚预期结果和实际结果
  - 做严重程度和优先级的判断（比如P0致命/P1高/P2中/P3低）
  - @开发、跟进讨论（经常要语音/会议演示）
- **跑自动化用例**（如果有维护了自动化测试用例的话）
  - 触发CI/CD pipeline后看下结果
  - 分析失败用例的原因，是代码问题,环境问题,还是用例问题
  - 修复脚本，ui用例可能要更新locator或者加等待；接口用例就增加字段或者修改已存在的字段名称
- **专项测试**（视项目阶段）
  - 性能或者压力测试（JMeter/Locust）
  - 安全测试（SQL注入/XSS/垂直或水平越权）
  - 兼容性/国际化/无障碍
  - 回归测试（尤其是大版本后）

### 下午/傍晚协作 & 收尾阶段（15:00–18:30）

- 参加**各种会议**（需求评审、缺陷评审、联调会、上线评审、复盘会）
- **与开发/产品/运营对齐**（最耗时也最关键）
  - 需求不清晰，那么怼产品
  - Bug开发不认，那么拉产品一起怼开发
  - 上线有风险，各种升级，拉所有人一起评估
- 写/更新**测试文档**
  - 写各种测试报告（日报/周报/版本报告）
  - 做测试总结，覆盖率统计，典型bug分析，bug趋势分析，输出质量指标
  - 写操作手册或者输出验收的checklist
- **环境维护/数据准备**
  - 造数、刷库、Mock接口
  - 清理脏数据、回收资源
- **学习/工具优化**（优秀测试的常态）
  - 研究新需求的技术实现，或者参加开发的方案评审
  - 学习/优化自动化框架
  - 玩OpenClaw/Claude等AI Agent写用例/生成脚本/分析日志（这个比较科幻）

### 一天结束前（下班前30分钟）

- 汇总当天Bug/测试进度 → 发日报/更新看板
- 确认明天要测的内容、功能是否提测，环境是否ready
- 把未完成的用例/阻塞事项记下来

可以看出典型QA的一天比较零碎，可以工程化的部分其实有限。不过我们仍然可以提炼出一些可以进行自动化的非测试场景。

## 可能的自动化场景

### 第三方服务 & API监控

- 定时轮询第三方接口的health检查接口，异常时立即发送提醒
- 每周对比外部API响应结构变化
- 监控自家API的feature flag、数据库迁移后数据、微服务间调用等drift问题
- API key、证书、sandbox账号到期提前多级提醒

### CI/CD集成与通知

- 流水线结束后自动格式化测试结果发到测试群（全绿打勾、失败列出详情）
- 记录并统计flaky test数据，给团队提供真实数字
- 监听staging部署，自动冒烟验证，成功/失败分别通知
- 给PR加上“needs-qa”标签自动提醒QA
- 一键多渠道发发布/回滚/重大事件通知

### 日志监控与报警

- 每日早会前自动总结昨夜错误日志并发到测试群
- 特定错误模式实时自动提bug发通知
- 部署后30分钟重点观察新错误类型

### 测试数据生成与管理

- 一键重置+database seed测试环境（各种角色用户，一键生成所有的核心数据和测试数据）
- 为性能测试批量生成高仿真度的dummy data
- 跨环境（dev/staging）同步相同测试数据

### Jira/TAPD与缺陷管理自动化

- 缺陷状态变化自动提醒相应QA
- Epic下所有bug关闭后自动推进Epic状态
- 新bug创建时查重并添加参考链接
- 每周bug老化报告（按缺陷年龄来分桶）
- 自动填充规范的bug模板（从日志或简短描述生成）

### 环境与部署管理

- 每天早8点检查所有环境健康
- 记录每一次部署历史到专用的测试群
- 自动总结git diff，给出QA关注点
- 跨环境版本对比，提醒drift

### 报告与数据汇总

- 每周五自动发测试通过率、周环比
- 每天自动生成日报
- 发布前一键生成上线前的检查清单
- 持续跟踪覆盖率趋势，下降时报警

上面的自动化场景尽管跟测试没有直接关系，但却把QA工作中**最烦人、最耗时、最不体现技术价值的那一半**（通知、检查、数据准备、报告、提bug）给自动化掉了。

这样测试人员可以把更多的精力放在更重要的事情上，无形之中增加了测试的时间。

## 用AI Agent来实现自动化工作

这些工作用openclaw之类的agent其实是可以很好的完成的。

比如上面提到的`自动总结git diff，给出QA关注点`的功能，我们就可以用openclaw的skill来实现。

我用AI生成了1个SKILL.md文件，大家可以参考一下。

`````markdown
---
name: git-diff-qa
description: "Generate git diff skill focused on QA/测试关注点。用于在提交Review或提测前，快速梳理这次变更的QA关注点。"
---

    # Git Diff + QA关注点生成 Skill

    目标：在提交代码前 / PR Review 时，通过 `git diff` 分析本次变更，帮助开发者/ reviewer / QA 快速判断：

    - 这次改动影响了哪些关键路径？
    - 是否需要QA重点验证？
    - 建议QA关注的点有哪些？

    ## 快速判断是否需要QA介入的 checklist

    ```text
    文件/目录包含以下任一情况 → 建议拉QA：
    ▸ src/main/java/...Controller.java
    ▸ src/main/java/...Service.java （核心业务逻辑）
    ▸ src/main/resources/application*.yml / application*.properties
    ▸ src/main/resources/mapper/*.xml
    ▸ pom.xml / build.gradle / package.json / yarn.lock / go.mod
    ▸ Dockerfile / docker-compose.yml / k8s/*.yaml
    ▸ shell脚本 / python / lua / js 运维脚本
    ▸ 包含了 @Cache* / redisTemplate / rocketmq / kafka / rabbitmq 的改动
    ▸ 新增/修改了定时任务 (@Scheduled / quartz / xxl-job)
    ▸ 权限相关改动 (shiro/spring-security/jwt/sa-token)
    ▸ 异常处理、全局拦截器、Filter、HandlerInterceptor 变更
    ▸ 数据库表结构变更（哪怕只是注释）
    ▸ 新增对外接口、新增枚举值、状态流转变更
    ````

    ## 常用命令组合（建议复制粘贴使用）

    ### 1. 看当前分支与目标分支的完整 diff

    ```bash
    # 假设你要合到 main 分支
    git diff origin/main...HEAD

    # 或者指定 PR 目标分支（更推荐）
    git diff origin/release-2026Q1...HEAD
    ```

    ### 2. 只看改动文件名（最快判断是否需要QA）

    ```bash
    git diff --name-only origin/main...HEAD

    # 按类型筛选
    git diff --name-only origin/main...HEAD | grep -E '\.(java|kt|xml|yml|yaml|properties|sql|sh|py|js|ts|go|php)$'
    git diff --name-only origin/main...HEAD | grep -E 'Controller\.java$|Service\.java$|application.*\.ya?ml$|mapper/.*\.xml$'
    ```

    ### 3. 带统计信息（+多少行 -多少行）

    ```bash
    git diff --stat origin/main...HEAD

    # 只看改动比较大的文件
    git diff --stat origin/main...HEAD | sort -k 2 -nr | head -15
    ```

    ### 4. 快速看配置、数据库、接口相关改动

    ```bash
    # 配置文件
    git diff origin/main...HEAD -- application*.yml application*.properties bootstrap*.yml

    # sql / mapper
    git diff origin/main...HEAD -- '*.sql' 'mapper/*.xml'

    # Controller 接口层
    git diff origin/main...HEAD -- '*Controller.java' '*Facade.java' '*Api.java'

    # 新增文件（常包含高风险点）
    git diff --name-status origin/main...HEAD | grep '^A'
    ```

    ## 推荐的 QA 关注点输出模板（你可以用 git diff 内容套这个模板）

    ```text
    本次改动概要：_______________________________

    是否建议QA介入：【是 / 否 / 建议冒烟验证即可】

    QA重点关注点建议（按风险从高到低）：

    1. _______________________________
    - 影响路径：___________________
    - 预期行为：___________________
    - 异常case：___________________

    2. _______________________________
    ...

    3. 基础功能冒烟（几乎所有改动都需要）：
    - 登录 / 鉴权
    - 列表查询（分页、搜索）
    - 核心业务主流程（如下单、支付、发货、退款等）
    - 接口入参边界（空值、超长、负数、非法枚举）
    - 并发场景（如果涉及库存、余额、积分等）

    涉及公共组件/基础改动（高危）：
    □ 全局异常处理
    □ 鉴权 / 权限过滤器
    □ 缓存使用变更
    □ 消息队列生产/消费
    □ 定时任务
    □ 配置中心 key 变更
    □ 数据库字段 / 索引变更
    □ 枚举值新增/变更/删除

    建议测试环境：
    □ 日常环境冒烟
    □ 预发环境回归
    □ 生产数据影子验证（如果涉及核心金额/库存）

    额外备注：
    - 是否需要灰度 / 分流验证？
    - 是否有回滚方案 / 监控指标？
    ```

    使用示例对话：

    > 这次改了什么呀？要不要测一测？
    > → 先跑 `git diff --name-only origin/main...HEAD` 给我看看改了哪些文件，我帮你判断要不要拉QA，以及大概要测哪些点。

    ```
`````

## 重构后的QA一天工作流程（AI Agent自动化时代）

如果我们真的使用openclaw等AI Agent工具提升了测试人员的工作效率，那么测试人员典型的一天大概会是下面这样的。

### 早晨启动阶段（9:00–9:30左右，缩短至30分钟）

- **自动化主导，QA只需快速审阅**：
  - 开电脑后，AI Agent已自动发送昨夜/早间的总结通知（到企业微信/Slack/测试群）：包括第三方API健康检查结果、日志错误总结、环境健康报告、部署历史、flaky test统计、周bug老化报告等。如果有异常（如API响应结构变化、证书到期、drift问题），AI已提前多级提醒相关方，QA只需确认是否需人工干预（如果AI提的bug有误，快速人工介入修复）。
  - 参加**站会/早会**（10-15分钟）：汇报昨天高价值输出（如新测试策略），今天计划（如探索特定风险场景）。AI已自动更新Jira/TAPD看板（比如Epic状态推进、bug状态变化提醒），无需手动追踪。
- **节省时间**：原本的邮件/Bug系统查看、环境拉取、需求变更评估等被AI Agent定时任务/监控取代。

### 上午核心测试阶段（9:30–12:00 / 13:00–15:00，扩展至4-5小时）

这是重构后最受益的部分，QA精力从“重复执行用例”逐渐转向“创新与深度质量评估”阶段：

- **测试执行与Bug处理（AI辅助为主）**：
  - AI Agent自动跑冒烟/回归/接口/兼容性测试（比如监听staging部署后30分钟验证结果，失败自动通知+格式化结果）。QA监督AI输出：审阅自动化用例结果，校验AI漏掉的边缘场景(这个部分还是要人工介入的)。
  - 发现Bug时，AI自动查重、填充模板（从日志/描述生成规范Bug单）、提单并@开发。QA只需验证高优先级Bug的复现/严重性，焦点放在探索式测试：如模拟真实用户行为、弱网/多设备组合、业务逻辑深度挖掘等。
  - 专项测试（如性能/安全）：AI生成高仿真dummy data，跑压力测试；QA分析结果，设计优化策略。
- **数据与环境准备（几乎全自动化）**：
  - 一键重置环境+seed数据（各种角色/核心测试数据），跨环境同步无需手动。QA只需指定prompt（如“生成1000条高仿真订单数据，覆盖异常场景”），让AI自动执行。
- **节省时间**：手工跑用例、造数、环境维护从几小时减至分钟，QA就可以进行更重要的工作，比如参与需求评审，设计测试策略，设计核心场景用例和异常场景用例等。

### 下午协作 & 优化阶段（15:00–17:30，精简至2-3小时）

- **会议与协作（更高效）**：
  - 参加需求/缺陷评审、上线评审：AI提供git diff总结、关注点清单、覆盖率趋势报警，QA基于此给出更多建议（比如“这个变更可能引入drift，建议加监控”）。
  - 与开发/产品对齐：AI监听PR标签、CI/CD结果，自动提醒QA介入。重大事件（如发布/回滚）一键多渠道通知，无需手动发文。
- **文档与报告（自动化生成，QA审阅/优化）**：
  - AI自动生成日报、周报、测试通过率、周环比、上线检查清单以及其他质量指标。QA快速审阅，调整和优化测试策略（比如“新feature导致覆盖率下降，建议增加一轮回归测试”）。
  - 优化Agent本身：QA花时间调整skills以及agent的memory，提升准确性，优化长期记忆。
- **学习与创新（新增高价值时间）**：
  - 研究新技术/工具（如OpenClaw新功能），设计更智能的测试框架；或跨团队分享“AI重构QA经验”。
- **节省时间**：通知、报告、提bug等杂事被AI接管，协作模式也从被动响应转为主动驱动。

### 一天结束前收尾（17:30–18:00，缩短至30分钟）

- AI自动汇总当天进度/Bug/报告，发到群/看板。QA确认无遗漏，规划明天的工作重点（比如 “明天重点探索AI生成的用例盲区”）。
- 如果有部署，AI监控后测试环境部署后30分钟内的新错误，QA只需处理异常。
  ![](2026-03-05-12-15-20.png)

## 重构后的整体变化与收益

通过上面的重构，我们可以看到，收益还是很容易体现出来的。

- **时间分配的变化**：琐碎任务从50-70%降至10-20%，高价值测试以及设计测试策略的时间占比从30%升至70-80%。QA从“苦力”变“AI Agent的指挥官”，工作强度降低，无形中增加了测试时间和测试深度（比如覆盖更多场景，降低上线风险）。
- **潜在新角色**：QA可能演变为“质量架构师”，负责AI Agent的prompt工程、长期记忆优化，质量数据分析、以及端到端风险管理工作。

不过需要注意的是，自动化不是万能，质量管理工作仍然需人类的介入以及专家技能的判断。另外初始化这些自动化工作也需要投资很长的一段时间，不过长期看来,ROI的预期还是很高的，值得期待。

另外QA的AI Agent重构也可能顺带影响整个研发团队以及研发流程的AI化重构工作，可以想象得到，不久的将来，开发的Agent与QA的Agent通力协作，讨论，修复以及验证bug的情景。

但Agent的工作完成之后，仍需要人类验收才能真正进行发布到生产环境的工作，毕竟如果发布的产出物是给人类使用的，AI在这方面仍然不能完全替代人类，另外线上出了问题还是需要有具体的自然人来进行背锅，毕竟反思和追责是组织文化里绕不过去的环节。