我花了一周的时间肝了个 playwright 的教程站，域名是 playwright.itest.info，事情的起因还要从 1 个油管视频说起。

我从那个视频上了解到，1 个做 AI 硬件的公司把 playwright 的自动化操作功能跟 AI 硬件结合了起来，融了 2000 万美金。

这让我大受震撼。

首先我没想到这么高大上的产品竟然用的是如此朴实无华的技术，更让我感到惊讶的是这家公司选择的工具是 playwright，而不是自动化届的老大哥 selenium。毕竟如果从纯技术的角度上考虑，selenium 是在原生浏览器上跑的，它的兼容性其实更好。

看来 playwright 确实是有它独到之处的。

这也让我陷入了思考，可能大部分人学习 ui 自动化工具的初衷不是测试，而是赚钱。

毫无疑问，在 2024 年的今天，playwright 是最有钱景的自动化测试工具，当然了，是金钱的钱。

不过我发现 playwright 的中文资料非常有限，所以我和虫师创建了这个站点，希望可以一直维护下去吧。

关于目前的进度

目前上线的版本有大概 24 篇左右的原创加翻译的资料。

我写了个爬虫去关注 playwright 的最新进展，也爬了 120 多篇非常优秀的英文教程。后面我会持续更新，这样一来资料会更加丰富一些。

除了翻译，我目前主要的精力是放在了原创教程上。在 playwright 可以找到的资料里，大部分的内容都是和自动化测试相关的，这些内容很好，不过我想如果我的教程把关注的重点放在爬虫和自动操作上，那么是不是受众会更广泛一些。

爬虫可以获取数据，在 AI 大行其道的今天，数据是各种大语言模型的基础。

自动化操作可以提升工作效率，在提效这个赛道上，永远是有商机可以挖掘的。

所以我开始肝一套 playwright 的中文教程，可以写的素材相当的丰富，既然要写很多，那么不如就写一本书吧。

目前书籍的进度大概是这样的，typescript 版本应该完成了有 50%了，等肝完 ts 的版本，再花点时间把 python 版本结束掉。

关于网站内容的质量，翻译的文章，我尽量翻译的通俗易通，然而水平毕竟有限，一些翻译的资料中会出现比较神奇的表达，希望大家可以多多指正。

原创的文章我会尽量做到深入浅出，让大家容易理解。

另外 playwright 的 api 变化很快，之前已经过期的内容我这边会人肉过滤掉，尽量保证呈现出的内容是最新的，一些翻译文章里我会加入自己的看法，明目张胆的夹带私货了。

结束掉文本资料的部分后，我会根据教程的内容录制一套 playwright 的视频教程，也会把重点放在爬虫和自动化操作上。

这是一个常见的经典问题，答案见仁见智，下面是一种比较普遍的观点。

这取决于你对“所有内容”的定义。

你可能指的是对整个应用程序进行全面的回归测试，包括所有功能、负面路径、边缘情况等。你说得对——除了一些非常小的产品外，你不可能在每次迭代中做所有这些事情。

但事实是：你不应该在每次迭代中进行这种全面的测试，你不应该觉得有必要这样做，也不应该被要求这样做。

迭代是敏捷软件开发中的概念——在软件长期开发并在最后一次性交付的模式中，“迭代”这个词没有意义。

迭代开发软件的全部意义在于引入小而有价值的变更并将其交付给用户。由于变更很小，产品的大部分与之前相同，因此不需要再次进行全面验证。假定它在过去已经被测试过了。

但也许变更的范围比看起来更广，或者它们在程序的其他部分引入了意想不到的后果。

这些都是合理的担忧。然而，开发人员引入的大多数变更并不影响整个系统，你不应该默认认为它们可能会这样。

值得补充的是，如果团队经常发现自己处于变更波及整个系统并需要全面测试的情况，那就是存在更深层次问题需要解决的迹象。

这可能意味着系统架构有问题，团队应该认真考虑偿还技术债务。 或者也许软件更像是一个原型、概念验证，而不是解决方案。在这种情况下，在团队更好地理解需求和利益相关者可以批准一种方法之前，可能不需要全面测试。许多测试人员在这种环境中工作时感到困难。他们将自己的角色视为可能存在缺陷的软件与用户之间的最后一道防线。他们对用户可能得到未经全面测试和验证的软件感到不安。

如果你是其中之一，你需要理解这种风险是经过计算的，也是重视短迭代和频繁交付的软件开发模式固有的。这些想法相互强化。产品没有经过全面测试，这意味着可能存在用户遇到前未被发现的错误、失误和问题。但正因为产品没有经过全面测试，它可以更快地发布。当团队了解到软件中的问题时，他们可以修复并进行新的发布。

如果这个论点不能说服你，我建议你尝试一下。承认你个人并不认同这种方法，但如果这是团队想做的，就不要阻止它。在几次发布中保留你的保留意见，看看会发生什么。你可能会发现产品的质量实际上并没有明显低于以前。如果结果显示质量确实下降了，那么你将有坚实的经验数据向团队展示。大多数人会同意这些结果是不理想的，需要某种改变。

最后，你不应该被要求在每次迭代中进行全面测试。

就我个人而言，我在这方面没有太多经验——我从未在试图这样做的团队中工作过。虽然我不能说在这种情况下什么方法可能有效，但我猜想首先要做的是理解这种要求背后的立场。也许需要教导利益相关者迭代的权衡；或者也许团队需要采用更谨慎的软件开发模式，以牺牲速度为代价。

我还没有提到自动化，它对以上所有观点都有贡献。作为测试人员，你的工作应该得到自动化的支持，至少每天运行一次，并提供关于产品状态的最新可靠信息。虽然自动化有限制，不能检查所有内容，但它可以检查一些行为。

你应该了解在你的项目中自动化能做什么和不能做什么，这样你就可以对哪些功能和路径不需要花费太多时间做出明智的决定。你应该对自动化结果有信心。当有人要求你反复执行特定测试时，你可以将其视为讨论花些时间改进自动化的机会。

在这篇文章的开头，我说过答案取决于“所有内容”的含义。它可能意味着全面测试，这是我到目前为止关注的重点。但它也可能意味着迭代期间发生变化的所有内容。

确实会发生开发人员完成了如此多的工作，以至于团队中的测试人员应接不暇的情况。不久前我就遇到过这种情况，对我们有效的方法是推动整个团队的所有权。大多数开发任务不需要专门的测试人员来测试或验证——它们只需要由没有编写代码的人来测试。在我们的案例中，我们所要做的就是在站会上表明问题，团队其他成员很快就想出了解决方案——一些开发人员应该停止接受新工作，而是专注于测试已经完成的内容。为每个任务明确列出完成的定义和验收标准肯定会有所帮助。

然而，处理这个问题的最好方法是主动避免它。总的来说，作为测试人员，尽量尽快测试变更。不要等到迭代结束。如果团队实践基于 PR 的工作流程，你可以尝试在代码合并之前测试创建的开发版本。让 CI 系统为每个 PR 构建工件会有所帮助，但另一种选择是在你自己的机器上设置构建环境。对于特别大的功能，在代码编写之前给开发人员反馈，并鼓励早期分享代码和想法。每日站会（如果有的话）是表达这种对话愿望的好机会。你也可以考虑主动联系开发人员并私下讨论。

可能会发生尽管使用了上述所有建议，测试人员在冲刺结束时仍然常常工作过载的情况。根据我的经验，这种情况更有可能发生在试图严格遵循僵化的 Scrum 结构的团队中，迭代周期为一到两周。由于工作在冲刺开始时分配，会有一段时间开发人员专注于他们的工作，而测试人员没有太多事情可做。这种动态在冲刺结束时会发生变化。在这种情况下，我强烈建议在回顾会议上提出这个问题。大多数人会同意这是一个长期不可持续的系统性问题。像往常一样，对于自组织团队来说，由团队自己想出解决方案。只要记住监控情况，保留数据，如果没有明显改善，就再次提出这个话题。

想象一下，你需要在 CI/CD 流水线中进行一些 API 调用，以进行身份验证、获取数据、发送简单请求或从网络 URI 下载文件。

你会选择哪些工具？

答案可能是使用像 Postman 这样的著名 API 测试工具。

不过一般情况下只需要用 curl 就够了。而且很多年之前 curl 就已经跨平台了，我记得 windows 上也是可以使用的。

所以我认为，写一篇关于 CURL 的文章是值得的。

我将这篇文章的范围缩小到 HTTP/HTTPS，因为写一篇关于 curl 全部功能的文章会花费好几天。你很快就会明白我为什么这么说。

curl 是做什么的？

Curl，全称为“Client URL”，是一种命令行工具，用于通过 URL 传输数据。curl 还用于汽车、电视机、路由器、打印机、音频设备、手机、平板电脑、医疗设备、机顶盒、电脑游戏、媒体播放器等。

Curl 是超过二百亿个软件应用程序中的互联网传输引擎。

几乎每个使用互联网的人每天都会使用 Curl。

你能想象它支持多少协议吗？

DICT、FILE、FTP、FTPS、GOPHER、GOPHERS、HTTP、HTTPS、IMAP、IMAPS、LDAP、LDAPS、MQTT、POP3、POP3S、RTMP、RTMPS、RTSP、SCP、SFTP、SMB、SMBS、SMTP、SMTPS、TELNET、TFTP、WS 和 WSS。curl 支持 TLS 证书、HTTP POST、HTTP PUT、FTP 上传、基于 HTTP 表单的上传、代理（SOCKS4、SOCKS5、HTTP 和 HTTPS）、HTTP/2、HTTP/3、cookie、用户+密码认证（Basic、Plain、Digest、CRAM-MD5、SCRAM-SHA、NTLM、Negotiate、Kerberos、Bearer tokens 和 AWS Sigv4）、文件传输恢复、代理隧道、HSTS、Alt-Svc、unix 域套接字、HTTP 压缩（gzip、brotli 和 zstd）、etags、并行传输、DNS-over-HTTPS，等等。

为什么选择 Curl？因为它简单、无处不在且灵活！

• 简单易用：Curl 就像 API 测试的瑞士军刀。它简单、直接，不需要编程博士学位就能使用。只需输入几个命令，按下回车键，瞧，你就像专业人士一样发送或测试 API！
• 随处可用：无论你是在 Mac、PC 还是 Linux 机器上，Curl 都能为你服务。不需要为不同平台使用不同的工具，Curl 与每个人都相处得很好。

让我们开始发送 API 请求吧

首先确保你已经在电脑上安装了 Curl。别担心，这就像下载一个应用程序或使用包管理器一样简单。安装完成后，你就准备好了！

对于测试同学来说，为了详细了解背景，你必须在合适的时间向合适的人提出合适的问题。如果没有背景信息，你可能无法设计出有效的测试场景。

在没有有效测试场景的情况下，你可能无法为团队提供有价值的反馈，而这是质量保证人员（QA）所期望的。最终，团队将对测试过程失去信心，产品负责人可能会对软件质量提出质疑。因此，提问不仅对深入了解背景至关重要，还对确保交付的软件符合每个利益相关者的期望至关重要。

我的测试方法总是从向参与决策过程的不同人员提问开始。这使我能够深入了解变更的原因。

我向技术主管和架构师提问，以了解他们如何规划代码变更以适应新的业务需求。

我向产品负责人提问，了解计划中的变更将如何解决用户的问题。这让我了解客户面临的问题。

在这篇文章里，我将分享在开始测试之前你应该问的这些基本问题。

目录

• 在测试之前 QA 应问的基本问题
  • 什么变了？
  • 为什么变了？
  • 影响在哪里？

什么变了？

你必须首先问产品负责人：计划做哪些变更？为了详细了解，可以进一步拆分为更小的问题，比如：

• 具体修改了哪些组件？（例如数据库、后端、前端或其他系统服务）
• 哪些改动影响了系统的状态路径？
• 是否引入了任何新的终端用户功能？
• 这些变更为终端用户解决了什么问题？

为什么变了？

同样重要的是了解变更背后的理由。你应该能够理解客户面临的问题，这些问题促成了这一决策。如果不了解用户的痛点，作为 QA，你无法确保变更是否有效地解决了这些问题。为了进一步拆分这个问题，你可以问以下跟进问题：

• 在此次变更之前，利益相关者具体遇到了哪些问题或痛点？
• 实施此变更预期带来的好处或改进是什么？

影响在哪里？

“影响在哪里？”是有效测试计划中最重要的问题之一。你应该尽早识别受影响的区域。通过定位受影响的区域，你可以设计出全面覆盖这些变更的测试场景。

总之，作为 QA，你应该具备设计有效测试场景所需的所有知识。你可以根据你的系统和情况调整这些问题，但你必须尽早得到这些问题的答案，以确保你的测试高效且有效。

这是一张 主流的 3 大自动化测试工具每周 npm 下载量的统计对比。

npm 是 nodejs 的依赖管理工具，所以这张图可以看出在 javascript 这门语言领域，每种工具使用人数的变化情况。

看图说话，从趋势图上看，3 大工具在 2024 年的命运大相径庭。

• cypress 增速明显放缓，考虑到 cypress 只有 javascript(typescript)版本，所以可以比较确定的是，cypress 的用户数已经停滞不前了;
• selenium 的用户数开始退坡，考虑到 selenium 有 java 和 python 的版本，我们只能说，在前端领域用 selenium 的人变少了；
• playwright 的用户数急剧增加，特别是在 2023 年的下半年，曲线陡然上升，可能新用户和从 selenium 转投过来的用户带来了这次爆发式的增长；

结合上次我做的一个关于如何使用 playwright 狂赚美刀的视频，结论很明显了。

2024 年最值得学习的自动化测试框架就是 playwright 了。

为什么是 playwright

• 首先 playwright 有个好爹，微软出品，如果项目不被砍的话，更新和维护的力度是可以得到保证的；
• 其次 playwright 的入门比 selenium 其实是要简单不少的，适合初学者；
• 另外 playwright 的多种特性保证了初学者可以用相对简单的代码写出可以稳定运行的测试用例，做过自动化测试的同学肯定知道，对于用例来说，稳定运行意味着什么；
• 最后，也就是最为重要的一点就是，大部分的在其他测试层面，比如单元测试或者接口测试，搞不定的用例或者操作，都可以用 ui 自动化工具来实现。也就是重剑无锋，大巧不工。这就意味着，除了测试，ui 自动化工具的应用范围其实非常广，学的好真的可以赚钱。还是我上次视频里提到的 ai 设备之耻——rabbit R1 的例子，既然 ai 现阶段没办法实现自动打车或者定外卖的功能，那就让 playwright 去实现吧；

如何学习

• 首先建议初学者使用 typescript 的版本，原因很简单，ts 版本配合编辑器会带来完备的代码提示，对初学者来说很可能带来极大的帮助；
• 建议使用默认的带 testsuit 也就是测试套件的版本进行学习，因为这个版本自带断言，测试的目的就是为了各种断言；
• 官方文档是最好的学习资料，因为官方文档更新非常及时，毕竟 playwright 还在密集开发中，经常隔一段时间就会带来一些新特性；

开坑

一转眼就下半年了，准备开个 playwright 教程的坑，其实之前一直想做的，但无奈 playwright 更新太快，所以就这么搁置起来了。

最近有机会看到了 RPA 在实际工作中的重度应用，深刻感受到了自动化的强大实力，以后的应用前景时完全可期的。

RPA (Robotic Process Automation) 简介

Robotic Process Automation (RPA) 是一种技术，使用软件机器人（或称“机器人”）来模拟人类在数字系统中执行的任务。RPA 可以自动执行高度重复性和规则驱动的任务，这些任务通常需要人类操作来完成。RPA 通过与现有系统和应用程序进行交互，无需对底层系统进行改动即可实现自动化。

本质上讲 RPA 就是自动化脚本，好的 RPA 脚本可以结合页面自动化，桌面自动化（操作桌面级的应用，比如微信电脑版）以及接口自动化，用自动化去替代人类操作。与自动化用例不同的是 RPA 里面的断言不是必须的，自动化用例的目的是验证，也就是实现断言；RPA 的目的是高效率低错误率的完成工作，比如给微信群群发消息之类的。从本质上讲，RPA 就是一种自动化测试，一种理论上可以省略断言的自动化测试。但实际上如果想要 RPA 脚本长时间稳定运行，断言也是必不可少的，当断言条件不满足时，RPA 脚本应该进行无损的容错处理，这样程序才会更加健壮。

我们可以把 RPA 看成是综合性的自动化测试，也就是设备端的自动化。比如下面这个 RPA 场景：

• 第一步调用 api 自动获取一些最新的资讯，用 ai 做改写。这是接口自动化；
• 在网页端把改写后的资讯发布到某资讯网站。这是网页自动化；
• 在桌面端把新发布的资讯自动发送到微信群里。这是桌面应用的自动化；
• 最后调用设备农场的手机，在所有的手机上给这篇资讯点赞。这是手机自动化；

因为测试金字塔的关系，我们会将自动化测试分为 ui，接口以及单元测试，这些测试之间天然隔绝，相对独立，所以想象的空间其实不大，只是代替人工进行验证而已。其实这是没问题的，毕竟每种测试代表的主体不一样，分开使得测试用例变得更加容易编写和维护。

但 RPA 的主体是机器人，他的目标就是代替人类办公过程中的大量的重复性操作，多种自动化技术和 ai 技术的结合才可以达到这种效果，这么一想其实结论很明显了，RPA 就是自动化测试，是所有种类自动化测试的终极合体形态（有点中二了）。

RPA 的真实应用案例

我看到的实际例子

我看到的实际应用其实是在电商上，有朋友开了一家跨境电商的公司，我去那边拜访的时候正好遇到他在研究国内某家 RPA 厂商(最近融资了 1 亿美金)的方案。因为电商的重复性劳动是非常多的，所以 RPA 的应用场景相当的广阔。最震撼的例子是退货退款的例子。

一些商家平时的销量比较大，但众口难调，出的单越多，退货的比例就越高。

每个退货单其实逻辑上不需要审核，只要退就好了，但是流程上还是要系统在系统上做一些操作的，因为处理有时效性，需要在短时间内快速解决掉，用人工做的话长时间下来工人会感到疲惫，另外操作的效率也相对较低。这时候 RPA 就可以很好的满足长时间高效率低错误率的重复性工作，据说一到两天可以处理几万个订单，这其中节省的人力真的是非常可观的。

另外还有很多跨境电商公司用 rpa 做批量上下商品等操作，也是非常杀手级的应用。

其他的 RPA 应用领域如下。

1. 银行与金融

应用场景: 贷款处理、账户开立、反洗钱监控、客户服务。 案例: 某大型银行采用 RPA 自动化贷款处理过程，包括贷款申请数据的验证和审批，从而将处理时间从几天缩短到几小时。此举不仅提高了效率，还减少了人工处理中的错误。