@chongyan/autospec 1.0.2 → 1.0.4

package/knowledge/03-guides/05-plan-testing.md

@@ -1,183 +0,0 @@
----
-name: test-planner
-description: 当进入QA测试阶段，需要制定测试方案、设计测试用例覆盖场景时触发。基于需求文档和代码实现规划测试策略。
-type: produce
----
-
-## 定位
-
-QA测试阶段专用技能。负责制定测试方案、设计端到端测试用例、规划边界条件和异常路径覆盖。
-
-## 输入
-
-- 必须输入：
-  - 需求文档（.autospec/specs/{feature}/requirement.md）- 提取验收标准
-  - 技术方案（.autospec/specs/{feature}/design.md）- 理解架构和接口
-  - 代码实现 - 理解实现细节
-  - 测试类型配置（config.json中的test命令）
-- 可选输入：
-  - 历史测试用例（可复用）
-  - 子系统配置（多系统项目的测试范围）
-
-## 输出
-
-```markdown
-## 测试方案
-
-### 测试范围
-- 功能范围：...
-- 边界范围：...
-- 不包括范围：...
-
-### 测试策略
-| 测试类型 | 方法 | 覆盖目标 | 优先级 |
-|----------|------|----------|--------|
-| 功能测试 | 逐条验证 | 100% 验收标准 | P0 |
-| 边界测试 | 极端值/异常输入 | 所有边界条件 | P1 |
-| 集成测试 | 端到端场景 | 核心用户场景 | P1 |
-| 兼容性测试 | 多环境验证 | 配置矩阵 | P2 |
-
-### 测试用例设计（示例）
-| 用例ID | 场景 | 输入 | 预期 | 优先级 | 类型 |
-|--------|------|------|------|--------|------|
-| TC001 | 正常创建 | ... | ... | P0 | 功能 |
-| TC002 | 边界值Max | ... | ... | P1 | 边界 |
-| TC003 | 空值处理 | null | 报错/默认值 | P0 | 异常 |
-
-### 关键假设验证计划
-- [ ] 假设X：在测试环境中验证...
-
-### 风险评估
-- **High Risk 区域**：...
-- **依赖项**：...
-- **环境限制**：...
-
-### 执行计划
-1. 准备测试数据（如果有）
-2. 执行优先级P0用例
-3. 执行P1/P2用例
-4. 探索性测试（30分钟）
-5. 生成测试报告
-```
-
-## 执行步骤
-
-### Step 1: 分析输入（确定性）
-
-1. 读取需求文档，提取所有验收标准
-2. 读取技术方案，识别关键接口和模块
-3. 检查 config.json：
-   - 确定项目类型（backend/frontend/ai）
-   - 读取测试命令配置
-   - 多系统项目记录各子系统的测试策略
-
-### Step 2: 设计测试策略（模型）
-
-基于输入分析设计测试策略：
-
-```
-决策逻辑：
-- API/后端项目 → 重点：接口测试 + 边界测试 + 并发测试
-- 前端项目 → 重点：E2E测试 + 兼容性测试 + 交互测试
-- AI/模型项目 → 重点：效果评测（另走evaluation-planner）
-- 数据管道 → 重点：数据完整性 + 转换逻辑 + 调度可靠性
-
-边界识别：
-- 数值边界：0, null, max, min, 溢出值
-- 集合边界：空列表、单元素、大量元素
-- 状态边界：初始态、终态、中间态转换
-- 并发边界：同时请求、资源竞争
-```
-
-### Step 3: 设计测试用例（模型）
-
-为每个验收标准设计测试用例：
-
-**原则**：
-- 每个验收标准至少1个正例
-- 每个边界条件至少1个边界测试
-- 预期结果必须可判定（pass/fail明确）
-
-**格式**：
-```
-用例ID: TC{三位数字}
-场景: {一句话描述}
-前置条件: {执行前必须满足的条件}
-输入: {具体输入值}
-预期: {期望输出或行为}
-优先级: P0/P1/P2
-类型: 功能/边界/异常/集成
-```
-
-### Step 4: 规划测试数据（确定性+模型）
-
-确定需要的测试数据：
-- 真实数据采样
-- 合成数据生成
-- Mock外部依赖
-
-### Step 5: 输出测试方案
-
-按格式输出完整的测试方案文档。
-
-## 反模式清单（DP7）
-
-1. **只测happy path**：遗漏边界和异常
-   - 检测：必须显式列出边界条件覆盖计划
-
-2. **用例不可执行**：描述模糊，无法判定结果
-   - 检测：每个用例的预期结果必须可判定
-
-3. **与需求脱节**：设计的用例不对应任何验收标准
-   - 检测：每个用例必须关联到需求的某条验收标准
-
-4. **过度测试**：在所有层重复测试同一逻辑
-   - 检测：明确测试分层，避免重复
-
-5. **忽略环境因素**：不考虑测试环境与生产的差异
-   - 检测：显式记录环境差异和应对策略
-
-## 适用场景与边界
-
-- **适用**：QA测试阶段开始、新功能需要测试方案、回归测试规划
-- **不适用**：单元测试设计（编码阶段已做）、纯探索性测试（无预设方案）
-- **前置**：代码实现完成、需求文档已审查通过
-- **后续**：test-generator（生成测试代码）或执行测试
-
-## 示例
-
-**输入**：
-```
-需求：用户收藏功能
-- 用户可以收藏商品
-- 取消收藏
-- 查看收藏列表（分页）
-- 最多收藏1000个商品
-
-验收标准：
-1. 收藏成功后返回收藏ID
-2. 重复收藏返回已存在提示
-3. 分页每页20条，支持排序
-```
-
-**输出**：
-```markdown
-## 测试方案
-
-### 测试用例设计
-| 用例ID | 场景 | 输入 | 预期 | 优先级 | 关联标准 |
-|--------|------|------|------|--------|----------|
-| TC001 | 正常收藏 | userId=1, productId=100 | 返回收藏ID, 状态200 | P0 | 标准1 |
-| TC002 | 重复收藏 | 同一用户收藏同一商品 | 返回提示"已收藏", 状态409 | P0 | 标准2 |
-| TC003 | 已达上限 | 用户已有1000个收藏，再收藏 | 返回错误"收藏上限" | P0 | - |
-| TC004 | 分页默认 | userId=1, 无参数 | 返回20条, 按时间倒序 | P0 | 标准3 |
-| TC005 | 分页排序 | page=1, size=10, sort=price_asc | 返回10条, 按价格升序 | P1 | 标准3 |
-| TC006 | 取消收藏 | 传入收藏ID删除 | 删除成功, 再次查询不存在 | P0 | - |
-| TC007 | 取消不存在 | 收藏ID不存在 | 返回404或静默成功 | P1 | - |
-| TC008 | 边界：第1000个 | 在第999个基础上再添加 | 成功，计数=1000 | P1 | 边界 |
-| TC009 | 边界：第1001个 | 已有1000个，再尝试添加 | 失败提示上限 | P1 | 边界 |
-
-### 关键假设验证
-- [ ] 假设：数据库事务保证收藏计数一致性
-  验证：并发场景下100个用户同时收藏，验证计数正确
-```

package/knowledge/03-guides/06-generate-tests.md

@@ -1,241 +0,0 @@
----
-name: test-generator
-description: 当需要系统化生成测试用例和测试代码以覆盖功能验证、边界条件和异常路径时触发
-type: produce
----
-
-## 定位
-测试阶段的核心"做"类skill。系统化生成测试用例，确保测试覆盖充分。用于研发自测和QA测试方案中的用例生成。
-
-## 输入
-- 必须输入：结构化需求文档（验收标准是测试用例的基础）、可运行代码
-- 可选输入：技术方案文档（理解设计意图和边界）、关键假设清单、现有测试代码（用于学习风格）
-
-## 输出
-
-### Step 0: 学习现有测试风格 + 加载环境知识（新增）
-
-在生成测试代码前，先分析项目现有的测试风格和加载环境知识：
-
-**a. 学习现有测试风格**：
-1. 调用 `test-context-analyzer` 分析现有测试代码
-2. 检测测试框架和工具（Jest、pytest、JUnit 等）
-3. 分析断言风格和组织结构
-4. 提取测试基础设施（setup/teardown、fixtures、mocks）
-5. 提取集成测试配置（环境启动方式、测试数据准备）
-6. 生成测试上下文报告（`.autospec/specs/{feature}/test-context.md`）
-
-**b. 加载环境知识中的集成测试最佳实践**：
-1. 读取 `.autospec/environment/registry.json` 获取活跃中间件
-2. 加载对应的 `integration/testing/{middleware}-testing.yaml`
-3. 提取可用的测试策略（testcontainer、mock 等）
-4. 提取测试模板和最佳实践
-
-**c. 生成测试代码时参考**：
-- 使用相同的测试框架和断言风格
-- 复用现有的测试基础设施
-- 应用环境知识中的集成测试最佳实践
-- 保持与现有测试代码风格一致
-
-**关键**：如果项目中已有测试代码，生成的测试必须与现有风格保持一致。
-
-### Step 1: 确定模式
-
-读取 `.autospec/config.json`，检查 `subsystems` 字段：
-- **无 subsystems 或长度为1** → 单系统模式
-- **有 subsystems 且长度>1** → 多系统模式
-
-检查是否需要效果评测：
-- 有 `type: ai` 的子系统或 `needsEvaluation: true` → 需要效果评测开发
-- 需求文档包含效果相关指标 → 需要效果评测开发
-
-### 单系统模式（普通功能）
-- 测试用例列表（含场景描述、步骤、预期结果）
-- 测试代码（单元测试、集成测试）
-- 覆盖报告（哪些需求点被覆盖、哪些未覆盖）
-- **关键假设验证用例**（针对关键假设设计的专项测试）
-- **证据清单**（测试执行日志、覆盖率数据）
-- 产出文件：`test-report.md`
-
-### 多系统模式
-- **`tests/integration.md`** — 集成测试报告
-  - 跨系统测试场景
-  - 接口联调结果
-  - E2E测试结果
-- **`tests/{subsystem}.md`** — 各子系统测试报告
-  - 单元测试覆盖率
-  - 集成测试结果
-  - 发现的问题
-
-### 效果评测模式（AI/模型功能）
-- **`tests/evaluation/dataset/`** — 评测数据集
-- **`tests/evaluation/evaluator.py`** — 评测脚本
-- **`tests/evaluation-report.md`** — 评测报告
-
-## 执行步骤
-
-### Step 2: 单系统模式（普通功能）
-
-1. 逐条对照需求文档的验收标准，生成正向测试用例
-   - 预期产出：每条验收标准至少一个测试用例
-   - 失败处理：验收标准不明确则标记，不自行假设
-2. 分析每条功能需求的边界条件，生成边界测试用例
-3. 识别异常路径（无效输入、超时、并发等），生成异常测试用例
-4. **针对关键假设设计验证用例**（验证假设是否在代码中正确体现）
-5. 将测试用例转化为可执行的测试代码
-6. 运行测试，确认用例本身无错误
-7. 生成覆盖报告，标注需求覆盖情况和假设验证情况
-
-### Step 3: 多系统模式
-
-1. **各子系统测试**：
-   ```
-   for subsystem in config.subsystems:
-     a. 运行 {subsystem.test}
-     b. 收集测试结果
-     c. 产出 tests/{subsystem.name}.md
-   ```
-
-2. **集成测试**（增强）：
-   a. 读取 `design/overview.md` 中的系统交互定义
-   b. **读取环境知识中的集成测试最佳实践**：
-      - 加载活跃中间件的测试知识（如 `mysql-testing.yaml`）
-      - 选择合适的测试策略（testcontainer、mock、docker-compose）
-      - 参考测试模板（`api-test.template.js`、`e2e-test.template.js`）
-   c. **生成集成测试代码**：
-      - 使用 Step 0 中学习的测试风格
-      - 应用环境知识中的测试策略模板
-      - 复用现有的测试基础设施
-   d. 执行端到端测试
-   e. 产出 `tests/integration.md`
-
-3. **验收标准对照**：
-   - 逐条对照需求文档中的验收标准
-   - 确保每条标准都有对应测试覆盖
-
-### Step 4: 效果评测开发（AI/模型类功能）
-
-当项目包含 AI/模型 相关功能时，测试阶段需要额外开发：
-
-#### 4.1 评测需求分析
-
-1. 从需求文档中提取效果相关指标：
-   - 准确率、召回率、F1等（分类任务）
-   - BLEU、ROUGE等（生成任务）
-   - 任务完成率、响应质量（智能体）
-   - 业务效果指标（转化率、用户满意度等）
-
-2. 确定评测方法：
-   - 自动评测（有标注数据）
-   - 人工评测（需要评测人员）
-   - A/B测试（线上对比）
-   - LLM-as-Judge（用LLM评估LLM）
-
-#### 4.2 评测数据集构建
-
-1. 从需求中提取典型场景
-2. 构造正例和反例
-3. 标注预期结果
-4. 数据集格式：
-   - 输入数据
-   - 预期输出/行为
-   - 评测维度（可选）
-5. 写入 `tests/evaluation/dataset/`
-
-#### 4.3 评测脚本开发
-
-```python
-# tests/evaluation/evaluator.py 示例结构
-
-def load_dataset():
-    """加载评测数据集"""
-    pass
-
-def run_evaluation(model, dataset):
-    """执行评测"""
-    pass
-
-def calculate_metrics(results):
-    """计算效果指标"""
-    pass
-
-def generate_report(metrics, results):
-    """生成评测报告"""
-    pass
-
-if __name__ == "__main__":
-    dataset = load_dataset()
-    results = run_evaluation(model, dataset)
-    metrics = calculate_metrics(results)
-    report = generate_report(metrics, results)
-    print(report)
-```
-
-#### 4.4 智能体评测
-
-如果项目包含智能体（Agent）功能：
-
-1. **任务完成评测**：
-   - 定义评测任务集
-   - 执行任务并记录过程
-   - 判断任务是否成功完成
-   - 计算任务成功率
-
-2. **响应质量评测**：
-   - 使用LLM-as-Judge评估响应质量
-   - 或使用预设规则评估
-   - 评分维度：准确性、完整性、有用性
-
-3. **工具使用评测**：
-   - 验证工具调用是否正确
-   - 验证参数传递是否正确
-   - 计算工具使用成功率
-
-#### 4.5 数据系统测试
-
-如果项目包含数据系统（data类型）：
-
-1. **数据质量测试**：
-   - 完整性检查（空值、缺失记录）
-   - 一致性检查（跨表关联、业务规则）
-   - 准确性检查（数据范围、格式校验）
-
-2. **ETL流程测试**：
-   - 数据转换正确性
-   - 增量更新正确性
-   - 异常数据处理
-
-3. **性能测试**：
-   - 大数据量处理能力
-   - 查询性能
-
-#### 4.6 评测报告生成
-
-产出 `tests/evaluation-report.md`，包含：
-- 评测概述（评测方法、数据集规模）
-- 效果指标结果
-- 与基线/目标对比
-- Badcase分析（失败案例及原因）
-- 改进建议
-
-## 反模式清单（DP7）
-1. **只测happy path**：不测边界和异常。检测：覆盖报告必须包含边界和异常用例
-2. **测试与需求脱节**：测了很多但没对照验收标准。检测：每条用例必须关联到具体验收标准
-3. **测试代码有bug**：测试本身逻辑有误导致假通过。检测：运行测试并review测试逻辑
-4. **假设验证遗漏**：不验证关键假设。检测：关键假设清单中每条必须有对应测试
-5. **过度mock**：mock掉了真正需要测试的部分。检测：集成测试不mock核心业务逻辑
-6. **跳过效果评测**：AI/模型功能不开发评测。检测：ml类型子系统必须有评测代码和报告
-7. **评测数据不真实**：评测数据过于简单或不具代表性。检测：评测数据需覆盖典型场景和边界
-8. **忽略现有测试风格**：生成的测试与项目现有风格不一致。检测：必须先执行 Step 0 学习现有风格
-9. **不复用测试基础设施**：重复创建 setup/teardown 而非复用现有配置。检测：检查是否复用了现有 fixtures/mocks
-10. **忽略环境知识**：不使用已定义的测试最佳实践。检测：必须加载环境知识中的测试配置
-
-## 适用场景与边界
-- 适用：需要系统化生成测试用例的场景
-- 不适用：探索性测试（那是quality角色的exploratory-tester）；性能测试（需专门skill）
-- 边界：生成用例和代码，不判断覆盖是否充分（那是test-reviewer的事）
-- 前置：code-implementer完成编码
-- 后续：test-reviewer审查测试充分性
-
-## 示例
-（待从实践中积累第一个完整示例）

package/knowledge/03-guides/07-check-release.md

@@ -1,205 +0,0 @@
----
-name: release-checker
-description: 当代码准备部署到生产环境、需要逐项检查所有发布前置条件是否满足时触发
-type: review
----
-
-## 定位
-交付阶段的"审"类skill。发布前的最后一道关卡，确保所有前置条件就绪，不带病上线。
-
-## 输入
-- 必须输入：QA测试报告、回滚方案
-- 可选输入：变更记录、methodology/checklists/release.md（检查标准）、关键假设清单（全链路）
-
-## 评判标准
-
-### 必须满足（所有模式）
-- [ ] QA测试报告结论为通过
-- [ ] 无未解决的Critical/Major级别缺陷
-- [ ] 回滚方案已准备并验证可行
-- [ ] 变更记录已编写
-- [ ] 数据库变更（如有）已review并有回滚脚本
-- [ ] 配置变更（如有）已确认
-- [ ] 关键假设全链路已验证
-
-### 多系统模式额外检查
-- [ ] 各子系统变更已确认
-- [ ] 跨系统接口变更已同步
-- [ ] 部署顺序已确定（通常：后端→前端→移动端；有ml时：模型服务可能需要先部署）
-
-### AI/模型功能额外检查
-- [ ] 效果评测已完成
-- [ ] 效果指标达到基线要求
-- [ ] 评测报告已产出
-- [ ] Badcase已分析和处理
-
-### 数据系统额外检查
-- [ ] 数据质量检查通过
-- [ ] ETL流程验证通过
-- [ ] 数据回滚方案已准备
-
-### 必须满足（高可用）
-- [ ] 应急开关/降级方案已准备（限流、降级、熔断）
-- [ ] 关键业务指标监控已配置（不仅技术指标，也含业务指标）
-- [ ] 资损点已识别并有针对性保障措施（如涉及资金）
-
-### 建议满足
-- [ ] 相关方已通知
-- [ ] 监控告警已配置或确认（含业务趋势波动监控）
-- [ ] 灰度/分批发布策略已确定（如适用）
-- [ ] 遗留风险已记录并经确认可接受
-- [ ] 发布时间窗口合适
-- [ ] 容量评估已完成（压测数据支撑）
-- [ ] 变更回滚预案已演练验证
-
-## 评审步骤
-
-### Step 1: 确定模式
-
-读取 `.autospec/config.json`，检查 `subsystems` 字段：
-- **无 subsystems 或长度为1** → 单系统模式
-- **有 subsystems 且长度>1** → 多系统模式
-
-检查是否需要效果验收：
-- 有 `type: ai` 的子系统或 `needsEvaluation: true` → 需要效果验收
-
-### Step 2: 单系统模式
-
-1. 检查QA测试报告状态和结论
-   - 证据获取：直接引用测试报告结论
-2. 检查是否有未关闭的blocking缺陷
-3. 检查回滚方案是否存在且可行
-   - 证据获取：回滚方案的具体步骤和预计耗时
-4. 检查变更记录是否完整
-5. 检查数据库和配置变更（如适用）
-6. 检查宪法门禁（不可违反红线）
-7. 检查通知和监控准备
-8. **检查关键假设全链路验证状态**
-9. **影响分析**：
-   - 分析任务依赖的表/接口
-   - 查询这些依赖被哪些下游使用
-   - 评估影响范围和风险
-   - 输出影响分析报告
-10. 汇总遗留风险
-11. 逐项输出判定结果，**每项附具体证据**
-
-### Step 3: 多系统模式
-
-1. **各子系统发布检查**：
-   ```
-   for subsystem in config.subsystems:
-     a. 检查 {subsystem.path} 变更内容
-     b. 确认 {subsystem.build} 成功
-     c. 确认 {subsystem.test} 通过
-     d. 检查依赖版本
-     e. 记录发布项
-   ```
-
-2. **跨系统一致性检查**：
-   - 确认跨系统接口变更已同步
-   - 确认部署顺序合理
-
-3. **汇总检查结果**
-
-### Step 4: 效果验收（AI/模型功能）
-
-当项目包含 AI/模型 相关功能时，需要额外验收：
-
-1. **检查评测报告**：
-   - 评测数据集是否覆盖典型场景
-   - 效果指标是否达到设计阶段定义的基线
-   - Badcase是否已分析和处理
-
-2. **效果指标验收**：
-   - 核心效果指标是否达标
-   - 业务效果指标是否达标（如有）
-   - 未达标指标是否有改进计划
-
-3. **智能体验收**（如适用）：
-   - 任务完成率是否达标
-   - 响应质量是否达标
-   - 工具使用正确率是否达标
-
-4. **产出验收结论**：
-   - 通过：效果达标，可发布
-   - 有风险：效果部分达标，需确认是否接受
-   - 不通过：效果未达标，阻止发布
-
-### Step 5: 数据系统验收
-
-当项目包含数据系统时：
-
-1. **数据质量验收**：
-   - 数据完整性检查结果
-   - 数据一致性检查结果
-   - 数据准确性检查结果
-
-2. **ETL流程验收**：
-   - 数据转换正确性
-   - 性能是否满足要求
-
-3. **数据回滚方案验收**：
-   - 回滚脚本是否准备
-   - 回滚是否可执行
-
-## 输出格式
-
-```
-## 审查结论：可发布 / 不可发布 / 有风险需确认
-
-### 逐项判定
-| 检查项 | 结论 | 证据 | 备注 |
-|--------|------|------|------|
-| QA测试通过 | ✅/❌ | {报告引用} | |
-| 回滚方案就绪 | ✅/❌ | {方案摘要} | {预计回滚耗时} |
-| ... | ... | ... | ... |
-
-### 多系统模式额外项
-| 子系统 | 类型 | 构建 | 测试 | 变更内容 |
-|--------|------|------|------|----------|
-| backend | 后端 | ✅/❌ | ✅/❌ | ... |
-| frontend | 前端 | ✅/❌ | ✅/❌ | ... |
-| ai | AI/模型 | - | ✅/❌ | ... |
-
-### 效果验收（如适用）
-| 指标 | 基线 | 实际 | 结论 |
-|------|------|------|------|
-| 准确率 | ≥90% | 92% | ✅达标 |
-| 召回率 | ≥85% | 83% | ❌未达标 |
-| ... | ... | ... | ... |
-
-### 阻塞项（如不可发布）
-- {具体阻塞原因} → {解决建议}
-
-### 遗留风险汇总
-- {风险描述} / 影响范围 / 建议处理方式（需人工确认可接受）
-
-### 关键假设最终状态
-- 假设X：已验证通过 / 未验证（风险：...）
-
-### 不可逆动作清单（需人工确认）
-- [ ] 数据库迁移：{描述}
-- [ ] 配置变更：{描述}
-- [ ] 外部API调用：{描述}
-- [ ] 模型部署：{描述}（AI/模型功能）
-
-### 部署方案（多系统模式）
-- 部署顺序：{子系统顺序}
-- 依赖关系：{描述}
-- 回滚计划：{描述}
-```
-
-## 反模式清单（DP7）
-1. **带病上线**：有已知blocking问题但放行。检测：blocking缺陷存在则必须判不可发布
-2. **回滚方案缺失**：忽略回滚方案检查。检测：回滚方案是必选项，不可跳过
-3. **环境差异忽视**：不检查测试/生产环境差异。检测：前置检查包含环境一致性
-4. **不可逆动作放行**：未标记需要人工确认的不可逆动作。检测：输出必须包含不可逆动作清单
-5. **跳过效果验收**：AI/模型功能不验收效果就发布。检测：ml类型子系统必须有效果验收结论
-6. **效果不达标放行**：效果未达标但无改进计划就发布。检测：效果不达标必须有明确的改进计划或人工确认接受
-
-## 适用场景与边界
-- 适用：所有准备发布到生产环境的部署
-- 不适用：开发/测试环境的部署（标准可降低）
-
-## 示例
-（待从实践中积累第一个完整示例）