经过两个星期的努力，我终于肝完了 playwright 中文站的主要内容。

站点地址 playwright.itest.info

后面我会把精力放到 playwright 的原创教程上去，预计也会在这两周发布吧。

这次技术选型的时候遇到了一些问题，肝到快结束才发现 zola 并不支持中文索引的能力，也就是说搜索功能就没办法实现了。

所以我搞了个全部教程的 archive 页面，大家需要搜索的话可以可以在全部教程页面进行搜索。

目前全站应该更新了 90 篇左右的资料，涉及到 playwright 的基础，框架设计，api 测试以及各种最佳实践，技术含量还是不错的。

在整理和翻译教程的过程中，我自己对 playwright 也有了比较深入的了解，对目前正在写的 playwright 教程的帮助很大，一些实现和配置目前基本上手到擒来，所以建站的过程也是一个非常好的学习的过程，付出和收获是对等的。

另外一些文章翻译的质量不是很高，比如有一篇关于 playwright 视觉测试的教程，英文内容本来是很好的，不过翻译过来之后就显得牛头不对马嘴，我自己理解起来都觉得费劲，所以下周我决定抽时间把这篇教程本地化一下，做一个高质量的视频教程。

因为写了很多爬虫的关系，站点的内容应该会持续更新下去的，后面有机会的话看能不能把之前 selenium 的内容也整理出来，做一个 selenium 的中文教程站，毕竟现在对静态网站的制作也是非常得心应手了。

推荐内容

我精选了一些我认为比较好的内容，我把教程的名字放在这里，感兴趣的内容大家自行去所有教程的存档页面搜索就可以了。

• 如何让 playwright 运行的更快: 非常实用，特别是你的自动化代码足够多的话
• 如何使用 Playwright 监控 JavaScript 控制台日志和异常: 监听页面的pageerror事件，对实时前端页面监控很有意义
• 挖掘 playwright 的隐藏宝藏: 各种最佳实践，量大管饱
• 全面的基于 Playwright 的 ui 自动化测试，使用页面对象模型的模块化框架: 用 playwright+po 实现测试框架
• Playwright: 如何正确使用 fixture 构建页面对象: 使用 fixture 来组织 po，这个实践的工程化水平很高，推荐
• 使用 playwrigth api 测试: 用 playwright 做 api 测试，这一系列教程确实写的很好
• 如何使用组件来重构 playwright 的代码: 在元素之上，page 之下还可以抽象 1 个组件层，代码思想很好

最后

创作内容和维护内容不易，希望这个站点对大家会有所帮助。

我花了一周的时间肝了个 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 更新太快，所以就这么搁置起来了。