搭建 CI/CD 流水线不难，难的是让它真正拦得住问题。不少团队的流水线只做了"编译通过就部署"，测试环节形同虚设；也有团队走向另一个极端，把所有测试一股脑塞进同一个阶段，结果每次提交要等四十分钟才有反馈，开发者干脆养成了"先提交再说"的习惯。持续测试的关键，在于分层设计与合理的反馈节奏。 第一层是提交阶段，目标是五分钟内给出反馈。这一层只跑单元测试和静态代码分析。单元测试针对函数、方法等最小可测单元，运行速度必须足够快；静态分析负责捕捉空指针风险、资源未释放、圈复杂度超标等问题。这一层的质量门禁通常包括单元测试全部通过、增量代码覆盖率不低于既定阈值、不引入新的严重级别静态告警。 第二层是构建与集成阶段。代码合入主干后触发，运行集成测试、契约测试和安全扫描。集成测试验证模块之间的接口协作是否符合预期；契约测试在微服务架构下尤为重要，它能在服务提供方修改接口时立刻发现下游消费方会被打破，避免联调阶段才暴露问题；安全扫描则覆盖 SAST 与依赖组件的成分分析。这一层可以接受十到二十分钟的执行时长。 第三层是预发布阶段，进行端到端测试、性能压测和兼容性验证。端到端测试从用户视角走通核心业务流程，数量要严格控制——这类用例执行慢、稳定性差，只应覆盖最关键的黄金链路。性能压测对照既定基线，若 P99 延迟劣化超过设定比例则阻断发布。兼容性验证覆盖主流浏览器与设备型号。 除了向左的门禁，测试右扩同样重要。灰度发布配合实时监控、生产环境的合成监控拨测、基于真实流量的影子测试，都能在问题影响面扩大前及时发现。发布之后的可观测性，本质上是持续测试在生产环境的延伸。 在嵌入式和硬件相关领域，这套体系同样成立，只是需要额外引入硬件在环（HIL）测试节点，用模拟器覆盖大部分场景，把真机验证收敛到关键回归集上，以平衡执行效率与真实性。 最后是几条容易被忽略的实践细节：测试用例必须能并行执行且互不干扰，否则扩容加机器也提不了速；flaky 用例要建立专门看板并限期修复，随手重跑一次通过就当没事，会迅速摧毁团队对流水线的信任；门禁阈值需要定期复盘调整，长期不变的指标会逐渐失去约束力。 流水线的价值不在于跑得多全，而在于让开发者相信：只要它是绿的，代码就可以放心发出去。