Help us learn about your current experience with the documentation. Take the survey.
GitLab 测试策略
核心原则
快速反馈 优先运行最相关的测试，追求速度——快速失败，快速修复。
渐进式测试 从窄到宽，逐步扩展。通过增量覆盖建立信心。
资源效率 每个测试都应该物有所值。没有重复，没有浪费。
明确所有权 每个测试套件都需要所有者。责任不明确会导致衰退。
测试稳定性 如果一个测试不能可靠地阻止合并、部署或发布，它就不应该存在。修复它或删除它。
测试套件放置指南
请参阅 testing levels 了解测试金字塔的详细信息，以及 pipeline tiers 了解合并请求流水线层级。
| 测试类型 | 目的 | 何时运行 | 阻断 |
|---|---|---|---|
| 单元测试 | 验证单个组件的独立性 | 所有 MR 流水线（第 1 层预测性，第 2 层+完整套件） | 是 |
| 集成测试 | 验证组件间的交互 | 第 2 层+ MR、稳定分支、部署 | 第 2 层+是 |
| 系统/功能测试 | 通过 UI 验证单个功能 | 第 2 层+ MR、稳定分支 | 第 2 层+是 |
| 端到端 (E2E) 测试 | 验证完整的关键用户旅程 | • 冒烟测试：部署流水线、功能标志切换 • 完整测试：第 3 层 MR、定时流水线 |
第 3 层是，冒烟测试阻断部署 |
流水线类型要求
合并请求流水线
| 层级 | 前端变更 | 后端变更 | 数据库变更 |
|---|---|---|---|
| 第 1 层 | 仅 Jest 预测性测试 | 仅 RSpec 预测性测试 | 迁移测试 + 预测性测试 |
| 第 2 层 | 完整 Jest 套件 + 选择性 E2E | 完整 RSpec 单元/集成测试 + 选择性 E2E | 完整测试套件 |
| 第 3 层 | 完整 Jest + E2E | 完整 RSpec + E2E | 完整套件 + E2E |
部署流水线
| 阶段 | 必需测试 | 阻断 |
|---|---|---|
| 预发布 | E2E 冒烟测试套件 | ✅ |
| 金丝雀 | E2E 冒烟测试套件 | ✅ |
| 生产 | 部署后冒烟测试 | ❌ |
稳定/安全分支
| 流水线类型 | 前端 | 后端 | 数据库 | E2E |
|---|---|---|---|---|
| 回溯 MR | 完整 Jest 套件 | 完整 RSpec 单元/集成测试 | 迁移、数据库模式检查 | Omnibus 和 GDK 上的完整套件 |
| 稳定/安全分支（合并后） | Jest 单元/集成测试 | RSpec 单元/集成/系统测试 | 迁移和后台迁移测试 | 无 |
开发工作流
添加新测试
测试类型选择 从可能的最低级别开始：单元 → 集成 → 系统 → E2E。
覆盖评估 编写新测试前先扫描现有测试。不要重复测试相同的内容。
套件放置 将测试匹配到正确的套件和阶段。遵循既定模式。
默认为阻断 新测试_默认为阻断_。非阻断测试是例外，而非规则。
修改流水线中的测试执行
左移 尽可能将测试移到流水线的前面。更快的反馈可以节省时间。
保持阻断状态 一旦测试在正确的阶段成为阻断，它就保持阻断状态。降级需要强有力的理由。
记录影响 对测试执行模式的每次更改都需要进行影响评估。不允许静默修改。
维护和监控
团队应建立定期实践来维护测试套件健康：
不稳定和隔离的测试 定期审查，立即修复或删除。详细信息请参阅 unhealthy tests。
测试套件健康 定期评估测试套件性能并识别冗余覆盖。