干测试的都知道登录是几乎所有 Web 系统和 App 系统的入口也是自动化测试绕不开的第一道关卡。只要登录这一关没打通后面的业务流程脚本全是空中楼阁。我之前用 Selenium 从零开始写登录用例光是元素定位和等待策略就折腾了大半天更别提各种测试数据要手动准备。最近换了个思路让 AI 编程助手 Trae 来辅助写自动化测试脚本整套流程顺畅了不少。Trae 本质上是一个带 AI 编程能力的代码环境你可以在对话框里用自然语言描述测试需求它直接生成可以运行的 pytest 代码也能在你已有代码里做补全、重构和排错。这篇博文就记录我在实际项目里用 Trae 从 0 到 1 完成登录功能自动化测试的完整过程包括工具环境搭建、测试用例设计、核心代码落地以及那些我不想让你再踩的坑。无论你刚接触自动化测试还是已经在维护一套老旧的 UI 脚本这篇文章都有可参考的实践细节。1. 为什么用 Trae 来做登录功能自动化测试1.1 自动化脚本的痛点与 Trae 的定位先说说我自己的处境。我的日常工作里有相当一部分是回归测试顶在最前面的就是 UI 自动化脚本。以前写脚本是纯手敲一个登录模块可能就要写上百行代码元素定位要靠浏览器 F12 一个一个抠定位出来还要担心它哪天就变了。更麻烦的是不同环境的登录框可能结构还不一样测试数据也要手动造一换环境就跑不动了。这些工作不是很难但非常消耗时间而且错一个字母就要调试半天。所以当我第一次接触 Trae 的时候我并没有把它当成一个简单的“代码补全器”而是当成一个“能听懂人话的结对编程伙伴”。Trae 的对话能力可以在项目上下文里直接生成、修改、重构代码它不只是根据你的光标位置补一句代码而是能根据你描述的业务规则、页面元素、测试目标生成一整套逻辑完整的测试函数。对我这种整天和测试用例、断言、定位器打交道的人来说这个能力刚好补在我最缺时间的地方。我的定位很简单Trae 负责把繁琐的编码体力活干完我负责提供准确的上下文和做最后的评审。这个协作方式我实测下来写登录功能自动化脚本的效率大概提升了 50% 左右而且代码的可读性比我自己手写还规整因为它默认就是按规范结构生成很少写出那种一个函数几百行、逻辑缠成一团的东西。1.2 登录功能测试的独特性为什么它是第一个要攻克的关卡登录功能在自动化测试里的地位很特殊它不是“一个普通功能”而是几乎所有业务用例的前置条件。我举个最简单的例子你要测购物车、订单、个人中心基本上都要求先处于登录状态。如果登录脚本不稳定后面所有用例都跟着遭殃所以登录功能的价值是“金字塔底座”级别的。另外登录本身还叠加了三个维度的问题。第一是数据敏感密码不能明文写到日志里断言的时候也不应该把用户密码打印出去。第二是状态复杂登录成功之后要处理 cookie、token、localStorage 这些状态甚至还有“记住我”的持久化场景。第三是异常分支多空用户名、空密码、密码错误、用户不存在、账号锁定、验证码超时、并发重复登录等等光把这些分支跑一遍就已经是一个中等规模的测试项目了。正因为它有这个复杂度登录功能反而特别适合作为“用 AI 辅助写自动化测试”的练习场。你在和 Trae 对话的时候本身就是在梳理自己的测试思路你把它拆成哪些前置条件、哪些步骤、哪些断言提交给 AI 的时候写得越清楚生成的代码就越能落地。我在后面的章节里会把这个过程一步步拆开讲。2. 环境准备把 Trae 和 pytest 这套组合装好2.1 Trae 安装与基础配置先别急着写代码环境不准备好AI 生成的天花乱坠的代码你也跑不起来。我用的是一台 Windows 开发机流程比较简单先从官网下载 Trae 安装包安装完打开它本质上是一个 IDE界面和主流开发环境挺像自带 AI 对话面板和代码内联提示。接着在设置里把 Python 插件装好再把项目文件夹打开让 Trae 能读到你当前项目的结构。有一个细节我特别强调打开项目之后先花两分钟在 AI 对话里简单介绍一下你的目录结构比如“tests 目录放用例pages 目录放页面对象data 目录放测试数据conftest.py 在项目根目录”。这么做的好处是Trae 后续生成代码时引用的相对路径和 fixture 位置都会准确很多不会动不动就给你生成一个根本不存在的目录名。我自己最初忽略了这个步骤让它生成文件路径结果一半代码的 from 导入全是错的。还有一个小坑是账号登录。Trae 本身需要登录账号才能使用 AI 能力有段时间我换到新电脑登录时一直提示“该设备绑定的账户数量已达上限”。这个问题的本质是账号被限制在多台设备同时使用解决方法是去后台解绑旧设备或者直接在原来那台电脑上退出登录。这件事我连载这里是因为它和被测系统的 session 踢下线机制非常像后面我在 5.3 里还会再提到。2.2 测试框架选型与依赖安装自动化测试框架我选择的是 pytest配合 Selenium 做 Web 端 UI 测试。为什么不用 unittest我个人的理由是pytest 的 fixture 机制更适合管理登录这类有前置条件的场景参数化装饰器也简洁断言直接用 assert 关键字配合插件还能生成漂亮的测试报告。如果你要做移动端登录就把 Selenium 换成 Appium主体结构是一样的页面对象模型依然成立如果被测系统有接口能力登录这块优先用 requests 在接口层做速度快、稳定性高。依赖清单我用的是一个 requirements.txtpytest8.2.1 selenium4.21.0 webdriver-manager4.0.1 allure-pytest2.13.5 requests2.32.3 PyYAML6.0.1安装命令就一条pip install -r requirements.txt。其中webdriver-manager是我强烈建议加的它会在每次运行时自动下载匹配版本的浏览器驱动省去手动维护 driver 版本的麻烦。Allure 命令行工具也要单独装后续生成报告要用macOS 上我一般用brew install allureWindows 上用包管理工具或直接下载压缩包都行。2.3 让 Trae 了解项目上下文提示词的基本功很多人觉得 AI 生成的代码不靠谱大部分时候不是 AI 不行而是你没把话说清楚。我总结了一套提示词模板四句话就能讲明白角色是什么、目标是什么、环境是什么、输出要求是什么。举个例子我给 Trae 的提示词通常是这样的你是资深测试开发工程师。项目使用 pytest selenium 被测登录页地址是 http://localhost:8080/login 用户名字段 idusername密码字段 idpassword登录按钮 idloginBtn。 请帮我生成一个登录成功的测试用例使用 conftest.py 里名为 browser 的 fixture 断言登录成功后页面跳转到首页且右上角显示用户名。同样让它生成登录失败用例我会把“错误提示文案在 classerror-msg 里”这些都写进去。实测下来提示词里信息越具体生成的代码越可用。如果只说“帮我写一个登录测试”它大概率会写一堆花花绿绿的示例代码但和你的项目根本对不上最后你还得手动改半天。记住一个原则Trae 不是你肚子里的蛔虫你对项目的了解就是它的上下文。3. 登录测试用例设计与 Trae 辅助生成3.1 登录场景拆解不能只测“用户名密码正确”做自动化测试最容易犯的错就是只把正向流程跑通就认为完成了。登录的用例设计至少应该覆盖下表里这些场景用例类型操作描述预期结果适合层面正常登录正确账号密码跳转首页显示用户信息UI/接口密码错误正确账号 错误密码提示账号或密码错误UI/接口用户不存在不存在的账号提示账号不存在UI/接口空用户名用户名留空表单校验提示UI空密码密码留空表单校验提示UI特殊字符用户名带 SQL 注入/XSS 字符串不被执行正常作为字符串处理接口优先记住我勾选记住我后登录关闭浏览器后仍保持登录UI异常锁定连续多次输错密码触发验证码或账号锁定UI/接口退出登录登录后点击退出回到登录页session 失效UI这里面有一部分场景其实不适合放在 UI 层比如 SQL 注入这类我更倾向于用接口测试去覆盖因为 UI 层做这种边界测试耗时又脆弱。你看光是拆解登录用例就已经能写满一块白板。这个拆解动作我强烈建议你在找 Trae 之前先自己做一遍因为 AI 能帮你写代码但很难帮你凭空想出业务上必须测的点。3.2 提示词怎么写Trae 才能生成靠谱用例拿到上面的用例清单就可以开始让 Trae 帮你生成对应的测试代码了。还是用那套模板但这次我会把用例表格直接贴给 Trae它就能按我的需求生成一个完整的测试文件。我实际使用的提示词长这样基于以下登录场景用 pytest selenium 生成测试代码 1. 正确账号密码登录成功 2. 错误密码提示账号或密码错误 3. 空用户名和空密码的表单校验 4. 用户不存在提示账号不存在 所有用例都使用 conftest 里的 browser fixture 登录页 urlhttp://localhost:8080/login 定位器username#username, password#password, loginBtn#loginBtn, errorMsg.error-msg 断言文案检查关键词即可。 请给每个用例添加日志并用 pytest.mark.parametrize 将场景2和4的参数化。这段提示词里包含了路径、定位器、断言方式、代码风格四个关键信息。Trae 生成出来的代码基本是能直接放进项目里运行的只是我在落地前还会做一次代码评审重点看有没有把 fixture 名字写错有没有在用例里写死环境地址。3.3 参数化用例生成与代码落地Trae 生成的登录用例大概是下面这个样子我贴一段精简版import pytest import logging logger logging.getLogger(__name__) class TestLogin: def test_login_success(self, browser): browser.get(http://localhost:8080/login) browser.find_element(#username).send_keys(tester001) browser.find_element(#password).send_keys(pass1234) browser.find_element(#loginBtn).click() assert 首页 in browser.title pytest.mark.parametrize(username,password,keyword, [ (tester001, wrong_pwd, 账号或密码错误), (not_exist_user, pass1234, 账号不存在), ]) def test_login_failed(self, browser, username, password, keyword): browser.get(http://localhost:8080/login) browser.find_element(#username).send_keys(username) browser.find_element(#password).send_keys(password) browser.find_element(#loginBtn).click() error_text browser.find_element(.error-msg).text assert keyword in error_text我在上面用logger只是因为演示真正项目里日志要是集中配置目的是方便失败后定位问题。参数化部分尤其好用同样的失败逻辑一套多组测试数据一叠你不需要复制粘贴 n 个几乎一样的函数。后面如果要扩展成几十组账号数据直接把数据放到 JSON 或 YAML 文件里用 pytest 的加载方法读进来即可这一点也能让 Trae 帮你生成。4. 核心实现从页面元素到登录态验证的完整链路4.1 页面对象模型与定位器管理如果登录用例只有三五条你把定位器直接写在函数里也没啥问题。但稍微上规模几十条用例里到处都是find_element(#username)一旦页面改版你要全局搜替换改到怀疑人生。所以我在项目里推行的是 Page Object Model简称 POM把“页面长什么样”和“测试想干什么”彻底分离。我让 Trae 帮我生成了 LoginPage 类大概是这样的结构from selenium.webdriver.common.by import By class LoginPage: URL http://localhost:8080/login def __init__(self, driver): self.driver driver property def username_input(self): return self.driver.find_element(By.CSS_SELECTOR, #username) property def password_input(self): return self.driver.find_element(By.CSS_SELECTOR, #password) property def login_button(self): return self.driver.find_element(By.CSS_SELECTOR, #loginBtn) property def error_message(self): return self.driver.find_element(By.CSS_SELECTOR, .error-msg) def open(self): self.driver.get(self.URL) def login(self, username, password): self.open() self.username_input.send_keys(username) self.password_input.send_keys(password) self.login_button.click()这里有个定位策略的优先级问题我踩坑总结出的排序是id最好因为它一般稳定且唯一然后是>def test_login_success(browser): page LoginPage(browser) page.login(tester001, pass1234) assert browser.current_url.endswith(/home) assert tester001 in page.user_info.text登录失败用例def test_login_wrong_password(browser): page LoginPage(browser) page.login(tester001, wrong_pwd) assert 账号或密码错误 in page.error_message.text关于断言我要多说一句。很多新手喜欢断言整段错误文案比如断言.error-msg的完整文本这看起来精确但产品文案调整频率可比逻辑调整高多了。今天文案是“账号或密码错误”明天改成“用户名或密码不正确”你的用例就挂了。所以我的习惯是断言关键词而不是完整文案这个经验是我维护老脚本时被折腾出来的。另外如果系统登录成功后用的是 token 方式你还可以额外断言localStorage里有没有 token 字段这个比查 URL 更贴近现在的 SPA 应用。4.3 注册、退出与 Session 状态处理登录、注册、下线这三位经常是一套功能自动化里也得配套处理。注册的自动化测试有个天然难点每次跑用例都需要一个不重复的新账号。我让 Trae 生成过一个随机器基于时间戳加随机数生成唯一手机号或邮箱用完即弃。Session 处理是登录自动化里最需要认真设计的地方。你有两种选择一种是不管测试业务每个用例都从 UI 重新走一遍完整登录流程稳定但慢另一种是用前置的一次登录拿到登录态之后直接复用。我常用的方案是在 conftest 里定义一个login_sessionfixture登录成功后导出 cookie后续用例通过browser.add_cookie()把 cookie 放回去跳开 UI 登录直接进入业务场景。这套逻辑让 Trae 生成也非常顺畅只要你在提示词里讲清楚项目用的是 cookie 还是 token、需要保存哪些关键值。同时fixture 一定要用yield写 teardown比如清理 cookie、关闭浏览器避免跑完一轮留下脏登录态给下一轮。退出用例的断言我一般看两点页面回到登录页以及原页面的访问需要重新登录。前者用 URL 判断后者可以尝试带着旧 cookie 去访问受保护页面看它是否被拦截。这里的细节能体现你测试深度而不只是沾沾自喜地跑过一个动效。4.4 测试报告与失败现场保存自动化测试跑完没有报告等于白跑你总不能每天人肉盯日志。我用 Allure 来生成 HTML 报告在项目里装好allure-pytest后执行命令就能得到结果目录pytest tests/test_login.py --alluredirreport/allure-results allure serve report/allure-results运行完可以直接在浏览器里查看通过率、每个用例的耗时、附带的截图和日志。有一次某个登录用例在回归时挂掉我把 Allure 里报错的 trace 文本贴给 Trae让它帮我分析它很快指出问题出在“等待元素时用了隐式等待但某个元素实际渲染在 iframe 里”我按它建议把定位器切换并加了显式等待下一轮就过了。失败现场的记录也值得提前做。我习惯在 conftest.py 里写一个pytest_runtest_makereport钩子用例失败时自动截图并把图片附加到 Allure 报告里。这个钩子的核心逻辑是pytest.hookimpl(tryfirstTrue, hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() if report.when call and report.failed: driver item.funcargs.get(browser) if driver: driver.save_screenshot(freports/screenshots/{item.name}.png)以后不管谁跑这条用例失败了留下的截图就是最直接的证据比翻日志快得多。5. 踩坑实录登录测试里我遇到的高频问题5.1 元素定位不稳定与等待策略登录页的自动化脚本最常见的“薛定谔的失败”前一天全绿第二天早上第一条全红你再手动跑一遍又好了。我排查过很多次绝大部分原因是等待策略没写对。新手经常用time.sleep(3)去等元素出现这是最脆弱的写法机器一慢就超时机器一快又白等三秒。我现在的做法是全部改成显式等待用一个WebDriverWait配合expected_conditions。比如等登录按钮可点击from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC wait WebDriverWait(browser, 10) wait.until(EC.element_to_be_clickable((By.CSS_SELECTOR, #loginBtn)))这里要提醒一个细节element_to_be_clickable和visibility_of_element_located的语义是不一样的可点击意味着“可见且未被遮挡且可用”更适合按钮等待如果你等的是错误提示文案用visibility_of_element_located更合适。两者混用就会出现“元素存在但点不动”的假象。这个坑我记忆深刻因为排查起来特别隐蔽。5.2 验证码与多环境配置登录功能自动化只要碰到验证码处理方式就得换个思路。最靠谱的方案不是去识别验证码而是让验证码在你的测试环境里“消失”。一般开发环境会给测试留一个配置开关比如固定验证码、或者直接关闭验证码校验。如果是生产环境不好动那就在测试设计层面规避把验证码触发阈值调高或者用一套专用的测试账号避开风控。OCR 识别验证码这个方案我不是完全否定但维护成本高成功率又不稳定日常回归里用它不如去推动环境改造。多环境配置这块我建议把环境信息从用例里抽出来统一放到一个配置文件里。我用的是最简方案一个config.yamlbase_url: http://localhost:8080 username: tester001 password: pass1234 headless: true然后在 conftest 里读取它生成 fixture。换环境的时候只需要改一个文件而不是翻遍所有测试用例。让 Trae 生成这套配置读取逻辑非常快你只要告诉它项目根目录的 config.yaml 结构即可。这个设计对其他业务模块同样通用是一本万利的事。5.3 数据清理、并发与账户绑定限制重复执行用例导致的数据冲突在登录测试里非常典型。比如你创建了一个新账号断言登录成功后退出第二次跑同一套用例注册环节发现“该账号已注册”直接失败。解决办法有两个要么在用例之前清理测试数据要么让被测对象每次都是唯一的。我偏好后者注册时用时间戳生成唯一用户名反正在自动化环境里数据“脏”一点没有关系关键是重复执行能稳定通过。并发问题同样值得提前设计。你在本地跑一条用例登录一个账号没有问题一旦上了多线程或者并行执行几个浏览器同时用同一个账号登录后登录的会把先登录的踢下线于是用例开始莫名失败。这种问题用“每台执行机分配独立测试账号”的方式解决最直接。另外我在 2.1 里提过的 Trae 账号设备绑定上限问题本质上也是同时登录端的冲突两者共享同一个原理。理解了 session 互踢模型你在排查类似问题时思路就清晰了不要把多个并发身份绑在同一个凭证上。下面是我整理的一份高频问题速查表方便你直接定位现象常见原因处理建议用例时好时坏使用了 time.sleep 隐式等待全部改成显式等待元素定位到但不可点击等待条件用了 visibility 而非 clickable改用 element_to_be_clickable登录成功但断言失败断言了完整文案或 URL 拼接不当改为断言关键词和稳定的 URL 片段第二次运行就报用户已注册注册数据写死用时间戳随机用户名并发跑用例互相踢下线多用例共用同一账号分配独立测试账号登录后 cookie 注入不生效域名/路径不匹配核对 add_cookie 的 name、value、domain6. 一点个人体会6.1 一次完整协作后的复盘心得走到这里我用 Trae 完成登录功能自动化测试的过程已经完整跑通了一遍。从环境准备、场景拆解、参数化生成到页面对象封装、session 处理和失败排查每一个环节里Trae 都不是一个“替你写好一切”的黑盒而是一个需要你把真实项目背景讲清楚、然后帮你把体力活干掉的协作对象。我个人的体会是和 AI 协作写自动化测试最大的分水岭不在工具多强而在你能否把业务逻辑描述得足够精确。你在给 Trae 写提示词时其实就是在做一次测试设计的书面化哪些场景要覆盖、哪些元素是稳定入口、哪些断言才算有效。这套思考过程即使没有 AI本身也值回票价。最后再分享一个小技巧是我后来一直沿用的如果你的登录用例里出现了大量重复的“打开页面—输入—点击—断言”结构就让 Trae 帮你把公共方法抽到一个 BasePage 里右击代码选择重构或者直接在对话里说“把这两处重复的等待和点击逻辑抽成方法”。这样跑一段时间之后你会发现维护一套自动化测试脚本真的没有想象中那么难。