| 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规则配置/计算逻辑"
提取小模块名称的规则：
- 从需求文档的章节标题中提取核心关键词作为小模块名称
- 去除"第X章"、序号等无关内容
- 简化长标题，保留核心业务含义（如"休眠账户指标计算逻辑" → "计算逻辑"）
- 常见小模块名称：配置、计算逻辑、结果展示、数据准备、触发机制、兼容性等
- 严禁在模块路径中出现"本地"、"测试"等无关业务的词汇
表格格式示例
| 用例名称 | 所属模块 | 用例等级 | 责任人 | 备注 | 前置条件 | 步骤描述 | 预期结果 | 标签 |
|----------|----------|----------|--------|------|----------|----------|----------|------|
| 验证提现待处理列表筛选正确 | 款项管理/出金/提现处理/待处理/列表筛选 | P1 | QwertyI | 验证筛选与分页 | 已登录；存在待处理数据 | 1. 进入待处理；2. 选择日期并查询 | 1. 仅显示待处理；2. 结果与条件一致 | 功能用例 |
所属模块（必守）
- 必须从
knowledge/modules.md 的模块树中选取完整路径（从一级到具体叶子），然后追加需求文档章节作为小模块。
- 小模块名称从需求文档章节标题中提取核心关键词，去除序号和冗余描述。
- 严禁在模块路径中出现"本地"、"测试"等无关业务的词汇。
- 每个小模块下建议至少 2 条 case；同一需求可分布在多个小模块下。
何时包含各类用例（判断逻辑）
三种类型不必每次全有，按需求与场景判断：
| 类型 | 何时应有 | 何时可省略 |
|---|
| 功能用例 | 有明确业务功能、主流程、状态变更、结果校验 | 纯配置/纯展示且无状态变化时仍建议至少 1 条主流程 |
| 逆向流程用例 | 存在可逆操作（驳回、撤销、取消、退回、作废）、多角色审批、状态回退 | 无逆向操作或不可逆流程时可省略 |
| 边界值用例 | 有数值/长度/数量限制（金额、笔数、长度、日期范围）、枚举/选项边界、分页/上限 | 无明确边界或限制时可省略 |
生成前先对需求做简要判断，在输出中说明本批包含哪些类型及理由（一两句即可）。
功能用例编写说明
- 目的：验证需求描述的主流程、正常输入下的正确结果。
- 步骤：按用户/系统真实操作顺序写，每步可验证一个界面或接口结果。
- 预期：与步骤一一对应，写清「界面/接口/数据应呈现什么」而非笼统的「成功」。
- 注意：
- 覆盖需求文档中的每条「应支持」「应能」类条款；
- 涉及状态变更的，预期中写清状态前后值或可见表现；
- 多角色时区分操作角色，前置条件中写清身份与权限。
逆向流程用例编写说明
- 目的：验证驳回、撤销、取消、退回、作废等反向操作后，数据与状态正确回退或关闭。
- 步骤：先完成一段正向流程，再执行逆向操作（如点击「撤销」「驳回」），必要时多步逆向。
- 预期：写清逆向后的状态（如订单/申请状态）、数据是否回滚、列表/详情是否不再展示或展示为已关闭。
- 注意：
- 仅当需求或流程图中存在明确逆向节点时才设计此类用例；
- 若有「仅某状态可撤销」「仅某角色可驳回」等规则，单独写用例并标清条件；
- 与功能用例区分：功能用例保证「正向走通」，逆向用例保证「反向走通且数据一致」。
边界值用例编写说明
- 目的：在边界处验证规则是否生效（最小值、最大值、临界值、空值、超限等）。
- 步骤：构造恰好等于边界或刚超边界的输入（金额、笔数、长度、日期、选项等），执行与功能用例相同的操作路径。
- 预期：写清系统应接受（如等于上限）或拒绝（如超限提示）、错误提示原文或错误码。
- 注意：
- 仅对需求/接口/UI 中明确给出的限制写边界用例，不臆造边界；
- 常见边界：最小/最大金额、单笔/日累计笔数、字符串长度、必填项为空、分页第一页/最后一页；
- 若同一字段有多处限制（如前端+后端），可合并为一条用例在备注中说明验证点。
其他功能性测试需考虑的内容
生成功能性用例时，除上述三类外还可兼顾（不单独作为标签，可体现在用例名称、备注或步骤中）：
- 等价类：同一规则下的等价输入选代表值即可，不必穷举；在备注中注明「代表等价类 XXX」。
- 场景与状态覆盖：若业务有多状态（如待审、已通过、已驳回），确保主状态至少有一条功能用例能到达并验证。
- 数据与权限：前置条件中写清所需数据（如某账户、某额度、某配置）；涉及多角色时写清「以 XX 角色登录」。
- 依赖与顺序：存在强依赖（如先 A 后 B）时，在步骤中体现顺序，前置条件中写清依赖已就绪。
- 可追溯性：用例名称或备注中可带需求编号/章节，便于回溯到需求文档。
生成流程建议
- 明确范围：若用户未给，先询问模块名、需求名或需求文档路径。
- 分析需求结构：仔细阅读需求文档，识别章节结构，提取章节标题作为小模块名称。
- 判断用例类型：根据上文「何时包含各类用例」判断本批要生成功能用例、逆向流程用例、边界值用例中的哪几种；可简要说明理由。
- 构建模块路径：
- 从
knowledge/modules.md 选定与需求对应的大模块路径
- 从需求文档章节标题中提取小模块名称（去除序号、简化描述）
- 组合为完整路径：
{大模块路径}/{小模块名称}
- 确保路径中不含"本地"、"测试"等无关词汇
- 生成用例：
- 按表头规范生成，包含责任人字段（默认"QwertyI"）
- 优先级判断遵循金字塔结构，大多数用例为 P1-P2
- 标签仅用
功能用例、逆向流程用例、边界值用例
- 识别需求文档路径：识别出需求文档所在的文件夹，后续生成的文件都要在这个文件夹下面。
- 输出文件：输出到
{需求文档所在文件夹}/{requirement}_functional_tc.md。
- 转成Excel文档：切到conda ai_testcases 环境，用
~/.claude/skills/gen-functional-testcase/md_to_xlsx_local.py 将生成的markdown文档输出为 Excel 文档。输出的目录为需求文档所在文件夹。
- 将Excel转成XMind：切到conda ai_testcases 环境，用
~/.claude/skills/gen-functional-testcase/xlsx_to_xmind.py 将生成的 Excel 文档输出为 XMind 文档。输出的目录为需求文档所在文件夹。
书写约定
- 多条项一律用中文分号
； 分隔（前置条件、步骤描述、预期结果）。
- 步骤与预期结果数量、顺序一一对应。
- 标签仅从
功能用例、逆向流程用例、边界值用例 中选，可多选，用英文逗号分隔。
参考
- 模块树定义（所属模块唯一依据）：
knowledge/modules.md
