메뉴
TestSpec 需求分析和梳理（流程第 2 步）- 对需求做深度测试分析，运用等价类、边界值、状态迁移等方法，产出 requirements-analysis.md。当用户要「分析需求」「梳理测试点」「做需求分析」「拆解可测项」或执行 testspec-analysis / testspec analysis 时使用。也适用于用户说「这个 PRD 有哪些要测的」「帮我分析一下测试范围」「需求评审准备」的场景。注意：如果用户要的是简短的测试点清单而非深度分析，应使用 testspec-points。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
TestSpec 生成测试用例（流程第 4 步）- 根据测试点（specs/*.md）生成完整测试用例并导出 Excel (.xlsx) 或 XMind (.xmind) 格式。当用户要「生成用例」「写测试用例」「导出 Excel」「导出 XMind」「生成测试用例表格」或执行 testspec-generate / testspec generate 时使用。也适用于用户说「把测试点展开成用例」「帮我出一份测试用例表」「生成 Excel 测试文档」的场景。使用内置 Python 脚本完成 Excel/XMind 文件生成，不依赖外部技能。
TestSpec 新建测试工作（流程第 1 步）- 创建测试变更目录，编写 proposal.md，并在用户提供已有 PRD/需求片段时净化成可验收的 requirements.md。当用户要「新建测试」「开始测试」「创建测试变更」「建一个测试项目」或执行 testspec-new / testspec new 时使用。也适用于用户说「我要测 XXX 功能」「帮我准备测试」「有个新需求要测」「帮我整理/审查 PRD」的场景——如果尚无 testspec/changes/ 目录，这是流程的起点。产出 testspec/changes/<name>/ 目录结构、proposal.md，必要时产出 requirements.md。
TestSpec 测试点（流程第 3 步）- 从需求分析中提炼「要测什么」的简短要点清单，产出 specs/testpoints.md。当用户要「写测试点」「提取测试要点」「列出要验证的内容」或执行 testspec-points / testspec points 时使用。也适用于用户说「这个功能要测哪些点」「帮我列测试清单」的场景。与测试用例区分：测试点只列验证目标（What），不写操作步骤（How）。产出供 testspec-generate 展开为完整测试用例。
TestSpec 用例评审（流程第 5 步）- 对生成的测试用例做 14 维度交叉验证（R1-R6 规则检查 + H1-H8 启发式检查），产出 review-report.md 评审报告。当用户要「评审用例」「检查用例质量」「审查测试用例」或执行 testspec-review / testspec review 时使用。也适用于用户说「用例写完了帮我看看」「检查一下覆盖度」「用例有没有问题」的场景。支持默认模式和 --deep 深度模式。
TestSpec 需求源更新与口径收敛（可重复执行的轻量 rebaseline）- 当已有 testspec/changes/<name>/ 后，用户补充、修改、删除、澄清、替换 PRD、接口文档、UI 图、原型图、产品回答、验收规则、权限规则、时间口径、收益映射、字段说明或需求范围时使用。适用于「产品改需求了」「补充接口文档」「新增 UI 图」「删掉这个需求」「同步最新 PRD」「口径收敛」「更新 requirements」「标记旧 analysis 过期」「用例写完后需求变了」「testspec-update / testspec update」。产出更新后的上游需求源、变更影响摘要、blocking_open_questions/dynamic_followups 分类，并标记 stale 下游产物。
Static Android app reverse-analysis workflow for exporting APKs from ADB, handling split APKs, decompiling with JADX/apktool/Vineflower, inventorying static artifacts, detecting packers, extracting API endpoints, and producing evidence-labeled reports. Use when the user asks to reverse engineer, decompile, inspect APKs, pull installed apps, dump packages, run jadx/apktool/smali/vineflower/dex2jar, analyze /tmp APK or JADX outputs, detect Android packers/native code, extract Retrofit/OkHttp/Volley/custom HTTP endpoints, find leaked static secrets, trace Android call flows, or says '用jadx逆向', '从手机导出安装包', '提取接口', '查包名并反编译', '检测加固', '提取泄露'.
| name | testspec-analysis |
| description | TestSpec 需求分析和梳理（流程第 2 步）- 对需求做深度测试分析，运用等价类、边界值、状态迁移等方法，产出 requirements-analysis.md。当用户要「分析需求」「梳理测试点」「做需求分析」「拆解可测项」或执行 testspec-analysis / testspec analysis 时使用。也适用于用户说「这个 PRD 有哪些要测的」「帮我分析一下测试范围」「需求评审准备」的场景。注意：如果用户要的是简短的测试点清单而非深度分析，应使用 testspec-points。 |
IRON LAW: Never replace requirements analysis with a reformatted PRD; every issue must explain why it affects testing.
TestSpec Analysis Progress:
- [ ] Step 1: Locate current change directory ⚠️ REQUIRED
- [ ] Step 2: Load requirements/proposal and available source material ⚠️ REQUIRED
- [ ] Step 3: Choose analysis modes from references/analysis-modes.md
- [ ] Step 4: Analyze risks, gaps, and testability
- [ ] Step 5: Run interrogation loop when ambiguity affects test design
- [ ] Step 6: Reflect, seed context metadata, and report next step
对需求进行深度测试分析，先基于用户目标和上下文选择合适的分析模式，再产出结构化的 requirements-analysis.md。核心价值是发现隐含风险、缺失信息和逻辑漏洞，而不是把需求文档换个格式重新罗列。
与 testspec-points 的分工：analysis 做深度拆解（"为什么要测、有哪些风险"），points 从 analysis 中提炼精简清单（"要测什么"，一句话一条）。
参见 ../_testspec-shared/references/common.md 中的「当前变更目录定位规则」。
references/analysis-modes.md../_testspec-shared/references/output-contracts.mdreferences/requirements-analysis-template.mdreferences/interrogation-loop.mdrequirements.md（若存在）；否则读取 proposal.md（必须）。若有外部需求文档（PRD、设计稿链接），尽可能获取内容。references/analysis-modes.md 中选择一个或多个模式。requirements-analysis.md。按
../_testspec-shared/references/thinking-protocol.md执行推理式决策。
../_testspec-shared/references/context-protocol.md）stale_downstream_artifacts 且包含 requirements-analysis.md：重新生成分析，不复用旧口径结论source_revision，但现有 requirements-analysis.md 缺少 testspec-context 或其中无 source_revision 字段，或 source_revision.version 低于 requirements.md 的版本：即使 stale_downstream_artifacts 未显式列出 requirements-analysis.md，也必须重新生成分析，不复用旧口径结论requirement_quality.readiness 为 blocked 或 needs_revision：先提示用户需求质量不足，建议回到维护当前 requirements.md 的 skill 补齐（若 source_revision.updated_by_skill == "testspec-update" 或变更目录已存在，使用 testspec-update；否则使用 testspec-new）；若用户仍要求继续，则加深质询并在 requirements-analysis.md 中标注低置信度material_quality 预判为 low，自动加深质询力度；已填写的「关键问题」项直接纳入质询清单种子输入testspec/testlib/index.json 存在）：
index.json，匹配相关模块和功能index.json 中的 file 路径定点读取对应 <feature>.json在正式分析前做一次快速直觉扫描。直觉不需要理由——它的价值在于捕捉分析方法可能遗漏的"说不清但感觉不对"的风险信号。
在完成材料评估后、进入正式模式推理前，快速浏览需求材料并记录直觉感受：
规则：
产出：在 requirements-analysis.md 的「分析摘要」后增加「直觉扫描」小节：
## 直觉扫描
- 不踏实的区域：<模块/功能名> — <一句话感受>
- 过于顺畅的描述：<位置> — <哪里感觉"太好了">
- 整体信心：<X/10>
下游影响：
risks_identified 中纳入直觉标记的模块（标注 source: intuition）通过 3 个核心问题推导分析模式，而非关键词匹配：
"这份材料最大的测试风险在哪里？"
"材料中是否有技术/安全/歧义/矛盾特征？"
"用户的实际关注点是什么？"
../_testspec-shared/references/thinking-protocol.md 的优先级）按
../_testspec-shared/references/reflection-protocol.md执行产物反思。
产物首次生成后，执行反思循环：
反思后修正产物，最多 2 轮迭代。告知用户迭代次数和修正摘要。
在 requirements-analysis.md 末尾，按 ../_testspec-shared/references/context-protocol.md 播种元数据：
<!-- testspec-context
{
"source_skill": "testspec-analysis",
"thinking_summary": "<推理过程摘要>",
"risks_identified": ["<识别到的关键风险>", "<直觉标记的风险区域，标注 source: intuition>"],
"intuition_flags": ["<直觉扫描中标记的不踏实区域>"],
"blocking_open_questions": ["<不确认就不能进入下一步的问题>"],
"material_quality": "<high/medium/low>",
"strategy_used": "<使用的分析模式组合>",
"source_revision": {"version": "<从 requirements.md 消费的版本号>", "summary": "<需求源摘要>", "updated_by_skill": "<上游 skill>"},
"testlib_coverage": {
"scanned": true,
"related_modules": ["<匹配到的 testlib 模块>"],
"existing_case_count": 0,
"reusable_features": ["<可复用的功能点>"],
"regression_risk_features": ["<可能需要回归的功能点>"]
}
}
-->
生成产物后，对照以下反模式自查。发现符合的情况时自动修正。
| 反模式 | 表现 | 正确做法 |
|---|---|---|
| 需求复述 | 分析内容只是把需求文档换了个说法重写一遍 | 每个分析项必须指出"为什么这是风险"或"缺了什么" |
| 万能模板 | 所有功能模块的分析结构完全相同，缺少针对性 | 根据模块特性选择性使用分析框架，复杂模块深入、简单模块精简 |
| 伪风险 | 风险点全是"可能出错""需要注意"等泛泛之言 | 风险必须指向具体场景（"并发修改同一订单时状态冲突"） |
| 实现泄漏 | 分析中出现 Redis、MQ、数据库表等实现细节 | 只描述业务行为和验证需求，不涉及技术实现 |
| 过度发散 | 分析了大量与当前需求无关的"最佳实践" | 只分析当前需求范围内的内容，标注明确的需求边界 |
| 缺失审问 | 发现需求不明确但没有列出问题清单 | 发现不明确处必须产出结构化问题，标注测试影响 |
当需求存在会影响用例设计或测试结果判断的不明确项时，加载 references/interrogation-loop.md，生成「需求审问清单」并支持后续回答合并。
识别需要验证的业务行为和质量属性，按 Functional / Boundary / Exception / Integration / Non-Functional 五个维度覆盖。分析聚焦"验证什么"和"为什么值得验证"，不涉及"如何执行测试步骤"。
按需使用以下方法，不机械套用：
从需求中识别以下内容，按 模块 → 功能点 层级组织：
以下内容优先作为独立分析项：
必须覆盖以下异常类型：
在需求中明确或隐含以下质量属性时，必须纳入分析：
当需求未明确说明某行为时：
# 需求分析：<被测对象>
## 需求来源
- PRD：<链接>
- 设计稿：<链接>
## 分析摘要
- 分析模式：<本次采用的模式>
- 总结：<一句话总结>
## 直觉扫描
- 不踏实的区域：<模块/功能名> — <一句话感受>
- 过于顺畅的描述：<位置> — <哪里感觉"太好了">
- 整体信心：<X/10>
## 主要问题
### 高优先级问题
- [类别] <问题描述>
- 位置：<位置>
- 建议：<建议>
### 中低优先级问题
- ...
## 已明确内容
- <当前材料中定义清楚的内容>
## 建议补充
- <建议补充的信息>
## 功能模块拆解
> 若 testlib 中已有相关模块用例，在模块分析前先列出「已有测试覆盖」摘要，帮助识别增量测试范围。
### 已有测试覆盖（来自 testlib）
> 仅当 `testspec/testlib/` 存在且包含与当前需求相关的模块时输出。无 testlib 时跳过此节。
| 模块 | 功能点 | 已有用例数 | 覆盖优先级 | 状态 |
| -------- | -------- | ---------- | ---------- | ------ |
| <模块名> | <功能点> | N | P1×a, P2×b | active |
**分析结论**：
- 已有覆盖可直接复用的功能点：<列表>
- 本次变更需新增覆盖的功能点：<列表>
- 已有用例可能受影响需回归的：<列表或"无">
### 模块 N：<模块名>
**功能描述**：<一句话>
**输入/输出**：
- 输入：<触发条件、数据>
- 输出：<系统响应、UI 变化>
**等价类分析**（若适用）：
| 条件 | 有效等价类 | 无效等价类 |
|------|-----------|-----------|
**边界值**（若适用）：
- <边界>：<临界值及预期>
**状态迁移**（若涉及状态切换）：
- <状态A> → <触发> → <状态B>
**业务规则**：
- <规则>
**风险点**：
- <可能出错的地方及原因>
**推荐设计技术**：
> 基于本模块的输入特征自动推荐，供 testspec-generate 参考选择。
- <技术1>：<推荐理由>
- <技术2>：<推荐理由>
选择参考：
- 有数值范围/长度限制 → 边界值分析 + 等价类划分
- 多条件相互依赖 → 判定表驱动
- 有工作流/状态序列 → 状态迁移法
- 多参数多取值组合（如系统×分辨率） → 配对组合测试（Pairwise）
- 完整用户场景 → 场景法
- 复杂逻辑依赖/权限交叉 → 错误推测法
## 非功能性关注点
- 性能 / 兼容性 / 安全 ...
## 阻塞澄清项
- [ ] <需与产品/开发确认的问题>
## 执行期动态跟进
- [ ] <测试执行中持续补充、不阻塞当前分析的问题>
完整模板与兼容说明见：
references/requirements-analysis-template.md../_testspec-shared/references/output-contracts.mdtestspec/changes/<name>/requirements-analysis.md