同一个回归测试:手动 3 小时,Playwright 4 分钟——差距不在工具,在“谁做机器的活”

举报
霍格沃兹测试开发学社 发表于 2026/10/21 14:17:01 2026/10/21
【摘要】 上周跟一个QA朋友吃饭,他掏出手机给我看了一张截图:同一套回归测试,手动跑3小时12分钟,Playwright跑4分钟07秒。他说:“我老板看到这个数据,第一反应是‘那你们以后是不是可以少两个人’。”我说:“你老板问错问题了。该问的是——那3小时里,到底有多少时间花在了‘人根本不该做的事’上。”这顿饭吃完,我把他那3小时的手动流程要了过来,一笔一笔拆。一、先算账:3小时里,人在做什么他把回归...
上周跟一个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分钟是自然结果.

【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0)

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。