测试之家

AI测试 AI 赋能测试实践 11：别把 Claude Code 当聊天框用了——三层改造，驯成你的测试专属智能体

EternalRights · 2026年07月07日 · 最后由 takaの 回复于 2026年07月07日 · 1306 次阅读

前言

        ClaudeCode作为现今智能体的先驱以及通用 Agent领域的事实领袖，可谓是发展迅猛。但是发展之下，却暗含恶意，ClaudeCode 通过代码来判断用户是否是中国用户，进而采取一系列穿小鞋的下三滥手段，把用户的信息发送出去。被曝光后，A 出 冠冕堂皇的回应是为了防止 AI 实验。曝光原帖如此：https://www.reddit.com/r/ClaudeAI/comments/1ujila1/anthropic_embedded_spyware_in_claude_code_and/

        首先，我这篇文章其实起草了很久了，但是谁曾料想啊！结果 7 月初 Anthropic 就来了波大的，属实又一次践踏了所有用户对于 Anthropic 的信任。想了想，这篇文章还是发出来了，因为本质上是通用的，重要的是借鉴一下打造的思维。

        本篇的核心内容将会放在如何将 ClaudeCode 打造为测试专属智能体。

关于 ClaudeCode

        Github 链接：https://github.com/anthropics/claude-code

        简单说一下 ClaudeCode 的近况，就在 7 月初的时候，Sonnet 5 成为了默认模型，原生 1M token 上下文，紧接着 Notification Hook 上线了——Claude Code 在后台跑完任务能直接推飞书/Slack（算是彻底超越 OpenClaw 了）。然后 6 月底的时候，/rewind 新增，对话现在可以回退了。接着是 Skill，Skill 现在支持堆叠调用，一个命令能串起多个 Skill（Skill 的融合，再一次体现出来主 Skill 附加子 Skill 的最佳实践了）。最重要的是：后台 Agent 现在能自己 commit、push、开 draft PR。

        虽然说，这些功能单个看都是"好用"的，但是串在一起看——它正在变成一个能持续参与一个特定工作流的角色，它的值守性以及 Loop 感得到极大的强化，这恰恰再次印证了 CLaudeCode 值得被打造为一个专属的测试 Agent。

一、给 ClaudeCode。换大脑

一个场景：你让 CluadeCode 写用例，为什么会感觉远不如你的新同事？

        笔者的团队之前做过一轮 AI 测试提效。流程是这样的——产品写完需求 PRD，研发也写好了技术文档，我们用内部定好的 Xmind 模板填测试点，然后把模板内容喂给大模型，让它"根据这个模板补充详细的测试步骤"，生成一个能够嵌入我们测试用例的文件。

        结果毋庸置疑，大把的吐槽，尤其是与之相关的 Skill，也是屡屡调试，进展缓慢，且迭代频繁。试用的员工更是叫苦连跌，创作 Skill 就把锅甩给了你模型不好。

        言归正传，ClaudeCode 生成的用例有个诡异的特征：格式完美，内容空洞。 编号整齐、模板字段一个不落（用例编号、用例名称、前置条件、接口、数据输入、步骤操作、预期结果、字段校验），看着像那么回事。但你仔细看——十条用例里，七条是"输入正确格式，预期成功"、"输入错误格式，预期报错"这种模板话。真正有测试价值的——比如"彩条 3 次触发频控限制，且具有数据计时"——一条都没。

        我们复盘的时候发现了一个根本问题，当时所有人都忽略了：这套模板是为了人类而设计的。

        不知可否的是，一个人类测试工程师看到这个模板后，脑子里会自动补全大量的信息——他知道这个系统历史上登录模块出过并发问题、知道那台旧服务器接口超时率偏高、知道上周有个 bug 是因为缓存刷新顺序、知道 RD 的技术文档中关于接口未提及过的字段。所以说，模板只是"线索"，真正的测试能力在人的脑子里。

        但你喂给 ClaudeCode 同样的模板，它脑子里没有这些。它看到的只是一个结构化的空壳，于是它按照这个壳的边界，生产出同样空洞的内容。

全世界都在撞同一面墙

        无独有偶，并非仅仅笔者遇到了这样的困境。前段时间看到一个 22 人测试团队的 AI 转型复盘（CSDN 上有完整记录），他们在 L1 阶段（工具赋能）就踩了一个很典型的坑：让 AI 直接生成完整测试用例集并试图"一键执行"，结果假阳性率高达 35%。后来改成"AI 生成草稿 → 人工精选 → 持续反馈"，才降到 8% 以下。

        他们的总结很直白：AI 没有项目的业务规则和历史缺陷记忆，所以它生成的用例只能停在"语法正确、语义空洞"的层面。

        但这里有个更深的矛盾——让 AI "记住业务规则"需要花时间整理上下文、写提示词、设计反馈机制，而恰恰测试人员最缺的就是时间。你一边被 AI 驱动的开发速度压得喘不过气，一边还要花几个小时去搭知识库、写 Skill、设计上下文——这是典型的"修水管的同时水管还在喷水"。

        所以这条路不能靠"加班补"走通，得换一个思路：重新设计一套对 AI 友好的底层架构。

        核心改动就三件事：

  1. 把"人类阅读"的测试资产改成"AI 能直接执行"的格式
  2. 用 CLAUDE.md 承载项目级的测试约定
  3. ** 让 Claude Code 从"被动工具"变成"主动参与者"——通过 Hooks 自动触发、通过 Subagent 隔离上下文

二、第一层改造：把你的测试资产指令化

一个反直觉的事实：结构化用例可能是 AI 最大的枷锁

        国内测试团队几乎都有一个 Excel 模板。字段大同小异：用例编号、模块、标题、前置条件、输入步骤、预期结果、优先级。这套模板存在了二十年，从手工测试时代用到现在，它解决的核心问题是——** 让人看一眼就能知道这个用例在测什么。

        但 AI 不需要"看一眼就知道"。AI 需要的是可执行的操作序列 + 可验证的断言条件 + 可追溯的业务上下文。

        举个例子。一个电商平台优惠券使用的用例，传统格式是这样：

        这份模板对 AI 来说有什么问题？

  1. 输入和步骤的边界模糊——“购买商品” 是购买的一个特殊指定的测试商品，有 RD 加白的？还是说随便一个？AI 不知道，它只能猜。
  2. 前置条件不可验证——"打开电商平台"——是否需要登录？是否需要配置一些测试环境？是否需要注意 Apollo 的命中？没有这些信息，AI 只能套模板。
  3. 预期结果太粗糙 ——"成功下单"——成功下单的标准是什么？对于该接口而言字段的变化是什么？AI 做不了断言，因为断言条件没有量化。

从"描述用例"到"定义任务"

        笔者的改法很简单：把每一行用例从"给人看的摘要"变成"给 AI 执行的指令"。

        同一个优惠券场景（以"订单金额 100，领取次数 1，有效期 0"这条用例为例），改成 AI 友好的格式：

task: coupon_use_valid_amount_100
description: 验证合法订单金额（100元）下优惠券的领取与使用流程
context:
  module: 营销-优惠券
  risk_area: 优惠券领取 → 下单抵扣 → 订单状态流转
  related_bugs: [BUG-3089, BUG-3112]  # 历史相关缺陷：满减叠加错乱、并发领取
precondition:
  environment:
    apollo_switch: coupon_v2_enabled=true   # Apollo 开关必须命中
    mock_payment: true                       # 走支付 Mock，不进真实支付通道
  user:
    account: ${TEST_USER}
    role: 普通用户
    login_state: 已登录
  product:
    sku: TEST_SKU_100                        # RD 加白的测试商品，金额=100
steps:
  - add_to_cart:
      sku: "${product.sku}"
      quantity: 1
  - claim_coupon:
      coupon_id: COUPON_2026_07
      expect_immediate: true                 # 领取应立即生效
  - place_order:
      use_coupon: true
      expect_amount_after_discount: 80       # 100-20=80，必须精确匹配
assertions:
  - api_response:
      endpoint: /api/v2/order/create
      status_code: 200
      body_contains:
        coupon_applied: true
        final_amount: 80
        order_status: "PAID_PENDING_SHIP"
  - db_check:
      table: t_coupon_record
      where: "user_id=${user.account} AND coupon_id='COUPON_2026_07'"
      expect:
        used_count: 1
        remain_count: 0
  - response_time_lt: 2000
tags: [smoke, coupon, p0]

        你会发现这个格式你作为人类看着非常扎眼，那就对了！因为不再"人类友好"了——读起来像配置文件而非测试文档。但正是因为这样，AI 不需要猜任何东西：

  • 商品 SKU 是明确的（TEST_SKU_100，RD 加白）——并非"随便一个商品"
  • Apollo 开关命中条件是明确的——并非"打开电商平台"这种含糊前置
  • 断言条件是量化的——接口返回 coupon_applied: true、数据库 t_coupon_record 的 used_count=1、响应时间 < 2s，每一项都能直接校验
  • 上下文包含了历史缺陷 ID——告诉 AI "这个模块以前在满减叠加和并发领取上翻过车"

        这套格式是为了让 AI 精准执行。 笔者花了两周把核心用例从 Excel 转成了这个格式，之后 Claude Code 的用例生成准确率从"能用"变成了"可依赖"——以前生成十条用例七条是模板话，现在它会主动按 related_bugs 把并发领取、Apollo 未命中、订单金额边界这些场景都覆盖进去。

实际效果：一页 CLAUDE.md 抵十页 Excel

        转换完之后，笔者把这些信息全部写进了项目的 .claude/CLAUDE.md：

## 测试约定

### 用例格式
所有测试用例使用 YAML 格式定义，结构为：
task / description / context / precondition / steps / assertions / tags

### 测试数据
- 测试账号从环境变量读取，不硬编码（${TEST_USER}, ${TEST_PASSWORD}）
- 测试数据构造脚本位于 tests/fixtures/ 目录
- 每个测试模块有独立的 fixture 文件

### 断言标准
- UI 测试：必须包含 element_visible 和 response_time 断言
- 接口测试：必须包含 schema 校验（使用 jsonschema）
- 任何涉及支付的测试：必须包含幂等性验证

### 关键风险区域
- 优惠券模块：历史满减叠加错乱（BUG-3089），必须覆盖优惠券+满减+折扣三重叠加场景
- 优惠券领取：历史并发超发漏洞（BUG-3112），必须覆盖同一用户并发领取 + Apollo 开关切换瞬间的领取
- 订单创建：历史幂等问题（BUG-2087），必须覆盖重复点击下单按钮 + 网络重试场景
- 支付回调：历史回调超时导致订单状态卡死（BUG-3056），涉及支付的功能必须覆盖回调超时 + 重复回调

### 测试环境
- 开发环境：dev.example.com（端口 3000）
- 预发环境：staging.example.com（端口 3000）
- 数据库：test-db.example.com:5432（只读，不写测试数据）

        这个文件装了什么？一个可被 ClaudeCode 直接消费的项目上下文。

        Claude Code 每次启动都会自动加载 CLAUDE.md。这意味着你不需要在每次对话开头解释：

  • "我们这个项目优惠券模块以前有过满减叠加错乱"
  • "支付相关的测试必须验证幂等"
  • "测试账号不要写死，从环境变量取"

        这些信息现在全部变成了 Claude Code 的"出厂设置"。以后你只需要说"帮我针对优惠券新需求生成用例"，它就自动知道这个模块踩过什么坑、该用什么格式输出、断言该覆盖什么维度。简直是一劳永逸呀。

三、第二层改造：让 Claude Code 成为"主动参与者"

让它持续看你的项目

        第二层改造花了更长时间，但也是最值的一层。这一层要解决两个问题：Claude Code 能不能在你不主动召唤它的时候自己感知项目变化？以及能不能在跑大规模任务的时候不撑爆主对话的上下文？

        第一个问题用 Hooks 解决，第二个用 Subagent 解决。

        可以回忆一下，我们测试人员传统用 ClaudeCode 的方式是"有问题 → 开对话 → 问 AI → AI 干活 → 得到答案 → 关对话"。但测试工作在这样运作下，其实效率和质量不能得到保障。测试工作里大量有价值的事情发生在间隙里——你跑完了一轮回归、你看到 CI 报了一个奇怪的警告、你收到了一条 Slack 消息说"xxx 服务刚才重启了"。这些事情里藏着风险，但是它们不会主动触发一个"问答"流程。

        笔者现阶段的做法是：用 Claude Code 的 Hooks 机制，在项目关键节点自动触发检查。 而且 7 月初 Claude Code 上线了 Notification Hook——agent_needs_input 和 agent_completed 事件可以直接推到飞书/Slack。这意味着 Agent 不再是一个需要你盯着黑窗口的东西——它跑完了会主动告诉你结果，真正的实现了后疫情时代的远程办公。

实战：PR 提测时的自动影响分析

        每当 RD 提 PR 到测试分支，Claude Code 的 PostToolUse Hook 会自动跑以下流程：

1. 读取 git diff（改动内容）
2. 对照 CLAUDE.md 中定义的关键风险区域
3. 分析改动涉及哪些模块，这些模块是否有历史缺陷记录
4. 输出一份"变更影响分析"，标注需要重点回归的场景

        笔者在 .claude/hooks/ 目录下配置了一个 PostCommit Hook：

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "BashTool",
        "command": "git diff --name-only HEAD~1",
        "run": "claude --print '分析以下改动的测试影响范围，重点关注 CLAUDE.md 中列出的关键风险区域：$(git diff HEAD~1)'"
      }
    ]
  }
}

        效果是怎样的呢？早上团队提了一个 PR，改了优惠券抵扣接口的返回值结构。Claude Code 自动检测到：

变更影响分析：

  • 涉及模块：优惠券抵扣（关键风险区域）
  • 历史缺陷：BUG-3089（满减叠加错乱）、BUG-3112（并发领取超发）
  • 建议回归：
    1. 优惠券 + 满减 + 折扣三重叠加场景
    2. 并发领取同一张券的边界场景
    3. Apollo 开关切换瞬间的领取链路
    4. 下游服务（订单创建、支付回调）的状态一致性验证

        以前这个分析需要笔者手工做——翻 git log、打开 VS Code、查 JIRA、回忆历史坑点、与 RD 沟通。现在 Claude Code 在 PR 提测的瞬间就完成了，连上下文都不需要重新建立。有没有一种灵性呢~

实战：回归结果的自动分析 + flaky 预警

        上篇讲了 Skill——写了一个 regression-analyst。在实际工作中它是这么被触发的：CI 跑完一轮回归之后，Jenkins 的 Post-build Action 调用 Claude Code：

claude --print "/regression-analyst 分析 tests/reports/latest/ 目录下的最新报告" --output-format markdown > regression_report.md

        然后这个报告通过 agent_completed Notification Hook 自动推到飞书群里。这个 hook 是笔者用 OpenClaw + Claude Code 桥接飞书做了大半年的事——现在 Claude Code 原生就支持了，不用再写胶水代码。Agent 跑完，飞书弹通知，全链路打通。

        笔者每天早上一打开飞书，就能看到昨晚的回归分析报告——哪些用例挂了、是不是 flaky、通过率是升了还是降了。

        如果回归挂了一堆但你怀疑是环境问题（比如支付模拟服务崩了），可以用 6 月底新增的 /rewind 命令回退到分析之前的对话状态，让 Claude Code 保留上下文重跑一轮，不用从零开始重新解释项目背景。

        以前是"我找问题"，现在是"问题找我"。 Claude Code 从一个被召唤的工具，变成了一个持续值守的角色。

实战：用 Subagent 隔离测试执行的"上下文噪音"

        前面讲的都是 Claude Code 在主对话里干活。但有一类场景有个隐藏问题——回归跑完，主对话的上下文被测试输出撑爆了。

        一个稍微完整点的测试套件，跑完输出可能几千行。这些日志全塞进主对话，后面再跟 Claude Code 讨论别的事，它会因为上下文太杂开始抓不住重点。Sonnet 5 的 1M 窗口听起来很大，但噪声越多，注意力越分散。

        Claude Code 的 Subagent 机制正好解决这个。Subagent 是一个独立 context window 的子代理，跑完任务只把摘要回传给主对话。

        笔者的做法是写一个测试专用 Subagent，放在 .claude/agents/test-runner.md：

---
name: test-runner
description: Runs test suites and reports only failures. Use proactively after code changes.
tools: Bash, Read, Grep, Glob
model: inherit
---

你是测试执行专家。被调用时：
1. 运行指定的测试套件
2. 捕获全部输出
3. 只回传：
   - 用例总数 / 通过 / 失败 / 跳过
   - 每个失败用例的名字、错误信息、相关堆栈
   - 如果有覆盖率数据，附上摘要
不要把通过的用例输出也回传。

        调用方式很简单：

"用 test-runner 跑 tests/api/ 目录下的所有用例"

        跑完之后主对话里只会出现一个简短摘要——"跑了 156 个，8 个失败，3 个是支付超时，5 个是订单字段变更"——其余几千行日志都留在 Subagent 自己的上下文里。

        关键设计点有几个：

  1. tools: Bash, Read, Grep, Glob——故意没给 Write/Edit。这个 Agent 只跑测试不修代码，权限最小化
  2. model: inherit——继承主对话的模型。Sonnet 5 默认，需要时手动切到 Opus 跑复杂场景
  3. description 里写"Use proactively"——Claude 会更倾向于在代码改动后主动调用它

        如果团队里有多类测试要并行跑，可以多写几个 Subagent：unit-test-runner、integration-test-runner、e2e-runner——每个有自己的工具权限和模型策略。比如 E2E 测试耗时长，可以让它在 background: true 后台跑，主对话继续干别的。

实战：需求评审时的测试点快速梳理

        这是笔者最喜欢的一个场景。产品发来一个新需求的 PRD（通常是一个 Notion 文档或飞书文档链接），以前的做法是花半小时到一小时通读、标注疑问、梳理测试点。现在直接在 Claude Code 里：

"Read https://notion.so/xxx 这个需求文档，对照 CLAUDE.md 中定义的关键风险区域，帮我梳理测试点。重点关注跟登录、支付、订单状态变更相关的风险。"

        Claude Code 会自动读完文档，对照项目上下文（历史缺陷、风险区域、测试约定），输出一份结构化的测试点清单。如果同时需要梳理环境信息和测试点，7 月新上的堆叠 Skill 调用可以一条命令全搞定：/api-test-generator /env-helper 分析这个需求——两个 Skill 串行执行，不用分两次对话。

        笔者做过十次对比：AI 输出的测试点 + 人工补充，比纯人工写测试点节省约 60% 的时间，而且不会漏掉历史风险区域——人的记忆力会衰退，AI 的 CLAUDE.md 不会。啊，当然了，唯一的缺点就是人的大脑可能会退化（手动滑稽）。

四、第三层改造：CLAUDE.md 不应该一次写完，需要长出来

很多人把 CLAUDE.md 当成"一次性配置"

        这是笔者踩过的一个大坑。刚接触 Claude Code 的时候，按照官方文档写了一版 CLAUDE.md，项目约定、技术栈、编码规范，洋洋洒洒写了一千多字。然后安安静静的躺在文件夹中，两个月没有再动过。

        两个月后项目变了——新增了微服务、换了数据库连接池、优惠券模块拆成了独立的 promotion-service。但 CLAUDE.md 还是老样子。于是 Claude Code 开始给出错误的建议——"优惠券的配置在 config/coupon.yml 里"——其实那个文件早就不存在了。

        CLAUDE.md 是一个活的文档。它需要在每次发生重大变更时同步更新。

        而且有一个反直觉的事实：7 月起 Claude Code 默认使用 Sonnet 5，上下文窗口到了 1M token。看起来"窗口大了就不用精选了"——恰恰相反。窗口越大，噪声越容易淹没关键信息。CLAUDE.md 的价值在于"信噪比够不够高"。 一页高信号密度的 CLAUDE.md，比一百条散乱的历史对话更有用。

笔者的更新策略

        任何涉及架构变更、接口废弃、关键流程改动的 commit，必须在 commit message 中标注 [claude-context]，并在 CLAUDE.md 中同步更新。

        示例 commit：

refactor: 优惠券模块迁移至独立服务 [claude-context]

- 优惠券功能已拆分到 promotion-service（端口 4001）
- 旧接口 /api/v1/coupon 已废弃，新接口 /api/v2/coupon
- CLAUDE.md 已更新关键风险区域: 新增 promotion-service 超时风险

        好处是实打实的——Claude Code 以后就不需要靠你的记忆力来保持准确，仅仅靠 commit 纪律来保持准确即可。 但是一次 commit 不规范，影响的是 AI 后续所有建议的准确度，所以 commit 的质量非常重要（恰恰说明，我们测试进一步提前到了 commit 阶段）。7 月更新后，后台 Agent 甚至能读取 CLAUDE.md 的变更，自动判断是否需要更新测试策略——你改了订单模块的关键风险区域，它下次生成用例时会自动同步覆盖新增的边界场景。

CLAUDE.md 里应该放什么？三份权威资料交叉验证后的清单

        笔者参考了三份来源：claude-code-best-practices（GitHub Trending 第一、Claude Code 开发者 Boris Cherny 审阅）、Anthropic 反模式画廊（14 条反模式对照表）、以及 12 条核心模式 中的 CLAUDE.md 章节。交叉验证后，测试项目的 CLAUDE.md 应该放这些东西：

类别 内容 反例（别这么写） 为什么重要
关键风险区域 哪些模块历史缺陷多、哪些接口不稳定、缺陷 ID 和根因。每条都要写「为什么这里容易出错」 "注意支付模块" — 空泛的提醒没有信息量 没有具体缺陷 ID，AI 只会做通用覆盖。有 BUG-3089 告诉它"满减叠加曾出过错"，它才会在涉及优惠券模块时主动加覆盖
测试数据约定 账号密码的获取方式（环境变量/密码管理器路径）、fixture 目录位置、数据刷新周期、数据生命周期 "测试账号在环境变量里" — 具体是哪个变量？数据什么时候过期？ AP-5 禁止写密钥，AP-4 禁止绝对路径。AI 需要知道数据从哪来、有没有有效期——否则你下周跑同一组用例，数据可能已经被别的测试改了
断言标准 UI/接口/支付的断言清单、常见漏断言（Gotchas）、不允许的断言（如硬编码时间戳校验） "做好断言" — AP-1：模糊指令 这是测试项目 CLAUDE.md 里信噪比最高的部分——每条 Gotcha 都是真实踩过的坑，并非你能预测到的边缘情况
环境信息 各环境地址/端口、数据库只读连接、Mock 服务开关、环境间差异清单（哪些配置在 dev 和 staging 不一样） "测试环境在 http://test:3000" — AP-4：硬编码绝对路径，别人用不了 AI 不需要每次问"测试环境在哪"。环境间差异清单能避免"在 staging 测通过了、灰度一开崩了"的经典事故
术语表 业务术语在代码中的实际名称、缩写展开、历史别名（这个模块三年前叫 X 现在叫 Y） 缺失时 AI 会把「订单」理解成 Transaction，而你代码里叫 Order AP-3 禁止过期引用。术语表让 AI 不误解
提交约定 [claude-context] 标签的使用规则、CHANGELOG 同步要求 没有提交规则时，每次 AI 生成的 commit message 格式不统一 一次 commit 不规范，影响 AI 后续所有建议准确度
模型选择策略 什么任务用什么模型（日常用 Sonnet 5、架构评审用 Opus、大批量回归用 Haiku） "使用 claude-3-opus" — AP-3：写死模型名，升级后就废了 描述选型标准而非具体模型名，模型迭代后无需改 CLAUDE.md
禁用规则 绝对不能碰的操作、禁止访问的目录、需要额外确认的高危命令 缺失时 AI 可能直接操作生产数据库或执行 git push --force 安全兜底——宁可多一条规则，不可少一条

        两个核心原则：

  1. CLAUDE.md 放"AI 最容易答错"的信息，以及"最不权威"的信息。 从反模式画廊里提取一个最典型的例子：你写"注意支付模块"，AI 收到了零信息量。你写"支付模块的幂等验证曾在 BUG-3056 中漏了回调超时场景，涉及支付的功能必须覆盖回调超时 + 重复回调"，AI 每次都会带上这个检查。

  2. 控制在 60 行左右，200 行是绝对上界。 超过之后后面的规则会被无声降优先级。如果你发现 CLAUDE.md 快要超了，用子目录分层——根目录 .claude/CLAUDE.md 放 30 行通用规则，tests/api/.claude/CLAUDE.md 放接口测试专属规则，Claude Code 会从当前目录向上合并加载。

五、一个完整的请求到上线的时间线

        笔者用一个真实的日常例子串一遍。

上午 10:00 —— 收到需求

        产品发来飞书文档："用户端新增一键复购功能"。

        Claude Code 操作：

"Read 这个需求文档，对照项目关键风险区域，输出测试点"

        输出：15 个测试点，其中 3 个标注了历史关联缺陷（满减叠加 BUG-3089、优惠券并发领取 BUG-3112、订单创建幂等 BUG-2087）。

上午 10:15 —— 设计用例

        以前要对着 Excel 模板一条条编。现在结合研发的技术文档用 Skill 自动生成了初版用例，再用 CLAUDE.md 中的断言标准逐条 review。

下午 14:00 —— 开发提 PR

        Git Hook 自动触发影响分析——Claude Code 读完 git diff，输出"改动涉及订单模块和支付模块，这两个都是关键风险区域，建议重点回归幂等、并发、回调超时三个场景。"

下午 15:00 —— 执行测试

        笔者不直接在主对话里跑测试——上下文会被几千行测试日志撑爆。而是让 test-runner Subagent 去执行：UI 回归用 Playwright MCP，接口回归用 pytest。Subagent 跑完只回传一份简短摘要——"156 个用例，8 个失败，其中 5 个是订单字段变更导致的断言错误"。

        值得一提的是 7 月更新的 autoMode.classifyAllShell 配置——所有 Bash 命令都过自动模式分类器，后台跑回归的时候即使出现了意料之外的命令（比如某个测试脚本自动触发了 deploy），也会被拦截或要求确认。

下午 16:30 —— 回归分析

        CI 跑完之后 regression-analyst Skill 自动输出分析报告，Notification Hook 直接把报告推送到飞书群里：

  • 通过率 94.2%（较上轮降 2.1pct）
  • 3 个失败全部是支付回调超时——疑似预发环境的支付模拟服务不稳定
  • 无新增 flaky case
  • 建议：排查支付模拟服务，用例本身没问题，可以上线

        整个过程笔者在开会，等打开手机看飞书消息的时候，报告已经在那儿了。

下午 17:00 —— 发版

        开发确认支付超时是环境问题，发版。整个测试流程，从收到需求到确认可以上线，6 小时。而核心测试设计时间（需要人脑判断的部分）不到 1 小时，其余全是 Claude Code 持续参与的。

下午 18:00 —— 下班

        哈哈哈，最终幻想，实际上还得继续坐着。

后记

        现在的工作趋势其实是人 + 智能体的组合，这样能够抗衡研发 AI 提效的产出。实际上，ClaudeCode 作为我们测试的智能体，已经是非常优秀的选择了，唯独近期这个产品自降口碑的一些龌龊勾当之事败坏好感，另外一边 CodeX 在持续发光发热。

        另外就是关于 Token 消耗上，其实大多数公司已经经历过了一波裁员，其实也就是为了给 Token 腾出空间。但近期各个大厂回归理性，Token 降低成为了常态，面对这种情况下，一方面是多用 DeepSeek，另外一方面就是把你的 ClaudeCode 打造一番，这样打造的收益直接降低了你 Token 的消耗成本。

「原创声明：保留所有权利，禁止转载」
3 个赞
共收到 3 条回复 时间 点赞
feng666 #1 · 2026年07月07日

蹲到最新的文章。现在这环境，测试 qa 还有得玩不。

KaZaKy #2 · 2026年07月07日

复杂的业务场景，比如多平台的联动，好像做起来是有点困难

takaの #3 · 2026年07月07日

笔者不直接在主对话里跑测试——上下文会被几千行测试日志撑爆。而是让 test-runner Subagent 去执行：UI 回归用 Playwright MCP，接口回归用 pytest。Subagent 跑完只回传一份简短摘要——"156 个用例，8 个失败，其中 5 个是订单字段变更导致的断言错误"。 这里不太懂 为什么叫回归测试 而不是测试？你们生成的用例是完全 AI 可以遵照执行的吗？ 那么执行用例时 ai 需要了解的业务逻辑，库表关系是怎么处理的，ai 断言是怎么处理的啊

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册。