收益：
- 能够使用人工智能生成健壮的 UI 测试代码，包括 data-testid、open wait 和断言，以验证真实的用户结果
- 能够避免脆弱的测试（错误的选择器、盲目等待）并使测试易于在页面对象模型结构中维护
- 能够测试通过破坏代码产生的每个 UI 测试，并检测和修复假通过的测试
用户在浏览器中进行的每次点击、每次表单填写、每次页面转换都无法通过手动一遍又一遍地进行测试 - 这就是 UI 测试自动化（用户界面；这些测试通过以编程方式驱动真实浏览器来模拟用户行为）存在的原因。 Selenium、Playwright 和 Cypress 是这项工作最常用的工具。人工智能 (AI) 非常擅长为这些工具编写代码：您描述一个测试用例，AI 会为您提供一份可行的自动化脚本草稿。但这里这个模块的核心警告再次发挥作用：AI 生成的 UI 测试代码通常可能是脆弱的测试，“亮起绿色但验证错误的东西”或随风飘动。您的工作不是运行此代码，而是确保它确实可靠地验证了正确的内容。
在本单元中，我们的目标是使用 AI 生成健壮、可维护且真正验证的 UI 测试；您将学会避免脆弱的测试。
可靠 UI 测试的三大支柱
1. 正确的元素定位器。测试使用选择器来查找页面上的元素。 AI 通常会产生脆弱的选择器：长 XPath 路径（地址过度依赖于页面结构）、基于 CSS 类名的选择器（设计更改时会中断）。稳健的方法是开发人员添加用于测试的稳定属性，例如 data-testid。明确地将这一点强加给人工智能。
2.显式等待。 UI 测试中漏洞的第一个来源是时机。持续的 sleep(3) （盲目等待）是不好的做法：有时还不够，有时会浪费时间。正确的方法是使用显式等待，即“等待该元素出现”。剧作家很大程度上是自动完成这一任务的。在 Selenium 中，您必须明确请求它。
3.有意义的主张。测试应该验证用户实际看到的结果，例如“订单号出现在屏幕上”，而不仅仅是“页面已加载”。如果 AI 生成的测试没有断言或不重要，则该测试将生成伪通过（第一个单元）。
注意：当您第一次看到 AI 生成的 UI 测试时，最多检查三件事：选择器是否已提交（data-testid）、是否处于等待状态（无盲目睡眠）以及断言是否验证了实际的用户结果？如果这三项都正常，那么测试可能是可靠的。
页面对象模型
随着测试变得越来越大，在每个测试中编写选择器成为维护的噩梦。页面对象模型（POM — 将每个页面/屏幕的选择器和操作收集到单个类中的设计模式）将选择器保留在一个位置；当界面发生变化时，您可以在单个文件中更新它。让 AI 在 POM 结构中生成测试，而不是直接生成；这使得维护变得更加容易。
弱提示/强提示
弱项：“为登录页面编写 Selenium 测试。”
Strong：“使用 Playwright (TypeScript) 编写登录流程测试。选择器仅使用 data-testid；不使用控制用户看到的内容，而不是页面标题。”
强大的提示功能；该工具给出了语言、选择器策略、等待策略、架构（POM）和表达性断言期望。
测试数据和环境独立性
可靠的 UI 测试不仅要正确编写，还要构建和清理自己的测试数据。 AI 生成的测试通常链接到假定环境中已存在的用户或记录（“以管理员用户身份登录”）。当测试在另一个环境中运行或在另一个测试之后运行时，这个假设就会被打破（单元 9 中的顺序依赖问题）。事实是，每个测试都会在测试开始时创建所需的数据（或通过 API 调用准备数据）并在结束时清理它。明确指示 AI“在测试内设置此测试所依赖的任何数据；不要假设来自外部的现成数据。”
另一个关键点是不要使用真实的用户数据进行 UI 测试。如果测试环境使用生产数据库副本，这些记录是真人的数据；屏幕截图和测试记录可能会揭示此数据。使用合成（虚构）测试帐户；它既可以保护机密性，又可以使测试具有可重复性。使用真实客户帐户进行“订单取消”测试既是道德错误，也是操作错误。
提示：尽可能少地进行 UI 测试；将实际验证留给API和单元测试，快速且稳定。 UI 测试既昂贵又脆弱——仅用它来验证真正的端到端用户流（测试金字塔逻辑）。
车辆对比
特征
硒
剧作家
柏树
语言
Java、C#、Python、JS
JS/TS、Python、.NET、Java
JavaScript/TypeScript
自动待机
否（手动）
是（强）
是的
多浏览器
宽
铬/火狐/WebKit
以铬为主
脆性倾向
高（手动待机）
低
低
易于学习
中等
容易
容易
并联运行
需要网格
内置的
居民/付费
向AI请求代码时，明确说明其所属车辆；否则，可能会产生令人困惑的、无法工作的代码。
四个可复制模板
1) 可靠的 UI 测试生成：
您的角色：高级测试自动化工程师。使用[工具+语言]按照以下流程编写测试：[流程]。规则：- 仅选择数据测试ID；使用 XPath/CSS 类。 - 禁止盲目睡眠；使用显式/自动等待。 - 应用页面对象模型。 - 让每个断言验证实际的用户结果。在每个测试开始时评论您要验证的验收标准。
2）脆性控制：
检查以下 UI 测试的脆弱性：- 是否存在不稳定的选择器（长
3）转换为页面对象：
将以下纯测试代码转换为页面对象模型结构。将选择器和操作移至页面类；让测试文件只读取场景流程。 [工具/语言].代码：[粘贴代码]
4）伪转移证明：
证明此 UI 测试确实有效：我对应用程序代码进行了哪些单一更改，将使此测试变为红色？如果找不到会破坏测试的更改，则测试是不充分的；添加缺少的断言。测试：[粘贴测试]
三个迷你箱子
案例 1——从脆弱的选择器中解放出来。在一个团队用 AI 进行的 40 项测试中，70% 在界面更新后被破坏；它们都不是真正的错误，它们都是脆弱的 XPath 选择器。该团队使用“脆弱性检查”模板将测试转换为数据测试 ID 库。在接下来的三个界面更新中，错误中断的数量降至零；维护时间从每周 6 小时减少到 30 分钟。
案例 2 — 假通过 UI 测试。 AI 进行了“添加到购物车”测试；测试结果是绿色的。当运行“fake-proof-of-passage”模板时，测试似乎只检查按钮点击和页面标题，而从未验证购物车计数器是否增加。即使购物车逻辑完全被破坏，测试也通过了。添加了真实断言（购物车徽章为“1”）。
案例3——盲目等待陷阱。 AI制作的Selenium测试中，每一步后都有sleep(2)； 60 次测试花费了 14 分钟，但仍然偶尔出现故障。切换到打开等待（等待元素可点击）后，时间下降到 5 分钟，脆性消失了。盲目等待既缓慢又不可靠。
常见错误
- 同意脆弱的选择器。按原样使用 AI 生成的长 XPath；测试在第一次界面更改时崩溃。
- 留下盲目的“睡眠”。用固定等待“解决”时序；既缓慢又优柔寡断。
- 微不足道的断言。只需验证页面已加载即可；不检查实际的用户结果（假通行证）。
- 无需 POM 即可生长。将选择器分配给每个测试；当界面发生变化时，手动更新数十个文件。
- 没有指定工具。不告诉AI你想要什么工具/语言；变得混乱、无法工作的代码。
- 当您运行生成的代码并通过时信任。不通过破坏代码进行测试。
总之
UI 测试自动化通过使用程序驱动实际浏览器来验证用户行为。人工智能可以快速生成此代码，但有两个大陷阱：脆弱的测试（错误的选择器、盲目等待）和假通过测试（不完整/琐碎的断言）。可靠 UI 测试的三大支柱是提交选择器 (data-testid)、显式等待和验证实际用户结果的断言。在页面对象模型中生成测试从根本上简化了维护。用“什么改变会破坏这个？”这个问题来测试每个生成的测试。
应用任务
从您自己的项目中选择用户流程（例如登录或搜索）。让 AI 使用“强大的 UI 测试生成”模板编写测试。然后：（1）检查并修复选择器并等待“脆弱性检查”，（2）证明每个测试实际上通过“伪通过证明”进行验证，（3）破坏代码并观察测试变成红色。报告生成和纠正的测试数量，以及您发现的漏洞和伪通行证的数量。
清单
- [ ] 我清楚地给了AI工具、语言、选择器策略和架构（POM）。
- [ ] 我验证了选择器是 data-testid。
- [ ] 我确保使用显式/自动等待而不是盲目睡眠。
- [ ] 我检查了每个断言都验证了实际的用户结果。
- [ ] 我通过破坏代码来测试每个测试；我看到它变红了。
- [ ] 我收集了页面对象模型结构中的测试。