1. 为什么我会盯上TRAE一个测试老兵的视角做测试这行快十年了从最早的手工点点点到后来搭接口自动化框架再到如今研究AI辅助测试我最大的感受是工具越来越聪明但测试人需要掌握的东西也越来越多。光是这两年冒出来的AI编程工具就够让人眼花缭乱。GitHub Copilot、Cursor、通义灵码……每个都在说“能帮你写代码”但真的落到测试场景里能顺畅完成“建系统、写用例、跑自动化”这条完整链路的并不多见。TRAE这个名字我最早是在一个技术社群里看到的。当时有人发了一张截图用自然语言让TRAE从零搭了一个订单管理系统还顺手生成了对应的测试用例。说实话第一眼我是不太信的。因为市面上大多数AI编程助手最大的短板恰恰在于“连续性”——你让它写一个函数没问题但要它持续理解你的项目上下文从页面搭建一路干到测试脚本编写往往中途就乱了。但实际用了两三周之后我的结论是TRAE在“工程化任务链”上的表现确实超出我的预期尤其是在测试用例生成和自动化落地上它不只是在补全代码更像是一个能理解测试思路的协作者。这篇文章我打算把最近用TRAE做的一整套实践完整记录下来覆盖三个环节用TRAE创建被测系统、用TRAE生成测试用例、把测试用例自动化跑起来。我会把每个环节里踩过的坑、调过的参数、最后沉淀下来的方法都写出来。不管你是刚接触AI辅助测试的新人还是已经在团队里推动测试提效的老人这篇文章应该都能给你一些可复用的思路。先说一个背景。我手头最近在做的项目是一个内部的后台管理系统典型的Web CRUD场景有登录、用户管理、订单列表、数据统计这几个模块。要是按照传统流程我得先让开发搭一套Demo环境或者自己本地启动一个开源项目然后才能开始写测试用例。但有了TRAE之后整个流程变成了我直接跟TRAE描述需求让它先把系统建出来然后基于系统生成测试用例最后把这些用例转成自动化脚本。听起来很顺滑对吧但实际走下来每个环节都有不少值得琢磨的细节。2. 先搞清楚TRAE的能力边界Chat、Build和智能体分别能干糙活还是细活很多刚上手TRAE的人都会把它当成一个“高级点的代码补全工具”这其实是最大的误解。TRAE的价值不在于帮你补全一行代码而在于它能在对话中理解你的项目背景并且通过不同的交互模式完成不同类型的任务。我建议任何一个想拿它做测试提效的人都先花半天时间把它的几个基础模式搞清楚。2.1 TRAE的三种工作模式Chat、Build、智能体到底怎么选TRAE的交互方式我在实际使用中主要会用到三种形态它们各有各的适用场景。第一种是Chat模式最适合做“问答型”的辅助。比如你有一段测试代码看不懂或者想知道某个接口的参数应该怎么构造直接把代码贴给它让它解释、给建议这种场景用Chat模式效率最高。它不会改动你的代码只是跟你聊帮你理思路。第二种是Build模式这是TRAE最核心的能力。它会在你确认需求后真正动手修改代码、创建文件、跨模块操作。比如我跟它说“在src目录下新建一个login页面包含用户名、密码输入框和登录按钮样式参考antd”它会直接把文件创建出来并生成对应的代码。Build模式跟Chat模式最大的区别在于Build模式有“动手能力”而且它会维护一个对话上下文你可以在后续对话里持续提出修改要求。第三种是智能体模式TRAE里面也经常被叫做Agent模式。如果说Build模式是在一个项目里干活智能体模式更像是一个可以“自主规划任务”的助手。它会分析你的项目结构拆解任务然后按步骤去执行。比如你可以跟它说“检查这个项目的测试覆盖率找到未覆盖的分支并生成对应的测试用例”它会自己去看代码、分析逻辑、生成用例而不是等着你一步步指令。我个人的建议是日常简单问答和代码解释用Chat创建和修改功能用Build需要跨文件、跨模块完成一个完整任务链用智能体。如果你一上来就在Build模式里让它干智能体的活很容易因为上下文过长而出现前后不一致的问题后面我会详细讲。2.2 把TRAE纳入测试工作流之前先想清楚这四件事在介绍具体实践之前我想先泼一盆冷水。TRAE很强但它不是万能的。在把它正式纳入测试工作流之前有几个边界问题你必须想清楚否则很容易被它带偏。第一TRAE不能替你决定“测什么”。它能帮你写用例、写代码但它不知道你的业务优先级是什么、哪个模块容易出问题、哪个功能对用户影响最大。这些都还是测试人自己的核心价值AI只是帮你把想法落地的工具。所以我的建议是先用人工梳理出测试重点和风险点再让TRAE去生成细节化的用例而不是反过来让AI告诉你测什么。第二TRAE生成的代码质量上限取决于你的Prompt质量。很多人用AI生成测试脚本直接甩一句“帮我写个登录的自动化脚本”结果生成出来一堆谁都能写的冒烟用例然后就得出“AI很鸡肋”的结论。但实际上同样的工具你如果给它足够的上下文比如接口文档、字段规则、异常场景清单它生成的用例质量会有质的提升。第三要注意项目上下文的管理。TRAE再好用也有上下文窗口的限制。我经历过一次很深刻的教训在一个较大的项目里连续让TRAE做了四五轮修改之后它突然开始“遗忘”前面已经确定的设计约束生成了一段跟之前逻辑冲突的代码。从那以后我养成了一个习惯关键约束重复强调重要结论随手让它做摘要记录避免上下文干扰。第四TRAE不等于自动化测试框架。它是一位“代码生成助手”但它本身不负责执行测试也不负责生成测试报告。真正跑起来你还是要依赖像Playwright、pytest、Appium这些测试框架。TRAE的角色是帮你把这些框架的代码写得更快、更好。想清楚这四点之后再来谈TRAE测试提效才是靠谱的。下面我把自己最近一次完整实践的全过程拆开讲包括怎么从零搭建被测系统怎么生成测试用例以及怎么把它们自动化。3. 从零到可用用TRAE创建被测系统的完整实录做测试的人都有一个痛点想练手自动化脚本但找不到合适的被测系统。开源的商城系统、博客系统虽然多但功能太散有些还年久失修。自己搭一个吧前后端写下来没个两三天搞不定。用TRAE建系统本质上就是把“需求描述”翻译成“可运行的代码”但这里面有个关键点你给的需求描述质量直接决定系统的可用性。3.1 我先给TRAE提了哪些需求一个订单管理后台的搭建过程这次实践的载体我选了一个比较有代表性的系统——订单管理后台。选择它的原因是订单系统覆盖了CRUD、状态流转、权限控制、统计报表等多种典型的测试场景拿它来跑测试用例生成和自动化能比较好地检验TRAE在复杂业务下的表现。先说说我在Build模式里的第一条指令。我没有直接说“帮我建一个订单管理系统”因为这个表述太模糊TRAE无从下手。我给的描述大概是这样在项目根目录下创建一个基于Vue 3 Element Plus的后台管理系统包含登录页、订单列表页、订单详情页、用户管理页和统计数据页。使用Vue Router实现路由Pinia管理登录状态。订单列表页需要支持按订单号模糊查询、按状态筛选、分页展示。这条指令包含了技术栈Vue3 Element Plus、页面结构登录页、订单列表页等、功能要求搜索、筛选、分页。TRAE收到后会开始在本地创建项目结构。这里要提醒一个细节TRAE的Build模式会直接操作你的文件系统所以最好在动手之前先建一个干净的空白目录并把项目初始化好比如git init否则它创建了一堆文件后你想回退就比较麻烦。第一条指令执行完后我检查了一下生成的文件结构。整体上它创建了一个标准的Vue3项目src目录下面有views、router、store、components这些子目录页面代码也比较规范。但首次生成的页面往往比较“素”只有基础功能没有数据填充。这时候我会继续跟它对话要求它加上Mock数据。这一步我用了一个相对具体的句式给订单列表页添加30条mock数据状态包括待支付、已支付、已发货、已完成、已取消五个状态订单金额在50到5000之间随机生成。同时在订单列表页顶部增加一个统计卡片区域展示订单总数、总销售额、待发货数三个指标。添加Mock数据这个操作很多测试同学会忽视但它其实很重要。自动化测试脚本的运行高度依赖测试数据的稳定性。如果没有Mock数据你的登录脚本可能因为查不到订单而失败有了Mock数据你的自动化用例才能有稳定的测试边界。TRAE在这一步表现不错它把Mock数据写进了一个独立的mock.js文件并用API的方式暴露给前端页面结构上很清晰。3.2 建好的系统要“能测”这几点改造不可跳过系统跑起来之后不能急着写用例还要做一些“面向可测性”的改造。这个思路跟平时开发提测前做自测是一样的。第一件要做的是用TRAE生成一个测试环境专用的入口。比如登录页的验证码在实际测试中是一个很麻烦的东西。我让TRAE在开发模式下自动跳过验证码校验。做法很简单我告诉它在登录接口的mock逻辑中增加一个环境判断当URL参数带上dev1时默认通过校验并返回一个固定的token。这样做的好处很明显自动化脚本里可以直接访问带有dev1标识的页面绕过验证码的干扰保持用例的稳定性。很多人在自动化脚本里处理验证码要么接OCR识别要么让开发留后门要么就干脆不测登录——其实用TRAE建系统的时候把这种测试后门做好后面所有的事情都会顺利很多。第二件要做的是给关键元素加上稳定的定位标识。这个很多人容易忽略直到写自动化脚本的时候才发现页面上那个“查询”按钮TRAE默认生成的class是.btn-search但等元素一多class名就变得不可控了。我在建系统阶段就让TRAE给关键操作按钮和输入框都加上data-test-id属性比如登录按钮的data-test-idlogin-btn搜索按钮的data-test-idsearch-btn。这一步对未来写Playwright脚本、Appium脚本的定位工作帮助巨大属于“前期花一分钟后期省一小时”的典型投资。第三件要做的是让每个页面都有独立的路由和清晰的页面标题。这样将来做自动化断言的时候可以通过URL和页面标题双重判断确保页面跳转正确。做完这三件改造这个被测系统就算是“能测”了。接下来才进入真正的核心环节让TRAE生成测试用例。4. 测试用例生成实战从等价类到场景法TRAE能帮你做到哪一步测试用例设计是最能体现测试人员功底的环节也是最耗费精力的环节。以前写用例靠的是经验、需求文档还有脑补。现在有了TRAE能不能把用例设计这件事也“提效”我的答案是能但你必须先掌握方法论然后把方法论教给AI。4.1 先把用例设计方法论讲给AI听等价类和边界值怎么落地很多测试新手包括一些写了几年用例的“老手”在用AI生成测试用例时喜欢直接说“帮我生成登录功能的测试用例”这种问法得到的答案通常是网上烂大街的模板看起来很多实际可用性不高。要让TRAE生成高质量的用例你得先让它“理解”被测功能的具体规则然后再结合等价类划分、边界值分析这些方法去展开。以登录功能为例。我跟TRAE的对话是这样的登录功能的需求规则如下用户名长度6到16位只能包含字母和数字密码长度8到20位必须包含大小写字母和数字验证码为4位数字登录失败5次后账号锁定30分钟。请结合等价类划分和边界值分析方法设计该登录功能的测试用例覆盖正常流程和异常流程并标注每条用例的优先级高/中/低。这里的关键是把需求规则事无巨细地告诉它。TRAE拿到这些规则后会按照等价类和边界值的思路去拆解。比如用户名长度6到16位它会设计出6位、16位边界通过、5位、17位边界失败、8位等价类通过、0位空值异常等用例。这些用例从设计思路来说是符合教科书方法的而且覆盖度相当不错。但我要提醒的是AI生成的用例不一定能直接“入库”。它最大的问题在于“过度追求覆盖”有时候会把一些毫无实际意义的组合也写上。比如用户名“只包含字母和数字”这个规则TRAE可能会生成一个“包含中文用户名”的异常用例但如果需求文档里根本没有约束输入法限制这种用例就不一定有效。我的处理方式是让TRAE先按标准方法生成然后我再基于业务经验做增删判断而不是全盘接收。在实际操作中我还会让TRAE把用例整理成表格字段包括用例ID、所属模块、用例标题、前置条件、测试步骤、预期结果、优先级。它有很强的表格生成能力而且可以直接导出成Markdown格式极大方便了后续的评审和归档。4.2 场景法才是看家本领如何让TRAE梳理核心业务链路等价类和边界值更多针对单个输入项但真正容易出问题的往往是业务场景层面的交互。比如订单系统中的“下单—支付—发货—完成”整条链路中间涉及状态流转和权限控制这需要用到场景法。场景法的核心是梳理出业务的主事件流和备选事件流。以前靠人工梳理很费劲因为要读需求文档还要和开发确认各种边界状态。现在让TRAE来做效率提升非常明显。我是这样做的订单状态的流转规则新订单创建后状态为待支付用户完成支付后变为已支付商家发货后变为已发货用户确认收货后变为已完成待支付状态超过30分钟系统自动取消。请用场景法设计订单状态流转的测试用例重点覆盖正常流转路径、异常中断路径和状态回退场景。这个Prompt设计得比较精准TRAE能识别出“正常流转”和“异常中断”两条路径。它生成的用例里会包含“待支付状态下用户取消订单”、“已支付状态下申请退款”、“已发货状态下用户拒收”这些场景。从场景覆盖度上说基本能满足一次中等复杂度的订单模块回归测试需求。不过场景法有一点是AI很难做到的隐性场景的挖掘。比如“用户重复点击提交订单按钮会不会产生重复订单”这个场景需求文档里未必会有但实际测试中非常关键。TRAE如果只依据你给的规则来设计很难生成这类“脑补型”场景。所以我在使用TRAE做场景法设计时会额外给它一个提示除了上述规则请额外考虑并发操作、重复点击、网络超时等异常场景设计对应的健壮性测试用例。加了这句之后TRAE生成的内容里会出现“快速重复点击提交按钮验证是否只生成一条订单”、“支付接口超时后订单状态是否仍保持待支付”这类用例。虽然还达不到一个资深测试专家脑补出来的完整度但已经能覆盖相当一部分高频问题点了。4.3 智能体模式让TRAE“自己读代码”来补用例如果说前两种方式是“你喂规则它出用例”那TRAE的智能体模式能做到更高阶的事让AI自己去看代码然后反过来补全用例。我最近尝试的一个操作是让TRAE以智能体模式分析订单列表页的筛选逻辑代码然后反过来给我出测试用例。它的执行过程是先扫描代码文件识别出筛选条件字段订单号、状态、时间范围再去看后端的Mock逻辑搞清楚这些字段的匹配规则模糊匹配还是精确匹配最后基于这些信息生成用例。整个过程基本不需要我操太多心。智能体模式生成的用例覆盖了“精确单号查询”、“模糊片段查询”、“状态多选组合查询”、“时间跨月查询”、“无结果查询”等场景这对一个列表查询页来说覆盖度已经相当能打了。但这里我要说一个注意事项智能体模式的质量高度依赖代码本身的可读性。如果你给的代码是一堆没有注释、命名混乱的“屎山”AI生成用例的质量也会直线下降。所以如果想让TRAE的智能体模式发挥最大价值你得确保被测系统的代码质量是过关的至少在变量命名和函数拆分上要规范。5. 从用例到自动化怎么让TRAE直接产出可跑的测试脚本生成了一堆测试用例如果只停在Excel和Markdown里价值大打折扣。测试提效的最后一公里是把用例转成可执行、可回归、可出报告的自动化脚本。TRAE在这一步能做的事情超出了我最初的预期。5.1 框架选型与Prompt设计让TRAE生成Playwright pytest的脚本先聊聊框架选型。Web端自动化我目前的主力框架是Playwright pytest。选Playwright的原因很简单它比Selenium更稳定自带等待机制可以自动处理很多以前需要手工等待的坑而且支持多浏览器、多标签页操作调试体验也非常好。加上pytest作为测试管理框架再用allure来出报告这几乎是当前Web自动化测试的主流组合了。TRAE对这套技术栈非常熟悉生成代码的准确率相当高。要让TRAE生成脚本不能直接复制病例让它“写成代码”那样生成的脚本往往是一个粗糙的demo跑倒是能跑但可维护性很差。我一般会给它一套比较完整的Prompt模板核心字段包括技术栈、被测地址、登录方式、测试数据、断言要求、报告输出。示例大概长这样使用Python Playwright pytest框架为订单管理后台的登录功能编写自动化测试脚本。测试地址为http://localhost:5173/?dev1。账号admin密码Admin123。请覆盖以下用例正确账号密码登录成功、错误密码登录失败并提示“用户名或密码错误”、用户名为空时提示“请输入用户名”。使用pytest的parametrize实现数据驱动断言需包含URL变化和页面元素显示最后使用allure生成报告。TRAE执行这条指令后会自动在项目里新建test_login.py文件并生成完整的代码。核心部分大概长这样import allure import pytest from playwright.sync_api import Page, expect BASE_URL http://localhost:5173/?dev1 allure.title(登录成功-正确账号密码) def test_login_success(page: Page): page.goto(BASE_URL) page.get_by_test_id(username-input).fill(admin) page.get_by_test_id(password-input).fill(Admin123) page.get_by_test_id(login-btn).click() expect(page).to_have_url(lambda url: /dashboard in url) expect(page.get_by_text(订单概览)).to_be_visible() allure.title(登录失败-错误密码) def test_login_fail_wrong_password(page: Page): page.goto(BASE_URL) page.get_by_test_id(username-input).fill(admin) page.get_by_test_id(password-input).fill(Wrong123) page.get_by_test_id(login-btn).click() expect(page.get_by_text(用户名或密码错误)).to_be_visible()可以看到它生成的代码用了get_by_test_id这个定位方式这正是我之前在建系统阶段让TRAE加>