1、Skill简介
这是一个将结构化测试用例（Steps + Expected Result）自动转化为可执行 Playwright 脚本（*.spec.ts）的 Skill。根据 @web / @Server / @API 三种脚本类型，参考项目现有代码风格，生成符合规范的测试脚本，并自动完成 Step 对齐自检，确保用例覆盖无遗漏。
适合使用 Playwright 做端到端测试、期望从手工用例快速生成自动化脚本的 QA 团队。
2、使用场景
你为什么想做它？
手工将测试用例转化为 Playwright 脚本是重复性极高的工作——每个用例都要配对动作、编写断言、处理等待，一个一个写既慢又容易出错。
之前遇到了什么麻烦？
逐条对照用例写脚本效率低，平均一个复杂用例要花 15-20 分钟
生成的脚本风格与项目既有代码不一致，PR Review 要反复改
写完容易漏断言，或者断言 message 不规范，后续排障困难
没有自动校验，不知道生成的脚本是否真的覆盖了用例的每一步
做出来之后能省掉哪些动作？
原来 15-20 分钟的手工转化，现在 1-2 分钟出初稿
脚本风格与项目完全一致，不需要反复返工
自动完成 Step 对齐检查，漏哪个断言一目了然
直接复用现有 POM 方法，不用重复造轮子
3、创作过程
核心思路：以参考脚本为中心生成
传统生成方式容易"跑偏"，因为 AI 不了解项目具体约定。本 Skill 的关键设计是——始终以项目中真实存在的参考脚本为模板，复用其：
test.describe tag 组合
beforeEach/afterEach 登录与清理模式
POM 对象命名、方法命名、等待策略、断言 message 规范
这样生成的脚本，团队任何人都能直接看懂、接手和维护。
生成流程（6 步）：
Step 0：分类落点 → 识别用例类型（@web/@Server/@API），确定目标目录
Step 1：参考脚本检索 → 找同页面/同模块/同动作的既有脚本作为模板
Step 2：动作-断言配对 → 每条用例 Step 转成"动作块+断言块"
Step 3：POM 增量 → 缺失方法补到 POM，spec 只调用不写业务逻辑
Step 4：模板对齐 → 文件头注释、timeout、try/catch 风格与项目一致
Step 5：可执行性检查 → 去除 test.only/skip/被注释断言等"屏蔽代码"
Step 6：自检闭环 → 调用 testcase-step-alignment 逐条验证，迭代到全部通过
关键提示词结构：
请一次性提供：
- 测试用例：编号/名称、Precondition、Steps + Expected Result、测试数据
- 运行环境：脚本类型（@web/@Server/@API）、语言环境
- 参考脚本：至少 1 个同模块的 *.spec.ts + 涉及的 POM/Helper
输出要求：
- 新生成的 *.spec.ts（可执行）
- 必要的 POM/Helper 最小增量改动
- Step 对齐自检报告（调用 testcase-step-alignment）
4、使用步骤
准备材料：测试用例（Steps + Expected）+ 参考脚本路径 + 运行环境说明
调用 Skill：触发 testcase-script-generator
输入信息：一次性提供用例和脚本信息
获取产物：等待输出 spec 文件 + POM 改动 + 自检报告
查看自检结果：如果有不通过项，Skill 会自动迭代修复，直到 Step 全部对齐
5、效果展示
输入示例：
用例编号：T1230
用例名称：创建订单并验证列表显示
Precondition：已登录系统，拥有创建订单权限
Steps + Expected：
Step 1: 进入订单管理页面
Step 2: 点击"新建订单"按钮
Step 3: 填写订单信息（客户、产品、数量）
Step 4: 点击"保存"按钮
Step 5: 验证成功 toast 出现
Step 6: 验证订单出现在列表中，状态为"待审核"
运行环境：@web
参考脚本：tests/gui/order/create-order.spec.ts
输出示例：
[已生成] tests/gui/order/T1230_create_order.spec.ts
[已更新] pages/OrderPage.ts (新增方法: waitForOrderInList, clickNewOrder)
Step 对齐自检报告：
| Step | 结论 | 问题点 |
|---|---|---|
| Step 1 | 通过 | - |
| Step 2 | 通过 | - |
| Step 3 | 通过 | - |
| Step 4 | 通过 | - |
| Step 5 | 通过 | waitForSuccessToast() 验证 |
| Step 6 | 通过 | waitForOrderInList() + expect 状态 |
[Blocker: 0] [Major: 0] [Minor: 0]
Step 对齐全部通过
6、Skill 链接
（请在此处填入你的 Skill 分享链接）
GitHub：https://github.com/ccbhwy/playwright-testcase-generator
7、总结与思考
这个 Skill 目前最满意的地方：
"参考脚本优先"策略真正解决了生成脚本"风格不统一"的痛点——生成即符合项目规范，不需要二次返工。加上自检闭环，生成质量有保证，QA 可以真正专注于用例设计本身。
后续还想怎么优化：
支持批量用例一次性生成，输出完整模块的测试套件
增加与测试管理平台的集成，自动同步用例列表
支持自然语言描述直接生成，减少用例结构化成本
希望别人怎么体验或给你什么建议：
如果你有真实的测试用例和参考脚本，欢迎试用。对齐结果是否符合预期？有没有漏掉的业务场景？期待反馈。
