PRD 飞书测试用例生成

解决什么问题

拿到 PRD 后写测试用例的常见问题是：结构随意，要么“整体页面”反复出现，要么功能入口和按钮混在一起；用例粒度不一致，有的一条覆盖多个状态或多个预期，执行者需要自行判断；写入飞书时手工整理格式、合并单元格、继承信息，既费时间又容易出错。这个技能把“PRD → 结构化用例 → 飞书在线表格”固化成一条可复核的流水线。

核心能力与工作流程

流程为：前置检查 → 获取需求 → 搭整体结构 → 按测试方法写用例 → 自检 → 写入飞书表格。

• 前置检查：必须提供飞书模板表格 URL，解析 spreadsheet_token 与 sheet_id；写入会复制模板工作表并保留样式、下拉和高亮，不新建文件、不改已有工作表。未提供 URL 前不开始生成。
• 需求获取：支持 Figma 链接（读取设计上下文与截图）、本地 md/docx/pdf 文档；项目内有业务知识库时优先读取，沿用术语、规则和状态定义。
• 先结构再用例：按 功能入口 → 整体页面 → 各功能点 搭建。每个功能点内固定顺序为 界面显示 → 正常流程 → 异常流程 → 专项异常，界面验证放在对应功能点里，不单独堆一个“界面与交互”大块。
• 测试方法：等价类、边界值、场景法、判定表、错误推测。常见控件（输入框、下拉/级联、图片/文件上传、保存/提交、列表/表格+筛选）按模板至少覆盖；多条件组合用判定表逐条验证，防抖、弱网/断网、4xx/5xx、越权/注入、多端并发等写进对应功能点。
• 书写规范：名称统一 验证xxx；属性为主流程/界面/功能/接口；优先级高/中/低；前置条件说明页面与数据状态；操作步骤写“在哪里 + 做什么 + 对象/取值”；预期结果必须可观测，禁止只写“正常/正确/成功”。
• 枚举必拆：状态、角色、类型、开关、页签每个取值单独一条。避免 ❌ 验证任务状态-待执行、执行中、已执行各状态展示，改成 ✅ 三条：验证任务状态-待执行 / -执行中 / -已执行，分别构造前置并分别写预期。
• 继承留空：同一 模块 或 测试点 下，首行填写，同组后续行留空表示继承，写入后合并单元格；若前置条件或操作步骤有差异，则必须完整填写。
• 写入飞书：通过 lark-cli 复制模板工作表，写表头信息与用例数据，按 A/B 列连续同组区间合并模块/测试点单元格，再回读首尾几行核对并汇报新工作表链接、用例总数与覆盖情况。

适用边界与注意点

• 需要飞书文档编辑权限；lark-cli 未就绪时需依次完成安装、config init、auth login，并确认 bot/user 均 ready，记录执行人 openId 与 userName。
• 模板第 1 行应为 A~I 表头，第 2 行执行人，第 3 行需求目标，数据从第 4 行开始；布局不同以实际为准。同名工作表已存在时改用 {需求名}-日期。
• 自动合并 A/B 列连续同组区间，不处理不相邻同值，也不打乱既定行序。
• 不替代需求澄清：PRD 缺失关键规则、数据状态或权限模型时，应先向用户追问，再生成可执行用例。
• 只处理结构化测试用例生成与飞书写入，不做缺陷管理、接口断言执行或持续集成集成。