---

name: auto-test-project description: | 项目级质量审查与测试优化技能：从项目结构、关键模块、配置、构建、测试、文档和安全边界进行系统性质量审查。 输出问题清单、修复计划、验证证据和质量门禁结论，适合发版前检查、跨模块风险排查和持续质量改进。 author: "Bensz Conan" license: "MIT" category: "debugging" tags: "项目测试, 质量审查, 跨模块分析, 测试计划" source: "https://github.com/huangwb8/skills/tree/main/auto-test-project" allowed-tools: "glob, read_file, search_file_content, write_file, replace, run_shell_command, ask_user_question"

Auto Test Project：项目级质量审查与测试优化

适用场景

适用于以下任务：

• 测试整个项目或做项目级自检
• 系统化发现跨模块、跨配置、跨构建链路的问题
• 为项目建立问题清单、修复计划、验证报告和质量门禁
• 审查项目是否达到合并、发版、交付或资源市场发布标准
• 对多轮质量改进进行计划、执行、验证和复盘

不适用场景

• 用户只要求修改某个单点功能，应直接处理该功能
• 用户只问项目结构或某段代码含义，应直接解释
• 项目来源不可信且用户要求运行未知脚本；此时默认只读审查
• 用户要求大规模重构但没有明确目标；先收敛范围，不要扩大工程

核心原则

• 项目视角：关注模块边界、数据流、配置流、构建链路和用户可见行为
• 批判性审查：优先找真实痛点和系统性风险，不用风格问题凑数
• 可追溯：问题、修复和验证必须能从文件、命令、测试或文档中找到证据
• 隔离产物：计划、报告和临时日志写入临时工作区，不污染源码结构
• 不破坏现有用户：任何公共 API、配置、数据格式、路由和交互行为变更都要评估兼容性

输入要求

必须确认：

参数	说明
project_root	项目根目录
goal	本轮目标：质量审查、发版前检查、安全审查、测试补齐等
rounds	审查轮数，默认 1；用户指定时按要求执行
focus	可选：架构、测试、安全、性能、配置、文档、构建部署
output_dir	可选，默认 tmp/run_<timestamp>/tests/

如果项目根目录或目标不明确，先询问用户。

工作流程

1. 项目初始化

识别项目类型和边界：

• 语言与框架：读取配置、依赖清单、入口文件
• 模块结构：识别源码、测试、文档、脚本、配置、构建产物
• 关键路径：定位用户入口、核心业务、数据存储、外部接口和权限边界
• 测试能力：查找已有测试命令、CI 配置、类型检查和构建命令

排除依赖目录、构建产物、缓存目录、历史测试产物和大型二进制文件。

2. A 轮项目级审查

每轮从当前项目状态独立审查，不依赖旧结论。

重点维度：

维度	检查点
架构	模块边界是否清晰，依赖方向是否合理，是否有重复状态
数据流	数据从输入到存储/输出是否一致，是否有遗漏同步路径
配置	默认值、环境变量、示例配置和运行时读取是否一致
构建	构建脚本、平台差异、打包产物、绝对路径和缓存策略
测试	单元、集成、端到端、回归和失败路径覆盖
安全	认证授权、输入校验、文件访问、命令执行、敏感信息处理
兼容性	是否破坏旧数据、旧配置、旧 API 或现有用户行为
文档	README、示例、变更说明是否与实际行为一致

问题分级：

• P0：阻塞运行、可利用安全问题、数据损坏、权限绕过、发版必炸、严重兼容性破坏
• P1：跨模块逻辑缺口、测试覆盖不足、配置漂移、性能风险、重要文档误导
• P2：局部可读性、文档补充、低风险清理和后续优化

每个 P0/P1 问题必须包含根因分析：

### P1-1：问题标题

- 位置：`文件:行号` 或 `目录/模块`
- 涉及模块：...
- 现象：...
- 根因：...
- 影响：...
- 修复建议：...
- 验证方式：...

3. 生成修复计划

计划按 P0 → P1 → P2 排序，并说明：

• 本轮必须修复什么
• 哪些问题只记录不修复及原因
• 每项修复的最小改动边界
• 预期验证命令或手工验证步骤
• 可能影响的用户行为和兼容性风险

4. 执行修复

执行时遵守：

• 不做无关重构
• 不引入未验证的新依赖
• 不把临时产物写入源码目录
• 不自动执行陌生脚本或外部发布流程
• 不覆盖用户未提交或不属于本轮目标的改动

如发现项目已有多人协作或未提交变更，先用 Git 状态确认边界，只提交本轮改动。

5. 验证

按项目实际能力选择最小充分验证：

1. 相关单元测试或集成测试
2. 类型检查、lint、构建
3. 安全/依赖/配置检查
4. 关键链路手工验证
5. 无法运行时，记录原因和替代验证

验证报告必须写明：

• 实际运行了什么命令
• 结果是通过、失败还是跳过
• 失败输出的关键摘要
• 哪些需求仍未被验证

6. B 轮质量门禁

完成 A 轮修复后，做一次收尾质量门禁：

门禁	检查点
P0/P1 闭环	高优先级问题是否修复或有明确阻塞理由
回归风险	修复是否引入新破坏
配置一致性	示例、默认值、运行时读取是否一致
文档一致性	用户文档是否反映实际行为
测试证据	关键结论是否有命令或手工证据
产物隔离	临时计划、日志、报告是否没有污染源码

输出格式

默认输出项目级报告：

## 结论

- 建议：通过 / 修复后通过 / 继续修复 / 暂缓发布 / 不建议合并
- 风险等级：Low / Medium / High / Critical
- 核心原因：...

## 审查范围

## 项目结构与关键路径

## 问题清单

## 修复计划

## 已执行修复

## 验证证据

## 质量门禁结果

## 遗留问题与下一步

如用户要求写文件，默认写入 tmp/run_<timestamp>/tests/；最终报告可按用户要求复制到项目根目录。

完成标准

• P0 已全部修复或明确建议停止
• P1 已修复或有清楚的不修复理由
• 验证覆盖本轮关键改动和主要风险
• 没有污染源码目录的临时产物
• 结论足以支持用户决定是否继续开发、合并或发布