先说个让人沮丧的案例
我从2018年开始搞自动化测试。当时团队处于“手动点单”的阶段，我兴致勃勃地选了Selenium+Java，写了整整两周的脚本，成功跑通了第一条“登录-下单-支付”的完整链路。当时那叫一个兴奋啊，感觉以后加班总算有救了。结果呢？一个月后，需求变动，页面DOM结构调整，我的定位器直接废了一半。
修复这些用例花了两个周末时间。更麻烦的是，每次CI跑失败，没人知道是代码bug还是我脚本过期了。后来我发现，这套UI自动化变成了一种“会呼吸的痛”。用例数量从20条涨到80条，执行时间从5分钟涨到35分钟。但每天真正能稳定通过的不超过一半。我花在修脚本上的时间，竟然比手工回归测试的时间还多。
于是我开始反思：我们到底是在做“自动化测试”还是“自动化了那些到处要修的脆弱脚本”？
UI自动化的投入产出比，被严重高估了
我承认UI测试的价值，它最接近用户真实行为。但需要注意，它在整个测试金字塔里属于最脆弱、最慢、最贵的一环。一个简单的按钮改名，就能让十几个用例同时失败。我记得有一个搜索框的输入，原先用id定位，后来前端改成了placeholder文本“请输入关键词”，id没了。我用XPath定位折腾了很久，结果用了层级之后还是因为页面结构变化崩了。这种细节折磨死人。
后来我接触了Playwright，它的自动等待和locator机制确实比Selenium友好很多，能少很多sleep等待，但并没有解决根本问题——UI层总是依赖布局和实现细节。你只要页面结构变了，测试就得跟着改。而且UI测试大多跑在浏览器里，需要依赖浏览器驱动和渲染资源，慢是先天不足。同样是跑100个业务场景，接口测试可能十几秒完成，UI测试要等一个浏览器一个个点击，如果中途出了个弹窗提示，脚本又懵了。
接口层自动化，才是大多数团队的性价比之王
我并不是说要把所有UI测试消灭。而是应该把精力往中间层移动。接口测试为什么爽？因为接口是相对稳定的契约。前端怎么改，后端接口不变，你的测试就不用动。我最近在项目里用pytest+requests写接口用例，每个用例对应一个业务场景，通过传入不同的参数组合来验证。比如下单接口，我可以通过构造不同的token、商品ID、数量来测权限、库存、金额计算。这比在界面上一步一步操作快太多了。
另外接口自动化比较容易做数据隔离。每一个用例可以用独立的测试账号、独立的订单号或者mock外部服务。但UI自动化做这些就特别重。你要去改页面上的数据，还要避免脏数据导致后续跑不了。接口层可以很容易地在setup/teardown里清理数据。如果你们用的是RESTful，用schema校验响应格式，还能在bug出现之前就做到及时拦截。这比在页面上看到一个小红字再截图靠谱得多。
重新想想，自动化测试到底想解决什么问题
最后想说一个真正核心的观点：自动化测试的维度，不是工具越先进越好，也不是用例越多越好，而是要解决“反馈速度”和“稳定性”之间的平衡。我们做自动化测试的目的是要快速知道这次改代码有没有弄坏东西。如果一套用例跑40分钟，其中有一半是失败的噪音，那开发者根本不会看，甚至还会对自动化失去信心。与其追求UI覆盖率的数字野心，不如先打磨好接口层和组件层的快速反馈回路。
我现在所在团队，最终形成了一套组合：单元测试和组件测试覆盖核心算法与UI状态，接口自动化覆盖业务逻辑和异常流程，UI自动化只留几条关键主流程作为冒烟。这样每天的CI时间控制到了8分钟内，而且稳定性可以做到95%以上。这不是什么高深理论，就是我踩了几年坑换来的经验。写代码、写用例都要考虑成本。真正的“全新”观点，其实是学会“拒绝”自动化的诱惑。