最近有同学问我一个问题 “现在越来越多公司的校招测开岗开始关注 AI 使用能力我需要准备到什么程度”先说一个更现实的结论AI 使用能力正在成为加分项但还远没到“不会就没机会”的程度。企业更看重的依然是你对测试的理解以及把事情做成的能力。这篇文章不讲概念我把自己最近一套跑通的流程分享出来用 AI 辅助写自动化测试从能生成代码到能稳定跑起来中间到底经历了什么。为什么是 Playwright Claude Code不是因为它们“最先进”而是更适合当前阶段的实践。Playwright的特点是接口设计比较语义化比如点击、输入、等待这些操作本身就比较直观这对 AI 生成代码是有帮助的。而Claude Code的优势在于它不仅依赖 prompt还可以读取项目中的代码结构。这一点很关键—— 相比只基于描述生成代码有上下文的生成更接近真实项目。不过需要注意 它并不能“完全理解你的业务”关键约束仍然需要你补充。第一步先让 AI 理解你的项目很多人会忽略一开始我直接让 AI 写脚本结果基本不可用。 后来补了一步在项目里加一个说明文件让 AI 知道基本约束。比如在根目录放一个 CLAUDE.md写清楚## 项目信息 - 前端React TypeScript - 测试框架Playwright - 测试目录tests/e2e/ - Base URLhttp://localhost:3000 ## 测试规范 - 使用 Page Object 模式 - 优先使用>第二步把测试场景说清楚而不是让 AI 猜一个常见问题是描述太模糊比如“写一个登录测试”这种输入AI 只能生成“看起来像测试”的代码但很难直接用。如果换成这样访问登录页输入用户名和密码点击登录校验跳转结果再补充异常情况密码错误、空提交你会发现生成结果明显更可用。本质上这一步不是在“写 prompt” 而是在做测试用例设计。第三步代码生成之后一定要做 ReviewAI 可以帮你写初稿但质量控制还是要靠人。我自己主要会看这几块选择器是否稳定AI 常用 class 或 id但这些容易随样式变化失效。更推荐>第四步运行和调试这是必经过程第一次执行失败是正常的。常见问题包括选择器不匹配页面未加载完成就开始操作测试数据不符合预期一个比较实用的做法是 把报错信息交给 Claude Code让它一起参与修改。通常几轮下来可以把用例稳定下来。第五步接入 CI让测试真正有价值当脚本可以稳定运行后可以考虑接入 CI 流程例如e2e-tests: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - run: npm ci - run: npx playwright install --with-deps - run: npx playwright test需要说明的是CI 中的测试不一定“永远稳定”实际项目中会存在波动flaky test目标是逐步提高稳定性而不是追求绝对 100%。三个常见问题踩坑总结1. 选择器过于脆弱使用 class 或 id 容易受页面改动影响建议统一规范。2. 测试之间有依赖应保证每个测试可以独立执行通过 beforeEach 处理前置条件。3. 忽略加载时序操作前应确认关键元素已渲染完成否则在 CI 环境容易失败。效率上的变化更客观的说法以常见场景为例登录测试从数小时缩短到几十分钟完整页面 E2E从 1~2 天缩短到数小时整体来看在结构清晰的场景下效率通常可以提升 2~3 倍。但需要强调AI 并不会减少你的判断工作只是减少了重复编码的时间。对校招生更重要的一点企业关注的不只是你“用了 AI”而是你是否理解测试场景如何设计为什么这么设计AI 在哪里帮助了你哪些地方需要人工介入如果你能把这些讲清楚比单纯展示工具更有价值。最后AI 确实在改变自动化测试的方式但它更像一个加速器而不是替代者。更合理的分工是人负责设计与判断AI 负责提高实现效率如果你还没开始尝试可以从一个简单场景入手比如登录流程完整跑一遍“生成—调试—稳定”的过程。这比单纯看教程更能建立你的真实能力。霍格沃兹测试开发学社是一个专注软件测试、自动化测试、人工智能测试与测试开发的技术交流社区