Playwright for .NET端到端测试实战：从登录到业务全流程覆盖

1. 项目概述：为什么选择 Playwright for .NET 来做端到端测试？

如果你是一名.NET开发者，或者你的团队主力技术栈是C#，那么当你需要为Web应用构建一套可靠的端到端测试时，Playwright for .NET 绝对是一个绕不开的选项。我最近刚用这套工具为一个电商后台管理系统完成了从用户登录到核心业务操作的全流程自动化测试覆盖，整个过程下来，感触颇深。它不仅仅是一个测试工具，更像是一个高度智能化的浏览器操作机器人，能帮你把那些重复、繁琐且容易出错的UI验证工作，变成一套稳定、可重复执行的代码资产。

简单来说，Playwright for .NET 是微软官方维护的.NET语言绑定，它让你能用熟悉的C#代码，去驱动真实的Chromium、Firefox或WebKit浏览器，模拟用户的所有操作：点击、输入、拖拽、等待页面加载、断言元素状态等等。相比之前我们团队用过的Selenium，Playwright在稳定性、执行速度和现代化API设计上，优势非常明显。特别是它内置的自动等待机制，能智能地等待元素可操作或网络请求完成，这直接解决了传统UI测试中最令人头疼的“元素未找到”或“超时”问题，让测试脚本的健壮性上了一个大台阶。

那么，这个“从登录到业务全流程覆盖”具体意味着什么？它指的是一套测试脚本，能够像真实用户一样，完整地走通一个业务场景。以电商后台为例，流程可能是：打开登录页 -> 输入账号密码登录 -> 验证登录成功并跳转到仪表盘 -> 导航到商品管理模块 -> 创建一个新商品 -> 填写所有必填信息并提交 -> 在商品列表中验证新商品已成功创建 -> 最后安全退出系统。这一连串的操作，涉及多个页面、多种交互和状态验证，Playwright for .NET 都能优雅地处理。接下来，我就结合实战经验，拆解如何一步步实现这个目标。

2. 环境搭建与项目初始化：打好地基

万事开头难，但Playwright for .NET 的开头相当友好。首先，你需要一个.NET项目。可以是现有的Web项目（比如ASP.NET Core MVC或Razor Pages项目），也可以专门新建一个测试项目。我个人强烈推荐后者，将测试代码与生产代码分离，结构更清晰，也便于CI/CD集成。

2.1 创建测试项目与安装依赖

打开你的终端或命令行工具，我们从头开始。假设你使用.NET 6或更高版本。

# 1. 创建一个新的类库项目，命名为 `E2ETests` dotnet new classlib -n E2ETests # 2. 切换到项目目录 cd E2ETests # 3. 将项目类型改为支持测试的MSTest或xUnit。这里以MSTest为例，它更轻量，与Visual Studio集成更好。 dotnet new mstest # 4. 安装 Microsoft.Playwright.NUnit 或 Microsoft.Playwright.MSTest 包。 # 注意：Playwright官方示例多用NUnit，但MSTest完全可用。我习惯用MSTest，所以安装： dotnet add package Microsoft.Playwright.MSTest

这个包是核心，它包含了Playwright的.NET API以及MSTest的集成支持。安装完成后，你还需要安装浏览器驱动。Playwright提供了一个非常方便的命令行工具来做这件事。

# 5. 安装 Playwright CLI 工具（全局或本地） dotnet tool install --global Microsoft.Playwright.CLI # 6. 安装浏览器（Chromium, Firefox, WebKit）。这条命令会下载所需的浏览器二进制文件到本地缓存。 playwright install

注意：playwright install命令可能会因为网络问题下载缓慢或失败。如果遇到这种情况，可以尝试设置环境变量PLAYWRIGHT_DOWNLOAD_HOST为国内的镜像源，或者使用科学上网工具（此处需注意合规性，建议使用企业内网代理或等待网络通畅时操作）。另一种方案是只安装你需要的浏览器，例如playwright install chromium。

2.2 项目结构规划

一个清晰的项目结构能让后续的测试代码维护变得轻松。我建议的目录结构如下：

E2ETests/ ├── E2ETests.csproj ├── Tests/ # 存放所有测试类 │ ├── BaseTest.cs # 测试基类，处理浏览器初始化、登录等通用操作 │ ├── LoginTests.cs # 专门的登录测试 │ └── ProductManagementTests.cs # 商品管理等业务测试 ├── Pages/ # 页面对象模型（Page Object Model, POM） │ ├── LoginPage.cs │ ├── DashboardPage.cs │ └── ProductPage.cs ├── Models/ # 测试数据模型 │ └── TestUser.cs ├── appsettings.json # 测试配置（如基础URL、用户凭证） └── playwright.config.json # Playwright 配置文件（可选，用于全局设置）

这种基于“页面对象模型”的设计模式是UI自动化测试的黄金法则。它将页面的元素定位和操作封装成类，测试脚本只调用这些封装好的方法，使得测试代码更易读、易维护，当页面UI变化时，你只需要修改对应的Page类，而不需要到处修改测试脚本。

3. 核心设计：页面对象模型与测试基类

在开始编写第一个测试之前，花点时间设计好基础设施是值得的。这能避免后期大量的重复代码和重构。

3.1 实现测试基类BaseTest.cs

基类的目的是为所有测试提供统一的初始化和清理环境。它负责启动浏览器、创建上下文和页面对象，并在测试结束后妥善关闭资源。

using Microsoft.Playwright.MSTest; using Microsoft.Playwright; using System.Text.Json; namespace E2ETests.Tests { [TestClass] public class BaseTest { // Playwright 核心对象 protected IBrowser? Browser { get; set; } protected IBrowserContext? Context { get; set; } protected IPage? Page { get; set; } // 配置信息 protected string BaseUrl { get; private set; } = "https://your-app-under-test.com"; protected TestUser AdminUser { get; private set; } = new TestUser("admin", "password123"); [TestInitialize] public async Task TestInitialize() { // 1. 启动 Playwright var playwright = await Playwright.CreateAsync(); // 2. 启动浏览器实例。Headless模式适合CI环境，调试时可设为false看到浏览器界面。 Browser = await playwright.Chromium.LaunchAsync(new BrowserTypeLaunchOptions { Headless = true, // 设置为 false 以在调试时查看浏览器窗口 SlowMo = 50, // 操作间延迟50毫秒，方便观察，正式运行可设为0或移除 }); // 3. 创建浏览器上下文。上下文相当于一个独立的浏览器会话，可以隔离cookie、本地存储等。 // 这里我们创建一个新的上下文，并设置视口大小和忽略HTTPS错误（针对测试环境）。 Context = await Browser.NewContextAsync(new BrowserNewContextOptions { ViewportSize = new ViewportSize { Width = 1920, Height = 1080 }, IgnoreHTTPSErrors = true }); // 4. 在新上下文中创建页面（Tab） Page = await Context.NewPageAsync(); // 5. 可选：加载通用配置 var config = JsonSerializer.Deserialize<TestConfig>(File.ReadAllText("appsettings.json")); if (config != null) { BaseUrl = config.BaseUrl; } } [TestCleanup] public async Task TestCleanup() { // 按照创建顺序的逆序关闭资源，避免资源泄露 if (Page != null) await Page.CloseAsync(); if (Context != null) await Context.CloseAsync(); if (Browser != null) await Browser.DisposeAsync(); } /// <summary> /// 通用登录方法，供所有需要登录状态的测试调用 /// </summary> protected async Task LoginAsync(TestUser user) { if (Page == null) throw new InvalidOperationException("Page is not initialized."); var loginPage = new LoginPage(Page); await loginPage.GoTo(BaseUrl); await loginPage.Login(user.Username, user.Password); // 等待登录成功后的跳转或某个标志性元素出现 await Page.WaitForURLAsync($"{BaseUrl}/dashboard"); // 或者等待某个只有登录后才显示的元素 // await Page.WaitForSelectorAsync("#user-menu", new PageWaitForSelectorOptions { State = WaitForSelectorState.Visible }); } } public class TestUser { public string Username { get; set; } public string Password { get; set; } public TestUser(string username, string password) { Username = username; Password = password; } } public class TestConfig { public string BaseUrl { get; set; } = ""; } }

关键点解析：

• TestInitialize和TestCleanup：这是MSTest的生命周期特性，分别在每个测试方法执行前和执行后运行。确保每个测试都在一个干净、独立的环境中开始。
• 浏览器上下文：使用NewContextAsync而不是为每个测试都启动一个新浏览器，效率更高，且能完美隔离测试。你可以为不同的测试套件创建不同的上下文，甚至模拟不同的设备（手机、平板）。
• LoginAsync方法：将其放在基类中，实现了登录逻辑的复用。任何需要登录的测试，只需在方法开始调用await LoginAsync(adminUser);即可。

3.2 实现页面对象模型：以LoginPage.cs为例

页面对象模型的核心思想是“封装”。我们将登录页面的所有细节（元素选择器、操作步骤）都封装在一个类里。

using Microsoft.Playwright; namespace E2ETests.Pages { public class LoginPage { private readonly IPage _page; // 使用定位器（Locator）来标识页面元素，这是Playwright推荐的方式 private ILocator UsernameInput => _page.Locator("#username"); private ILocator PasswordInput => _page.Locator("#password"); private ILocator LoginButton => _page.Locator("button[type='submit']"); private ILocator ErrorMessage => _page.Locator(".alert-error"); public LoginPage(IPage page) { _page = page; } /// <summary> /// 导航到登录页面 /// </summary> public async Task GoTo(string baseUrl) { await _page.GotoAsync($"{baseUrl}/login"); // 等待页面关键元素加载完成，增强稳定性 await UsernameInput.WaitForAsync(new LocatorWaitForOptions { State = WaitForSelectorState.Visible }); } /// <summary> /// 执行登录操作 /// </summary> public async Task Login(string username, string password) { await UsernameInput.FillAsync(username); await PasswordInput.FillAsync(password); await LoginButton.ClickAsync(); } /// <summary> /// 获取错误提示信息，用于断言 /// </summary> public async Task<string> GetErrorMessageAsync() { await ErrorMessage.WaitForAsync(new LocatorWaitForOptions { State = WaitForSelectorState.Visible }); return await ErrorMessage.TextContentAsync() ?? string.Empty; } /// <summary> /// 检查是否仍在登录页面（用于登录失败断言） /// </summary> public async Task<bool> IsStillOnLoginPageAsync() { return await _page.Locator("#username").IsVisibleAsync(); } } }

实操心得：

• 使用ILocator而非IElementHandle：ILocator是Playwright的核心抽象，它代表一个元素选择器，而不是一个立即获取的元素句柄。它的WaitForAsync等方法内部集成了智能等待，是编写稳定测试的关键。每次调用_page.Locator(“selector”)都会返回一个新的ILocator实例，开销很小。
• 选择器策略：优先使用id(#username)、>using Microsoft.Playwright; using Microsoft.VisualStudio.TestTools.UnitTesting; namespace E2ETests.Tests { [TestClass] public class LoginTests : BaseTest { [TestMethod] public async Task Login_WithValidCredentials_ShouldRedirectToDashboard() { // Arrange var loginPage = new LoginPage(Page!); // Act await loginPage.GoTo(BaseUrl); await loginPage.Login(AdminUser.Username, AdminUser.Password); // Assert // 验证URL已跳转到仪表盘 await Expect(Page!).ToHaveURLAsync($"{BaseUrl}/dashboard"); // 验证页面中存在代表登录成功的元素，例如用户菜单 var userMenuLocator = Page!.Locator("#user-menu"); await Expect(userMenuLocator).ToBeVisibleAsync(); // 甚至可以验证用户名显示正确 var userNameDisplay = Page!.Locator(".user-name"); await Expect(userNameDisplay).ToHaveTextAsync(AdminUser.Username); } } }

  代码解读：

  • [TestMethod]：MSTest标记测试方法的特性。
  • Page!：因为我们在基类中已经初始化了Page，这里使用null包容运算符告诉编译器它不为空。
  • ExpectAPI：这是Playwright提供的一个非常强大的断言API。它与Locator深度集成，内部包含了等待逻辑。例如，ToHaveURLAsync会持续检查页面URL，直到匹配或超时。这比传统的Assert.AreEqual(Page.Url, expectedUrl)要稳定得多，因为它能处理页面重定向的延迟。
  • 测试结构（Arrange-Act-Assert）：保持清晰的“准备-执行-断言”结构，让测试意图一目了然。

  4.2 登录失败测试

  测试不仅要覆盖“阳光路径”，更要覆盖各种异常情况。

  [TestMethod] public async Task Login_WithInvalidCredentials_ShouldShowErrorMessage() { // Arrange var invalidUser = new TestUser("wrongUser", "wrongPass"); var loginPage = new LoginPage(Page!); await loginPage.GoTo(BaseUrl); // Act await loginPage.Login(invalidUser.Username, invalidUser.Password); // Assert // 验证错误信息出现 var errorMessage = await loginPage.GetErrorMessageAsync(); StringAssert.Contains(errorMessage.ToLower(), "invalid"); // 检查错误信息包含特定关键词 // 验证页面没有跳转，仍然在登录页 Assert.IsTrue(await loginPage.IsStillOnLoginPageAsync()); }

  注意事项：

  • 断言文本的灵活性：对于错误提示，不要断言完整的、一字不差的字符串，因为UI文案可能会微调。使用StringAssert.Contains检查关键信息即可，这样测试更健壮。
  • 异步等待：所有Playwright操作都是异步的，务必使用await。测试方法本身也必须是async Task而不是void。

  5. 实现业务全流程测试：以商品管理为例

  登录只是起点，真正的价值在于覆盖核心业务流。我们以“创建商品”这个场景为例，演示如何串联多个页面对象，完成一个多步骤的端到端测试。

  5.1 扩展页面对象模型

  首先，我们需要DashboardPage和ProductPage。

  // Pages/DashboardPage.cs using Microsoft.Playwright; namespace E2ETests.Pages { public class DashboardPage { private readonly IPage _page; private ILocator MenuProduct => _page.Locator("nav >> text=商品管理"); private ILocator SubMenuCreateProduct => _page.Locator("nav >> text=创建商品"); public DashboardPage(IPage page) { _page = page; } public async Task NavigateToCreateProductPageAsync() { // 假设菜单需要悬停或点击展开 await MenuProduct.HoverAsync(); await SubMenuCreateProduct.ClickAsync(); // 等待商品创建页面加载 await _page.WaitForURLAsync("**/product/create"); } } } // Pages/ProductPage.cs using Microsoft.Playwright; namespace E2ETests.Pages { public class ProductPage { private readonly IPage _page; private ILocator ProductNameInput => _page.Locator("#productName"); private ILocator ProductPriceInput => _page.Locator("#productPrice"); private ILocator CategoryDropdown => _page.Locator("#productCategory"); private ILocator SaveButton => _page.Locator("button:has-text('保存')"); private ILocator SuccessToast => _page.Locator(".toast-success"); private ILocator FirstProductNameInList => _page.Locator("table tbody tr:first-child td:nth-child(2)"); public ProductPage(IPage page) { _page = page; } public async Task CreateProductAsync(string name, decimal price, string category) { await ProductNameInput.FillAsync(name); await ProductPriceInput.FillAsync(price.ToString()); // 处理下拉框选择 await CategoryDropdown.SelectOptionAsync(new SelectOptionValue { Label = category }); await SaveButton.ClickAsync(); // 等待操作成功的反馈 await SuccessToast.WaitForAsync(new LocatorWaitForOptions { State = WaitForSelectorState.Visible, Timeout = 10000 }); } public async Task<string> GetFirstProductNameAsync() { return (await FirstProductNameInList.TextContentAsync())?.Trim() ?? string.Empty; } } }

  5.2 编写全流程测试

  现在，在ProductManagementTests.cs中编写一个完整的测试。

  using Microsoft.Playwright; using Microsoft.VisualStudio.TestTools.UnitTesting; using System.Threading.Tasks; namespace E2ETests.Tests { [TestClass] public class ProductManagementTests : BaseTest { [TestMethod] public async Task CreateNewProduct_ShouldAppearInList() { // Arrange: 登录系统 await LoginAsync(AdminUser); var dashboardPage = new DashboardPage(Page!); var productPage = new ProductPage(Page!); // 生成唯一的商品名，避免测试数据冲突 string uniqueProductName = $"TestProduct_{System.DateTime.Now:yyyyMMddHHmmss}"; decimal testPrice = 99.99m; string testCategory = "电子产品"; // Act: 导航并创建商品 await dashboardPage.NavigateToCreateProductPageAsync(); await productPage.CreateProductAsync(uniqueProductName, testPrice, testCategory); // 假设创建成功后页面会跳转回商品列表页，或者我们需要手动导航回去 // 这里我们模拟点击“返回列表”按钮或等待URL变化 await Page!.GoBackAsync(); // 简单示例，实际可能需具体导航 await Page!.WaitForLoadStateAsync(LoadState.NetworkIdle); // 等待列表页加载完毕 // Assert: 验证新创建的商品出现在列表首位（假设列表按创建时间倒序排列） var firstProductName = await productPage.GetFirstProductNameAsync(); Assert.AreEqual(uniqueProductName, firstProductName); } } }

  避坑技巧：

  • 测试数据独立性：每个测试都应该使用独立的数据，避免测试间相互影响。使用时间戳、GUID等方式生成唯一标识符。对于不能重复创建的数据（如唯一商品编码），测试后需要有清理逻辑（[TestCleanup]或通过API删除）。
  • 等待策略：WaitForLoadStateAsync(LoadState.NetworkIdle)是一个有用的方法，它等待页面网络活动基本停止，适用于数据通过API加载的列表页。但需注意，如果页面有持续的网络活动（如WebSocket），它可能永远不会完成。此时应使用更精确的等待，如等待某个列表加载完成的特定元素出现。
  • 页面跳转与状态：业务流涉及多个页面时，要清楚每个操作后的页面状态。必要时，在页面对象方法内加入明确的WaitForURLAsync或WaitForSelectorAsync来确保页面已正确跳转和加载。

  6. 高级技巧与最佳实践

  当基本流程跑通后，为了提升测试套件的可靠性、可维护性和执行效率，你需要考虑以下进阶内容。

  6.1 处理身份验证与状态持久化

  每次测试都从头登录很耗时。Playwright的Browser Context支持存储状态。

  [TestInitialize] public async Task TestInitialize() { var playwright = await Playwright.CreateAsync(); Browser = await playwright.Chromium.LaunchAsync(new BrowserTypeLaunchOptions { Headless = true }); // 尝试从文件加载之前保存的登录状态 string storageStatePath = "state/admin-auth-state.json"; if (File.Exists(storageStatePath)) { Context = await Browser.NewContextAsync(new BrowserNewContextOptions { StorageStatePath = storageStatePath, ViewportSize = new ViewportSize { Width = 1920, Height = 1080 }, IgnoreHTTPSErrors = true }); } else { Context = await Browser.NewContextAsync(new BrowserNewContextOptions {...}); Page = await Context.NewPageAsync(); // 执行登录 var loginPage = new LoginPage(Page); await loginPage.GoTo(BaseUrl); await loginPage.Login(AdminUser.Username, AdminUser.Password); // 等待登录完全成功 await Page.WaitForURLAsync($"{BaseUrl}/dashboard"); // 保存状态到文件 await Context.StorageStateAsync(new BrowserContextStorageStateOptions { Path = storageStatePath }); } Page = await Context.NewPageAsync(); }

  这样，第一次运行测试后会生成一个包含cookies和localStorage的文件，后续测试可以直接复用这个状态，跳过登录步骤，极大提升测试速度。

  6.2 模拟网络与拦截请求

  Playwright可以拦截和修改网络请求，这对于测试特定场景（如模拟API失败、慢速网络）或准备测试数据非常有用。

  [TestMethod] public async Task CreateProduct_WhenAPIFails_ShouldShowError() { await LoginAsync(AdminUser); await Page!.RouteAsync("**/api/product/create", route => route.AbortAsync()); // 拦截创建API并中止 var productPage = new ProductPage(Page); // ... 导航到创建页面并填写表单 await productPage.CreateProductAsync("Test", 10, "Books"); // 断言页面上显示了网络错误提示 var errorLocator = Page.Locator(".network-error"); await Expect(errorLocator).ToBeVisibleAsync(); }

  6.3 并行测试与配置

  在playwright.config.json中可以进行丰富配置，支持多浏览器、并行测试等。

  { "timeout": 30000, "retries": 1, "workers": 4, "use": { "baseURL": "https://your-app-under-test.com", "headless": true, "viewport": { "width": 1920, "height": 1080 }, "ignoreHTTPSErrors": true, "screenshot": "only-on-failure", "video": "retain-on-failure", "trace": "retain-on-failure" }, "projects": [ { "name": "chromium", "use": { "browserName": "chromium" } }, { "name": "firefox", "use": { "browserName": "firefox" } } ] }

  在测试项目中，你可以通过[Parallelizable]特性来允许测试并行运行，但要注意测试间的隔离性（使用独立的Browser Context是关键）。

  6.4 录制与调试

  对于快速生成测试脚本初稿，Playwright的Codegen工具是无敌的。

  # 打开录制工具，它会启动一个浏览器和代码生成器 playwright codegen https://your-app-under-test.com/login

  然后你在浏览器里的所有操作都会被实时转换成C#代码，你可以直接复制粘贴到你的页面对象或测试中，作为起点进行修改和封装。这是学习Playwright API和快速创建复杂流程测试的绝佳方式。

  7. 常见问题与排查技巧实录

  在实际项目中，你一定会遇到各种“坑”。下面是我总结的一些典型问题及其解决方案。

  7.1 元素定位失败：Selector总是找不到？

  这是UI自动化最常见的问题。

  • 问题：Page.Locator(“button”).ClickAsync()抛出TimeoutException，提示元素未找到或不可操作。
  • 排查：
    1. 检查选择器：使用浏览器的开发者工具（F12）检查你的选择器是否唯一匹配目标元素。Playwright Test Runner自带的“Pick Locator”工具也很好用。
    2. 检查iframe：目标元素是否在<iframe>里？如果是，你需要先定位到iframe，再在iframe的上下文中查找元素。

    var frame = Page.FrameLocator(“iframe[name=‘content’]”); await frame.Locator(“button”).ClickAsync();

    3. 检查动态内容：元素是AJAX加载的吗？确保在操作前已经等待其出现。永远不要使用Task.Delay，而应该用Locator.WaitForAsync()或Expect(locator).ToBeVisibleAsync()。
    4. 检查元素状态：元素是否被禁用（disabled）或被其他元素遮挡？Playwright的点击默认会检查元素的可操作性。你可以通过Force参数强制点击，但这可能掩盖了真实的UI问题。

    await Page.Locator(“button”).ClickAsync(new LocatorClickOptions { Force = true }); // 慎用

  7.2 测试在CI/CD环境中不稳定（Flaky Tests）

  • 问题：测试在本地通过，但在CI服务器上时而失败。
  • 解决方案：
    • 增加超时时间：CI环境可能比本地慢。在playwright.config.json中适当增加timeout。
    • 使用更稳定的选择器：避免使用基于索引或绝对位置的选择器（如:nth-child(3)），改用具有唯一性的属性。
    • 启用重试：在配置中设置”retries”: 1，让失败的测试自动重试一次，可以过滤掉因瞬时网络或资源问题导致的失败。
    • 收集更多信息：配置screenshot、video和trace为”on-failure”。当测试失败时，这些文件会被保存，你可以通过playwright show-trace命令打开trace文件，像看视频一样回放测试的每一步，精确查看失败瞬间的页面状态、网络请求和Console日志，这是排查CI失败的神器。

  7.3 处理文件上传与下载

  • 文件上传：不要尝试模拟“点击文件选择对话框”，这是操作系统级别的控件，Playwright无法直接交互。正确做法是直接设置<input type=”file”>元素的值。

    await Page.Locator(“input[type=‘file’]”).SetInputFilesAsync(“./test-data/test-image.jpg”);

  • 文件下载：需要监听Download事件。

    var downloadTask = Page.WaitForDownloadAsync(); // 等待下载开始 await Page.Locator(“#export-button”).ClickAsync(); // 触发下载 var download = await downloadTask; // 可以获取下载路径、保存文件等 string path = await download.PathAsync();

  7.4 测试数据的管理与清理

  • 原则：测试不应该污染环境，也不应该依赖特定环境状态。
  • 策略：
    • 事前准备：在[TestInitialize]中，通过调用后端API创建测试所需的基础数据（如测试品类、仓库）。
    • 事后清理：在[TestCleanup]中，通过API删除本测试创建的所有数据。可以使用测试类级别的[ClassInitialize]和[ClassCleanup]进行更粗粒度的数据管理。
    • 使用测试数据库：最佳实践是让测试针对一个可重置的测试数据库运行。每次测试套件开始前，恢复到一个干净的数据库快照。

  8. 集成到CI/CD流水线

  自动化测试只有集成到CI/CD中才能发挥最大价值。这里以GitHub Actions为例，展示如何运行Playwright for .NET测试。

  # .github/workflows/playwright-e2e.yml name: Playwright E2E Tests on: push: branches: [ main, develop ] pull_request: branches: [ main ] jobs: test: timeout-minutes: 60 runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Setup .NET uses: actions/setup-dotnet@v3 with: dotnet-version: '8.0.x' - name: Restore dependencies run: dotnet restore ./E2ETests/E2ETests.csproj - name: Install Playwright run: dotnet tool restore - name: Install Playwright Browsers run: playwright install --with-deps chromium - name: Run tests run: dotnet test ./E2ETests/E2ETests.csproj --configuration Release --logger "trx;LogFileName=test-results.trx" env: BASE_URL: ${{ secrets.TEST_BASE_URL }} - name: Upload test results if: always() uses: actions/upload-artifact@v3 with: name: playwright-test-results path: | ./E2ETests/TestResults/ ./E2ETests/playwright-report/ retention-days: 7

  关键点：

  • --with-deps：确保安装浏览器所需的系统依赖。
  • 环境变量：通过env将测试环境的基础URL传递给测试项目，这样你的测试代码可以通过Environment.GetEnvironmentVariable(“BASE_URL”)读取，实现配置与代码分离。
  • 结果收集：上传测试结果文件和Playwright报告，便于失败时查看截图、视频和Trace。

  从登录到业务全流程的端到端测试，用Playwright for .NET来实现，是一段从搭建脚手架到编写稳定、可维护测试代码的旅程。它要求你不仅会写测试，更要理解前端交互模式、网络状态管理和测试架构设计。一旦这套体系建立起来，它将成为你保障Web应用质量最坚实的防线。记住，好的UI测试不是记录操作的脚本，而是模拟用户意图、并对应用状态进行断言的代码。多花时间在页面对象设计和等待策略上，后期维护成本会大大降低。当你的测试套件能在CI中稳定运行，并成功拦截到几次回归缺陷时，你就会觉得所有的投入都是值得的。