Playwright Java 如何稳定测试跨浏览器的表单校验提示？

结论：原生校验主要验证行为，自定义提示按产品要求验证文本

测试浏览器原生表单校验时，不建议跨浏览器统一断言完整的提示文字。更稳定的做法是验证字段的有效性、违反了哪条约束，以及无效输入是否会阻止提交。

如果应用自己渲染错误提示，且文案是明确的产品要求，就应验证文本并固定测试语言。也不必仅仅为了让自动化测试通过而放弃原生校验。

“字段无效”和“用户看到了错误提示”是两回事：validity 或 :invalid 能证明校验状态，但不能单独证明提示已经显示。

为什么不适合统一断言原生提示文本

原生提示由浏览器提供，应用不能直接控制其措辞、语言和呈现方式。如果要求所有浏览器返回同一句话，就等于把浏览器的实现细节当成应用的通过条件。

validationMessage 可以作为诊断信息记录，但通常不适合跨浏览器逐字比较。即使断言它非空，也只能证明浏览器提供了校验消息，不能证明屏幕上的提示气泡可见。

原问题提到 headed、headless 和不同环境下观察到了差异，但没有提供具体配置，不能据此认定 headless 模式就是原因。排查时应比较浏览器版本、语言、页面状态和触发校验的操作。

把校验测试拆成三类断言

测试原生校验时，可以用 :invalid 补充断言状态。测试自定义校验时，应检查应用实际提供的状态，例如 aria-invalid="true"；不要假设所有原生无效字段都会自动具有这个属性。

Playwright Java 示例：验证必填约束和提交阻断

示例使用一个最小 HTML 页面，方法接收已有的 Page，断言使用 JUnit Jupiter。代码通过记录 submit 事件是否触发来判断是否通过原生校验，不涉及真实后端请求。

import com.microsoft.playwright.Locator;
import com.microsoft.playwright.Page;

import static org.junit.jupiter.api.Assertions.assertFalse;
import static org.junit.jupiter.api.Assertions.assertTrue;

public static void verifyRequiredField(Page page) {
    page.setContent(
        "<form id='signup'>"
        + "<label for='email'>Email</label>"
        + "<input id='email' name='email' type='email' required>"
        + "<button type='submit'>Submit</button>"
        + "</form>"
    );

    page.evaluate("() => {"
        + "window.submitSeen = false;"
        + "document.querySelector('#signup')"
        + ".addEventListener('submit', event => {"
        + "event.preventDefault();"
        + "window.submitSeen = true;"
        + "});"
        + "}");

    Locator email = page.locator("#email");
    Locator submit = page.locator("button[type='submit']");

    // 空值违反 required 约束。
    email.fill("");
    assertTrue((Boolean) email.evaluate(
        "el => el.validity.valueMissing"
    ));
    assertTrue((Boolean) email.evaluate(
        "el => el.matches(':invalid')"
    ));

    // 点击提交后，原生校验应阻止 submit 事件。
    submit.click();
    assertFalse((Boolean) page.evaluate(
        "() => window.submitSeen"
    ));

    // 修正输入后，表单应能进入 submit 处理逻辑。
    email.fill("tester@example.com");
    assertTrue((Boolean) email.evaluate(
        "el => el.validity.valid"
    ));

    submit.click();
    assertTrue((Boolean) page.evaluate(
        "() => window.submitSeen"
    ));
}

代码让无效输入和有效输入走同一个提交入口。若只检查“无效输入没有提交”，按钮未绑定事件或页面脚本出错等问题也可能让测试通过。

在真实应用里，应观察业务结果，而不是使用示例中的标记。例如，检查提交处理函数是否执行、相关请求是否发出，以及提交成功后的页面状态。涉及异步行为时，使用框架提供的等待或重试断言，避免依赖固定休眠时间。

自定义提示如何断言

如果应用在页面中渲染错误提示，可以按产品约定检查可见性和完整文本。例如，假设页面包含 #email-error：

import static com.microsoft.playwright.assertions.PlaywrightAssertions.assertThat;

assertThat(page.locator("#email-error")).isVisible();
assertThat(page.locator("#email-error"))
    .hasText("请输入邮箱地址");

这里的选择器和文案只是示例，需要替换为应用的实际内容。如果应用约定使用 aria-describedby 关联错误说明，或使用 aria-invalid 表达错误状态，也应验证这些关系。

固定文案可以精确匹配。含用户名、数量等动态内容时，可以断言固定部分或使用范围明确的正则表达式。不要为了减少失败，把所有提示都改成宽泛的“包含某个词”，这样容易漏掉错误文案。

跨浏览器和环境如何组织测试

建议在各浏览器以及 headed、headless 配置下执行同一组行为断言，保持测试数据和业务操作一致。失败时，记录浏览器及版本、执行模式、测试语言、字段值和相关 validity 属性，必要时附上截图或 trace。

Playwright 的 Chromium、Firefox、WebKit 测试目标与具体品牌浏览器并非完全一一对应。WebKit 测试通过，不能直接当作实际 Safari 已验证；若验收要求覆盖实际 Safari，需要安排对应验证。

如果产品明确要求某个平台上的原生提示文案或外观，可以为该平台单独设置测试基线，并固定语言和浏览器版本。不要把这一基线作为所有环境共用的断言。

是否应该改成自定义校验

是否自定义取决于产品对文案、布局、交互和可访问性的要求。需要统一错误摘要、字段提示或多语言文案时，自定义提示通常更容易控制，但也需要维护错误状态、焦点处理和辅助技术关联。

继续使用原生校验时，测试应通过真实用户操作触发提交。不要用 form.submit() 代替点击提交按钮来验证原生阻断，因为它会绕过约束校验。还需检查表单是否设置了 novalidate，以及提交按钮是否设置了 formnovalidate，这些都会影响预期行为。

无论前端选择哪种方式，服务端仍应验证输入；浏览器校验只覆盖用户界面这一层。

备注：内容仅供参考。