最近不少测试同学开始有了新焦虑接口自动化刚跑稳行业里已经开始聊大模型测试开发、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 CodeAnthropic 推出的命令行软件工程智能体可以读取项目代码、调用 Shell 命令、修改文件、执行测试。对测试开发来说它更像一个“能干活的下属”你说清需求它负责操作工程。TRAE目前字节跳动推出的 AI IDE强调把大模型能力嵌入编辑器开发流程。它更适合在编码界面里让 AI 辅助补全、重构、解释报错。Skill可以理解为给智能体准备的“岗位说明书”。Claude Code 等支持 Skill 的工具会按照一个约定好的方式读取技能目录当用户描述的任务命中某个技能时模型按技能内定义的规范输出。DeepSeek作为大模型能力提供方既可以作为智能问答和代码生成的后端模型也可以在企业内网私有化部署解决测试数据不能出域的合规问题。智能体能独立拆分任务、调用工具、根据执行结果调整下一步的 AI 程序。普通脚本是“按固定步骤执行”智能体是“自己决定步骤并执行”。1.3 一套完整的 AI 测试工作流长什么样把上面工具拼起来一条理想的测试工作流大致如下测试人员在 Claude Code 中描述测试目标。模型根据目标自动选择对应的 Skill。Skill 约束模型输出符合团队规范的 pytest 代码。测试脚本在本地或 CI 环境执行。测试失败时智能体读取失败日志给出原因推测和修复补丁。性能、车载、嵌入式等场景配合 Python 脚本做数据采集与日志分析。也就是说Claude Code、TRAE、Skill、DeepSeek 不是互相替代的关系。IDE 负责“写代码时的人机协作”命令行 Agent 负责“跑任务时的自动执行”Skill 负责“让输出更规范”DeepSeek 或其它大模型则负责“思考与生成”。2. 搭建环境Python、Claude Code 与 TRAE2.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时返回code0和 token否则返回错误码。4.2 创建被测接口服务文件路径app.pyfrom flask import Flask, request, jsonify app Flask(__name__) app.route(/api/user/login, methods[POST]) def login(): data request.get_json(silentTrue) 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(host127.0.0.1, port8080, debugFalse)启动服务python app.py启动后不要关闭终端另开一个终端继续后续操作。4.3 使用 Claude Code 生成测试用例被测接口准备好后在项目根目录运行claude然后输入请使用 api-test-case skill为 http://127.0.0.1:8080/api/user/login 接口生成 pytest 测试文件。 接口返回规则 - 缺少 username 时code1001 - password 错误时code1002 - 正确登录时code0data 中包含 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.pyimport 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}, timeout5, ) 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, jsonpayload, timeout5, ) body resp.json() assert resp.status_code 200 assert body[code] ! 0运行结果应全部通过4 passed in 0.23s4.5 案例小结这个案例虽然不是特别复杂但它体现了 AI 测试工作流的核心不是让模型“一次性写对”而是用 Skill 约束规范、用 pytest 验证输出、再把失败信息反馈给模型形成闭环。实际项目中接口数量可能很多只要你的接口文档完整完全可以批量让 Claude Code 按同一套 Skill 生成用例然后把精力集中在评审和补充边界条件上。5. 完善性能测试让 Agent 辅助压测和报告5.1 性能测试脚本的开发思路传统性能测试要装 JMeter、设计线程组、配置监听器。现在很多接口级性能测试可以直接用 Python 脚本实现。配合 Claude Code 或 TRAE脚本开发速度会快很多。性能测试脚本并不需要太复杂核心是控制并发数和总请求数。记录每个请求耗时和成功失败状态。统计平均耗时、P50、P95、P99。将数据输出或写文件。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}, timeout10, ) 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_workersCONCURRENCY) 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(fP50: {median(latencies):.2f} ms) print(fP95: {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 ms5.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 写一个轻量智能体下面是一个轻量级“测试结果分析智能体”的示例。它的工作流程是执行pytest收集测试结果。把测试报告发送给大模型。让大模型返回失败原因与修复建议。先读取环境变量保证 API Key 不写进代码。export LLM_API_KEY你的大模型API Key export LLM_BASE_URLhttps://api.deepseek.com export LLM_MODELdeepseek-chat文件路径tools/ai_test_analyzer.pyimport os import json import subprocess import requests def run_pytest(): result subprocess.run( [pytest, tests/, -q, --tbshort], capture_outputTrue, textTrue, ) 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: fBearer {api_key}, Content-Type: application/json, }, json{ model: model, messages: [{role: user, content: prompt}], temperature: 0.2, }, timeout60, ) 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 很难替工程师连台架、插线束但可以在以下环节提供明显帮助报文解析把 DBC 文件里的报文说明给大模型让它解释某个信号位于哪个字节、用什么换算公式。诊断用例生成根据 UDS 诊断需求生成诊断测试步骤和预期响应。日志分析车载路试日志量大先用脚本做关键字过滤再用大模型做根因猜测。例如在车载项目里常见的做法是让 Claude Code 读取 DBC 信号描述再根据报文 ID 或信号名自动生成 Python 解析代码。这类需求依赖项目内部的报文库和协议文档编写 Skill 时要把协议文档、信号换算规则注明避免模型凭经验猜测。7.2 嵌入式测试单元测试生成和串口日志分析嵌入式测试更关注代码运行在资源受限环境下的正确性。比如 C 语言模块测试、串口日志分析、内存和 CPU 占用统计。AI 在嵌入式测试中比较实用的三个方向生成 C 语言单元测试框架代码例如 Unity、CMock 风格的测试函数。分析串口打印日志把大量相似错误聚合成几类减少人工盯屏。根据板端资源信息辅助分析内存泄漏可能性。下面是一个通用的日志聚类脚本可用于车载、嵌入式设备保存下来的文本日志对 ERROR、WARN 按模块统计。文件路径tools/log_analyzer.pyimport re from collections import Counter LOG_PATTERN re.compile( r\[(?PlevelERROR|WARN|INFO)\].*?(?Pmodule\w):(?Pmessage.*) ) def main(log_path: str): counter Counter() error_samples [] with open(log_path, r, encodingutf-8, errorsignore) 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 登录或请求失败账号权限未开通、API Key 配置错误或网络无法访问官方服务确认账号权限、检查环境变量、在符合官方网络要求的环境下操作Skill 没有被自动触发description 写得太泛模型没有判断出适用场景在描述中增加触发条件例如“当用户提供接口路径时”生成的 pytest 用例不符合规范Skill 中缺少硬性规则或规则放在提示词后方被模型忽略把最重要规则放在 Skill 文件靠前位置并加“必须”字样pytest 执行时报模块找不到虚拟环境未激活或依赖未安装激活虚拟环境后重新pip install -r requirements.txt性能测试大量超时压测目标不明确、并发数过大或目标服务资源不足先小并发验证脚本正确性再逐步增加并发日志分析脚本统计结果为空日志格式与正则不匹配先手工打印前 5 行日志调整正则后重试大模型分析报告不够准确输入上下文不足或模型不了解项目背景在提示词中补充接口文档、协议描述或日志样例如果生成的代码反复报错不要一直重新生成。更有效的做法是把完整报错信息贴回给 Claude Code并明确要求“先解释根因再给出修复代码”。大多数情况下模型根据错误信息定位问题的能力比凭空重写要好得多。9. 工程实践与进阶建议9.1 把 Skill 当作代码管理Skill 文件本质上是项目资产。建议把它提交到 Git 仓库和测试代码一起评审、一起版本管理。一个比较合理的团队流程是由测试负责人定义用例规范起草 SKILL.md。在少量样本接口上验证输出效果。不满足要求时调整 Skill而不是反复修正单个用例。稳定后冻结 Skill让所有成员统一使用。当团队里不同人用同一个 Skill 生成结果仍然不稳定时往往不是 Skill 写得不够好而是模型版本有差异。此时可以把核心规则提取到更明确的步骤中让模型“按步骤执行”而不是“理解风格”。9.2 数据安全与授权边界无论用什么模型都需要考虑数据安全问题。强烈建议遵守三条底线不把未经脱敏的生产数据提交给外部模型。涉及真实车辆、车联网、嵌入式设备的数据时先确认数据是否可以离开测试环境。大模型生成的代码必须经过 review 后才能进入自动化流水线。企业内部如果对代码和数据有强管控要求可以考虑私有化部署开源模型。AI 测试的工具链模式不变只是大模型来源从云端 API 换成内网地址。9.3 明确 AI 测试的边界AI 测试并不意味着大模型真的“理解”测试业务。它更擅长做模式匹配、代码转换、信息归纳但对业务规则的理解依然不可靠。尤其是嵌入式硬件、车辆控制这类对正确性要求极高的领域AI 生成的用例只能作为初稿必须由熟悉业务的人补齐边界和异常路径。一个健康的使用方式是AI 生成初稿 - 人工补齐业务边界 - 自动执行 - AI 分析失败 - 人工确认根因把 AI 放在“快但不是绝对正确”的位置上反而能最大化提效。9.4 后续可以往哪个方向深入如果你刚开始接触 AI 测试不用一步到位学习所有工具。可以按这个顺序推进先安装 Claude Code 或 TRAE把一个测试项目交给 AI观察输出质量。编写第一个 Skill把团队已有接口测试规范沉淀进去。尝试让 AI 修复 pytest 失败用例