测试开发这行做久了你会发现每天至少有一半时间耗在不产生任何技术含量的重复劳动里接口变了要补用例、同一份业务逻辑在不同项目里反复写断言、压测脚本换个协议就要重搭一套。这两年AI编程工具特别火但网上讲的基本都是帮程序员写业务代码很少有人说清楚这套东西用在测试开发里到底怎么玩。我花了不少时间把Claude Code、TRAE、DeepSeek这些工具和大模型测试开发的思路揉在一起在Python自动化测试、性能测试还有相对冷门的车载测试和嵌入式测试里都实际跑过一遍。这篇就按我自己的实操顺序来写先把工具选型和环境说清楚再讲用例生成、API调用、Agent编排顺便把B站那些零散讲Claude Code、TRAE、大模型测试开发的视频串成一条完整的落地方案最后单独聊聊车载和嵌入式场景里AI到底能用在哪、哪里不能指望它。1. 测试开发与AI编程工具的适配关系选型比用法更重要1.1 Claude Code、TRAE、DeepSeek在测试开发里分别干哪份活一上来先对齐一个概念现在市面上火的AI编程工具不是同一类东西。Claude Code本质是一个跑在终端里的编程Agent给它一个任务它自己读代码、改文件、跑命令像来了个实习生坐在你终端里干活。TRAE是字节下面的AI IDE它更像VS Code的加强版把聊天、代码补全、多文件改动集成在IDE内部普适性更强。DeepSeek则要拆成两半看一半是可以通过API调用的模型服务一半是可以本地部署的开源模型。这三者的关系不是替代而是不同环节各管一段。我自己的分工是Claude Code负责需要自主执行的重活比如一次性生成一整套pytest工程、把旧的unittest用例批量迁移过来TRAE负责我日常在编辑器里改代码、写断言、补注释因为IDE内联体验更顺手DeepSeek负责两类事一是当成本敏感的备用模型二是本地部署之后做需要内网隔离环境的测试数据生成。这样组合下来既不容易被单一工具绑死也能在模型不可用或限流的时候快速切换。1.2 测试开发场景为什么比纯研发场景更需要AI辅助可能有人觉得测试开发的代码不就是发个请求、做个断言、算个耗时哪里需要AI。实际恰恰相反测试开发的工作有两个特点非常适合AI介入。第一是重复且边界复杂接口自动化要覆盖正常值、边界值、异常值、鉴权失败、超时返回这些用例用人的大脑去穷举很容易漏但给模型一个接口定义它会非常机械地把这些组合列全。第二是业务代码之外有大量一次性脚本需求生成测试数据、解析日志、把Excel用例转成JSON、写个批量压测入口这些脚本写一次就扔专门花一小时手写很不值让AI帮忙几分钟就能糊一个能跑的版本。另外测试领域有一个更独特的场景就是需要对模型的输出做测试。这就是标题里说的大模型测试开发的另一层意思你的被测对象本身是AI能力那么测试用例的设计就要考虑提示词边界、输出格式稳定性、异常输入处理。Claude Code也好、DeepSeek也好在这个场景下既是开发工具又是被测对象的一部分这个双重视角是很多测试工程师还没意识到的。2. 从零起步环境准备与Claude Code、TRAE的落地细节2.1 Python环境装错版本后面全是坑不管是pytest、Locust还是后面要提的车载测试Python库第一步都是把Python环境弄干净。我给的建议非常直接新手直接装Python 3.10或3.11别一上来就追新版本。有些库比如opencv-python、部分嵌入式串口库在Python 3.13这种太新的版本上wheel包还没跟上你装的时候会看到一堆Building wheel报警最后甚至直接编译失败。Windows安装时记得勾选Add Python to PATH这个选项否则你在cmd里敲python会提示找不到命令。环境装好之后强烈建议每个项目建一个虚拟环境。我见过太多同事图省事直接用全局pip装结果项目A要requests 2.28、项目B要requests 3.0直接互相打架。具体命令是python -m venv .venv然后激活Windows下是.venv\Scripts\activatemacOS/Linux下是source .venv/bin/activate。装依赖的时候如果下载速度不理想可以用国内镜像源比如pip install -i https://pypi.tuna.tsinghua.edu.cn/simple opencv-python把opencv这类体积大的包装稳。pip换源本身是Python社区的常规操作放心配。2.2 Claude Code安装配置一次跑通的关键点Claude Code的安装不难但第一次跑通有几个小地方容易卡住。我这边是Node环境里用npm安装的anthropic-ai/claude-code这个包装完之后在终端敲claude进入交互模式。首次启动会让你配置模型访问凭证通常会检查环境变量里有没有对应的API Key没有的话会让你粘贴一个。这里有一个我踩过的坑不要把API Key写进项目配置文件里再提交到Git一旦仓库公开Key就泄漏了。建议单独放在用户级环境变量里项目里只放引用。另一个关键是权限控制。Claude Code能自己执行终端命令这意味着它在测试环境里能跑pytest、能改文件、能装包但如果在生产或预发环境里放开权限风险是很大的。我现在的习惯是默认只放行读取和pytest相关命令涉及安装依赖、改重要配置的让它停下来等人工确认。说白了AI写代码可以冲得快但执行权限不能全是绿灯。2.3 TRAE安装使用与Skill技能包的正确打开方式TRAE的安装比Claude Code省心很多直接去官网下对应平台的安装包装完用账号登录国内版有积分体系模型调用的消耗和你的积分挂钩。官方不定期会放一些兑换码想省积分的话可以多留意活动和更新日志。平时做测试开发我常用TRAE的Chat模式和Build模式Chat模式适合你问一句、它答一句比如帮我解释这段pytest fixture的作用Build模式则是让它跨文件改代码、新建文件、跑命令更像一个能落地的智能体。关于Skill机制我多说一句。TRAE和Claude Code这类工具都支持把一套固定的指令、约束、最佳实践打包成技能之后每次用到就会自动加载。对我的测试团队来说我把pytest用例编码规范接口测试断言模板性能测试报告格式要求这三套东西整理成了技能包。这样不管哪个同事调用AI生成测试代码产出的风格都基本统一团队内的代码评审压力小很多。3. 大模型测试开发实战用例生成、API调用与智能体编排3.1 给模型的上下文里该放什么生成结果才靠谱很多人让AI生成测试用例结果拿到一堆So easy的用例分析下来无非是接口路径、参数名都对了但业务约束、状态流转这些关键信息没喂进去。我的做法是把上下文组织成四个部分接口定义Swagger/OpenAPI或者抓包的请求响应、业务规则状态机、枚举值、边界条件、工程约束框架用pytest还是unittest、断言风格、是否接Allure、已知坑之前线上出过的问题。有了这四块AI生成的用例才不是看起来像而是真正能覆盖到业务风险。这里给一个我常用的示例提示词以Claude Code为例请根据下面的接口定义生成pytest测试用例 接口POST /api/order/submit入参包括userId、skuId、quantity、couponId均为JSON。 业务规则quantity取值1-99超过99直接返回参数错误couponId非必填库存不足时返回400且codeSTOCK_NOT_ENOUGH。 工程约束使用requests库断言用pytest.raises处理异常场景类名TestOrderSubmit全部用例打上allure.feature(订单提交)。 请同时生成正常用例、边界用例、异常用例并为每个用例写上注释说明覆盖的测试意图。这样喂下去出来的代码基本可以直接进工程不用大改。3.2 DeepSeek API调用与本地部署测试数据制造的两条路DeepSeek在测试开发里最常见的使用方式就是造测试数据。造数据听起来简单但真正做业务测试的人都知道最难受的是造符合业务语义的数据。比如订单号要符合某个校验规则、手机号要看起来真实、批量数据之间不能互相冲突。用DeepSeek的API可以通过一段Python代码直接生成一批结构化的测试数据示例import requests url https://api.deepseek.com/chat/completions headers { Authorization: Bearer YOUR_API_KEY, Content-Type: application/json } prompt 请生成20条测试订单数据字段包括订单号以OD开头加8位数字、用户ID整数、金额保留两位小数、状态PENDING/PAID/CANCELLED。要求订单号不重复状态分布为10个PENDING、6个PAID、4个CANCELLED。只输出JSON数组不要其他解释。 payload { model: deepseek-chat, messages: [{role: user, content: prompt}], temperature: 0.3, response_format: {type: json_object} } resp requests.post(url, headersheaders, jsonpayload) print(resp.json()[choices][0][message][content])注意三个细节一是temperature调低一点0.2到0.4生成的数据更稳定二是明确要求只输出JSON避免解析时还要处理一堆解释性文字三是有条件的话把响应校验一下毕竟模型偶尔还是会字段缺失。批量造数脚本我一直当成测试数据工厂来维护它既不是测试代码也不是业务代码但它是整个自动化体系的原料来源。本地部署这条路适合内网环境。很多公司的测试环境不能访问外部API那就用Ollama这类工具把DeepSeek的量化版本拉下来跑在GPU机器上。本地部署的好处是数据不出内网、调用没有次数限制坏处是模型响应速度和效果会打折造简单测试数据完全够用复杂业务逻辑生成还是云端更强的模型胜出。3.3 把Agent串成流水线需求解析、用例生成、执行、分析单个Chat对话已经是过去式了现在更值钱的是组织多个Agent协同。我在团队里搭过一个测试智能体流水线大致分四步需求解析Agent负责读需求文档和接口定义输出关键业务规则和边界清单用例生成Agent根据规则清单生成pytest用例文件执行Agent在测试环境跑这批用例并把结果归类结果分析Agent拿到失败结果后结合日志自动判断是代码缺陷、用例断言过严还是环境问题。这四步之间不是全自动一条路走到黑每个Agent的产出物都要人工确认一次。比如需求解析Agent给出的业务规则清单是后面所有用例的依据这一步错了后面全错。执行Agent跑完的失败用例结果分析Agent只能给建议不能直接改代码提PR。我的经验是Agent流水线把耗时从一人搞一周压到半天到一天但质量把关还是得靠人AI不会为线上的事故负责。4. Python自动化测试与性能测试AI辅助的落地姿势4.1 pytest接口自动化让AI批量生成用例并保持规范接口自动化的核心矛盾是用例数量不能太少少了覆盖不住也不能全是复制粘贴否则维护成本爆炸。AI正好缓解这个矛盾。我之前接手过一个老系统的订单模块Swagger里有30多个接口想让AI一次性生成整个模块的用例。做法是先给它一两个我手工写好的范例用例让它模仿这个风格生成其他接口的用例。这个技巧很关键模型模仿特定代码风格的能力比它凭空发挥的能力要稳定得多。生成完之后不要直接入库我会用脚本做三层检查。第一层是语法检查python -m compileall扫一遍目录避免低级语法错误第二层是静态检查跑一下flake8把未使用导入、明显不符合PEP8的问题清掉第三层是跑一遍冒烟用例确认框架本身没有坏。这三层做完再进代码评审速度快很多。实际体验下来AI生成的pytest代码有个通病就是fixture的scope经常用错有时所有用例共享一个可变对象导致隔离失败评审的时候重点看这类并发和隔离问题。4.2 Locust性能测试脚本从压测计划到可运行代码性能测试和功能测试的思维方式不太一样压测脚本虽然代码量不大但每一步都影响结果的可信度。我自己通常先写压测计划并发数、爬坡时间、持续时间、业务比例再让AI按计划生成Locust脚本。比如下面这个简单的脚本就是AI生成的底子加上我改的压测业务比例from locust import HttpUser, task, between class OrderUser(HttpUser): wait_time between(1, 3) task(7) def query_order(self): self.client.get(/api/order/query?orderIdOD20250101001) task(2) def submit_order(self): payload {userId: 1001, skuId: 2002, quantity: 1} self.client.post(/api/order/submit, jsonpayload) task(1) def cancel_order(self): self.client.post(/api/order/cancel, json{orderId: OD20250101001})这里面的任务权重task后面的数字是根据真实业务流量估算出来的AI不会替你调研业务流量它只能帮你把架子搭好。压测脚本的坑通常不在Locust本身而在被测环境有没有做并发预热、数据库连接池够不够、日志有没有打爆磁盘。AI能帮你把脚本写得干净但压测前的环境准备和监控采集还是得测试工程师亲自去盯。4.3 AI生成测试代码的审查清单哪些地方最容易翻车用多了AI写测试代码之后我总结了一份二次审查清单分享给同路人。断言太弱AI非常爱写assert resp.status_code 200但状态码200不代表业务正确关键是要校验响应体里的业务字段和状态流转评审时我会逐个确认每个用例有没有业务断言。测试数据硬编码AI默认会用一堆写死的ID、手机号、时间戳一旦跑在共享环境里就可能相互污染建议改成带随机后缀或通过fixture动态生成。异常场景缺失功能正常的用例生成得很好超时、超限、鉴权失败、并发冲突这些异常场景经常漏需要结合业务规则逐条补。依赖外部状态比如用例依赖数据库里已有订单数据顺序执行没问题乱序跑就挂这类用例要么做成自带数据准备要么明确标出依赖关系。这些坑不是AI特有的手工写也会犯但AI会把它们放大因为它生成得快、量也大。所以现在我的原则是AI负责提量和提速测试负责人负责把关和收口。5. 车载测试与嵌入式测试AI能帮哪些忙别指望哪些5.1 车载测试的AI切入点CAN报文、UDS诊断与HIL脚本车载测试和纯软件测试最大的区别是被测对象不再是一个进程而是一堆电子控制单元ECU。日常测试里既有台架上的HIL测试也有实车上的网络与诊断测试。这中间有一个非常适合AI发挥的环节就是CAN总线报文和诊断脚本的编写。比如用Python-can库写一个简单的CAN报文收发脚本AI几秒钟就能生成一个骨架再配合ECU的DBC文件去解析信号能省很多手工查字段的功夫。UDS诊断测试也是一样。诊断工程师最烦的就是把ISO 14229的一大堆服务、子功能、否定码背下来而AI对这类公开协议规范的知识掌握得相当不错。你可以直接让它生成一段UDS会话切换、读取DTC诊断故障码的测试脚本或者生成CAPL脚本的某个函数块效率会高很多。但注意一点车载测试的脚本最终要跑在真实或半真实的硬件环境里AI生成的代码只能作为初稿DBC文件的信号定义、CANoe工程里的CAPL环境适配这些必须由懂业务的工程师逐行确认。5.2 嵌入式测试的AI切入点交叉编译、串口日志与单元测试嵌入式测试的难点在于环境受限。测试代码要交叉编译到目标板上跑串口日志是最好的线索来源但日志量一大人眼分析非常累。我处理过一批设备日志几百MB的串口输出扒top命令的CPU占用、异常重启的关键堆栈用AI来总结和分类确实香。把日志文件喂给Claude Code或者TRAE让它先按关键字归类再把疑似异常的部分提取出来几分钟能顶上人工半天的排查量。嵌入式单元测试也值得尝试。Unity、CMock这类测试框架的测试用例模板、mock桩函数AI能生成得比较标准。但嵌入式环境的坑在于有些Bug是时序相关的单次单元测试过了不代表集成到实时系统里没事交叉编译工具链的链接错误、内存对齐问题AI是看不到你具体硬件配置的。所以我的建议是AI在嵌入式测试里当日志分析师和模板生成器没有大问题当全自动测试系统则远远不够。5.3 为什么车载和嵌入式场景不能全自动硬件、安全与合规最后必须泼一盆冷水。AI编程工具在纯软件测试里已经能承担相当一部分执行层面的工作但车载和嵌入式场景里自动化必须止步于辅助这个边界。原因有几个层次。第一是硬件成本台架、ECU、测试车辆都是稀缺资源AI没法替你排期也没法判断现在上电是否安全。第二是实时性嵌入式系统对时序极度敏感AI生成的代码在PC上跑得通在真实目标板上可能因为中断延时、内存布局的不同而翻车。第三是行业合规车载ECU测试有功能安全标准、软件升级合规要求测试记录、数据追溯都有硬性规定这部分流程不是AI能自动生成的。我自己在车载项目里用AI的方式是把重复度极高、公开知识依赖强的部分交给AI提效比如DBC信号解析、UDS服务的查表脚本、日志初筛把涉及安全、合规、真实硬件行为判断的部分坚决自己来。这个边界如果把握不住AI提效就会变成AI背锅这是最不想看到的结果。6. 常见问题与排查技巧实录从工具链到模型幻觉6.1 环境与工具配置问题速查表我把自己在实践里遇到最多的问题整理成一个速查表新手照着查能省不少时间。现象常见原因处理办法pip安装opencv-python报编译错误Python版本过新没有预编译wheel降到Python 3.10/3.11或先装Anaconda环境终端输入claude提示命令不存在npm全局bin目录没有加到PATH检查Node安装路径将全局bin目录加入PATHClaude Code首次启动登录失败网络不通或API Key配置位置不对确认终端能访问模型服务地址检查环境变量是否在正确层级TRAE的Build模式不执行跨文件操作权限设置或对话里任务描述不明确在对话里明确列出要改的文件路径和期望结果打开对应权限开关DeepSeek API返回HTTP 401API Key错误或余额不足重新生成Key检查账户余额与套餐状态本地部署的DeepSeek响应慢模型太大、显存不够或CPU推理换更小量化版本或把推理请求改为批量/异步执行这张表解决的是跑不起来的问题真正麻烦的是跑起来但结果不对那就落到模型幻觉的问题上。6.2 控制token消耗与成本让AI在测试场景里更省钱很多测试团队用AI工具最担心的不是效果而是成本。我的做法是从两个维度压缩token消耗。第一个维度是上下文精简不要每次把整个项目塞给模型而是只给相关文件或模块的路径和关键片段。Claude Code这类工具虽然能自己读文件但读得越多token烧得越快。第二个维度是任务拆分一个大任务让AI一口气完成往往中间步骤反复重读代码不如手动拆成三四个小任务每一步确认后再继续。还有一个小技巧很多测试脚本是一次性脚本生成完之后不要反复让AI修改而是让它直接输出最终版本。如果要在不同项目里复用就把公共方法抽出来维护成自己的工具包这样每次AI生成的代码量会越来越少。实测下来一个五人测试小组按这样的方式用API账单能控制在一个比较可接受的范围内关键是别让模型在无关背景上浪费token。6.3 模型幻觉与断言错误如何让AI的输出可信最后聊一个所有AI测试开发绕不开的问题幻觉。AI生成的测试代码里有些函数名、库用法是它想象出来的看起来头头是道一跑就报AttributeError。处理办法只有一条朴素的真理一切以测试执行为准。生成完代码必须跑一遍编译错误、导入错误第一时间暴露断言逻辑必须人工核对业务预期不能因为AI写得很顺就默认正确。我再分享一个区别对待的经验AI的OpenAPI/Swagger解析能力、公开协议比如HTTP、UDS的代码生成准确率比较高因为它见过大量类似数据AI对公司内部业务规则、历史线上事故的认知基本为零。所以凡是涉及公共知识的代码大胆让AI去写凡是涉及内部业务逻辑的断言和数据构造必须人来把关。把这两类任务分清AI辅助测试开发的收益才会最大化。最后聊点我自己目前的工作方式变化。以前早上到工位第一件事是翻一遍昨天的失败用例然后花一两个小时改脚本。现在同一批活我会先用Claude Code按模板把初版改动生成好再扔到TRAE里用Build模式做局部调整测试数据交给DeepSeek API去造真正需要我动手的部分往往是业务规则确认和最终代码评审。这个流程用了两三个月最大的感受不是说AI完全取代了测试开发而是把我的精力从写代码重新拉回到设计测试上。车载和嵌入式那边AI的参与度还比较克制但日志分析和模板生成已经实打实地在省时间。这套方案对一个人数不多的测试团队很友好上手成本不高只要记住一条AI能提速但测试的判断力和责任心永远是自己的。
AI编程工具在测试开发中的实战：从用例生成到车载嵌入式测试
测试开发这行做久了你会发现每天至少有一半时间耗在不产生任何技术含量的重复劳动里接口变了要补用例、同一份业务逻辑在不同项目里反复写断言、压测脚本换个协议就要重搭一套。这两年AI编程工具特别火但网上讲的基本都是帮程序员写业务代码很少有人说清楚这套东西用在测试开发里到底怎么玩。我花了不少时间把Claude Code、TRAE、DeepSeek这些工具和大模型测试开发的思路揉在一起在Python自动化测试、性能测试还有相对冷门的车载测试和嵌入式测试里都实际跑过一遍。这篇就按我自己的实操顺序来写先把工具选型和环境说清楚再讲用例生成、API调用、Agent编排顺便把B站那些零散讲Claude Code、TRAE、大模型测试开发的视频串成一条完整的落地方案最后单独聊聊车载和嵌入式场景里AI到底能用在哪、哪里不能指望它。1. 测试开发与AI编程工具的适配关系选型比用法更重要1.1 Claude Code、TRAE、DeepSeek在测试开发里分别干哪份活一上来先对齐一个概念现在市面上火的AI编程工具不是同一类东西。Claude Code本质是一个跑在终端里的编程Agent给它一个任务它自己读代码、改文件、跑命令像来了个实习生坐在你终端里干活。TRAE是字节下面的AI IDE它更像VS Code的加强版把聊天、代码补全、多文件改动集成在IDE内部普适性更强。DeepSeek则要拆成两半看一半是可以通过API调用的模型服务一半是可以本地部署的开源模型。这三者的关系不是替代而是不同环节各管一段。我自己的分工是Claude Code负责需要自主执行的重活比如一次性生成一整套pytest工程、把旧的unittest用例批量迁移过来TRAE负责我日常在编辑器里改代码、写断言、补注释因为IDE内联体验更顺手DeepSeek负责两类事一是当成本敏感的备用模型二是本地部署之后做需要内网隔离环境的测试数据生成。这样组合下来既不容易被单一工具绑死也能在模型不可用或限流的时候快速切换。1.2 测试开发场景为什么比纯研发场景更需要AI辅助可能有人觉得测试开发的代码不就是发个请求、做个断言、算个耗时哪里需要AI。实际恰恰相反测试开发的工作有两个特点非常适合AI介入。第一是重复且边界复杂接口自动化要覆盖正常值、边界值、异常值、鉴权失败、超时返回这些用例用人的大脑去穷举很容易漏但给模型一个接口定义它会非常机械地把这些组合列全。第二是业务代码之外有大量一次性脚本需求生成测试数据、解析日志、把Excel用例转成JSON、写个批量压测入口这些脚本写一次就扔专门花一小时手写很不值让AI帮忙几分钟就能糊一个能跑的版本。另外测试领域有一个更独特的场景就是需要对模型的输出做测试。这就是标题里说的大模型测试开发的另一层意思你的被测对象本身是AI能力那么测试用例的设计就要考虑提示词边界、输出格式稳定性、异常输入处理。Claude Code也好、DeepSeek也好在这个场景下既是开发工具又是被测对象的一部分这个双重视角是很多测试工程师还没意识到的。2. 从零起步环境准备与Claude Code、TRAE的落地细节2.1 Python环境装错版本后面全是坑不管是pytest、Locust还是后面要提的车载测试Python库第一步都是把Python环境弄干净。我给的建议非常直接新手直接装Python 3.10或3.11别一上来就追新版本。有些库比如opencv-python、部分嵌入式串口库在Python 3.13这种太新的版本上wheel包还没跟上你装的时候会看到一堆Building wheel报警最后甚至直接编译失败。Windows安装时记得勾选Add Python to PATH这个选项否则你在cmd里敲python会提示找不到命令。环境装好之后强烈建议每个项目建一个虚拟环境。我见过太多同事图省事直接用全局pip装结果项目A要requests 2.28、项目B要requests 3.0直接互相打架。具体命令是python -m venv .venv然后激活Windows下是.venv\Scripts\activatemacOS/Linux下是source .venv/bin/activate。装依赖的时候如果下载速度不理想可以用国内镜像源比如pip install -i https://pypi.tuna.tsinghua.edu.cn/simple opencv-python把opencv这类体积大的包装稳。pip换源本身是Python社区的常规操作放心配。2.2 Claude Code安装配置一次跑通的关键点Claude Code的安装不难但第一次跑通有几个小地方容易卡住。我这边是Node环境里用npm安装的anthropic-ai/claude-code这个包装完之后在终端敲claude进入交互模式。首次启动会让你配置模型访问凭证通常会检查环境变量里有没有对应的API Key没有的话会让你粘贴一个。这里有一个我踩过的坑不要把API Key写进项目配置文件里再提交到Git一旦仓库公开Key就泄漏了。建议单独放在用户级环境变量里项目里只放引用。另一个关键是权限控制。Claude Code能自己执行终端命令这意味着它在测试环境里能跑pytest、能改文件、能装包但如果在生产或预发环境里放开权限风险是很大的。我现在的习惯是默认只放行读取和pytest相关命令涉及安装依赖、改重要配置的让它停下来等人工确认。说白了AI写代码可以冲得快但执行权限不能全是绿灯。2.3 TRAE安装使用与Skill技能包的正确打开方式TRAE的安装比Claude Code省心很多直接去官网下对应平台的安装包装完用账号登录国内版有积分体系模型调用的消耗和你的积分挂钩。官方不定期会放一些兑换码想省积分的话可以多留意活动和更新日志。平时做测试开发我常用TRAE的Chat模式和Build模式Chat模式适合你问一句、它答一句比如帮我解释这段pytest fixture的作用Build模式则是让它跨文件改代码、新建文件、跑命令更像一个能落地的智能体。关于Skill机制我多说一句。TRAE和Claude Code这类工具都支持把一套固定的指令、约束、最佳实践打包成技能之后每次用到就会自动加载。对我的测试团队来说我把pytest用例编码规范接口测试断言模板性能测试报告格式要求这三套东西整理成了技能包。这样不管哪个同事调用AI生成测试代码产出的风格都基本统一团队内的代码评审压力小很多。3. 大模型测试开发实战用例生成、API调用与智能体编排3.1 给模型的上下文里该放什么生成结果才靠谱很多人让AI生成测试用例结果拿到一堆So easy的用例分析下来无非是接口路径、参数名都对了但业务约束、状态流转这些关键信息没喂进去。我的做法是把上下文组织成四个部分接口定义Swagger/OpenAPI或者抓包的请求响应、业务规则状态机、枚举值、边界条件、工程约束框架用pytest还是unittest、断言风格、是否接Allure、已知坑之前线上出过的问题。有了这四块AI生成的用例才不是看起来像而是真正能覆盖到业务风险。这里给一个我常用的示例提示词以Claude Code为例请根据下面的接口定义生成pytest测试用例 接口POST /api/order/submit入参包括userId、skuId、quantity、couponId均为JSON。 业务规则quantity取值1-99超过99直接返回参数错误couponId非必填库存不足时返回400且codeSTOCK_NOT_ENOUGH。 工程约束使用requests库断言用pytest.raises处理异常场景类名TestOrderSubmit全部用例打上allure.feature(订单提交)。 请同时生成正常用例、边界用例、异常用例并为每个用例写上注释说明覆盖的测试意图。这样喂下去出来的代码基本可以直接进工程不用大改。3.2 DeepSeek API调用与本地部署测试数据制造的两条路DeepSeek在测试开发里最常见的使用方式就是造测试数据。造数据听起来简单但真正做业务测试的人都知道最难受的是造符合业务语义的数据。比如订单号要符合某个校验规则、手机号要看起来真实、批量数据之间不能互相冲突。用DeepSeek的API可以通过一段Python代码直接生成一批结构化的测试数据示例import requests url https://api.deepseek.com/chat/completions headers { Authorization: Bearer YOUR_API_KEY, Content-Type: application/json } prompt 请生成20条测试订单数据字段包括订单号以OD开头加8位数字、用户ID整数、金额保留两位小数、状态PENDING/PAID/CANCELLED。要求订单号不重复状态分布为10个PENDING、6个PAID、4个CANCELLED。只输出JSON数组不要其他解释。 payload { model: deepseek-chat, messages: [{role: user, content: prompt}], temperature: 0.3, response_format: {type: json_object} } resp requests.post(url, headersheaders, jsonpayload) print(resp.json()[choices][0][message][content])注意三个细节一是temperature调低一点0.2到0.4生成的数据更稳定二是明确要求只输出JSON避免解析时还要处理一堆解释性文字三是有条件的话把响应校验一下毕竟模型偶尔还是会字段缺失。批量造数脚本我一直当成测试数据工厂来维护它既不是测试代码也不是业务代码但它是整个自动化体系的原料来源。本地部署这条路适合内网环境。很多公司的测试环境不能访问外部API那就用Ollama这类工具把DeepSeek的量化版本拉下来跑在GPU机器上。本地部署的好处是数据不出内网、调用没有次数限制坏处是模型响应速度和效果会打折造简单测试数据完全够用复杂业务逻辑生成还是云端更强的模型胜出。3.3 把Agent串成流水线需求解析、用例生成、执行、分析单个Chat对话已经是过去式了现在更值钱的是组织多个Agent协同。我在团队里搭过一个测试智能体流水线大致分四步需求解析Agent负责读需求文档和接口定义输出关键业务规则和边界清单用例生成Agent根据规则清单生成pytest用例文件执行Agent在测试环境跑这批用例并把结果归类结果分析Agent拿到失败结果后结合日志自动判断是代码缺陷、用例断言过严还是环境问题。这四步之间不是全自动一条路走到黑每个Agent的产出物都要人工确认一次。比如需求解析Agent给出的业务规则清单是后面所有用例的依据这一步错了后面全错。执行Agent跑完的失败用例结果分析Agent只能给建议不能直接改代码提PR。我的经验是Agent流水线把耗时从一人搞一周压到半天到一天但质量把关还是得靠人AI不会为线上的事故负责。4. Python自动化测试与性能测试AI辅助的落地姿势4.1 pytest接口自动化让AI批量生成用例并保持规范接口自动化的核心矛盾是用例数量不能太少少了覆盖不住也不能全是复制粘贴否则维护成本爆炸。AI正好缓解这个矛盾。我之前接手过一个老系统的订单模块Swagger里有30多个接口想让AI一次性生成整个模块的用例。做法是先给它一两个我手工写好的范例用例让它模仿这个风格生成其他接口的用例。这个技巧很关键模型模仿特定代码风格的能力比它凭空发挥的能力要稳定得多。生成完之后不要直接入库我会用脚本做三层检查。第一层是语法检查python -m compileall扫一遍目录避免低级语法错误第二层是静态检查跑一下flake8把未使用导入、明显不符合PEP8的问题清掉第三层是跑一遍冒烟用例确认框架本身没有坏。这三层做完再进代码评审速度快很多。实际体验下来AI生成的pytest代码有个通病就是fixture的scope经常用错有时所有用例共享一个可变对象导致隔离失败评审的时候重点看这类并发和隔离问题。4.2 Locust性能测试脚本从压测计划到可运行代码性能测试和功能测试的思维方式不太一样压测脚本虽然代码量不大但每一步都影响结果的可信度。我自己通常先写压测计划并发数、爬坡时间、持续时间、业务比例再让AI按计划生成Locust脚本。比如下面这个简单的脚本就是AI生成的底子加上我改的压测业务比例from locust import HttpUser, task, between class OrderUser(HttpUser): wait_time between(1, 3) task(7) def query_order(self): self.client.get(/api/order/query?orderIdOD20250101001) task(2) def submit_order(self): payload {userId: 1001, skuId: 2002, quantity: 1} self.client.post(/api/order/submit, jsonpayload) task(1) def cancel_order(self): self.client.post(/api/order/cancel, json{orderId: OD20250101001})这里面的任务权重task后面的数字是根据真实业务流量估算出来的AI不会替你调研业务流量它只能帮你把架子搭好。压测脚本的坑通常不在Locust本身而在被测环境有没有做并发预热、数据库连接池够不够、日志有没有打爆磁盘。AI能帮你把脚本写得干净但压测前的环境准备和监控采集还是得测试工程师亲自去盯。4.3 AI生成测试代码的审查清单哪些地方最容易翻车用多了AI写测试代码之后我总结了一份二次审查清单分享给同路人。断言太弱AI非常爱写assert resp.status_code 200但状态码200不代表业务正确关键是要校验响应体里的业务字段和状态流转评审时我会逐个确认每个用例有没有业务断言。测试数据硬编码AI默认会用一堆写死的ID、手机号、时间戳一旦跑在共享环境里就可能相互污染建议改成带随机后缀或通过fixture动态生成。异常场景缺失功能正常的用例生成得很好超时、超限、鉴权失败、并发冲突这些异常场景经常漏需要结合业务规则逐条补。依赖外部状态比如用例依赖数据库里已有订单数据顺序执行没问题乱序跑就挂这类用例要么做成自带数据准备要么明确标出依赖关系。这些坑不是AI特有的手工写也会犯但AI会把它们放大因为它生成得快、量也大。所以现在我的原则是AI负责提量和提速测试负责人负责把关和收口。5. 车载测试与嵌入式测试AI能帮哪些忙别指望哪些5.1 车载测试的AI切入点CAN报文、UDS诊断与HIL脚本车载测试和纯软件测试最大的区别是被测对象不再是一个进程而是一堆电子控制单元ECU。日常测试里既有台架上的HIL测试也有实车上的网络与诊断测试。这中间有一个非常适合AI发挥的环节就是CAN总线报文和诊断脚本的编写。比如用Python-can库写一个简单的CAN报文收发脚本AI几秒钟就能生成一个骨架再配合ECU的DBC文件去解析信号能省很多手工查字段的功夫。UDS诊断测试也是一样。诊断工程师最烦的就是把ISO 14229的一大堆服务、子功能、否定码背下来而AI对这类公开协议规范的知识掌握得相当不错。你可以直接让它生成一段UDS会话切换、读取DTC诊断故障码的测试脚本或者生成CAPL脚本的某个函数块效率会高很多。但注意一点车载测试的脚本最终要跑在真实或半真实的硬件环境里AI生成的代码只能作为初稿DBC文件的信号定义、CANoe工程里的CAPL环境适配这些必须由懂业务的工程师逐行确认。5.2 嵌入式测试的AI切入点交叉编译、串口日志与单元测试嵌入式测试的难点在于环境受限。测试代码要交叉编译到目标板上跑串口日志是最好的线索来源但日志量一大人眼分析非常累。我处理过一批设备日志几百MB的串口输出扒top命令的CPU占用、异常重启的关键堆栈用AI来总结和分类确实香。把日志文件喂给Claude Code或者TRAE让它先按关键字归类再把疑似异常的部分提取出来几分钟能顶上人工半天的排查量。嵌入式单元测试也值得尝试。Unity、CMock这类测试框架的测试用例模板、mock桩函数AI能生成得比较标准。但嵌入式环境的坑在于有些Bug是时序相关的单次单元测试过了不代表集成到实时系统里没事交叉编译工具链的链接错误、内存对齐问题AI是看不到你具体硬件配置的。所以我的建议是AI在嵌入式测试里当日志分析师和模板生成器没有大问题当全自动测试系统则远远不够。5.3 为什么车载和嵌入式场景不能全自动硬件、安全与合规最后必须泼一盆冷水。AI编程工具在纯软件测试里已经能承担相当一部分执行层面的工作但车载和嵌入式场景里自动化必须止步于辅助这个边界。原因有几个层次。第一是硬件成本台架、ECU、测试车辆都是稀缺资源AI没法替你排期也没法判断现在上电是否安全。第二是实时性嵌入式系统对时序极度敏感AI生成的代码在PC上跑得通在真实目标板上可能因为中断延时、内存布局的不同而翻车。第三是行业合规车载ECU测试有功能安全标准、软件升级合规要求测试记录、数据追溯都有硬性规定这部分流程不是AI能自动生成的。我自己在车载项目里用AI的方式是把重复度极高、公开知识依赖强的部分交给AI提效比如DBC信号解析、UDS服务的查表脚本、日志初筛把涉及安全、合规、真实硬件行为判断的部分坚决自己来。这个边界如果把握不住AI提效就会变成AI背锅这是最不想看到的结果。6. 常见问题与排查技巧实录从工具链到模型幻觉6.1 环境与工具配置问题速查表我把自己在实践里遇到最多的问题整理成一个速查表新手照着查能省不少时间。现象常见原因处理办法pip安装opencv-python报编译错误Python版本过新没有预编译wheel降到Python 3.10/3.11或先装Anaconda环境终端输入claude提示命令不存在npm全局bin目录没有加到PATH检查Node安装路径将全局bin目录加入PATHClaude Code首次启动登录失败网络不通或API Key配置位置不对确认终端能访问模型服务地址检查环境变量是否在正确层级TRAE的Build模式不执行跨文件操作权限设置或对话里任务描述不明确在对话里明确列出要改的文件路径和期望结果打开对应权限开关DeepSeek API返回HTTP 401API Key错误或余额不足重新生成Key检查账户余额与套餐状态本地部署的DeepSeek响应慢模型太大、显存不够或CPU推理换更小量化版本或把推理请求改为批量/异步执行这张表解决的是跑不起来的问题真正麻烦的是跑起来但结果不对那就落到模型幻觉的问题上。6.2 控制token消耗与成本让AI在测试场景里更省钱很多测试团队用AI工具最担心的不是效果而是成本。我的做法是从两个维度压缩token消耗。第一个维度是上下文精简不要每次把整个项目塞给模型而是只给相关文件或模块的路径和关键片段。Claude Code这类工具虽然能自己读文件但读得越多token烧得越快。第二个维度是任务拆分一个大任务让AI一口气完成往往中间步骤反复重读代码不如手动拆成三四个小任务每一步确认后再继续。还有一个小技巧很多测试脚本是一次性脚本生成完之后不要反复让AI修改而是让它直接输出最终版本。如果要在不同项目里复用就把公共方法抽出来维护成自己的工具包这样每次AI生成的代码量会越来越少。实测下来一个五人测试小组按这样的方式用API账单能控制在一个比较可接受的范围内关键是别让模型在无关背景上浪费token。6.3 模型幻觉与断言错误如何让AI的输出可信最后聊一个所有AI测试开发绕不开的问题幻觉。AI生成的测试代码里有些函数名、库用法是它想象出来的看起来头头是道一跑就报AttributeError。处理办法只有一条朴素的真理一切以测试执行为准。生成完代码必须跑一遍编译错误、导入错误第一时间暴露断言逻辑必须人工核对业务预期不能因为AI写得很顺就默认正确。我再分享一个区别对待的经验AI的OpenAPI/Swagger解析能力、公开协议比如HTTP、UDS的代码生成准确率比较高因为它见过大量类似数据AI对公司内部业务规则、历史线上事故的认知基本为零。所以凡是涉及公共知识的代码大胆让AI去写凡是涉及内部业务逻辑的断言和数据构造必须人来把关。把这两类任务分清AI辅助测试开发的收益才会最大化。最后聊点我自己目前的工作方式变化。以前早上到工位第一件事是翻一遍昨天的失败用例然后花一两个小时改脚本。现在同一批活我会先用Claude Code按模板把初版改动生成好再扔到TRAE里用Build模式做局部调整测试数据交给DeepSeek API去造真正需要我动手的部分往往是业务规则确认和最终代码评审。这个流程用了两三个月最大的感受不是说AI完全取代了测试开发而是把我的精力从写代码重新拉回到设计测试上。车载和嵌入式那边AI的参与度还比较克制但日志分析和模板生成已经实打实地在省时间。这套方案对一个人数不多的测试团队很友好上手成本不高只要记住一条AI能提速但测试的判断力和责任心永远是自己的。