本文作者：欧海锋，碧桂园服务高级测试工程师，致力于研究测试技术。

注：本文档所有操作均基于 macOS 系统。

1 项目背景

当前 IT 项目的测试工作主要采用接口自动化及手工操作两种方式，其中手工测试方式耗时长、易出错，而且界面验证还依赖人工进行操作。基于此，我们考虑引入相应的 UI 自动化测试工具进行辅助测试。通过将稳定的项目功能实现 UI 自动化，可以提高测试回归验证的效率和准确性。

借此次工具调研的契机，我们将工具用于场地系统，以评估工具对项目带来的测试价值和效率提升情况。

2 UI 自动化工具对比

当前比较流行的 UI 自动化工具有 Playwright 和 Selenium，它们都拥有丰富的功能和 API，适用于测试 Web 应用程序。我们可以根据不同的需求和场景，选择合适的自动化测试工具。以下是这两个工具的对比情况：

基于上述的对比项，不难看出：

• Playwright 相对容易学习，对使用人员的技术要求较低。

• Playwright 的录制生成脚本功能可以显著提高 UI 自动化实现的效率。

• Playwright 提供的功能更加全面，执行效率更高。

• Playwright 拥有更突出的性能优势。

因此，在本次项目实践中，我们选用的是更加简单容易的 Playwright。

3 Playwright+ Pytest 实战

注：本项目实践基于场地系统进行。

3.1 前置准备

• python 3.7+

• python 三方库 Playwright（pip install playwright）

• playwright 浏览器驱动安装（python -m playwright install）

注：下载资源缓慢请更换 pip 源为国内源

3.2 项目架构

• codegen_data：录制的脚本存放。

• common：公用方法存放。

• data：测试数据存放。

• log：脚本运行产生的日志存放。

• test_case：测试用例脚本存放。

• test_report：测试报告存放。

• config.py：命令/路径等配置信息文件。

• conftest.py：setup 执行的操作存放。

• myRunner.py：执行 main。

3.3 录制脚本

① PC 端实操

命令行工具执行命令：

python -m playwright codegen -o 'test_login.py' --target python -b chromium https://cas-test.bgyfw.com/idp/authcenter/ActionAuthChain?entityId=BIZTEST

让我们一起解读一下命令的意图：

使用当前计算机的 Chromium 打开指定 URL，生成的脚本语言为 python，保存名称为 test_login.py。

以上为命令执行后进入的界面，可以发现：

• 当鼠标滑过元素的时候，会自动提示元素的 xpath。

• 启动的是无痕浏览模式，可以很容易和本地浏览的页面进行区分。

• 同时也会打开一个 Playwright Inspector 的窗口，显示生成的代码，以便对页面进行实时操作。

关闭浏览器时，将停止录制并输出脚本文件。从这里可以看出，脚本文件正是上述命令中指定的文件名。这里使用的是同步模式，生成源码如下所示：

from playwright.sync_api import Playwright, sync_playwright, expect

def run(playwright: Playwright) -> None:    browser = playwright.chromium.launch(headless=False)    context = browser.new_context()    page = context.new_page()    page.goto("https://cas-test.bgyfw.com/idp/authcenter/ActionAuthChain?entityId=BIZTEST")    page.goto("https://open-test.bgyfw.com/gateway.html")    page.goto("https://open-test.bgyfw.com/%E6%93%8D%E4%BD%9C%E6%88%90%E5%8A%9F")    page.goto("https://cas-test.bgyfw.com/idp/authcenter/ActionAuthChain?entityId=BIZTEST")    page.get_by_role("img").first.click()    page.close()
    # ---------------------    context.close()    browser.close()

with sync_playwright() as playwright:    run(playwright)

生成的代码可以直接运行，运行后会自动打开 Chromium 浏览器执行相应的页面操作。

到这里我们有一个疑问：Playwright 是否支持主流的浏览器？我们如何切换到浏览器？

让我们再次查看执行的命令，发现其中有一个参数【-b】，用于指定浏览器。再看看说明：

-b, --browserbrowser to use, one of cr, chromium, ff, firefox, wk, webkit (default: "chromium")

从上述说明中可以看到，参数【-b】支持 Google Chrome、Microsoft Edge（cr，chromium）、 WebKit 内核的 Apple Safari （ wk， webkit）和 Mozilla Firefox（ff，firefox）浏览器。

让我们基于每一个浏览器都录制生成一份代码：

chrome 浏览器

firefox 浏览器

 Safari 浏览器

我们可以发现不同的浏览器在操作上是相似的，生成的代码有一个地方有所不同，如上图红框所示。换个角度来说，我们只需要基于一个浏览器生成代码后，手动修改就能实现浏览器兼容测试和代码的复用，极大地提升了效率。

② 移动端网页实操

命令行工具执行命令：

python -m playwright codegen -o 'test_login.py' --target python -b chromium --device="iPhone 12 Pro" https://cas-test.bgyfw.com/idp/authcenter/ActionAuthChain?entityId=BIZTEST

对比 PC 端实操执行的命令，当前命令多入参了一个参数【--device】

让我们一起解读一下命令的意图：

模拟 iPhone 12 Pro 设备打开指定 URL，使用 Chromium 驱动，生成的代码语言设置为 python，保存名称为 test_login.py。

以上为命令执行后进入的界面，可以发现录制的界面与 iPhone 12 Pro 打开的网页一致。这不禁让我们产生了一个想法：项目的手机界面兼容测试是不是可以通过 Playwright 解决？

答案是可以的！

Playwright 支持的手机/平板型号共有 116 种，基本覆盖了 50%左右的主流设备，具体如下图所示：

让我们抽几个手机型号录制各生成一份代码：

iPhone 12 Pro

Galaxy S9+

Nexus 7

我们可以发现，不同的手机在相同的操作下，生成的代码只有两行不同，如上图红框所示。

换个角度来说，我们只需要基于一个手机型号生成代码后，手动修改一下就能实现手机浏览器兼容测试和代码的复用，这将大大提升效率。

3.4 conftest 应用

在 pytest 中，除了提供现成的 setup 和 teardown 方法，还提供了 conftest 文件结合 fixture 的方法来处理测试用例的前置条件和后置条件的操作。

• conftest 简介：conftest 是一个固定的 py 文件，修改为其他名字不会生效。

• conftest 作用域：作用范围在该目录及其下的子目录。

• conftest 作用：同目录下的测试用例文件运行前都会执行 conftest.py 文件，相当于一个前置文件。

conftest 实际应用如下图所示：

对比生成的两个脚本，发现前置的步骤均一致，我们可以把一致的部分提取出来做成 setup。

同时，根据 conftest 文件的作用，我们把前置操作在 conftest.py 用方法封装起来，如下图所示：

封装完成后对脚本进行简化处理。简化效果如下图所示：

从简化效果来看，可以发现 conftest.py 文件是不需要导入的，它在执行 pytest 的时候会自动查找并使用 conftest.py 文件。

3.5 断言运用

断言当前页面的标题是否是指定的页面标题

expect(page).to_have_title("碧桂园服务统一认证")

expect(page).to_have_title("增值平台")

断言元素是否存在当前页面

assert page.wait_for_selector('#app > section > div.layout-container > section > div > h4')

断言当前元素的文本是否跟预期一致

content = page.text_content('#app > section > div.layout-container > section > div > h4')

assert content == "欢迎使用社区资源管理平台～"

断言元素的文本是否是期望值

js_content = page.locator('#app > section > div.left-menu.wujie-left-menu > div > ul > div:nth-child(3) > li > div > span').text_content()

assert js_content == "客户管理"

断言点击复选框后，复选框为选中状态

page.locator("selector").first.click()

checked = page.is_checked('selector')

assert checked

断言点击取消选择后，复选框为空状态

page.get_by_role("button", name="取消选择").click()

checked = page.is_checked('selector')

assert checked == False

断言按钮原始状态为非激活状态

enabled = page.is_enabled('selector')

assert enabled == False

断言输入内容后，按钮状态变为激活状态

page.get_by_label("新增客户", exact=True).get_by_placeholder("请输入客户税号").click()

page.get_by_label("新增客户", exact=True).get_by_placeholder("请输入客户税号").fill("test")

enabled = page.is_enabled('selector')

assert enabled

3.6 批量执行生成测试报告

生成的测试脚本加上断言后，需要批量执行测试脚本并生成测试报告。

在给出的项目架构中，可以通过配置文件来控制需要执行的测试范围。

首先，在项目中的 common/config.py 中已经定义了测试用例的路径(case_path)为项目中的 test_case 文件夹。具体如下图所示：

然后，在项目根目录 config.py 文件中定义了一个名为 cases_path 的变量，该变量可用于指定具体的测试范围。我们可以选择定义一个文件夹，以便在执行的时候运行该文件夹下的所有测试脚本；或者指定一个 py 文件以进行单独执行。具体如下图所示：

最后，配置好测试范围后，可以开始执行测试。在项目根目录 myRunner.py 文件中，点击运行按钮即可批量执行测试并生成测试报告。

3.7 失败截图定位问题

如果用例执行失败了，要如何进行定位？

根据报告提供的失败截图功能，可以在生成的报告中看到相应的截图和报错信息，帮助我们快速定位问题并进行分析。

4 项目应用取得的成果

场地系统共有数千条测试用例，使用 Playwright 后，大部分测试用例实现了 UI 自动化，整体自动化率得到大幅提升。

随着 Playwright 的使用，场地项目的自动化率不断提高，测试的回归效率也在不断地提升。

注：上图为项目自动化工程脚本树部分截图

5 总结

1. Playwright 是一个功能强大的自动化工具，可用于测试和浏览器兼容。它提供了丰富的功能，可以大大提高测试和自动化的效率和可靠性。

2. Playwright 的录制生成脚本功能解决了测试人员编写操作步骤代码的问题，通过精准的定位，测试人员只需要专注于如何断言即可。相比传统的纯代码，它极大地提升了效率并降低了对测试人员的代码能力要求。

3. Playwright 还解决了 UI 自动化脚本维护的难题，只需重新录制一份脚本、编排断言并移除旧的脚本即可实现维护。

4. 此外，Playwright 还提供了许多适用于自动化的功能，只有在实践中才能更好地发挥其作用。