结构化测试知识库

问题在哪

很多团队的 PRD 仍是叙述性文档：功能散落在段落里，判断逻辑藏在「大概」「应当」里，边界与异常要么没写，要么和主流程混在一起。直接把整段 PRD 丢给大模型生成测试用例，常见结果是覆盖不全、步骤含糊、断言对不上业务规则。

本技能的目标不是「再写一份测试文档」，而是把需求压成可检索、可对照的结构化知识：术语统一、功能点可一一映射用例、规则可写成可验证分支、风险单独列出。

技能如何工作

输入可以是粘贴的 PRD、多段补充说明，或飞书文档链接（由 feishu_fetch_doc 拉取正文）。收集完整内容后，固定按四个模块输出，顺序与标题不可改：

1. 术语定义：仅收录 PRD 中出现的专有名词、角色、字段/API 标识，一行一词，解释锚定原文。
2. 树状功能点：业务域 → 功能模块 → 具体功能点，最多三层；功能点须是可验证的原子操作（一条用例对应一个点），层级用短句名词而非完整句子。
3. 明确的判断规则：每个具体功能点单独一章，强制 IF…THEN…ELSE 表达流转；无复杂分支时仍按格式写「满足条件则执行」。
4. 边界风险与异常场景：在字面需求之外补权限与安全、数据边界、逆向/回滚、歧义与跨模块冲突等维度（不适用的可跳过子节）。

处理时会识别角色、数据流、权限与状态变更；表格直接拆成功能与规则；图片文字尽量纳入，无法解析则标注需人工确认。若 PRD 自相矛盾，会指出矛盾而非强行统一。输出语言与 PRD 一致。

适用边界

• 适合有明确业务描述的需求文档；极短的需求片段也能跑，但功能树与规则会偏薄。
• 不负责替代测试执行或自动化脚本生成；产出是测试设计用的结构化中间层，下游仍需要你把模块四的风险落成具体用例。
• 飞书链接依赖可用的文档读取能力；混合排版（大量截图、扫描件）会增加人工核对成本。