通常把 AI 放在“提高测试工程效率”的位置而不是让 AI 直接替代测试框架和断言。整体流程可以分成几层。一、AI 如何参与自动化测试需求分析与用例生成根据 PRD、接口文档、历史缺陷生成测试场景。自动补充边界条件、异常流程、权限组合和数据校验。生成后由测试人员审核尤其关注业务规则是否理解正确。测试脚本生成AI 根据页面结构、接口定义或已有 Page Object 生成 Playwright、Cypress、Selenium 等脚本。让 AI 遵循项目已有规范例如统一使用data-testid、Page Object、fixture 和断言库。不建议让 AI 直接生成大量独立脚本否则维护成本很高。测试数据和环境准备生成参数化测试数据。通过 API、数据库 fixture 或工厂方法准备数据而不是依赖手工操作页面。自动构造边界值、重复数据、非法格式和权限数据。失败分析将失败日志、截图、DOM 快照、网络请求和最近代码变更交给 AI。让 AI 判断是产品缺陷定位器失效测试数据问题环境问题接口超时或外部依赖异常。AI 可以生成修复建议但修复结果仍需要人工审核和回归验证。回归测试维护根据页面结构变化和 Git diff提示可能受影响的用例。对失败用例进行聚类避免同一个根因产生几十条重复告警。统计高频失败定位器和高维护成本页面作为测试治理依据。二、页面元素经常变动时怎么处理核心思路是让脚本依赖“稳定的业务语义”不要依赖脆弱的页面实现细节。1. 优先使用稳定定位器定位器通常按下面的优先级选择awaitpage.getByRole(button,{name:提交订单}).click();awaitpage.getByLabel(手机号).fill(13800138000);awaitpage.getByTestId(order-submit).click();优先级一般是data-testid或专门的自动化属性role accessible namelabel、placeholder 等语义属性稳定的业务文本CSS 选择器XPath尽量作为最后手段。避免这种定位方式awaitpage.locator(.ant-btn.css-1abc23).click();awaitpage.locator(div:nth-child(3) span).click();这类选择器通常只反映当前 DOM 结构页面稍微重构就会失效。2. 和开发约定稳定的测试属性例如buttondata-testidorder-submit提交订单/button或者inputdata-testiduser-phonearia-label手机号/测试属性应该表达业务含义而不是样式或布局data-testidprimary-blue-button不推荐应该使用data-testidorder-submit如果页面频繁改版这个约定的收益非常明显。测试不需要知道按钮使用了什么组件、CSS 类名或 DOM 层级。3. 使用 Page Object 或 Screen Object 集中管理定位器不要在几十个测试文件里重复写定位器classOrderPage{constructor(privatepage:Page){}submitButtonthis.page.getByTestId(order-submit);phoneInputthis.page.getByLabel(手机号);asyncsubmitOrder(){awaitthis.submitButton.click();}}页面元素变更时只需要修改一个对象。对于组件库较多的项目也可以进一步抽象成业务组件对象例如classDataTable{constructor(privatepage:Page){}rowByText(text:string){returnthis.page.getByRole(row).filter({hasText:text});}asyncdeleteRow(text:string){awaitthis.rowByText(text).getByRole(button,{name:删除}).click();}}4. 用语义和关系定位而不是固定位置例如表格中的操作按钮不要写“第三行最后一个按钮”awaitpage.locator(tbody tr:nth-child(3) button:last-child).click();应当根据业务数据定位行constrowpage.getByRole(row).filter({hasText:订单号 10001});awaitrow.getByRole(button,{name:删除}).click();这样即使排序、分页、列顺序和 DOM 层级变化测试仍然更稳定。5. AI 自愈定位器只能作为受控兜底可以让 AI 根据以下信息尝试修复失效定位器原定位器当前 DOM元素文本和属性页面截图历史定位器测试步骤上下文。但不能让 AI 在运行时“随便找一个看起来相似的元素然后点击”。否则可能出现测试通过但实际操作了错误控件的问题。比较合理的策略是先使用固定、稳定的主定位器主定位器失败后生成候选定位器检查候选元素是否唯一校验元素的角色、名称、可见性和上下文低风险动作可以自动尝试删除、支付、发布等高风险动作必须人工确认或直接失败记录自愈过程并创建维护任务。伪代码类似asyncfunctionclickWithGuard(primary:Locator,candidates:Locator[],expectedName:string){if(awaitprimary.count()1){awaitprimary.click();return;}for(constcandidateofcandidates){if(awaitcandidate.count()1awaitcandidate.getAttribute(aria-label)expectedName){thrownewError(Primary locator is broken. Candidate found; update the locator explicitly.);}}thrownewError(No safe locator found);}重点是自愈应当帮助发现和修复问题不能悄悄掩盖产品或测试的问题。6. 等待业务状态而不是固定等待时间不推荐awaitpage.waitForTimeout(3000);推荐等待明确状态awaitexpect(page.getByTestId(order-result)).toContainText(创建成功);awaitexpect(page.getByRole(button,{name:提交订单})).toBeEnabled();awaitpage.waitForResponse(responseresponse.url().includes(/api/orders)response.status()200);页面变化频繁时固定等待尤其容易产生偶发失败。应该等待元素可见、可操作、接口完成或业务状态出现。7. 将页面测试和接口测试分层不是所有流程都应该从 UI 开始。例如创建测试订单可以通过 APIconstorderawaitcreateOrderByApi();awaitpage.goto(/orders/${order.id});这样可以减少页面步骤数量对登录、导航、表单结构的依赖测试执行时间页面改版导致的连锁失败。UI 测试重点验证真实用户路径和关键交互数据准备、清理和大量组合场景尽量通过 API 或数据库 fixture 完成。三、我会如何设计 AI 生成脚本的约束让 AI 生成脚本时通常会给它固定规则1. 使用 Playwright。 2. 优先使用 getByRole、getByLabel、getByTestId。 3. 禁止使用 nth-child、动态 CSS class 和无业务含义的 XPath。 4. 每个关键操作必须有业务断言。 5. 测试数据通过 API fixture 创建。 6. 页面元素必须封装在 Page Object 中。 7. 删除、支付、提交等动作需要验证目标对象和最终结果。 8. 不使用固定 sleep使用状态等待。 9. 生成脚本后输出使用到的定位器和潜在风险。AI 输出后还需要经过静态检查例如扫描是否出现nth-child是否出现固定waitForTimeout是否存在没有断言的测试是否直接依赖动态 class是否重复登录和重复造数据是否对高风险动作缺少结果校验。四、实际落地时的原则我会把稳定性目标分成三层定位稳定性使用测试属性、可访问性语义和业务上下文数据稳定性使用 API fixture、唯一数据和可重复环境断言稳定性验证业务结果不验证无意义的 DOM 细节。AI 适合做生成、分析、归因和维护辅助稳定性最终还是依赖测试架构、页面可测试性和明确的业务契约。对于频繁变动的页面最有效的方案通常不是不断让 AI 猜新的 CSS 选择器而是推动开发提供稳定的语义定位器并把高频页面对象集中封装。