test-authoring

PM Agentic Cookbook 六阶段流程的阶段五:测试(Test)。职责:把"原型实现与 PRD 之间的偏差"从不可见变为可裁定——以 PRD 为预言(oracle),对实现施加可执行测试,产出测试用例文档与测试报告。

本 skill 默认面向 B 端系统,并可按业务领域加载对应的领域 Provider(references/providers/<domain>/)。不限定产品形态。

支持用户点名调用和自动触发(当用户要求写测试、生成用例、出测试报告、验证实现是否符合 PRD 时)。

输入

• 待测模块的 PRD / 系统设计文档(测试用例的来源/预言)
• 经用户确认的验收标准清单（名称、路径、版本），用于检查PRD细化及用例覆盖
• 已确认需求范围及关联模型/PRD版本；一个范围可引用多个文件，不能按PRD文件数另造标准
• 模块的代码实现(被测对象)
• 调用方给出的路径
• 项目已有上下文:Domain Model、状态机、权限矩阵、UI/UX 规范、既有测试与测试约定

调用方随调用给出的参数,优先作为输入源。

核心原则

1. PRD 是预言(oracle):期望值取自 PRD 口径与业务不变量,不照抄实现常量。测试失败优先视为"实现或口径的真实发现",而非改测试迁就实现。
2. 可自评,不自我宣告通过:如实给出通过/失败与缺陷分级,不输出"测试通过/可进入下一步"的自我背书;是否通过、是否推进由用户裁定(沿用 create-prd / check-prd 已确立的边界)。
3. 贴近真实测试环节:产出可运行、可回归的测试 + 测试用例文档 + 测试报告,而非仅 markdown 清单。
4. v1 可不追求覆盖率:先证明闭环可跑通、能暴露偏差;覆盖率、追溯矩阵、CI 留待迭代。
5. 执行者隔离(建议):若当前 Agent 同时是被测实现的作者,建议委派独立子代理执行本 skill——测试作者独立于实现作者,期望值更不易被实现现状"锚定"。派发规则见本 skill 所在 cookbook 的 Agent 执行协议（<cookbook>/process/agent-execution-protocol.md）第 3 节；单独安装、取不到该协议时，派发 prompt 至少写明 PRD 路径、被测实现范围、输出位置与完成标准。
6. 发现处理:测试代码、用例文档和报告按用户要求的测试范围产出。测试发现的实现缺陷与 PRD/Mock 口径问题均须写入报告；是否同时修改产品实现，由用户的任务授权决定。

执行流程

严格按顺序,不跳步。

第一步:确定被测面与 PRD 预言来源

1. 阅读PRD与范围内已确认验收标准清单，定位可推导测试的内容。清单/PRD有缺漏、待确认或冲突时，暂停受影响用例并回改上游、确认后同步，不按实现现状自补。
2. 阅读代码,识别可测面并按测试金字塔分层:纯函数/派生逻辑→单元;状态流转/跨实体规则→集成;关键页面→组件。
3. 列出"按业务关键度 × 可测性排序"的测试目标清单,与用户确认 v1 范围。

迭代场景下 oracle 是两份,不是一份。 当被测对象是已在运行的系统的一次变更时(存量迭代),预言来源 = 现状基线 + 新 PRD:

• 新 PRD 定义"这次要改成什么样",守护新行为;
• 现状基线定义"哪些行为不许变",守护老行为。

只用新 PRD 当 oracle,测试会全绿而回归无人守——新功能对了,被顺手改坏的老路径没有任何断言拦得住。基线中标为 INFERRED 或 UNRESOLVED 的条目不得写成断言,先交用户裁定。UNRESOLVED 是尚未裁定的矛盾;INFERRED 是推导所得,尚未被实现或真实数据证实。两级都不得进回归用例——先升级可信度(找实现入口、找能覆盖该行为的真实数据、或请用户确认),或登记为未覆盖区域。现状基线对 INFERRED 的处置口径见其模板。

加载映射规则:

PRD → 测试用例 映射规则

第二步:推导测试用例并落地为可执行测试

1. 逐条把PRD结构化内容转成测试用例，每条标注具名PRD章节和“清单名称 AC-n”；每条范围内已确认标准至少一个用例，待确认/作废行不写作生效断言。不能覆盖的标准进入未覆盖区域，说明原因；仅守护现状基线的回归用例注明验收标准不适用及基线来源。
2. 用项目既有测试栈实现可执行测试(若无则建议 Vitest + Testing Library 等贴合技术栈的方案)。
3. 期望值取自 PRD 口径与业务不变量。

加载用例与测试约定:

测试用例与命名/分层/裁定约定

第三步:运行测试并产出文档

代码写完、交付之前，做一次代码缺陷自查并修复，见 代码缺陷自查。这是作者自己的质量动作：发现即修，向用户简述修了什么，不出报告。

1. 运行测试(如 npm run test:run),收集机器结果。
2. 产出测试用例文档(模板 templates/tob_test_case_spec.md):用例编号、具名PRD章节、验收标准（清单名称加编号）、步骤、预期、结果。 交接每条标准实际覆盖的角色/条件/路径、机器结果位置、实现/标准基线及未覆盖原因；计划用例与实际执行分开。Mock/单元测试保留替身与层级边界，不声称真实集成或完整旅程已验收；新语义下旧绿色证据须重新验证。流程执行者据此维护范围级台账，测试作者不代用户填写验收结论。

3. 产出测试报告(模板 templates/tob_test_report.md):通过/失败汇总 + 失败缺陷清单(P 分级 + 裁定列)。

   两份模板随本 skill 分发。取不到模板时不阻塞:按上面两条列出的内容自行组织,并在产出中注明"未套用模板"。

   落点取自宿主契约(cookbook.config.json 的 host 一节):测试用例文档放 <模块目录>/<host.testsDir>/,测试报告是过程记录,放 <模块目录>/<host.processRecordsDir>/,模块目录 = host.moduleDocs 中的 <module> 换成模块目录名。字段未声明时停下请用户指明。

第四步:如实分类与裁定移交

1. 失败项分类为「实现缺陷」或「PRD/Mock 口径待确认」,各自给出证据与定位(文件:行)。
2. 不自我宣告通过;把"是否通过、是否修复、是否推进"明确移交用户裁定。
3. 新发现不自动进入修复清单；主 Agent 原样报告后停止，等待用户显式修订合同。

输出规范

• 测试代码:可运行、可回归,文件就近放置(如 __tests__/),命名见约定。
• 测试用例文档与测试报告:按模板输出;失败项必须可追溯到 PRD 条目与代码位置。
• 缺陷分级:P0 阻断核心流程/数据正确性;P1 关键规则偏差;P2 口径待确认/边界;P3 优化项。
• 严禁:为了让套件"全绿"而把测试改写成迁就实现的现状测试;或在报告中替用户下达通过结论。

停机条件

没有实现代码时：只产出测试用例文档，不写可执行测试、不运行；报告写明"无实现可测"，第三、四步不执行。

同时满足才算完成：

1. 测试目标清单经用户确认，范围内的用例全部落地
2. 测试已实际运行，结果如实记录；不稳定的测试复跑并记录
3. 测试代码写完后已做代码缺陷自查并修复
4. 每个失败项都分类为实现缺陷或口径待确认，并有定位

停下交用户：期望值在需求文档里有两种读法；同一个测试连续两次修测试代码仍失败且无法定位原因——不改断言去迁就实现。

不宣告"测试通过"。

工作风格

• 目标是让偏差可见、可回归、可裁定,而非堆砌用例数量。
• PRD 口径不明确时,标注为「口径待确认」交用户,而不是自行假设。
• 与既有项目测试约定保持一致;新增约定时更新宿主测试规范(宿主契约 host.specMap 的 testing 角色),未声明时请用户指明。