gen-functional-testcase

name	gen-functional-testcase
description	Generates functional test cases only (normal flow, reverse flow, boundary) in Markdown for securities backend requirements. Use when the user asks for 功能测试用例、功能性用例、正向/逆向/边界用例. Output uses fixed table format and project module tree for 所属模块.

功能性测试用例生成

根据需求文档仅生成功能性测试用例（Markdown 表格），所属模块必须来自既定模块树。支持三种标签：功能用例、逆向流程用例、边界值用例；按需求判断是否包含各类用例。

何时使用

• 用户要求「生成功能测试用例」「只出功能性用例」「正向/逆向/边界用例」
• 需求已就绪，只需功能向的用例表（不包含接口、性能、UI 等专项）

引用限制

• 因为用例独立可用原则，用例中对其他地方的引用都要改为具体内容，否则后续使用时别人无法知道你具体引用是什么，无法测试。
• 示例：
  • 验证 F02 与 F01 互斥。这里 F02 与 F01 脱离本次测试后，完全不知道是什么，不符合规范。
  • 按 F01 的逻辑进行银行层级取数。F01 后续也无法再知道是什么意思，无法知道具体逻辑。

用例表头与字段规则

生成的用例必须包含以下列（顺序一致）：

列名	说明与规则
用例名称	清晰、简洁，从名称即可看出验证目的
所属模块	从根到叶的完整路径，层级用 / 分隔；必须从 knowledge/modules.md 的模块树开始，可在此基础上追加需求文档的章节作为子模块（如：业务参数设置/风控规则/AML规则配置/计算逻辑）；禁止出现"本地"等无关内容
用例等级	P0（核心主流程、关键业务逻辑、数据一致性验证）/ P1（重要功能点、常用场景、异常处理）/ P2（一般功能、边界场景、辅助功能）/ P3（低优先级、极端场景、可选功能）；大多数新增需求用例为P1-P2
责任人	默认填写「QwertyI」，除非用户明确指定其他人员
备注	执行目的、注意事项、需验证的库表/接口等
前置条件	环境、数据等；多条用中文分号 ； 分隔
步骤描述	带编号的步骤；多条用 ； 分隔
预期结果	与步骤一一对应；多条用 ； 分隔
标签	仅限：功能用例、逆向流程用例、边界值用例。多标签用英文逗号分隔

用例标题规范

用例名称（标题）需清晰、简洁。根据实际情况自行判断选用下列一种形式，同一批用例内可混用不同形式以更好表达不同测试点。

类型	格式	适用场景	示例
动宾结构型	[动作] + [对象] + [结果/条件]	逻辑简单、直接的功能点；最常用	登录系统-输入正确账号密码-登录成功；上传头像-选择超过5MB图片-提示文件过大
场景化（User Story）型	[身份/前提] + [在什么场景下] + [实现什么目标]	需强调业务场景、多角色/身份时	未登录用户-在购物车页面点击结算-强制跳转登录页；VIP会员-购买特价商品-享受折上折优惠
条件判断型	[前提条件] + [操作] + [结果]	逻辑复杂、多分支/多前置条件的后台算法	余额不足-点击转账-弹出余额补足提醒；网络断开-提交订单-提示网络异常并保存草稿
预期结果导向型	[预期结果] + [原因/操作]	需在报告或列表中快速定位结论时	【失败】输入框输入非法字符SQL注入攻击；【成功】使用第三方微信授权快捷登录
标准化三段论	[功能模块] - [测试点] - [预期结果]	模块多、需严格分类、团队规范要求高时	【支付模块】- 银行卡余额校验 - 余额为0时支付置灰；【用户体系】- 手机号注册 - 重复注册拦截并提示

选用建议：主流程/单点验证优先用动宾；多角色/业务场景明显用场景化；逆向、分支、异常条件多用条件判断型；强调通过/失败结论时用结果导向；需求跨多模块或需与模块树强对应时用三段论（可与 modules 路径呼应）。

前置条件编写规范

前置条件需明确「在什么状态下开始执行步骤」，便于复现与理解。根据用例类型自行组合下列类别中的要素，多条用中文分号 ； 分隔。

类型	编写重点	示例
账号权限与身份定义类	角色名称 + 权限状态 + 登录状态	账号已登录，且具有「财务审批」权限；用户为首次注册的非会员用户；账号处于「被冻结」状态
数据与对象状态类	对象唯一标识 + 特定状态	系统内已存在一个状态为「待支付」的订单；银行卡列表中已绑定至少一张有效借记卡；该手机号已在后台黑名单库中
环境与配置开关类	具体的开关名 + 设定值	系统后台「转账限额校验」功能已开启；当前环境模拟网络延迟大于 3000ms；App 权限设置中已禁用「定位服务」
链路路径（上游步骤）类	核心动作的完成结果	用户已进入转账详情页，且已输入合法的收款人信息；商品已成功加入购物车，并进入结算页面

生成前置条件时，按需选用：涉及多角色/审批时必写身份与权限；依赖特定业务数据时写清对象与状态；依赖开关或环境时写清配置；用例处于长流程中间环节时简述上游路径。

用例等级判断标准

P0（核心，约5-10%）：

• 核心主流程的关键步骤（如登录、支付、下单主流程）
• 数据一致性验证（如资金流水对账、持仓同步）
• 关键业务逻辑验证（如风控规则触发、额度计算）
• 必须通过才能上线的功能

P1（重要，约30-40%）：

• 重要功能点的主要场景
• 常见的正常业务流程
• 重要的异常处理和边界条件
• 新增需求的主要功能验证

P2（一般，约40-50%）：

• 一般功能点的补充场景
• 辅助功能和配置项验证
• 非核心的边界条件
• 新增需求的辅助功能

P3（低优先级，约10-15%）：

• 极端场景和罕见边界
• 可选功能和非必需配置
• 兼容性验证

判断原则：

• 大多数新增需求的用例应为 P1-P2
• 仅核心主流程和关键业务逻辑设为 P0
• 避免过多 P0，保持金字塔结构

所属模块细化规则

模块路径组成：{modules.md中的路径}/{需求文档章节标题}

示例：

• 需求文档第三章标题为"休眠账户指标计算逻辑"
• modules.md中的路径为"业务参数设置/风控规则/AML规则配置"
• 最终模块路径为："业务参数设置/风控规则/AML规则配置/计算逻辑"

提取小模块名称的规则：

1. 从需求文档的章节标题中提取核心关键词作为小模块名称
2. 去除"第X章"、序号等无关内容
3. 简化长标题，保留核心业务含义（如"休眠账户指标计算逻辑" → "计算逻辑"）
4. 常见小模块名称：配置、计算逻辑、结果展示、数据准备、触发机制、兼容性等
5. 严禁在模块路径中出现"本地"、"测试"等无关业务的词汇

表格格式示例

| 用例名称 | 所属模块 | 用例等级 | 责任人 | 备注 | 前置条件 | 步骤描述 | 预期结果 | 标签 |
|----------|----------|----------|--------|------|----------|----------|----------|------|
| 验证提现待处理列表筛选正确 | 款项管理/出金/提现处理/待处理/列表筛选 | P1 | QwertyI | 验证筛选与分页 | 已登录；存在待处理数据 | 1. 进入待处理；2. 选择日期并查询 | 1. 仅显示待处理；2. 结果与条件一致 | 功能用例 |

所属模块（必守）

• 必须从 knowledge/modules.md 的模块树中选取完整路径（从一级到具体叶子），然后追加需求文档章节作为小模块。
• 小模块名称从需求文档章节标题中提取核心关键词，去除序号和冗余描述。
• 严禁在模块路径中出现"本地"、"测试"等无关业务的词汇。
• 每个小模块下建议至少 2 条 case；同一需求可分布在多个小模块下。

---

何时包含各类用例（判断逻辑）

三种类型不必每次全有，按需求与场景判断：

类型	何时应有	何时可省略
功能用例	有明确业务功能、主流程、状态变更、结果校验	纯配置/纯展示且无状态变化时仍建议至少 1 条主流程
逆向流程用例	存在可逆操作（驳回、撤销、取消、退回、作废）、多角色审批、状态回退	无逆向操作或不可逆流程时可省略
边界值用例	有数值/长度/数量限制（金额、笔数、长度、日期范围）、枚举/选项边界、分页/上限	无明确边界或限制时可省略

生成前先对需求做简要判断，在输出中说明本批包含哪些类型及理由（一两句即可）。

---

功能用例编写说明

• 目的：验证需求描述的主流程、正常输入下的正确结果。
• 步骤：按用户/系统真实操作顺序写，每步可验证一个界面或接口结果。
• 预期：与步骤一一对应，写清「界面/接口/数据应呈现什么」而非笼统的「成功」。
• 注意：
  • 覆盖需求文档中的每条「应支持」「应能」类条款；
  • 涉及状态变更的，预期中写清状态前后值或可见表现；
  • 多角色时区分操作角色，前置条件中写清身份与权限。

---

逆向流程用例编写说明

• 目的：验证驳回、撤销、取消、退回、作废等反向操作后，数据与状态正确回退或关闭。
• 步骤：先完成一段正向流程，再执行逆向操作（如点击「撤销」「驳回」），必要时多步逆向。
• 预期：写清逆向后的状态（如订单/申请状态）、数据是否回滚、列表/详情是否不再展示或展示为已关闭。
• 注意：
  • 仅当需求或流程图中存在明确逆向节点时才设计此类用例；
  • 若有「仅某状态可撤销」「仅某角色可驳回」等规则，单独写用例并标清条件；
  • 与功能用例区分：功能用例保证「正向走通」，逆向用例保证「反向走通且数据一致」。

---

边界值用例编写说明

• 目的：在边界处验证规则是否生效（最小值、最大值、临界值、空值、超限等）。
• 步骤：构造恰好等于边界或刚超边界的输入（金额、笔数、长度、日期、选项等），执行与功能用例相同的操作路径。
• 预期：写清系统应接受（如等于上限）或拒绝（如超限提示）、错误提示原文或错误码。
• 注意：
  • 仅对需求/接口/UI 中明确给出的限制写边界用例，不臆造边界；
  • 常见边界：最小/最大金额、单笔/日累计笔数、字符串长度、必填项为空、分页第一页/最后一页；
  • 若同一字段有多处限制（如前端+后端），可合并为一条用例在备注中说明验证点。

---

其他功能性测试需考虑的内容

生成功能性用例时，除上述三类外还可兼顾（不单独作为标签，可体现在用例名称、备注或步骤中）：

1. 等价类：同一规则下的等价输入选代表值即可，不必穷举；在备注中注明「代表等价类 XXX」。
2. 场景与状态覆盖：若业务有多状态（如待审、已通过、已驳回），确保主状态至少有一条功能用例能到达并验证。
3. 数据与权限：前置条件中写清所需数据（如某账户、某额度、某配置）；涉及多角色时写清「以 XX 角色登录」。
4. 依赖与顺序：存在强依赖（如先 A 后 B）时，在步骤中体现顺序，前置条件中写清依赖已就绪。
5. 可追溯性：用例名称或备注中可带需求编号/章节，便于回溯到需求文档。

---

生成流程建议

1. 明确范围：若用户未给，先询问模块名、需求名或需求文档路径。
2. 分析需求结构：仔细阅读需求文档，识别章节结构，提取章节标题作为小模块名称。
3. 判断用例类型：根据上文「何时包含各类用例」判断本批要生成功能用例、逆向流程用例、边界值用例中的哪几种；可简要说明理由。
4. 构建模块路径：
   • 从 knowledge/modules.md 选定与需求对应的大模块路径
   • 从需求文档章节标题中提取小模块名称（去除序号、简化描述）
   • 组合为完整路径：{大模块路径}/{小模块名称}
   • 确保路径中不含"本地"、"测试"等无关词汇
5. 生成用例：
   • 按表头规范生成，包含责任人字段（默认"QwertyI"）
   • 优先级判断遵循金字塔结构，大多数用例为 P1-P2
   • 标签仅用 功能用例、逆向流程用例、边界值用例
6. 识别需求文档路径：识别出需求文档所在的文件夹，后续生成的文件都要在这个文件夹下面。
7. 输出文件：输出到 {需求文档所在文件夹}/{requirement}_functional_tc.md。
8. 转成Excel文档：切到conda ai_testcases 环境，用 ~/.claude/skills/gen-functional-testcase/md_to_xlsx_local.py 将生成的markdown文档输出为 Excel 文档。输出的目录为需求文档所在文件夹。
9. 将Excel转成XMind：切到conda ai_testcases 环境，用 ~/.claude/skills/gen-functional-testcase/xlsx_to_xmind.py 将生成的 Excel 文档输出为 XMind 文档。输出的目录为需求文档所在文件夹。

书写约定

• 多条项一律用中文分号 ； 分隔（前置条件、步骤描述、预期结果）。
• 步骤与预期结果数量、顺序一一对应。
• 标签仅从 功能用例、逆向流程用例、边界值用例 中选，可多选，用英文逗号分隔。

参考

• 模块树定义（所属模块唯一依据）：knowledge/modules.md