别一上来就写脚本
很多人觉得自动化测试就是赶紧把脚本跑起来，越快越好。但现实是，盲目上手反而拖慢进度。比如小李他们团队，刚接手一个电商项目，急着把登录、下单流程自动化，结果页面结构一变，所有脚本全挂。后来才明白，得先理清楚哪些用例适合自动化——高频执行、逻辑稳定、数据可模拟的才值得投入。
选对工具比写好代码更重要
不是所有项目都得用 Selenium。如果是接口测试多，直接上 Postman + Newman 配合 CI 流程，轻量又高效。Web UI 层面确实绕不开浏览器操作时，再考虑 Playwright 或 Cypress 这类现代框架。比如现在不少团队用 Playwright，它支持多语言、自动等待机制强，写起来省心不少。
举个简单例子，用 Playwright 等待按钮可点击：
await page.click('button#submit');不用手动加 sleep，也不用反复判断 DOM 状态，框架自己处理好了。
测试数据要独立且可控
很多失败不是因为逻辑错，而是数据乱。比如测试支付成功场景，结果用了真实已使用的订单号，自然走不通。建议用工厂模式生成测试数据，或者对接 mock 服务。数据库操作尽量走 API 清洗，避免直接连生产库。
本地起一个 mock server 也很方便：
npx json-server --port 4000 --watch db.json这样前端即使没联调完，也能跑通全流程。
别让自动化变成“一次性工程”
脚本写完不能扔在那吃灰。放进 CI/CD 流水线里，每次代码提交自动触发核心路径检查。Jenkins、GitLab CI 都支持定时任务和条件触发。发现失败及时通知负责人，而不是等上线前才发现一堆红叉。
页面元素定位要够“抗折腾”
开发改个 class 名字，你的 xpath 就失效？太常见了。尽量用稳定的属性定位，比如 data-testid：
<button data-testid="login-btn">登录</button>对应脚本里这样写：
await page.click('[data-testid="login-btn"]');跟样式和文案解耦，维护成本低多了。
日志和截图别省
当某个用例在 Jenkins 上挂了，没人愿意花半小时复现问题。运行时自动截屏、保存控制台日志、记录网络请求状态，能快速定位是前端报错、接口超时还是元素没加载。这些信息一并归档，排查效率高不少。
保持小步迭代
别想着一口气覆盖全部功能。先从主干流程做起，比如用户注册→登录→浏览商品→下单→支付。这一条链路稳了，再扩展分支场景。每新增一个用例，确保不影响已有运行结果。回归测试的意义就在于此——改了代码，老功能照样跑得通。