上周跟一个QA朋友吃饭，他掏出手机给我看了一张截图：同一套回归测试，手动跑3小时12分钟，Playwright跑4分钟07秒。
他说：“我老板看到这个数据，第一反应是‘那你们以后是不是可以少两个人’。”
我说：“你老板问错问题了。该问的是——那3小时里，到底有多少时间花在了‘人根本不该做的事’上。”
这顿饭吃完，我把他那3小时的手动流程要了过来，一笔一笔拆。
一、先算账：3小时里，人在做什么
他把回归测试的每一步都记了时间：
打开测试环境、登录、等页面加载：约12分钟
钻三层菜单找到目标功能页：约8分钟
填表单、点提交、等响应：约15分钟
切到后台管理系统核对状态：约10分钟
重复以上动作，覆盖23个测试场景：约2小时
手动截图、整理结果、写回归报告：约25分钟
加起来3小时10分钟。
这里面有一个很扎眼的事实：23个场景里，有19个是“上一次跑过、这一次只需要确认没坏”的重复验证。 真正需要人动脑判断的，是“这次改动会不会影响那个边界条件”“新加的字段有没有可能让状态机走错”。
但人的时间全花在了“打开、登录、钻菜单、填表单、点提交、等加载”上。 这些动作有一个共同点：有确定路径、有确定结果、不需要判断。
这些就是“机器的活”。
二、差距不在工具，在“谁在干确定性的活”
Playwright快，不是因为它是什么黑科技。官方基准很透明：同样250条用例，Playwright跑3分48秒，Selenium要6分52秒；单步操作Playwright约290毫秒，Selenium约536毫秒。
但4分钟对3小时，这个差距主要不在“每步快一点”，而在任务分配逻辑变了。
手动测试的分配是：人做全部——判断+操作+记录+汇报。 Playwright的分配是：机器做操作+记录，人做判断。
3小时里真正“必须由人来做”的部分，大概是“这19个重复场景里，哪几个有可能因为这次改动而受影响”。 这个判断，10分钟能做完。剩下的2小时50分钟，是机器该干的活。
三、4分钟是怎么构成的：把动作和等待都压缩掉
他的Playwright脚本不长，核心就几段：
登录和导航，用Playwright的storageState复用登录态，跳过重复登录。原来每次跑都要重新登录，光这一步就省了十几分钟。
定位，全部用get_by_role和get_by_label。他的原话是：“我不是为了优雅。我是为了下次前端改class的时候不用回来改脚本。”基于角色的定位器能把测试脆弱性降低60%到80%，这是有数据支撑的。
等待，脚本里几乎没有sleep。Playwright在执行动作前会自动检查元素的可见性和可操作性，等待逻辑内建在API里。原来手动测试里“等页面加载”的十几分钟，大部分被这个机制吃掉了。
并行，23个场景分到几个worker里跑。Playwright原生支持并发，4核机器上并行10个任务比串行快约7倍。UI测试的时间主要花在等网络和等渲染上，并行带来的墙钟时间压缩非常直接。
断言，分三层：UI元素可见、网络请求状态码和核心字段、业务状态（通过接口确认订单真的生成了）。第三层是关键——很多UI自动化“假通过”，就是因为只看了第一层。
报告，pytest-html自动生成，截图挂在每个用例下面。原来手动整理报告的25分钟，变成了0。
四、实测数据：压缩发生在哪
把两边的数据摆在一起看：
环节
手动
Playwright
登录和环境准备
12分钟
复用登录态，<10秒
页面导航和操作
约2小时
并行执行，约2.5分钟
结果核对
约30分钟
三层断言自动校验，包含在执行时间内
截图和报告
25分钟
自动生成，0分钟
人工判断
10分钟
10分钟
（不变）
机器的部分被压掉了，人的判断时间一分钟没少。 这才是“4分钟”能成立的原因——不是人变快了，是人不做机器的活了。
五、避坑指南：4分钟不是抄个脚本就有的
坑一：把手动流程原封不动翻译成代码。 手动流程里混着大量冗余动作和“人顺手做的判断”。不先做减法，脚本会又长又脆。先问一句：这一步是“确认没坏”，还是“需要判断”？前者交给机器，后者留给人。
坑二：定位器随手写CSS class。 你今天写的.btn-primary，明天前端重构就没了。定位优先级是：get_by_role → get_by_label → get_by_text → get_by_test_id → 最后才是CSS。
坑三：只用UI状态做断言。 页面弹了“提交成功”，不等于订单真的生成了。前端乐观更新、接口500但Toast提前弹出，这类“假通过”在手动测试里靠人的经验能兜住，在脚本里必须用网络层和业务层断言兜住。
坑四：一上来就追求“全自动”。 先从一条最稳定、最重复的流程跑通闭环。跑通一条4分钟的，比写十条永远在修的两小时脚本有价值得多。
坑五：忘了“人该做什么”。 自动化之后，QA的时间不是“省下来了”，是“腾出来了”。腾出来的时间该花在哪——风险分析、测试策略、探索性测试。如果腾出来之后还是去点下一页，那4分钟和3小时没有本质区别。
最后
那个朋友后来跟我说了一句话，我觉得比4分钟这个数字更重要：
“以前我一天里大部分时间在操作，只有一小部分在思考。现在反过来了。”
手动3小时和Playwright4分钟，差的从来不是工具的价格、不是脚本的行数。差的是你把人放在了“操作”的位置上，还是放在了“判断”的位置上。
机器做机器的活，人做人的活。这条线画清楚了，4分钟是自然结果。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
