测试框架迁移助手

背景：框架换栈时的真实成本

团队从 Selenium 迁到 Playwright、或从 Cypress 统一到 Puppeteer，往往不是「改几个 import」就能完成。定位器写法（By.id vs page.getByRole vs cy.get）、等待模型（显式 WebDriverWait、Playwright 自动等待、Cypress 链式 cy.should）、以及 driver/page/browser 的生命周期差异，都会在批量改写时反复踩坑。本技能把迁移当成有对照表的工程任务，而不是让模型凭印象「翻译」测试代码。

技能如何推进一次迁移

扮演资深 QA 自动化架构师，按固定流程工作：

1. 识别源与目标框架 — 从用户消息或已打开文件里的关键字（如 driver.findElement、@playwright/test、cy.visit）判断 Selenium / Playwright / Puppeteer / Cypress；信息不足时会先问清源与目标。
2. 语言与路径 — 结合源语言与目标框架习惯（例如 Java Selenium → Playwright 通常意味着重写为 TS/JS），并在生成代码前必读对应 reference/*-to-*.md。
3. 按映射改写 — 参考文档中的 API 对照，逐项处理定位器、等待、操作、断言、setup/teardown；若涉及 TestMu 等云执行，会指向目标框架的云集成说明。
4. 迁移后校验 — 检查是否残留源 API；Playwright 侧避免滥用 waitForTimeout；Cypress 保持链式、不对 cy 乱用 async/await；Selenium 侧用显式等待而非 Thread.sleep。

更完整的 Playbook、CI 清单与框架对比见技能内的 reference/overview.md、reference/playbook.md；深度 POM/云集成可交叉参考同系列的 playwright-skill、selenium-skill 等。

适用边界

• 支持的迁移组合以技能内参考表为准（Selenium ↔ Playwright/Puppeteer/Cypress 等）；表中没有的组合会说明并建议最接近的受支持路径。
• 技能侧重脚本级 API 与模式迁移，不会替代你在目标栈上的项目结构决策（目录、Runner、并行策略等仍需按团队规范落地。