CI与CD中的测试差异及CI测试时机、失败处理疑问

1. CI测试的执行时机与失败回滚问题 #

CI测试的执行时机分两种主流场景，对应不同的协作工作流：

• 预集成阶段（代码合并前）：这是当前PR/MR工作流的标准操作。开发者提交代码变更发起合并请求后，CI工具自动触发测试套件，在代码合并到主分支前验证其正确性。只有测试全部通过，才允许合并到主分支——这是为了提前拦截有问题的代码，避免污染稳定分支，防止回归问题。
• 集成后阶段（代码合并后）：这是早期CI的模式，先将代码合并到主分支再执行测试。但这种方式风险极高，一旦测试失败，主分支已被污染，现在几乎被预集成测试取代。你看到的图示可能是这种旧模式，或是混淆了“CI流水线拉取分支代码”与“合并到主分支”的概念——很多CI流水线会先拉取待合并的分支代码（未合并）执行测试，这一步也可被描述为“版本控制之后”，但本质仍是预合并验证。

关于测试失败的回滚：

• 若为预集成阶段测试失败：代码不会被合并，无需回滚，开发者需修复问题后重新提交合并请求。
• 若为合并后测试失败：此时需执行回滚，比如用git revert撤销合并提交，或快速提交修复补丁。但这种情况应通过预集成测试尽量避免。

2. CI与CD阶段测试的核心区别 #

CI和CD阶段的测试目标、类型与范围差异明显：

CI阶段测试 #

核心目标是验证代码变更的正确性与兼容性，确保新代码能和现有代码正常协作，快速反馈问题。主要包含：

• 单元测试：验证单个函数/模块的逻辑正确性
• 集成测试：验证模块间的交互逻辑
• 静态代码分析：检查代码规范、潜在bug
• 轻量UI测试（前端项目）
  这类测试执行速度快，能在数分钟内给出结果，方便开发者快速迭代修复。

CD阶段测试 #

核心目标是验证应用在类生产/生产环境中的可用性与稳定性，确保版本可安全交付给用户。主要包含：

• 系统测试：验证整个应用的端到端功能流程
• 性能测试：评估高负载下的响应速度与稳定性
• 安全测试：扫描漏洞、验证权限控制逻辑
• 验收测试（UAT）：模拟用户场景验证业务需求
• 部署后冒烟测试：确认部署成功后核心功能可用
  这类测试耗时更长，环境更接近生产，目的是确保交付的版本成熟可用。

内容的提问来源于stack exchange，提问作者mentalmushroom