Menu
功能测试用例设计与产物输出。由 qalore 调用，不独立触发。 以断言集合为输入，设计覆盖正向/边界/异常/上下游的测试用例，产出 story 和脑图产物。 业务逻辑由 qa-understand 提炼后传入，或已存在于 story 文件中。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | qa-functional-test |
| description | 功能测试用例设计与产物输出。由 qalore 调用，不独立触发。 以断言集合为输入，设计覆盖正向/边界/异常/上下游的测试用例，产出 story 和脑图产物。 业务逻辑由 qa-understand 提炼后传入，或已存在于 story 文件中。 |
| practices_min_version | 2026-06-15-v18 |
| 变量 | 来源 | fallback |
|---|---|---|
{practices_path} | qalore 注入 | 自动恢复：读 ~/.claude/qalore-config.json 重建 context |
{story_path} | qalore 注入 | 自动恢复：读 ~/.claude/qalore-config.json 重建 context |
{确认项目名} | qalore 注入 | 立即终止，输出「项目名 context 已丢失，请重新执行任务」 |
拿到断言集合后，先问： 如果这个模块今天在生产中出问题，用户最先感受到什么损失？
以这个答案定义 2-3 个优先测试场景，为这些场景设计多角度用例。
断言集合作为覆盖验证：⚠️ 和 （待代码确认） 断言额外追加高优先用例；
其余断言遵循 cases.md 覆盖规则处理。
多模块任务： 本 capability 负责驱动多模块间的迭代执行，遵循 handbook.md「多模块任务规范」章节。网关完成路由后不介入，由本 capability 自主推进每个模块的流程并控制 .mm 产物输出时机。
输入来源（按优先级）：
【测试意图已提炼】 交接块 → 以此为主输入（格式见 story-formats.md「统一交接块格式」章节）存量用例处置原则：
版本号来源（用于 changelog 和用例头部）：
prd_version 字段断言置信度对用例设计的影响：
（✓）：正常设计，前置条件可精确到实现细节（✓,部分代码确认）：正常设计，在用例备注中标注「部分实现待确认，执行前核实未覆盖仓库」（待代码确认）：正常设计，在用例备注中标注「实现待确认，执行前需与开发核实」（代码独立）：与其他断言同等对待，按业务重要程度设定优先级，标注「来自代码分析」（代码独立,多源）：与其他断言同等对待，可信度高于单源代码独立断言，标注「多仓库代码均发现」⚠️：暂停，将文本-代码冲突列入执行计划，要求用户确认以哪个版本为准后再继续⚠️(代码)：暂停，将多源代码冲突列入执行计划，要求用户确认以哪个仓库逻辑为准后再继续TC 序号续接约束：
{story_path}/{项目}/{模块}/{模块名}-功能-测试用例.md，取文件中最大 TC 序号 N，新增用例从 N+1 开始按需加载规范遵循 {practices_path}/common/handbook.md「context 标记规范」章节。
本 capability 使用的 practices 文件：
tech-stacks/functional/cases.md（设计用例时）tech-stacks/functional/changelog.md（写入 changelog 时）tech-stacks/functional/output.md（生成 .mm 产物时）tech-stacks/functional/story-formats.md（读写 story 文件时）遵循 handbook.md「执行前确认规范」章节。本 capability 的计划摘要格式：
【功能测试执行计划】
项目：{确认项目名}
模块：{模块名}
功能点范围：{列出将要覆盖的功能点}
测试维度：正向 / 边界 / 异常 / 上下游
预计用例数：P0 {n} 条 / P1 {n} 条 / P2 {n} 条 / P3 {n} 条
新增 TC ID 范围：TC-{PREFIX}-{起始序号} ～ TC-{PREFIX}-{结束序号}
产物输出：{.mm（{范围}）/ 仅更新 TC 文件}
规范版本：{practices version}
TC 前缀不存在时自动推断（模块名英文意译首字母缩写，2-5个大写字母，与同项目已有前缀不冲突），推断结果纳入执行计划展示，并单独要求用户对推断前缀做出明确确认（是/否），否则不得继续（因前缀注册后不可变，一旦写入无法修改）。
输出【待沉淀】声明，操作类型遵循 handbook.md「用例变更规则」：
【待沉淀】
| 文件 | 路径 | 操作 | 变更摘要 |
|------|------|------|---------|
| {模块名}-功能-测试用例.md | {路径}/ | {3.1新增/3.2更新/3.3删除} | TC-{PREFIX}-{起}-{止}（{n}条），现有 {m} 条 → 变更后 {总数} 条 |
| {模块名}-功能-测试用例.changelog.md | {路径}/ | 只增不删 | {版本} {操作摘要} |
| index.json | {路径}/ | {新建条目/patch} | {变更字段摘要} |
新增/更新用例预览（供用户确认内容正确性）：
{逐行列出本次新增或更新的用例 ID + 标题，格式：TC-{PREFIX}-{seq}：{标题}（{测试维度}·{优先级}·{n}个断言）}
TC 关联标注（有跨模块上下游断言时）：
遵循 cases.md「跨模块 TC 归属规则」，若业务逻辑.md 中存在带 [模块::功能点] 标签的【上下游】断言，TC 写入完成后须回写业务逻辑.md：找到对应的【上下游】断言行，在行末追加 → 见 TC-{PREFIX}-{seq}，建立断言与用例的双向关联。在【待沉淀】声明中追加该行：
| {模块名}-功能-业务逻辑.md | {路径}/ | 3.2更新 | 在 {n} 条【上下游】断言行末追加 → 见 TC 关联标注 |
测试用例文件头部（新建时写入，更新时同步刷新）：
# {模块名} 功能测试用例
> TC 前缀：{PREFIX} | 用例总数：{n} 条 | 最新版本：{v1.2 / 未关联版本} | 最后更新：{YYYY-MM-DD}
外部路径（deliverable_path）处理：用户消息中存在文件系统路径时，该路径为 deliverable_path，.mm 产物同时输出至该路径。story 写入不受影响，仍正常执行。deliverable_path 只接收 .mm 文件，不接收 story 文件。
错误处理：
TC 文件写入完成后必须执行以下检查，任一项不通过则暂停展示问题清单：
| 检查 | 方法 |
|---|---|
| tc_count | grep -c "^用例 ID：" {TC文件} 与 index.json 一致 |
| pending_count | BL pending + CL pending 与 index.json 一致 |
| assert_seq | max(BL maxID, CL maxID) 与 index.json 一致 |
| 文件头断言数 | BL 头声明的断言数与实际一致 |
| 文件头用例数 | TC 头声明的用例数与实际一致 |
## 功能点：{name} 节功能点： 第一级覆盖扫描 TC 步骤和预期，检测以下禁止的工程语言模式：
| 禁止模式 | 正则 |
|---|---|
| API 调用 | 调用\s*(POST|PUT|DELETE|GET)\s+/api/ |
| 组件 API | ElMessage\.|authService\.|router\.(push|replace) |
| CSS 类名 | \.agent-|\.chat-|\.preset-|\.empty-|\.editor- |
| 内部变量 | showDashedBorder|sidebarCollapseKey|collapsedTimelines|autoScroll |
在灰盒注解 （） 中出现时豁免。
| 检查 | 方法 |
|---|---|
| 断言覆盖率 | 每条 TC 的每个 → 预期： 至少对应一个 → 断言： |
| 断言格式 | 每个 → 断言： 符合 {类型}({参数}) 格式 |
| 断言类型合法性 | 类型名在 execution.md 定义的 10 种范围内，不得使用未定义类型 |
用例评审。由 qalore 调用，不独立触发。 对测试用例执行多层质量检查，输出问题报告。不产生持久化产物，报告仅在对话中呈现。 修复路径由 qa-functional-test 承接。
测试用例执行。读取 TC 文件中的断言规则，通过 Playwright MCP + CDP Network MCP 在浏览器中逐条执行，产出执行报告。不修改 TC 文件。
测试意图理解与提炼。将任意信息源转化为可测试的理解，写入 story，供 qa-functional-test 和 qa-case-review 使用。 调度层设计：按需加载对应适配器，不预加载所有内容。 内置适配器：文本（PRD/需求/口述）、代码（文件/目录/片段，支持 N 个代码仓库）。 多源时顺序执行各适配器（文本适配器完成后依次执行各代码适配器），完成后加载综合层产出统一交接块。 由 qalore 调用，不独立触发。
全栈测试工程师网关。满足以下任一条件时使用： 1. 收到测试相关任务（生成用例、需求分析、覆盖率检查、用例评审等） 2. 涉及读写 story 的操作——story 是本 skill 管理的结构化测试知识库（路径存于 ~/.claude/qalore-config.json），含业务逻辑/测试用例/代码逻辑/变更日志四类文件， 按项目-模块两级目录组织。用户说「更新story/沉淀/写入story」时必须调用本 skill， 不得自行在其他路径创建文件代替。 已建设能力：测试意图理解、功能测试、用例评审。未建设（Phase 2）：自动化、性能、安全、混沌。 执行前必须先读 ~/.claude/qalore-config.json 获取 practices 和 story 路径， 验证路径有效后继续。路径无效时立即停止，不得使用通用知识代替。
Token 使用统计能力。由 Claude Code Stop Hook 自动触发，不由 qalore 主动调用。 从 transcript JSONL 累加本轮所有 API call 的 usage 数据，以固定格式打印到对话。 仅统计本轮；通过 last_assistant_message 信号词过滤，非 qalore 会话静默退出；无需额外 API 调用。