01 · 测试体系总览
测试在企业项目中的定位
测试模块的本质是质量信息的生产者和传递者。它在企业项目生命周期中承担三大职责：
- 向上游要求清晰输入 — 不接受模糊需求、不接受没有自测的提测
- 向下游提供可信输出 — 报告要有数据支撑、结论要有风险量化
- 用规范和工具保证一致性 — 模板化、流程化、门禁化
整体架构：三层设计
┌─────────────────────────────────────────────────┐
│ Layer 1: 能力抽象层（What） │
│ 定义"测试需要什么能力"，不绑定具体工具 │
├─────────────────────────────────────────────────┤
│ Layer 2: 工具适配层（With What） │
│ 每种能力提供 2-3 个常见工具的适配方案 │
├─────────────────────────────────────────────────┤
│ Layer 3: 平台兼容层（Where） │
│ 路径、命令、脚本支持 macOS/Windows/Linux │
└─────────────────────────────────────────────────┘
能力抽象层 — 10 种核心能力
| ID | 能力 | 测试阶段 | 必备 |
|---|---|---|---|
| C1 | 需求文档协作 | 需求分析 | ✅ |
| C2 | 代码仓库与变更追踪 | 提测、回归 | ✅ |
| C3 | API 契约定义与变更对比 | 用例设计 | ✅ |
| C4 | Bug/Issue 追踪 | 执行 | ✅ |
| C5 | 测试用例管理 | 设计、执行 | ✅ |
| C6 | 测试报告与知识沉淀 | 准出、复盘 | ✅ |
| C7 | CI/CD 流水线 | 提测验收 | 可选 |
| C8 | 监控与告警 | 线上验证 | 可选 |
| C9 | 自动化测试运行环境 | 执行 | 可选 |
| C10 | 即时通讯与通知 | 全流程 | 可选 |
工具适配层 — 能力到工具的映射
| 能力 | 推荐方案 | 备选方案 |
|---|---|---|
| C1 文档协作 | Markdown 文件（通用） | Confluence / GitLab Wiki / Notion |
| C2 代码仓库 | GitLab / GitHub | Gitea / Bitbucket |
| C3 API 契约 | Markdown 接口文档（推荐） | Postman / YApi / JSON Schema |
| C4 Bug 追踪 | GitLab/GitHub Issues | Jira / 禅道 / TAPD |
| C5 用例管理 | Markdown + Git（推荐） | TestRail / MeterSphere |
| C6 报告沉淀 | Markdown + Git | Confluence / Allure |
| C7 CI/CD | GitLab CI / Jenkins | GitHub Actions |
💡 核心思想：无论上层用什么工具，最终都落到 Markdown 格式作为中间层。Markdown 是最稳定、最通用、最易迁移的。
平台兼容层
| 平台 | 优先级 | 说明 |
|---|---|---|
| macOS | Phase 1 | 当前优先支持 |
| Linux | Phase 2 | 与 macOS 差异较小 |
| Windows | Phase 3 | 需 PowerShell 脚本适配 |
详见 platforms/ 目录。
下一步阅读
- 02-lifecycle — 测试的六阶段生命周期
- 03-roles-contracts — 与产品/开发/运维的协作契约
- 04-gates — 每个阶段的门禁标准（含提测达标）