企业更看重的，依然是你对测试的理解，以及把事情做成的能力。
这篇文章不讲概念，我把自己最近一套跑通的流程分享出来：
用 AI 辅助写自动化测试，从能生成代码，到能稳定跑起来，中间到底经历了什么。
不是因为它们"最先进"，而是更适合当前阶段的实践。
Playwright 的特点是接口设计比较语义化，比如点击、输入、等待这些操作本身就比较直观，这对 AI 生成代码是有帮助的。
而 Claude Code 的优势在于，它不仅依赖 prompt，还可以读取项目中的代码结构。这一点很关键------ 相比只基于描述生成代码，有上下文的生成更接近真实项目。
不过需要注意： 它并不能"完全理解你的业务"，关键约束仍然需要你补充。
一开始我直接让 AI 写脚本，结果基本不可用。 后来补了一步：在项目里加一个说明文件，让 AI 知道基本约束。
比如在根目录放一个 CLAUDE.md，写清楚：
项目信息
- 前端：React + TypeScript
- 测试框架：Playwright
- 测试目录：tests/e2e/
- Base URL：http://localhost:3000
测试规范
- 使用 Page Object 模式
- 优先使用 data-testid
- 每个测试文件对应一个功能
这一步不复杂，但效果很明显： 后面生成的代码，结构和风格都会更接近你的项目。
一个常见问题是，描述太模糊，比如：
"写一个登录测试"
这种输入，AI 只能生成"看起来像测试"的代码，但很难直接用。
如果换成这样：
- 访问登录页
- 输入用户名和密码
- 点击登录
- 校验跳转结果
- 再补充异常情况（密码错误、空提交）
你会发现生成结果明显更可用。
本质上，这一步不是在"写 prompt"， 而是在做测试用例设计。
AI 可以帮你写初稿，但质量控制还是要靠人。
我自己主要会看这几块：
选择器是否稳定
AI 常用 class 或 id，但这些容易随样式变化失效。
更推荐 data-testid 或 Playwright 提供的定位方式。
等待策略是否合理
如果看到固定时间等待（比如 waitForTimeout），基本需要调整。
断言是否完整
不仅要判断元素是否存在，还要验证内容和状态。
测试是否独立
避免用例之间存在隐式依赖（例如默认已登录）。
第一次执行失败是正常的。
常见问题包括：
- 选择器不匹配
- 页面未加载完成就开始操作
- 测试数据不符合预期
一个比较实用的做法是： 把报错信息交给 Claude Code，让它一起参与修改。
通常几轮下来，可以把用例稳定下来。
当脚本可以稳定运行后，可以考虑接入 CI 流程，例如：
e2e-tests:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4 - 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 测试等内容，侧重测试实践、工具应用与工程经验整理。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/280033.html