test-case-completeness-review

star 0

Review whether manual or automated test cases are missing scenarios. Supports two modes: lightweight review from testcase standards and historical badcases only, or full omission comparison using user-provided PRD, optional TRD, and remote branch diff against release. Use when the user asks to check case completeness, review DMS/manual/automation cases, compare cases against PRD/optional TRD/code diff, find missing test scenarios, or assess coverage before release.

540415003 By 540415003 schedule Updated 6/9/2026
play_arrow Run Skill in Manus View GitHub

name: test-case-completeness-review author: tingting.liutt@shopee.com version: 1.0.0 description: >- Review whether manual or automated test cases are missing scenarios. Supports two modes: lightweight review from testcase standards and historical badcases only, or full omission comparison using user-provided PRD, optional TRD, and remote branch diff against release. Use when the user asks to check case completeness, review DMS/manual/automation cases, compare cases against PRD/optional TRD/code diff, find missing test scenarios, or assess coverage before release.

测试用例完整性检查

目标

基于测试用例规范、历史漏测 badcase，以及用户愿意提供的 PRD、可选 TRD、远程代码分支相对 release 基线的最新改动，判断用例是否存在遗漏。重点检查主干流程、边界/异常、关联影响、代码实际改动范围，以及 PRD/可选 TRD 没写清但代码已经改变的风险。

确认用户已经明确提供测试用例后，开始分析前先读取 references/coverage-dimensions.md，再读取 badcases/ 目录下用户持续维护的历史漏测样例。coverage-dimensions.md 来自《提升测试设计和执行能力》的核心方法，用来补齐通用检查维度；badcases/ 用来补齐团队真实漏测风险。

省 token 输入策略

用户必须明确提供测试用例：DMS 用例、手工用例、自动化用例、用例文档、测试计划。输入可以是路径、链接、粘贴内容或附件。

如果用户没有明确给出测试用例输入，必须先问用户提供测试用例路径、链接或内容，并在同一次提问里顺带询问是否要补充 PRD、TRD、代码仓库/需求分支或 diff。提问后停止本次 review 准备动作。不要扫描当前目录、最近文件、git 改动、文件名候选、历史上下文或日志来猜测要检查哪份用例。

推荐提问话术：

请把要检查的测试用例发我，路径、链接、粘贴内容或附件都行。也可以一起补充 PRD、TRD、代码仓库路径 + 需求分支，或直接给 diff；补了我会做逐项遗漏比对，不补就按用例规范和历史 badcase 做轻量检查。代码分支的默认基线是 origin/release。

只读取两类材料：

  • 用户本轮或当前任务上下文中明确给出的测试用例、PRD、TRD、代码仓库/分支、diff、链接或附件。
  • 本 skill 自带的 references/coverage-dimensions.md 和 badcases/。

不要把当前工作目录中“看起来像用例/PRD/TRD”的文件当作输入；除非用户明确指定路径或文件名。

PRD、TRD、代码仓库/分支/代码改动默认不要求上传。为了避免浪费 token，开始 review 前，如果用户还没有提供 PRD/TRD/代码改动材料，且本轮还没有问过这些补充材料，先用一句话提醒并询问：

要不要补充 PRD / TRD / 代码分支或 diff 做遗漏比对？传了我会逐项对照需求、技术改动和代码改动；不传我就只按用例规范和历史 badcase 判断现有 case 是否有明显遗漏。

如果已经在“缺少测试用例”的合并提问里问过 PRD/TRD/代码材料，用户回复时只提供了测试用例，就视为暂不补充这些材料，直接进入轻量模式，不要二次追问。

用户选择后按两种模式执行：

  • 轻量模式：用户不传 PRD/TRD/代码改动时，只根据 references/coverage-dimensions.md、badcases/ 和现有测试用例判断遗漏。输出中明确“未做 PRD/TRD/代码逐项遗漏比对”。
  • 比对模式：用户传了 PRD、TRD、代码分支或 diff 中的任意材料时，必须使用已提供材料做遗漏比对。传了 PRD 就对 PRD；传了代码改动就对代码 diff；传了 TRD 就对 TRD。PRD + TRD + 代码改动都传了时，必须做完整遗漏比对。

对话过程中要提醒用户：后续补充 PRD/TRD/代码改动后，本次结论会升级为“材料对照后的遗漏比对”；不补充时，结论只代表“按规范和历史 badcase 的用例自检”。

用户可以提供：

  • PRD：需求背景、范围、业务规则、角色/站点/市场、页面交互、验收标准、非目标范围。
  • TRD：技术方案、接口、库表、状态机、消息、定时任务、配置、依赖服务、兼容/迁移/回滚设计。
  • 代码仓库与分支：每个仓库包含本地仓库路径或 Git 仓库地址、需求分支名。release 基线默认使用远端 origin/release，用户只有在要覆盖默认值时才需要提供 release 分支、tag 或 commit。
  • 代码改动材料：PR diff、commit diff、分支 diff、MR/PR 链接、用户指定改动文件。

如果用户没有提供 TRD，不要自己搜索、猜测或从 PRD/代码中反推出“TRD”。输出中将 TRD 标记为“未提供，按要求不识别 TRD 改动点”，覆盖矩阵不出现 TRD 来源项。

如果 PRD、TRD、代码仓库与分支中任一类缺失，不要自行查找或猜测。只在输出中说明这些材料未提供，因此无法判断对应维度的完整遗漏。release 基线缺失不算材料缺失，按默认 origin/release 继续做代码对比。测试用例本身缺失或无法读取时，不能做 review，必须向用户要可读取的用例输入。

历史 badcase 资料库

本 skill 预留 badcases/ 目录，用户会不定期追加 dev 自测遗漏、QA 用例遗漏、线上/灰度发现的问题。每次 testcase review 都必须读取该目录。

推荐维护方式：badcases/sources.md 记录原始来源链接，badcases/raw/ 保存从 Confluence/Jira/表格复制或导出的原始内容，badcases/normalized/ 保存已经提炼好的本地 badcase 快照。不要只依赖远程链接，也不要只依赖模型“记住”。本地快照可重复、可版本化，远程链接用于追溯和刷新。

执行方式：

  1. 使用 find badcases -type f 或等价方式列出文件。
  2. 读取优先级：badcases/normalized/ > badcases/raw/ > badcases/sources.md。README.md、templates/ 只作为维护说明，不当作 badcase 输入。
  3. 读取可解析文件内容，优先支持 .md、.txt、.csv、.json、.yaml、.yml。
  4. 如果存在 badcases/sources.md，读取来源链接；如果链接当次可访问，可补读最新内容；如果不可访问，不阻塞评审，继续使用本地快照。
  5. 如果目录为空或只有来源链接、没有本地快照，只在「已读取材料」中标记“暂无本地历史 badcase 快照”，不要阻塞评审。
  6. 如果文件过多，优先读取与当前 PRD、仓库、模块、Jira key、业务域、关键词匹配的文件，再概览通用文件。
  7. 从 badcase 中提取：遗漏场景、触发条件、失败原因、缺失断言、影响模块、应该补的测试设计维度。
  8. 将 badcase 映射为当前需求的类比风险：例如权限、配置开关、历史数据、异常降级、跨仓字段同步、幂等、并发、导出、日志、监控、回滚。

Confluence 本地 MCP stdio 读取

如果 badcases/sources.md 中有 Confluence 来源链接，且当前会话的工具列表没有暴露 Confluence MCP，不要只用 curl 判断不可读。普通 curl 访问 Shopee Confluence 经常会跳登录页，但本机可能已经配置了 MCP token。

优先使用本 skill 的 helper 脚本读取：

cd "/Users/liutingting/DELIVERY automation/ai-skills/qa-skills/test-case-completeness-review"
python3 scripts/confluence_stdio_fetch.py --page-id 2514193970 --children --output-dir badcases/raw/confluence-2514193970

脚本会通过 ~/.codex/bin/mcp-atlassian.sh 启动本地 MCP stdio，并调用：

  • confluence_get_page
  • confluence_get_page_children

使用规则：

  • 先通过 helper 读取目录页和子页面；成功后把原始内容保存到 badcases/raw/。
  • 再把可复用检查点提炼到 badcases/normalized/。
  • 如果 helper 报错，再检查 ~/.codex/config.toml 是否有 mcp-atlassian 或 confluence_communication_server，以及 ~/.codex/mcp-secrets.sh 是否配置 token。检查时只看变量名，不输出 token。
  • 不要把 Confluence 登录页 HTML 当成 badcase 内容。

使用边界：

  • badcase 只能作为补充检查维度和风险提醒，不能当成当前测试用例已覆盖的证据。
  • 当前需求无关的 badcase 不要硬套；可在输出中标为“不适用”或不进入覆盖矩阵。
  • 如果当前用例没有覆盖 badcase 暴露过的同类风险，要在覆盖矩阵中列为 Partial 或 Missing，来源写 BadCase。
  • 如果 badcase 暴露的是 dev 自测遗漏，仍按 QA 用例覆盖标准检查，不能默认“开发会测”。

远程分支和 release 对比

代码改动必须优先从远程最新状态获取，不以本地当前分支或旧 diff 为准。

对用户提供的每个仓库执行：

  1. 进入仓库目录；如果用户只给 Git URL 且本地没有仓库，可 clone 到临时目录。
  2. 读取当前工作区状态，避免覆盖用户本地改动。
  3. 拉取远程最新引用：优先执行 git fetch --all --tags --prune，确保需求分支和 release 基线都是最新。
  4. 解析需求分支 ref：优先使用 origin/<需求分支>；如果用户提供完整 ref、tag 或 commit，则按用户提供值解析。
  5. 解析 release 基线 ref：如果用户提供 release 分支，优先使用 origin/<release分支>；如果用户提供 tag 或 commit，则按用户提供值解析；如果用户没有提供 release 基线，默认使用 origin/release，不要因此跳过代码对比。
  6. 使用 merge-base 找出从 release 分出来后的需求改动：git merge-base <release_ref> <feature_ref>。
  7. 生成最新改动清单和 diff：
    • git diff --name-status <merge_base>..<feature_ref>
    • git diff <merge_base>..<feature_ref> -- <直接相关文件>
    • 必要时用 git log --oneline <merge_base>..<feature_ref> 看提交意图。
  8. 如果需求分支不是从该 release 基线分出，或 merge-base 明显异常，补充一次直接对比：git diff --name-status <release_ref>..<feature_ref>，并在输出中说明 diff 基线风险。

不要为了查看 diff 切换分支；能用远程 ref 完成时，不执行 checkout。确需 checkout 时，只在工作区干净且有必要时进行，并说明原因。

读取顺序

  1. 先确认用户已明确提供测试用例路径、链接、粘贴内容或附件；没有提供就一次性询问测试用例、PRD、TRD、代码仓库/需求分支或 diff，然后停止，不读取工作区候选文件。代码仓库未给 release 基线时默认使用 origin/release。
  2. 读取 references/coverage-dimensions.md。
  3. 读取 badcases/，提取历史漏测模式和同类风险检查点。
  4. 读取用户明确提供的测试用例，提取每条 case 的前置条件、步骤、预期结果、覆盖对象。
  5. 如果用户明确提供 PRD，读取 PRD，提取需求点和业务验收点；未提供则跳过 PRD 对照。
  6. 如果用户明确提供 TRD，读取 TRD，提取技术改动点、内部流程、数据流、依赖和异常处理；未提供则跳过 TRD 对照，不识别 TRD 改动点。
  7. 如果用户明确提供代码仓库/分支，按“远程分支和 release 对比”拉取远程最新需求分支与 release 基线，生成真实代码改动范围；如果用户直接提供 diff，则读取该 diff。未提供则跳过代码改动对照。
  8. 建立覆盖矩阵，逐项判断 Covered / Partial / Missing / Not Verifiable。

不要只按 PRD 或用例标题判断覆盖。代码 diff 中出现但 PRD/已提供 TRD 没写的改动，也要进入检查范围。轻量模式下，不要声称已经覆盖 PRD/TRD/代码改动，只能说按规范和 badcase 看是否有明显遗漏。

分析方法

1. 需求到用例

把 PRD 拆成原子需求点：

  • 用户操作路径、页面入口、角色权限、市场/站点/作业域差异。
  • 字段规则、默认值、必填/选填、格式、长度、枚举、唯一性。
  • 正向流程、反向流程、取消/回滚/重试/恢复。
  • 新旧数据兼容、历史数据处理、灰度或配置开关。
  • 验收标准、数据口径、报表或导出要求。

每个原子需求点必须能在用例里找到明确步骤和预期结果。只有「提到」但没有输入、操作、断言的，不算完整覆盖。

2. TRD 到用例（仅用户提供 TRD 时执行）

把 TRD 拆成技术风险点：

  • 接口：方法、路径、参数、错误码、权限、幂等、超时、重试、下游失败。
  • 数据库：增删改查、事务、唯一约束、索引、并发锁、数据一致性。
  • 消息/中间件：Kafka、Redis、Apollo、异步任务、死信、重复消息、乱序。
  • 定时任务：调度时间、重复触发、并发执行、中断恢复、依赖不可用。
  • 状态机：合法流转、非法流转、重复流转、跨端/跨系统同步。
  • 兼容性：新旧字段、新旧服务、新旧数据、版本回滚。

技术方案中的关键分支、配置开关、异常路径都要有对应 case。只测 API 成功响应，不等于覆盖内部写库、发消息、状态流转和副作用。

如果用户未提供 TRD：

  • 不要自行查找或推断 TRD。
  • 不要把代码分析结果标为 TRD 来源。
  • 输出中明确“TRD 未提供，已按要求跳过 TRD 维度”。

3. 代码改动到用例

从代码 diff 反推真实影响面：

  • 改动文件属于哪个模块、入口、接口、handler、service、repository、job、consumer。
  • 是否改到底层公共函数、公共 DTO、公共配置、校验器、状态常量、权限逻辑。
  • 是否出现新增字段、默认值、枚举、feature flag、SQL、migration、消息 topic、缓存 key。
  • 是否影响旧接口、旧页面、旧数据、上下游系统或跨作业域流程。
  • 测试用例是否覆盖 diff 中新增/修改/删除的每个分支。

发现「代码有改，PRD/已提供 TRD 未说明」时，列为需求/技术文档缺口，同时检查是否需要补用例。

4. 历史 badcase 到用例

从 badcases/ 反推容易漏测的真实风险：

  • dev 自测遗漏但 QA case 也没有覆盖的场景，要优先进入缺失用例。
  • 同类模块曾经漏过的问题，要检查当前 case 是否有明确前置条件、操作步骤和预期断言。
  • 历史 badcase 中的“失败原因”要转成可执行的测试点，而不是只复述问题描述。
  • 对跨仓、上下游、配置、灰度、回滚、异常降级、数据一致性类 badcase，要结合当前代码 diff 判断是否有同类影响面。
  • 如果 badcase 只适用于旧业务或当前需求无相似风险，不强行要求补 case。

判定标准

  • Covered：用例有明确前置条件、输入/操作、预期结果，能验证该需求或改动点。
  • Partial：覆盖了主路径，但缺少边界、异常、关联影响、副作用或断言不够具体。
  • Missing：没有对应用例，或只有泛泛描述。
  • Not Verifiable：材料缺失、环境不可见、依赖信息不足，当前不能确认。

严重度按发布风险评估：

  • P0：主干流程、数据写入/状态流转、权限/资金/履约关键链路、会导致发布事故的关联影响。
  • P1：边界值、异常路径、兼容性、跨模块影响、幂等/并发、配置/消息/任务失败。
  • P2：文案、展示、易用性、低频非核心组合、可延后补充的探索性场景。

输出格式

用中文输出，先给结论，再给证据和缺口。

## 结论

- 完整性判断：完整 / 基本完整 / 不完整 / 当前无法完整判断
- 主要风险：1-3 条

## 已读取材料

| 类型 | 来源 | 读取结果 |
| --- | --- | --- |
| Review 模式 | 轻量模式 / 比对模式 | 已确认 |
| PRD | ... | 已读并用于比对 / 未提供，已跳过 / 部分可读 |
| TRD | ... | 已读 / 未提供，已跳过 / 部分可读 |
| 代码仓库与分支 | ... | 已拉取远程 / 未提供，已跳过 / 部分可读 |
| release 基线 | ... | 已解析 / 未提供，已默认使用 origin/release / 部分可读 |
| 代码改动 | ... | 已用于比对 / 未提供，已跳过 / 部分可读 |
| 历史 badcase | ... | 已读 / 暂无 / 部分可读 |
| 测试用例 | ... | 已读 / 缺失 / 部分可读 |

## 覆盖矩阵

| 检查点 | 来源 | 现有用例证据 | 状态 | 严重度 | 建议补充 |
| --- | --- | --- | --- | --- | --- |
| ... | PRD/TRD/Code/BadCase | 用例名/文件/行号 | Covered/Partial/Missing/Not Verifiable | P0/P1/P2 | ... |

## 缺失用例

| 优先级 | 缺失场景 | 为什么要补 | 建议用例 |
| --- | --- | --- | --- |
| P0 | ... | ... | ... |

## 文档或代码疑点

- ...

工作约束

  • 不要为了显得覆盖完整而补想象中的用例证据。
  • 不要只看用例标题；必须看步骤和预期结果。
  • 不要忽略代码 diff 中的隐性影响面。
  • 不要用本地过期分支或手工给出的旧 diff 代替远程最新分支对比。
  • 不要在用户未提供 TRD 时自行识别 TRD；这时只按 PRD、远程代码改动和测试用例判断。
  • 不要在用户未提供 PRD/TRD/代码改动时伪装成完整遗漏比对；必须说明轻量模式只基于规范和 badcase。
  • 不要把「开发自测」默认当成 QA 用例覆盖，除非能读到自测步骤和断言。
  • 不要把「测主流程」当成完整覆盖；边界、异常、关联影响是独立检查项。
  • 对无法读取的链接、文件或权限问题，直接写明影响范围。

SKILL_USAGE_START This skill must call the usage report API exactly once after the skill execution is completed. POST https://ai-management.ssc.test.shopee.io/api/v1/skill-usage/report Body: {"skill_name":"test-case-completeness-review"}

Install via CLI
npx skills add https://github.com/540415003/hjx_personal --skill test-case-completeness-review
Repository Details
star Stars 0
call_split Forks 0
navigation Branch main
article Path SKILL.md
More from Creator
540415003
540415003 Explore all skills →