大家好! 我总是对具有双重目的(UI 和 API 测试覆盖率)的测试自动化框架持怀疑态度。通常,您将在不同的测试运行(或事件项目)中运行不同的测试层,因为每个测试可能都有自己的 , 和 。 依赖关系 配置, 环境变量 最近,我查看了 在 测试方面提供的内容,并将其与我 经验进行了比较,所以以下是我要与大家分享的内容...... Playwright API 在 Cypress 的 柏 不久前就实现了 测试。您可以 ,通过示例了解该工具在 测试方面的出色表现。 Cypress API 在学习门户上找到一篇文章 API 安装性能 为了运行测试,您需要安装项目依赖项,对吗?好吧, 附带了 ,如果你想专门运行 测试,那么安装它可能会非常多余(而且耗时)(比方说,你在 CI 中有单独的工作用于 UI 和 API 测试运行,通常是这种情况)。 Cypress 一个电子浏览器 API 看起来不太好,是吧? ☝️ 此外,当您运行 测试时 - 它无论如何都会启动浏览器。 API 测试实例 使用 的简单 测试如下所示: Cypress API it('Sign in with valid credentials', () => { cy.request('POST', '/auth', { login: Cypress.env('username'), password: Cypress.env('password'), }).should(response => { expect(response.body.token).to.be.a('string') expect(response.status).to.eq(200) }) }) 看起来很漂亮 剧作家 就像 一样, 是一个测试自动化框架 - 您 ,也可以使用 (测试运行器、断言库、浏览器自动化工具、HTTP 客户端、报告器等)。 Cypress Playwright 可以只使用浏览器自动化工具 整个框架 安装性能 这里的区别在于 不附带任何开箱即用的浏览器 - 您必须使用单独的命令安装它们(如果您愿意)。 Playwright 它在这里产生了巨大的差异,因为就专门运行 测试而言,它不会运行任何浏览器或任何其他桌面应用程序,并在您的计算机上节省一些运行时间和资源。 API 测试实例 使用 进行的简单 测试如下所示: Playwright API import {test, expect} from '@playwright/test' test('Sign in with valid credentials', async ({request}) => { const response = await request.post('/auth', { data: { login: process.env.USERNAME, password: process.env.PASSWORD, }, }) expect(response.status()).toEqual(200) expect(await response.json()).toEqual({ token: expect.any(String), }) }) 我想强调一下断言对象的 : 类似 Jest 的语法 expect(await response.json()).toEqual({ token: expect.any(String), }) 这种语法允许您仅通过一次 调用来验证对象的整个结构☝️ expect 结论 API 测试应该是小而轻的,因为它们不需要太多的运行。 让我们总结一下上面的材料... 安装性能 ✅ 凭借 快的开箱即用干净安装而获胜。 Playwright 13 倍 ℹ️ 如果 或 中,您可以减少 中的 安装时间。 使用带有预安装依赖项的映像 将它们缓存在 CI 存储 CI Cypress 运行性能 ✅ 获胜,因为它不需要浏览器来运行 API 测试,所以它开门见山。 Playwright ℹ️ 在 API 测试中没有办法“不运行”浏览器,因为它是框架逻辑的一部分。 测试语法 这里无法选出获胜者,因为 和 都没有客观优势。 Cypress Playwright 它们的语法都非常简单,但略有差异。我想说这是测试人员决定在这里选择他们喜欢的东西。 全面的 我可以肯定地说,由于其性能,使用 进行 测试自动化是足够安全的。如果您已经使用此框架进行了 测试,那么这将是一个公平的解决方案。 Playwright API UI 我对那些使用 进行 测试并想要覆盖 层的人的建议 - 最好使用其他东西( + ,你可以 看到一个例子)。 Cypress UI API Jest Axios 在那里