大模型测试开发工作流：Claude Code、Skill与pytest实战

最近不少测试同学开始有了新焦虑：接口自动化刚跑稳，行业里已经开始聊大模型测试开发、AI Agent、智能体；性能测试刚学会用 JMeter 写线程组，网上又冒出“让 AI 写性能脚本、自动分析报告”的玩法；车载测试、嵌入式测试的同学也被问到“你会不会用 AI 辅助解析报文与日志”。

这些信息不是贩卖焦虑，而是测试开发这个岗位真的在换工具链。本文不打算把 Claude Code、TRAE、Skill、DeepSeek 这些词逐个做成名词解释，而是把它们组合成一条测试开发工作流：从环境搭建、Skill 编写、pytest 自动化用例生成，到性能测试辅助、智能体编排，再到车载与嵌入式场景的落地点。内容适合想转 AI 测试方向的进阶测试工程师，也适合正在搭建 AI 自动化测试平台的团队参考。

1. 大模型测试开发：测试工程师的新技能树

1.1 从自动化测试到 AI 测试

传统自动化测试的基本思路，是人写脚本、脚本执行断言、最后人工分析报告。这套流程最大的瓶颈不是框架，而是“把业务需求翻译成用例代码”的成本。

AI 测试并不是把测试人员替换掉，而是把最花时间的部分——需求理解、代码生成、数据构造、失败日志归因——交给大模型先做一轮，再由测试人员审核、修正、补充边界。

于是出现了新的岗位能力要求：AI 测试工程师不仅要懂 pytest、Selenium、性能测试，还要会跟大模型对话，会设计 Agent 的工作流程，会让工具按照团队规范产出稳定结果。

这也是“大模型测试开发”真正的含义：测试开发本身没有消失，只是它的开发对象从“测试脚本”扩展到了“测试智能体”。

1.2 Claude Code、TRAE、Skill、DeepSeek、智能体分别是什么

在一个测试团队里，这几个概念很容易混淆，先做一个简单分工。

• Claude Code：Anthropic 推出的命令行软件工程智能体，可以读取项目代码、调用 Shell 命令、修改文件、执行测试。对测试开发来说，它更像一个“能干活的下属”，你说清需求，它负责操作工程。
• TRAE：目前字节跳动推出的 AI IDE，强调把大模型能力嵌入编辑器开发流程。它更适合在编码界面里让 AI 辅助补全、重构、解释报错。
• Skill：可以理解为给智能体准备的“岗位说明书”。Claude Code 等支持 Skill 的工具会按照一个约定好的方式读取技能目录，当用户描述的任务命中某个技能时，模型按技能内定义的规范输出。
• DeepSeek：作为大模型能力提供方，既可以作为智能问答和代码生成的后端模型，也可以在企业内网私有化部署，解决测试数据不能出域的合规问题。
• 智能体：能独立拆分任务、调用工具、根据执行结果调整下一步的 AI 程序。普通脚本是“按固定步骤执行”，智能体是“自己决定步骤并执行”。

1.3 一套完整的 AI 测试工作流长什么样

把上面工具拼起来，一条理想的测试工作流大致如下：

1. 测试人员在 Claude Code 中描述测试目标。
2. 模型根据目标自动选择对应的 Skill。
3. Skill 约束模型输出符合团队规范的 pytest 代码。
4. 测试脚本在本地或 CI 环境执行。
5. 测试失败时，智能体读取失败日志，给出原因推测和修复补丁。
6. 性能、车载、嵌入式等场景配合 Python 脚本做数据采集与日志分析。

也就是说，Claude Code、TRAE、Skill、DeepSeek 不是互相替代的关系。IDE 负责“写代码时的人机协作”，命令行 Agent 负责“跑任务时的自动执行”，Skill 负责“让输出更规范”，DeepSeek 或其它大模型则负责“思考与生成”。

2. 搭建环境：Python、Claude Code 与 TRAE

2.1 准备 Python 与 pytest 环境

AI 测试开发仍然离不开 Python，因为最终执行测试的还是本地脚本。下面以 Python 3.10+ 环境为例，Windows、macOS、Linux 都适用。

建议先创建虚拟环境，避免把依赖装到系统 Python 里。

python3 -m venv .venv source .venv/bin/activate # Windows 下执行 .venv\Scripts\activate pip install --upgrade pip pip install pytest requests flask pytest-html

安装完成后验证一下：

pytest --version

如果命令找不到，可以检查虚拟环境是否激活，或者用python3 -m pytest --version代替。

2.2 安装 Claude Code

不同版本的 Claude Code 安装方式可能略有差异，最常用的方式是通过 npm 全局安装：

node -v npm -v npm install -g @anthropic-ai/claude-code

安装完成后运行：

claude --version

正常会显示版本号。确认版本号后，运行claude进入交互界面。首次使用需要确认账号权限和 API 访问方式。如果使用 API Key，可以提前在环境变量中配置：

export ANTHROPIC_API_KEY="你的API Key"

提醒一句：Claude Code 的安装、登录、调用都依赖 Anthropic 官方服务能被正常访问，并且账号有对应使用权限。如果团队网络无法访问官方服务，工程上更多会选择国内可直接调用的模型 API 或私有化模型服务，不建议强行绕过限制。

2.3 安装 TRAE 并理解它与 Claude Code 的搭配

TRAE 目前可以直接从官网或应用商店下载桌面版。安装后一般会引导你设置语言、模型来源和代码目录。

TRAE 的好处在于，它把 AI 放在 IDE 旁边，适合边看代码边让模型修改。比如 pytest 用例报错了，你可以直接框选报错信息，让 TRAE 里的模型解释原因；也可以让它重写某个测试文件。

在实际项目中，推荐的搭配方式是：

• Claude Code：适合执行批处理任务，比如批量生成测试脚本、批量修复报错、按 Skill 统一整理代码。
• TRAE：适合单文件级别的交互式开发，比如人工审核智能体改过的代码、对局部逻辑进行重构。

它们在工程上是互补的，并不冲突。

2.4 推荐的项目目录结构

测试项目尽量保持结构清晰，方便 Claude Code 理解工程上下文。下面是一个参考结构：

ai-test-demo/ ├── .venv/ # Python 虚拟环境 ├── .claude/ │ └── skills/ │ └── api-test-case/ │ └── SKILL.md # 测试用例生成技能 ├── app.py # 被测本地接口服务 ├── tests/ │ ├── conftest.py # pytest 公共配置 │ └── test_login_api.py # 接口自动化用例 ├── tools/ │ ├── local_perf.py # 本地压测脚本 │ └── log_analyzer.py # 日志分析脚本 └── reports/ # 测试报告输出目录

目录越规范，大模型读取上下文时越不容易出错。

3. 用 Skill 约束 Claude Code 生成测试用例

3.1 理解 Claude Code 的 Skill 机制

直接让大模型“写用例”通常能得到一段看起来能运行的代码，但并不能保证符合团队规范。比如有的团队要求所有接口用例必须包含超时断言、有的团队要求用例必须参数化。如果每次都靠人工在提示词里反复说明，效率太低，而且容易遗漏。

Skill 解决的就是这个问题。它通常是一个 Markdown 文件，内部描述某类任务的输出规范、步骤和示例。当用户请求与 Skill 的 description 匹配时，Claude Code 会读取这个技能并按照约束执行。

Skill 目录常见位置是项目下的.claude/skills/，每个技能一个目录，目录内必须有SKILL.md文件。

3.2 编写一个 api-test-case Skill

下面是一个用于接口自动化用例生成的简单 Skill。

文件路径：.claude/skills/api-test-case/SKILL.md

--- name: api-test-case description: 当用户需要基于接口描述生成 pytest 接口测试用例、对既有接口测试进行参数化扩展，或补充异常场景用例时，使用本技能。 --- # 接口自动化测试用例生成规范 ## 目标 生成符合项目要求的 pytest 接口测试用例，减少模型输出的随意性。 ## 必须遵循的规则 1. 如果项目中已有 API Client 封装，必须复用，不要重复创建连接逻辑。 2. 每个接口至少覆盖： - 正常入参 - 缺失必填参数 - 参数类型错误 - 鉴权失败场景 3. 请求必须设置 timeout。 4. 断言必须包含 HTTP 状态码、业务字段、响应时间阈值。 5. 使用 pytest.mark.parametrize 管理多组数据，不要复制粘贴多个函数。 ## 输出格式 返回一个新的 .py 文件路径，以及简短的用例设计说明。修改文件前先说明修改点，等待用户确认后再执行。

这个 Skill 看起来不像传统配置文件，但它传达给模型的信息非常丰富。模型读到之后，不只是“生成代码”，而是会严格按照规范执行。

3.3 在 Claude Code 中触发 Skill

进入 Claude Code 后，可以直接用自然语言触发：

请使用 api-test-case skill，为下面的接口生成 pytest 测试用例： POST /api/user/login 请求参数：username、password 本地服务地址：http://127.0.0.1:8080

执行后，Claude Code 会先读取 Skill 文件，再根据技能里的规则生成测试代码。这样做的好处是，即使换一个项目、换一批人，只要 Skill 文件相同，输出风格就会保持稳定。

3.4 Skill 使用注意事项

编写 Skill 时最容易遇到的问题不是模型读不懂，而是描述太宽泛。比如 description 只写“生成测试”，模型就无法准确判断什么时候该触发。

更好的做法是在 description 中写明触发条件，例如：

• “当用户给出接口路径和参数时”
• “当用户要求补充参数化用例时”
• “当 pytest 用例风格不符合项目现有风格时”

另外，Skill 文件不要写得像一本百科全书，重点写“必须遵守的规则”和“输出格式”，这类命令式约束对模型最有效。

4. 完整案例：生成 pytest 接口自动化用例

4.1 项目目标与需求

为了演示效果，本文在本地搭建一个最简单的登录接口，然后让 Claude Code 按 Skill 生成 pytest 用例。

被测服务使用 Flask，接口地址为：

POST http://127.0.0.1:8080/api/user/login

请求数据为 JSON：

{ "username": "tester", "password": "123456" }

接口逻辑：当用户名不等于空、密码等于123456时，返回code=0和 token；否则返回错误码。

4.2 创建被测接口服务

文件路径：app.py

from flask import Flask, request, jsonify app = Flask(__name__) @app.route("/api/user/login", methods=["POST"]) def login(): data = request.get_json(silent=True) or {} username = data.get("username") password = data.get("password") if not username: return jsonify({"code": 1001, "message": "username is required"}), 200 if password != "123456": return jsonify({"code": 1002, "message": "invalid username or password"}), 200 return jsonify({ "code": 0, "message": "success", "data": {"token": "fake-token"} }), 200 if __name__ == "__main__": app.run(host="127.0.0.1", port=8080, debug=False)

启动服务：

python app.py

启动后不要关闭终端，另开一个终端继续后续操作。

4.3 使用 Claude Code 生成测试用例

被测接口准备好后，在项目根目录运行claude，然后输入：

请使用 api-test-case skill，为 http://127.0.0.1:8080/api/user/login 接口生成 pytest 测试文件。 接口返回规则： - 缺少 username 时，code=1001 - password 错误时，code=1002 - 正确登录时，code=0，data 中包含 token 请将文件放到 tests/test_login_api.py。

Claude Code 会根据 Skill 自动生成代码。由于不同模型生成结果会有差异，最关键的是审核它是否满足项目规范。如果生成结果不够理想，可以继续追问：

补充一组“密码为 None”和“请求体不是 JSON”的异常用例。

4.4 运行并修复用例

生成代码后，在终端执行：

pytest tests/test_login_api.py -v

下面是一份符合 Skill 要求的参考结果，供你对照审核：

文件路径：tests/test_login_api.py

import requests import pytest BASE_URL = "http://127.0.0.1:8080" class TestLoginAPI: def test_login_success(self): resp = requests.post( f"{BASE_URL}/api/user/login", json={"username": "tester", "password": "123456"}, timeout=5, ) body = resp.json() assert resp.status_code == 200 assert body["code"] == 0 assert "token" in body["data"] assert resp.elapsed.total_seconds() < 1.0 @pytest.mark.parametrize( "payload", [ {"password": "123456"}, {"username": "", "password": "123456"}, {"username": "tester"}, {"username": "tester", "password": "wrong"}, ], ids=["missing_username_field", "empty_username", "missing_password", "wrong_password"] ) def test_login_invalid(self, payload): resp = requests.post( f"{BASE_URL}/api/user/login", json=payload, timeout=5, ) body = resp.json() assert resp.status_code == 200 assert body["code"] != 0

运行结果应全部通过：

4 passed in 0.23s

4.5 案例小结

这个案例虽然不是特别复杂，但它体现了 AI 测试工作流的核心：不是让模型“一次性写对”，而是用 Skill 约束规范、用 pytest 验证输出、再把失败信息反馈给模型形成闭环。

实际项目中，接口数量可能很多，只要你的接口文档完整，完全可以批量让 Claude Code 按同一套 Skill 生成用例，然后把精力集中在评审和补充边界条件上。

5. 完善性能测试：让 Agent 辅助压测和报告

5.1 性能测试脚本的开发思路

传统性能测试要装 JMeter、设计线程组、配置监听器。现在很多接口级性能测试可以直接用 Python 脚本实现。配合 Claude Code 或 TRAE，脚本开发速度会快很多。

性能测试脚本并不需要太复杂，核心是：

1. 控制并发数和总请求数。
2. 记录每个请求耗时和成功失败状态。
3. 统计平均耗时、P50、P95、P99。
4. 将数据输出或写文件。

5.2 本地接口压测脚本示例

文件路径：tools/local_perf.py

下面脚本只用于本地或已获得授权的测试环境，不能对未授权目标压测。

import time import requests from concurrent.futures import ThreadPoolExecutor from statistics import mean, median TARGET_URL = "http://127.0.0.1:8080/api/user/login" CONCURRENCY = 10 TOTAL_REQUESTS = 100 def one_request(_): start = time.perf_counter() try: resp = requests.post( TARGET_URL, json={"username": "tester", "password": "123456"}, timeout=10, ) ok = resp.status_code == 200 and resp.json().get("code") == 0 except Exception: ok = False cost_ms = (time.perf_counter() - start) * 1000 return ok, cost_ms def main(): results = [] with ThreadPoolExecutor(max_workers=CONCURRENCY) as pool: for ok, cost_ms in pool.map(one_request, range(TOTAL_REQUESTS)): results.append((ok, cost_ms)) success_count = sum(1 for ok, _ in results if ok) error_count = TOTAL_REQUESTS - success_count latencies = sorted(cost_ms for _, cost_ms in results) p95_index = max(0, int(len(latencies) * 0.95) - 1) print(f"总请求数: {TOTAL_REQUESTS}") print(f"并发数: {CONCURRENCY}") print(f"成功数: {success_count}, 失败数: {error_count}") print(f"平均耗时: {mean(latencies):.2f} ms") print(f"P50: {median(latencies):.2f} ms") print(f"P95: {latencies[p95_index]:.2f} ms") if __name__ == "__main__": main()

运行：

python tools/local_perf.py

输出示例：

总请求数: 100 并发数: 10 成功数: 100, 失败数: 0 平均耗时: 12.35 ms P50: 8.21 ms P95: 35.67 ms

5.3 让 Claude Code 参与性能测试代码优化

本地压测脚本写完后，可以把它丢给 Claude Code 做 review。进入项目根目录运行claude，然后输入：

请阅读 tools/local_perf.py，从以下几个角度帮我优化： 1. 如果某个请求一直超时，当前脚本会不会卡住？ 2. 如何增加更多的耗时分布统计，比如 P99、最大耗时？ 3. 是否支持把统计结果追加写入 CSV 方便后续生成趋势图？

模型给出的修改建议往往不一定完全符合项目场景，需要人工判断后选择哪些建议采纳。长期来看，可以把团队常用性能分析口径写入一个perf-review.skill，让后续每次性能分析都沿用同一套标准。

6. AI 测试常用集成：DeepSeek、大模型 API 与智能体

6.1 DeepSeek 在测试工具链中的定位

在 AI 测试工具链里，DeepSeek 可以作为大模型后端使用。它既可以在 TRAE、各种 AI IDE 中作为模型来源，也可以通过 API 被 Python 脚本调用，用于日志归因、报告总结、测试数据生成等。

工程上需要考虑的是：测试数据往往来自业务库，直接提交给外部大模型可能存在合规风险。DeepSeek 的优势在于支持私有化和国内直接调用，团队可以根据数据敏感程度选择云端 API 还是私有部署。

调用方式一般遵循 OpenAI 兼容协议，因此很多工具可以通过配置 Base URL 和 API Key 接入。

6.2 用 Python 写一个轻量智能体

下面是一个轻量级“测试结果分析智能体”的示例。

它的工作流程是：

1. 执行pytest收集测试结果。
2. 把测试报告发送给大模型。
3. 让大模型返回失败原因与修复建议。

先读取环境变量，保证 API Key 不写进代码。

export LLM_API_KEY="你的大模型API Key" export LLM_BASE_URL="https://api.deepseek.com" export LLM_MODEL="deepseek-chat"

文件路径：tools/ai_test_analyzer.py

import os import json import subprocess import requests def run_pytest(): result = subprocess.run( ["pytest", "tests/", "-q", "--tb=short"], capture_output=True, text=True, ) return result.stdout + result.stderr def analyze_with_llm(report_text): api_key = os.getenv("LLM_API_KEY") base_url = os.getenv("LLM_BASE_URL", "https://api.deepseek.com") model = os.getenv("LLM_MODEL", "deepseek-chat") prompt = f"""你是一名资深测试开发工程师。 下面是一次 pytest 执行的输出，请帮我分析失败原因，并给出修复建议。 要求： 1. 先列出失败用例数量。 2. 按失败原因分组。 3. 给每个失败点给出最可能的修复代码片段。 测试输出： {report_text[:6000]} """ response = requests.post( f"{base_url}/chat/completions", headers={ "Authorization": f"Bearer {api_key}", "Content-Type": "application/json", }, json={ "model": model, "messages": [{"role": "user", "content": prompt}], "temperature": 0.2, }, timeout=60, ) response.raise_for_status() return response.json()["choices"][0]["message"]["content"] if __name__ == "__main__": report = run_pytest() print("======== pytest 原始输出 ========") print(report) print("======== AI 分析结果 ========") print(analyze_with_llm(report))

这段代码是典型的大模型测试开发案例：程序本身负责确定性执行，大模型负责不确定性分析。最终输出是否采纳，仍然要由测试人员判断。

6.3 智能体与普通自动化脚本的区别

普通脚本就像流水线，每一步都是提前写好的：

运行测试 -> 输出报告 -> 人工分析

智能体则多了一个“分析-决策-行动”的循环：

运行测试 -> 收集输出 -> 调用大模型分析 -> 如果失败则按建议修复 -> 重新运行测试

这个循环不能做成完全无人值守。因为大模型可能给出错误修复，导致测试被“修坏”。合理的工程实践是让智能体生成修复补丁，但必须由人工 review 后再应用。

7. 车载测试与嵌入式测试的 AI 辅助场景

7.1 车载测试：从报文解析、诊断用例到日志归因

车载测试与普通 Web 测试差别很大，涉及 CAN 总线、UDS 诊断、台架 HIL、实车路试等。AI 很难替工程师连台架、插线束，但可以在以下环节提供明显帮助：

1. 报文解析：把 DBC 文件里的报文说明给大模型，让它解释某个信号位于哪个字节、用什么换算公式。
2. 诊断用例生成：根据 UDS 诊断需求，生成诊断测试步骤和预期响应。
3. 日志分析：车载路试日志量大，先用脚本做关键字过滤，再用大模型做根因猜测。

例如在车载项目里，常见的做法是让 Claude Code 读取 DBC 信号描述，再根据报文 ID 或信号名自动生成 Python 解析代码。这类需求依赖项目内部的报文库和协议文档，编写 Skill 时要把协议文档、信号换算规则注明，避免模型凭经验猜测。

7.2 嵌入式测试：单元测试生成和串口日志分析

嵌入式测试更关注代码运行在资源受限环境下的正确性。比如 C 语言模块测试、串口日志分析、内存和 CPU 占用统计。

AI 在嵌入式测试中比较实用的三个方向：

1. 生成 C 语言单元测试框架代码，例如 Unity、CMock 风格的测试函数。
2. 分析串口打印日志，把大量相似错误聚合成几类，减少人工盯屏。
3. 根据板端资源信息，辅助分析内存泄漏可能性。

下面是一个通用的日志聚类脚本，可用于车载、嵌入式设备保存下来的文本日志，对 ERROR、WARN 按模块统计。

文件路径：tools/log_analyzer.py

import re from collections import Counter LOG_PATTERN = re.compile( r"\[(?P<level>ERROR|WARN|INFO)\].*?(?P<module>\w+):(?P<message>.*)" ) def main(log_path: str): counter = Counter() error_samples = [] with open(log_path, "r", encoding="utf-8", errors="ignore") as fp: for line in fp: match = LOG_PATTERN.search(line) if not match: continue level = match.group("level") module = match.group("module") counter[(level, module)] += 1 if level == "ERROR" and len(error_samples) < 50: error_samples.append(line.strip()) print("===== 日志级别/模块统计 Top 10 =====") for (level, module), count in counter.most_common(10): print(f"{level:5s} {module:20s} {count}") print("\n===== 错误样本前 5 条 =====") for sample in error_samples[:5]: print(sample) if __name__ == "__main__": main("device.log")

这类脚本的价值在于，它能减少大模型的“阅读量”。智能体不需要一次读完几万行日志，只要读取聚类后的统计结果，就可以快速给出排查方向。

7.3 给 Agent 设计“人机边界”

车载和嵌入式场景往往涉及真实硬件，操作错误可能会造成安全问题。所以在这些领域使用 AI Agent 要特别注意边界：

• 不直接让 Agent 操作真实台架或车辆，除非有完整的权限控制和急停机制。
• 不把原始生产日志直接发到外部大模型，先做脱敏和聚合。
• Agent 只负责生成测试方案、脚本、解析结果，最终执行和判定由工程师完成。

这也是车载测试、嵌入式测试相比 Web 测试更强调“人机协同”的原因。

8. 常见问题与排查思路

在实际使用 AI 测试工具链时，下面几个问题比较常见：

如果生成的代码反复报错，不要一直重新生成。更有效的做法是把完整报错信息贴回给 Claude Code，并明确要求“先解释根因再给出修复代码”。大多数情况下，模型根据错误信息定位问题的能力比凭空重写要好得多。

9. 工程实践与进阶建议

9.1 把 Skill 当作代码管理

Skill 文件本质上是项目资产。建议把它提交到 Git 仓库，和测试代码一起评审、一起版本管理。

一个比较合理的团队流程是：

1. 由测试负责人定义用例规范，起草 SKILL.md。
2. 在少量样本接口上验证输出效果。
3. 不满足要求时调整 Skill，而不是反复修正单个用例。
4. 稳定后冻结 Skill，让所有成员统一使用。

当团队里不同人用同一个 Skill 生成结果仍然不稳定时，往往不是 Skill 写得不够好，而是模型版本有差异。此时可以把核心规则提取到更明确的步骤中，让模型“按步骤执行”，而不是“理解风格”。

9.2 数据安全与授权边界

无论用什么模型，都需要考虑数据安全问题。强烈建议遵守三条底线：

1. 不把未经脱敏的生产数据提交给外部模型。
2. 涉及真实车辆、车联网、嵌入式设备的数据时，先确认数据是否可以离开测试环境。
3. 大模型生成的代码必须经过 review 后才能进入自动化流水线。

企业内部如果对代码和数据有强管控要求，可以考虑私有化部署开源模型。AI 测试的工具链模式不变，只是大模型来源从云端 API 换成内网地址。

9.3 明确 AI 测试的边界

AI 测试并不意味着大模型真的“理解”测试业务。它更擅长做模式匹配、代码转换、信息归纳，但对业务规则的理解依然不可靠。尤其是嵌入式硬件、车辆控制这类对正确性要求极高的领域，AI 生成的用例只能作为初稿，必须由熟悉业务的人补齐边界和异常路径。

一个健康的使用方式是：

AI 生成初稿 -> 人工补齐业务边界 -> 自动执行 -> AI 分析失败 -> 人工确认根因

把 AI 放在“快但不是绝对正确”的位置上，反而能最大化提效。

9.4 后续可以往哪个方向深入

如果你刚开始接触 AI 测试，不用一步到位学习所有工具。可以按这个顺序推进：

1. 先安装 Claude Code 或 TRAE，把一个测试项目交给 AI，观察输出质量。
2. 编写第一个 Skill，把团队已有接口测试规范沉淀进去。
3. 尝试让 AI 修复 pytest 失败用例