wangjiayi0124-joy 产品功能验收
将所有用户提供的 PRD、原型、网页链接、截图、会议记录、聊天说明和补充规则视为需求证据。先基于证据建立本次验收框架，再执行；不要把某个项目的角色、入口、端形态或变更记录固化为通用前提。
工作流
1. 建立需求与范围
- 列出每份需求证据及其可验证的规则、流程、限制和待确认点。
- 发现来源互相冲突、信息过期或预期效果不明确时，标记冲突并向用户询问；不要擅自选择某份材料为最高优先级。
- 明确本轮范围：验收对象、端/设备、测试环境、是否需要登录、可用身份和数据、是否允许外部跳转，以及不得触碰的操作。
- 将可验证需求拆成
一级模块 → 二级模块 → 功能/规则/链路 → 用例。层级服务于理解，不为凑三级而拆分。
2. 生成并确认测试框架
在操作页面前，先向用户提供用例框架和覆盖范围，等待确认后再测试。用例字段以以下基底灵活增减：
| 用例 ID | 一级板块 | 二级板块 | 三级功能/链路 | 条件/前置 | 优先级/严重级 | 复现步骤 | 预期效果 | 实际结果 | 状态 | 问题描述 | 证据 |
|---|
只有需求确实存在特殊属性时，再增加字段，例如：身份、平台/设备、测试数据、版本、埋点、性能指标、接口结果、风险归属。
根据本次需求选择测试维度，不要默认全测。选择依据见 覆盖与交付规范：权限身份、入口与路由、数据状态、业务规则、异常恢复、外部依赖与跳转、兼容与迁移、可重复性等。
3. 安全地执行测试
- 先做主路径，再做高风险规则、边界与异常路径；每个结论均记录触发条件和可复核证据。
- 用户自己完成登录、验证码、账号切换和任何凭证输入。不要索取、保存或转述密码、Cookie、验证码或敏感配置。
- 可正常浏览和操作验收对象；但点击会离开目标域/打开第三方应用的跳转前，说明去向并询问用户。涉及创建、提交、发布、支付、删除、改权限、发消息、下载敏感数据等副作用前，也必须先确认。
- 测试中发现新的分支、状态或隐藏规则时，补充用例并说明其来源；将新用例纳入同一层级，不静默漏测。
- 遇到需求不清、环境异常、缺账号/数据、或无法安全执行时暂停：说明已观察到的事实、缺失条件、可选下一步和对交付的影响，交由用户决定。
4. 判断状态与问题
使用四种状态：
- 通过：在已满足前置条件下，实际结果符合明确预期。
- 不通过：前置条件可满足，且实际结果与明确需求或验收预期不符。
- 阻塞：无法判断是否符合预期，例如缺少账号、权限、测试数据、环境能力、外部依赖或副作用授权。写明“阻塞原因”和需要谁提供什么。
- 待定：用例已规划但本轮未执行，或用户主动暂停/延期。写明“待补测”的范围。
不要因页面无响应就直接判为不通过：先排除未满足前置、加载、账号或环境问题。反之，已验证的功能缺失、错误路由、权限错配、规则不一致等，不能以“阻塞”淡化。
问题描述保持可读和可复现：用 问题描述：、阻塞原因： 或 待补测： 起首；一段只表达一个事实。将“实际现象、影响、缺失条件”分句或分段，避免整段堆叠。预期效果与问题描述不要互相重复。
5. 交付与校验
交付三部分：
- 验收测试清单：全部用例及其当前状态。
- 未通过/阻塞清单：筛出不通过和阻塞项；待定项单列“待补测”，不伪装成已发现缺陷。
- 可导入办公表格的 CSV：字段顺序与清单一致，保留完整文本和有效转义；适用于钉钉、飞书、金山等支持 CSV 导入的表格工具。
若用户要求直接创建办公文档或在线表格，按其指定的目标（如钉钉、飞书或金山）使用对应的原生表格能力，不以 Markdown 竖线文本代替；按 覆盖与交付规范 设置列宽和顶端对齐，并在写入后读回或预览核验。CSV 不携带列宽样式，因此要同时保证文本本身短句、分段、可扫读。
最终汇报：覆盖范围、用例与状态数量、不通过项、阻塞项、待补测项，以及继续验收所需的最小条件。不要把未验证推断写成测试结论。