跳转至

03—AI Skill 测试用例设计完整指南：8 种类型 + 断言自检，覆盖率从 40% 到 90%

Ch03.032 03—AI Skill 测试用例设计完整指南：8 种类型 + 断言自检，覆盖率从 40% 到 90%

📊 Level ⭐ | 6.1KB | entities/ai-skill-测试用例设计.md

03—AI Skill 测试用例设计完整指南：8 种类型 + 断言自检，覆盖率从 40% 到 90%

系列：SkillSentry · AI Skill 测评体系从零到一（三） 📌 一句话摘要：不知道怎么设计 AI Skill 测试用例？本文系统拆解 8 种用例类型、断言强度三级分类和 5 条断言自检规则，帮你把 Skill 测评覆盖率从 40% 提升到 90%。 坏用例不会报错，只会让你误以为 Skill 没问题。两种后果： 1. 漏测：Skill 有问题，但用例没覆盖到，测完以为没问题

相关实体

→ 原文存档

深度分析

测试金字塔在 AI Skill 场景下的适配揭示了一个核心洞察：每层测试能发现的问题类型是严格分层的 ^。单元测试（原子场景）只能发现单条规则是否正确，无法检测规则之间的组合冲突；集成测试（业务逻辑/边界/鲁棒性）能发现规则组合问题但无法覆盖完整对话状态维护；只有 E2E 测试能发现"规则冲突"与"状态污染"这类只有在完整用户旅程中才会暴露的系统性问题 ^。这一分层框架为测试团队提供了明确的优先级判断依据——在资源有限时，应该优先确保 E2E 测试的覆盖率而非在单元测试层面过度投入。

断言质量是测评可信度的根基，这一判断在实践中被反复验证 ^。存在性断言（只验证"有/无"）是测试结果虚高的主要来源——约三分之一的新手测试设计都会掉入这个陷阱。这类断言即使没有 Skill 也能通过，因为大语言模型本身就会产生看似合理的输出。精确断言（定义具体可验证的字段值/计数/格式）和语义断言（需要语义理解判断）才是真正有判别力的测试手段 ^。这一发现对测试流程的设计有直接影响——应该在用例评审阶段就建立断言强度分级审查机制，而不是在测试执行后发现通过率虚高。

八种用例类型覆盖了从正常路径到极端负向场景的完整谱系 ^。值得特别关注的是第六种"负向测试"——验证 Skill 知道"什么时候不该做什么"。这类用例的设计思路是：构造关键词命中但意图不符的场景，观察 Skill 是否会被表面线索误导而启动错误的处理流程 ^。在实践中，这类边界案例往往是线上事故的高发区，因为正常路径测试无法覆盖到这些"看似合理但意图错位"的场景。

用例数量与覆盖率目标的关系是_guideline而非硬性规则 ^。quick 模式 10-15 个用例对应 ≥40% 覆盖率，standard 模式 25-30 个对应 ≥70%，full 模式 40-50 个对应 ≥90%——这些数字是覆盖率达标后的自然结果，不是通过凑数能达到的目标。这意味着测试设计应该从分析 Skill 的规则清单和场景覆盖缺口开始，用例数量只是这个分析过程的输出反映。强迫团队"凑够 25 个就算 standard"不仅无效，还会催生大量低质量的"存在性断言"用例 ^。

五条断言自检规则提供了可操作的评审框架 ^。其中"有判别力"是最核心的自检问题——如果没有 Skill 这个断言是否也会通过？如果是，说明断言无效。这个反向测试思路简单但极其有效，可以快速识别出大量伪测试。第五条"覆盖负向"则要求测试设计者不仅验证预期行为，还要验证禁止行为是否确实被阻止 ^。

实践启示

  1. 建立断言强度分级审查制度：在测试用例评审流程中加入断言分级检查，将精确断言（★）作为准入判断的核心依据，筛除无判别力的存在性断言（○）。建议精确通过率作为版本能否上线的判断标准，而非综合通过率 ^。

  2. 以规则清单为基准驱动用例设计：用例数量不是起点而是终点。先拆解 SKILL.md 中的业务规则清单，对照八种用例类型逐条设计覆盖方案，再根据覆盖率缺口决定用例数量目标。这样可以避免"凑数式"测试设计 ^。

  3. 确保失败用例能直接定位到规则编号：好的原子场景用例在失败时应该能立即指向具体是哪条规则出问题，而非需要人工分析日志才能定位。这要求每条用例的断言都必须有对应的规则来源标注（R-XX 格式） ^。

  4. 警惕通过率虚高——用反向测试验证断言有效性：对每个存在性断言问自己一个问题："如果没有 Skill，这个断言还会通过吗？"如果答案是肯定的，这条断言需要立即重构。定期抽查高频通过的用例，防止"100% 通过率"掩盖下的质量盲区 ^。

  5. 从 standard 模式（≥70% 覆盖率）作为质量基线：quick 模式（≥40%）适合开发过程中的快速验证，但不应作为交付标准。在 CI/CD 流程中集成 standard 模式用例集，确保每次代码变更都经过足够的覆盖度检验后再进入下一阶段 ^。