メニュー
功能测试用例设计与产物输出。由 qalore 调用，不独立触发。 以断言集合为输入，设计覆盖正向/边界/异常/上下游的测试用例，产出 story 和脑图产物。 业务逻辑由 qa-understand 提炼后传入，或已存在于 story 文件中。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| 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 调用。