@chongyan/autospec 1.0.1 → 1.0.3

package/knowledge/guides/stages/test-context-analyzer.md

@@ -1,250 +0,0 @@
----
-name: test-context-analyzer
-description: 在生成测试代码前，分析项目现有测试代码的风格和模式，提取可复用的测试基础设施
-type: produce
----
-
-## 定位
-
-测试阶段的前置技能。分析现有测试代码，提取风格、模式、基础设施，供 test-generator 使用。
-
-## 输入
-
-- 必须输入：
-  - 项目源码目录（包含现有测试代码）
-  - config.json 中的测试配置
-- 可选输入：
-  - 环境知识中的测试最佳实践
-
-## 输出
-
-- 测试风格分析报告（写入 `.autospec/specs/{feature}/test-context.md`）
-
-## 执行步骤
-
-### Step 1: 检测测试框架和工具
-
-1. 检查依赖文件：
-   - **Node.js**: `package.json` 的 devDependencies
-   - **Python**: `requirements.txt` 或 `pyproject.toml`
-   - **Java**: `pom.xml` 或 `build.gradle`
-   - **Go**: `go.mod`
-
-2. 识别测试框架：
-
-| 框架类型 | 常见选择 |
-|---------|---------|
-| 单元测试 | Jest, Mocha, pytest, JUnit, TestNG, Go testing |
-| E2E测试 | Cypress, Playwright, Selenium, Puppeteer |
-| API测试 | Supertest, REST-assured, httpx |
-| Mock工具 | Sinon, unittest.mock, Mockito, testify |
-
-3. 检测测试相关配置：
-   - Jest: `jest.config.js`, `jest.setup.js`
-   - pytest: `pytest.ini`, `conftest.py`
-   - Maven: `surefire` 插件配置
-
-### Step 2: 分析测试代码风格
-
-扫描现有测试文件（`tests/`, `__tests__/`, `test/`, `src/**/*.test.*`, `*_test.py` 等）：
-
-1. **命名规范**：
-   - 文件命名：`*.test.js`, `*.spec.ts`, `*_test.py`, `*Test.java`
-   - 函数命名：`describe/it`, `test_`, `@Test`
-
-2. **断言风格**：
-   - Jest: `expect().toBe()`, `expect().toEqual()`
-   - Mocha + Chai: `expect().to.equal()`, `should.equal()`
-   - pytest: `assert x == y`
-   - JUnit: `assertEquals()`, `assertThat()`
-
-3. **组织结构**：
-   - `describe/it` 嵌套层级
-   - `beforeEach/afterEach` 使用模式
-   - `fixture` 文件组织方式
-
-### Step 3: 提取测试基础设施
-
-1. **Setup/Teardown**：
-   - 全局 setup 文件位置和内容
-   - `beforeAll/beforeEach` 中的初始化逻辑
-   - 数据库连接、Mock 初始化
-
-2. **Mock 配置**：
-   - Mock 文件位置（`__mocks__/`, `mocks/`, `fixtures/`）
-   - Mock 策略（自动 mock vs 手动 mock）
-   - 常用 Mock 模式
-
-3. **测试数据**：
-   - Fixtures 目录结构
-   - Factory 模式使用
-   - 测试数据准备脚本
-
-### Step 4: 提取集成测试配置（关键）
-
-1. **环境启动方式**：
-   - `docker-compose.yml` 的使用
-   - `npm scripts` 中的测试环境命令
-   - `Makefile` 中的测试目标
-
-2. **依赖服务配置**：
-   - 测试数据库配置（连接字符串、数据库名）
-   - 测试 Redis 配置
-   - Mock 服务配置
-
-3. **测试数据准备**：
-   - Seed 脚本位置
-   - 测试数据文件
-   - 数据清理策略
-
-### Step 5: 加载环境知识中的测试最佳实践
-
-1. 读取 `.autospec/environment/registry.json` 获取活跃中间件
-2. 加载对应的 `integration/testing/{middleware}-testing.yaml`
-3. 提取可用的测试策略和模板
-
-### Step 6: 输出测试上下文
-
-生成 `.autospec/specs/{feature}/test-context.md`：
-
-```markdown
-## 测试风格分析
-
-### 测试框架
-- 单元测试: Jest
-- E2E测试: Cypress
-- Mock工具: Sinon
-
-### 断言风格
-- 使用 `expect().toBe()` 风格
-- 异步测试使用 `async/await`
-
-### 测试基础设施
-- Setup: `jest.setup.js`
-- Fixtures: `tests/fixtures/`
-- Mocks: `__mocks__/`
-
-### 集成测试配置
-- 环境启动: `docker-compose -f docker-compose.test.yml up -d`
-- 数据库: 使用测试数据库 `test_db`
-- 数据准备: `npm run test:seed`
-
-### 环境知识最佳实践
-- MySQL: 使用 testcontainer 策略
-- Redis: 使用 mock 策略
-
-### 复用建议
-- 新测试文件放在 `tests/` 目录
-- 使用现有的 `testUtils.ts` 工具函数
-- 集成测试复用 `docker-compose.test.yml`
-- 参考 `mysql-testing.yaml` 生成数据库测试
-```
-
-## 检测模式
-
-### Node.js 项目检测
-
-```javascript
-// 检测 package.json
-const pkg = require('./package.json');
-const devDeps = pkg.devDependencies || {};
-
-// 检测测试框架
-const frameworks = {
-  jest: devDeps.jest ? 'Jest' : null,
-  mocha: devDeps.mocha ? 'Mocha' : null,
-  vitest: devDeps.vitest ? 'Vitest' : null,
-  cypress: devDeps.cypress ? 'Cypress' : null,
-  playwright: devDeps['@playwright/test'] ? 'Playwright' : null,
-};
-
-// 检测测试命令
-const testScript = pkg.scripts?.test;
-const testSetup = pkg.scripts?.['test:setup'];
-const testTeardown = pkg.scripts?.['test:teardown'];
-```
-
-### Python 项目检测
-
-```python
-# 检测 requirements.txt 或 pyproject.toml
-# 常见测试框架：
-# - pytest
-# - unittest
-# - nose2
-
-# 检测配置文件
-# - pytest.ini
-# - conftest.py
-# - setup.cfg
-```
-
-### 测试文件扫描
-
-```
-扫描目录：
-- tests/
-- test/
-- __tests__/
-- src/**/*.test.{js,ts}
-- src/**/*.spec.{js,ts}
-- **/*_test.py
-- **/test_*.py
-- src/test/**/*Test.java
-```
-
-## 反模式清单（DP7）
-
-1. **忽略现有测试风格**：生成与项目风格不一致的测试
-   - 检测：必须先分析现有测试再生成
-
-2. **不复用基础设施**：重复创建 setup/teardown
-   - 检测：必须检查并复用现有配置
-
-3. **忽略环境知识**：不使用已定义的测试最佳实践
-   - 检测：必须加载环境知识中的测试配置
-
-## 适用场景与边界
-
-- **适用**：测试阶段开始前、需要生成与现有代码风格一致的测试
-- **不适用**：全新项目（无现有测试代码）
-- **前置**：项目有测试代码或环境知识
-- **后续**：test-generator 使用分析结果生成测试
-
-## 示例
-
-**输入**：一个使用 Jest + MySQL 的 Node.js 项目
-
-**输出**：
-
-```markdown
-## 测试风格分析
-
-### 测试框架
-- 单元测试: Jest v29
-- API测试: Supertest
-
-### 断言风格
-- 使用 `expect().toBe()` 风格
-- 异步测试使用 `async/await` + `resolves/rejects`
-
-### 测试基础设施
-- Setup: `jest.setup.js` - 初始化测试数据库
-- Fixtures: `tests/fixtures/` - JSON 格式测试数据
-- Mocks: `__mocks__/` - 手动 mock 外部服务
-
-### 集成测试配置
-- 环境启动: `npm run test:setup` (docker-compose)
-- 数据库: MySQL testcontainer
-- 数据准备: `tests/seed.ts`
-
-### 环境知识最佳实践
-- MySQL: 项目使用 testcontainer 策略
-- 参考 `mysql-testing.yaml` 中的模板
-
-### 复用建议
-1. 新测试文件放在 `tests/` 目录，命名为 `*.test.ts`
-2. 使用 `tests/utils/testDb.ts` 创建测试数据库连接
-3. 使用 `tests/fixtures/` 中的测试数据
-4. 参考 `tests/api/users.test.ts` 的测试结构
-```

package/knowledge/guides/stages/test-generator.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/guides/stages/test-planner.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个用户同时收藏，验证计数正确
-```