Test Case Workflow (测试用例工作流)

Overview

一条直线流水线，把需求变成经过 AI 审核、可供人工复核的测试用例 Excel。

核心原则

• 无 AI 侧审批门：测试点、用例、AI 审核全部自动推进，不在中间问你「通过还是改」。唯一的自然数门是你拿到 V2 去人工审。
• 不明确就问，绝不假设：需求模糊或业务背景缺失时，先澄清必要信息再动手。这是「问信息」的门，不是「要审批」的门。
• 产出只有用例：最终交付物是一份测试用例 Excel，不附带需求背景报告、AI 审核报告等额外文档。
• 需求 / 知识库是唯一真相源：以原始需求和知识库查证到的业务上下文为准。

Versioning

每次输出 Excel 都存为新版本文件，不覆盖历史：

{需求名称}-测试用例-V{n}.xlsx

• V1：用例 + 审核结果(空表头) sheet（初始）
• V2：用例 + 审核结果(空表头) sheet（AI 审核全改后）→ 交人工审
• V3：用例 + 审核结果(已填充) sheet（人工审反馈应用后）

审核结果 表每个版本都带着：V1/V2 为空表头，你人工审完的 V3 才填入 新增/修改/删除 记录。任何版本打开都能看到该表，不再混淆「哪版才有表」。

最终交付 = 最新版本的 Excel（用例 + 审核结果）。历史版本保留作对比安全网，但不作为交付文档。

Workflow

需求(文本/文件/图片/腾讯文档)
  │
  ▼ S1 需求分析 — 建立可测认知(KB预研 + 图片解析 + 主动澄清 → 立业务线+测试策略)
  │
  ▼ S2 测试点(内部底稿,不进Excel) — 业务驱动 + 覆盖度静默自检
  │
  ▼ S3 写用例 → V1(用例 + 审核结果[空])
  │
  ▼ S4 AI 审核(甲·全改) → V2(用例 + 审核结果[空])
  │
  ▼ 交你人工审 → 应用反馈 → V3(用例 + 审核结果[已填])

S1 需求分析 — 建立可测认知

目标：在动手前搞清需求的业务地位与测试策略。这一步不产出文档，结论直接吸收进后续用例。

1. 知识库预研（可选增强）

• 若已连通知识库（如 ima 知识库），先查询该需求在业务里的地位、归属业务线、上下游系统、关联模块、已有规则与术语。
• 命中须一句话亮出处（如「据 KB《XX 业务说明》…」），便于你否掉错误引用。
• 知识库不可用则跳过，转为下面的多问模式——KB 永不阻塞写用例。
• 若知识库返回多个互相矛盾的来源，不要自选边——先概括冲突内容（各来源分别说了什么、矛盾点在哪），再抛给你裁决。

2. 图片 / 原型强制解析

• 需求含图片、原型、截图时，必须读取并解析，提取其中的状态、字段、交互、边界值——这些信息几乎只画不写，是测试点的关键来源。

3. 主动澄清（信息门）

• 有问题就问，怕的是不问导致用例写一半。凡存在阻断性歧义（不知数据从哪来、不知结果用到哪、核心业务规则不清等），必须澄清。
• 把知识库仍补不齐的缺口攒成一轮一次性问齐，不挤牙膏式逐条问。
• 澄清维度（KB 优先，只问 KB 补不齐的）：
  • 业务线 / 系统位置
  • 数据上游（从哪来、谁产生）
  • 数据下游（送到哪、被谁消费）
  • 测试范围与重点（总是问，避免测多或测漏）
  • 关键业务规则 / 校验逻辑
  • 测试环境 / 账号 / 数据前提
  • 与其他模块的权责边界（仅当涉及跨模块接口时问）
  • 性能（仅当需求本身涉及性能要求时问）
• 停止判据：所有阻断性歧义澄清完毕，即可进入 S2；不再额外追问。

4. 输出

• 立住「业务线 + 测试策略」，作为 S2 测试点的输入。
• 不生成任何背景文档；业务上下文在 S3 写用例时直接吸收进 前置条件、步骤与预期。

注：始终以新需求为准写用例，不做「变更型 / 回归」特殊识别。

S2 测试点（内部底稿，不进 Excel）

测试点只作内部覆盖率底稿，不写入交付物 Excel。

维度

功能(正常) / 边界 / 异常（不含性能、不含兼容性）

优先级

level 0 – 4，定义见 references/testcase-format.md。

生成规则

• 业务驱动，而非功能点翻译：从 S1 立的「业务线 + 测试策略」出发拆测试点；同一功能点在主链路上可拆多条，边角展示可能只需一条。优先级随业务重要性走。
• 聚焦需求侧重点 / 变更点（核心）：用例精力压到本次新增 / 优化的字段与变更的校验逻辑上。判断依据：需求文本、模板中高亮（标色）的新字段列、用户澄清的「新字段 / 优化点」。对需求范围外的既有稳定字段（如导出表里早已存在、已有覆盖的基础列）不逐个铺开写用例，最多保留 1 条冒烟级校验。切忌写一条「含全部字段」的泛化用例去铺历史字段。
• 只测本需求的边界，不越界测源模块：若新字段来自上游模块（如门店类型(新)来自组织架构维护），用例验证「导出侧取到的值正确」，不要去测上游模块自身的维护功能——那是另一个需求的范畴。
• 表达粒度：每条写成「模块 + 具体场景 + 覆盖类型 + 优先级」，场景要具体到能直接对应一条用例。

设计技法（必用，禁止纯 happy-path 公式校验）

写测试点 / 用例时，必须显式套用以下技法，而不是「喂一条典型订单、核对公式算对」——后者和肉眼看一眼等价，没有测试价值：

• 场景法（基本流 / 备选流 / 异常流）：从业务流程出发，先写通「基本流」端到端主路径，再补「备选流」（筛选后导出、仅退款无支付等分支）与「异常流」（无结果、批量中坏行、中断等）。专治流程走不通 / 走偏 / 半路出错——这是字段级技法覆盖不到的。
• 等价类划分：每个数值 / 枚举输入分有效类与无效类，每类至少一例（如代收款 >0 / =0 / 某组件占比 0%）。
• 边界值分析：必测 min / min+ / 名义 / max- / max（运费 =0、截断边界 .xx5、日期精确临界点 06-30 23:59:59 vs 07-01 00:00:00、超大金额）。
• 决策表：多条件组合规则（如「日期 ≤6月 × 是否例外字段 → 空 / 填」）须枚举全部组合，不漏角。
• 组合 / 正交：多因素交叉场景（套餐 × 代销 × 代收款 × 加盟店 × 历史）至少构造一条全交叉，验证各逻辑互不污染。
• 错误推测：经验性异常（分母为 0、关键字段缺失、超大额 / 精度溢出、网络中断）。

判定标准：若一条用例删掉后，「造一个普通订单看一眼」仍能覆盖它，说明它是无效的 happy-path 用例，须替换为上述技法驱动的覆盖点。

覆盖度静默自检

生成后回查需求 + S1 的图片解析结果，核对需求写到的功能点 / 状态 / 交互是否都有对应测试点；缺口直接补全，不打扰你，随即进入 S3。

静默自检意味着 AI 主动放弃测试的某点你不会被告知——这由后续人工审核兜底补缺。

S3 写用例 → V1

列

用例名称 | 前置条件 | 优先级 | 步骤 | 预期结果

命名

##[产品名]-[模块/页面]，[测试场景] —— 场景必须写明白，禁用缩写 / 简写。

质量规则（硬约束）

• 粒度：每个边界 / 异常条件单独成条（边界 = 合理值 / 不合理值 / 卡在两者中间，三类即可）。
• 步骤 ↔ 预期严格 1:1。
• 一场景一条，不混。
• 可执行硬门槛：步骤要让不了解背景的人也能照着做，预期结果必须是能判定「过 / 不过」的具体描述；禁止「检查页面」「显示正常」这类空话。
• 数据具体合理：前置条件 / 步骤 / 预期 里必须造具体、合理的测试数据，禁止「用户 A」「数据 X」等代号占位；数据须符合业务规则与边界。
• 前置条件编号：多个条件时用 1. xxxn2. xxx 编号列出，明确条件条数；仅一条也写作 1. xxx，让读者一眼看出有几条前置。
• 业务上下文吸收：数据上游写进 前置条件，上下游链路写成功能 / 异常用例，业务规则落到步骤与预期。

输出

{需求名称}-测试用例-V1.xlsx，含 用例 sheet + 审核结果 sheet（空表头）。

S4 AI 审核（甲 · 全改）→ V2

五维检查

1. 一致性：标题、步骤、预期是否描述同一场景。
2. 完整性：需求功能是否都有用例，有无漏。
3. 覆盖度：测试点（功能 / 边界 / 异常）是否都有对应用例。
4. 准确性：预期是否具体可判定，优先级是否恰当。
5. 格式：命名规范、1:1、有无空话。

检查时回查需求 + S1 图片解析结果 + S2 测试点底稿。

全改（甲）

发现的问题一律直接改（含整条删除），不拦、不对删除单独高亮。

无报告文档

改动直接落进用例，V2 即改好的用例本身；聊天至多一句话带过改了什么，不产独立报告。

输出

{需求名称}-测试用例-V2.xlsx，含 用例 + 审核结果(空表头) sheet → 交你人工审。

人工审核 → V3

1. 你提供审核反馈（聊天说明，或标注新增 / 修改 / 删除）。
2. AI 将反馈应用到 用例 sheet。
3. 填充已存在的 审核结果 sheet（列：类型[新增/删除/修改，下拉] | 用例标题 | 审核结果）。
4. 另存为 {需求名称}-测试用例-V3.xlsx（或更多轮次递增）。

最终交付

最新版本的 Excel，含 用例 + 审核结果 两个 sheet，内容即最终测试用例。