--- name: test-design description: 独立基于业务规则和可用材料设计测试用例、评估场景与断言缺口，默认交付便于阅读的 HTML 测试设计。适用于开发前的用例设计、检查已有用例遗漏和评估业务场景覆盖；不要求已有架构方案，不编写或执行测试，不运行覆盖率／突变工具或诊断修复失败。 --- # 测试用例设计与覆盖评估 将已确认业务规则转成具体用例，或核对已有测试中的业务遗漏；只交付设计。 输入可以是用户需求、PRD、设计、契约或已有代码／测试等任意可用材料，不要求先运行任何技能，也不指定下一步流程。只有需求或 PRD 时也能设计业务场景；缺少技术入口或工程设施时注明暂无法定位，不为此要求补一份架构方案。 ```text 明确范围与依据 → 识别现有测试设施 → 设计场景与预期结果 → 对照已有用例和断言 → 交付覆盖缺口与验证方案 ``` ## 职责与边界 - 产出业务规则清单、测试用例、覆盖对应关系、缺口及验证办法。这里的“覆盖”指业务场景和断言的覆盖，不等同于代码覆盖率或突变分数。 - 只读取相关需求、设计、代码、测试和已有报告；只写设计文档。不编写或修改测试代码，不派发测试编写任务，不运行测试或分析工具，也不安装依赖、搭建测试环境。 - 测试形式与入口跟随项目已有设施。存在单元、组件或其他测试时，按本次任务的关联性使用；某类设施不存在时不为它新增框架。相关规则无法由已有设施验证时，保留为验证缺口，不伪造测试入口或删除业务规则。 - 不从当前实现反推正确行为，不把缺少测试直接定性为业务 Bug，不承诺穷尽全部输入。评估结论限定于本次范围、已知规则和现有证据。 ## 1. 明确设计目标与依据 先区分用户是在设计新功能的用例，还是检查已有用例/测试的充分性；确定功能或改动范围、需求版本及交付位置。复用用户提供的材料，不默认全仓扫描，不要求简单任务必须先补一份大型设计文档。 按规则来源读取已确认需求、用户决策、接口契约及相关项目约定。实施设计用于理解职责、调用关系、关键方法契约和副作用；当前代码用于识别入口与风险，不能独自证明预期行为正确。已有测试同样不能替代业务依据。 为关键规则保留来源和简短编号（如 R1）。记录适用角色/状态、触发条件、期望结果和禁止的副作用。业务依据冲突或缺失时标为待确认，不自创约定；只询问影响预期结果的具体问题。可先交付已明确规则的用例，不因一个未知项停掉全部设计。 ## 2. 识别项目已有测试方式 读取范围内的测试目录、运行配置、脚本和少量代表性测试，确认实际使用的框架、入口、fixture、mock 边界、断言方式及组织风格。不能仅凭安装了某个依赖就宣称项目已有对应测试能力。 有单元测试时选择现有公开函数或业务入口；有组件测试时选择现有页面/组件交互入口；项目已有其他类型时仅使用相关且可定位的入口。测试命令可引用为后续执行建议，但本技能不执行。 没有相关测试设施时，仍可交付业务场景及预期结果，并明确没有现成自动化承接入口。不要生成未安装框架的测试骨架，也不要为迎合既有测试能力把跨模块副作用声称为已经验证。 ## 3. 从业务规则推导用例 先列出正常路径，再按适用性检查边界、缺失/非法输入、状态变化、权限、依赖失败、重复操作与时序。复杂输入和组件交互的推导方法见 `references/scenario-design.md`，只读取与当前任务有关的部分。 每个用例必须能回答：依据哪条规则，什么前置条件下，以什么输入或操作触发，应该观察到什么结果，以及哪些副作用必须发生或不得发生。给出能直接用于后续编写测试的具体代表值和操作顺序，不交付只有“测试空值”“测试异常”的标题列表。 按规则所在边界和输入可达性设计。空值可能在接口入口被拒绝、被约定为默认值，或根本不能进入某个内部方法；不能强制给每个方法套同一份非法输入清单。方法名用于定位入口，不以“一方法一套用例”代替业务场景设计。 多条件组合优先覆盖规则相互作用和高影响结果；没有业务理由不穷举所有组合。等价场景可参数化设计，但零、缺失和非法类型不能因预期报错相同就直接视为业务上等价。 ## 4. 核对用例与已有测试 建立“业务规则 → 用例编号 → 验证入口 → 已有测试与断言”的对应关系。逐条检查：是否遗漏失败路径、边界或操作序列；是否只断言函数调用却未断言业务结果；是否缺少副作用检查；mock 是否替代了目标行为，或预期值是否由同一被测实现计算。 新增功能尚无测试代码时，评估已设计用例是否覆盖关键规则，不将“尚未实现测试”误报为设计失败。评估已有测试时给出文件位置及实际断言；测试标题或执行次数不能证明覆盖。未找到测试只说明本次搜索范围内没有对应证据。 优先报告高影响遗漏，说明缺什么、依据是什么、需要增加或加强哪条用例。对于已有且断言充分的用例标明复用，不为增加数量再设计一份。无实质缺口时允许明确报告未发现遗漏。 “已有断言对应”属于静态评估；运行结果仅引用用户提供或现成报告中的实际证据，并注明基线、范围和时间限制。当前版本变化或结果不明时标记执行待确认，不补跑测试，也不把静态匹配写成验证通过。 ## 5. 交付设计与验证办法 按 `references/deliverable-template.md` 核对内容，按 [HTML 测试设计](references/html-delivery.md) 默认生成实际的 `test-design.html`。至少交付范围与依据、测试设施、具体用例、规则对应关系、优先缺口和未确认项；说明关键用例的输入/操作、结果断言与必要数据，技术入口未知时如实标注，不编造。 交付状态按第 4 步的证据边界和参考模板区分；不以“100% 完整”或行覆盖率代替场景与缺口说明。 默认在对话给出 HTML 文件链接和简短摘要，不贴长篇正文代替文件。优先用户指定位置、仓库报告约定或已有测试设计目录；无约定时使用目标项目 `docs/test-design/YYYY-MM-DD-主题/test-design.html`。目标项目未确定时使用本任务可写产物目录并说明，不写到技能安装目录。用户明确指定其他格式、只要对话草稿或已有正本约定时沿用，不强制重复 Markdown，不擅自修改忽略规则。 ## 结果使用 交付后结束，用户决定是否及如何使用产物，不调用其他技能、不自动派发测试编写、运行测试或业务修复。已有调查、设计与报告只作为可选依据，保留实际范围与证据限制；只有规则、材料变化或发现具体缺口时补充本次设计。测试缺口不等于已证明业务缺陷。 ## 交付前自检 检查预期结果有业务依据、用例可承接；已知测试入口可定位，未知入口已明确标注；确认规则与场景的对应关系、缺口和未知项清楚，没有把未执行内容标为通过。检查本次产物只有设计文档，没有越界修改代码或执行测试。