Playwright Trace Viewer能帮校招项目补上什么？不是截图那么简单

失败截图只能证明它失败过

“UI自动化做完了”常见展示是一张失败截图。面试官再问：它为什么点错？当时页面有没有加载完？网络有没有异常？脚本改完后怎么证明不会再错？很多人只能说“我又跑了一遍”。 AI Coding 加入 UI 自动化后，这个问题更明显：AI 可能把定位器从文本改成了第一个按钮，运行速度更快，却把“申请退款”点成“取消订单”。要回答这种问题，需要一条可回放的执行证据。

把一次误点设计成项目亮点

准备一个订单详情页，故意放两个相近按钮；让AI生成或修改定位器；保存失败 Trace。复盘时从 Trace 里展示操作前后的 DOM、网络请求、截图和步骤。然后增加语义断言：点击前必须确认按钮文案、订单状态和弹窗标题同时满足。

可直接写进项目的断言

expect(page.get_by_role("button", name="申请退款")).to_be_visible()
expect(page.get_by_text("订单状态：已签收")).to_be_visible()
page.get_by_role("button", name="申请退款").click()
expect(page.get_by_role("heading", name="退款申请")).to_be_visible()

它验证的不是“某个CSS选择器还存在”，而是用户要进入的业务状态。Trace 则让你在失败后能回答：页面变了、网络变了，还是AI改坏了定位逻辑。

面试回答框架

不要把这个项目说成“我用 Playwright 跑了自动化”。更好的讲法是：我选了一个 AI 网页客服的订单页，设计了模型把“取消”误识别为“退款”的风险；我用 Trace 保存点击前后的 DOM、网络请求和截图；当失败发生时，能定位是模型视觉定位错、前端按钮文案变了，还是后端接口真正执行了错误动作。最后我用 URL、接口副作用和订单状态三层断言拦截回归。

项目最容易犯的错误是只保存失败截图。截图不能证明点击落在哪个元素，也不能证明后端有没有副作用。面试前至少准备一段 Trace 回放：先展示错误点击，再展示网络请求，最后展示修复后的断言。这会让面试官看到你做的是 AI 测试开发，而不只是录制脚本。

按“业务风险—失败证据—修复断言—回归方式”讲：退款误点风险高；Trace显示点击目标错误；用角色/文本/状态三重约束修复；每次AI改脚本都保留失败Trace并接进CI。这样一个小项目也能讲出测试开发的闭环。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理