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