1. 环境工程概述：测试环境定义、环境工程目标、环境在研发流程中的位置、常见环境类型

大家好，我是这门课的主讲。咱们直接进入正题。

做测试这么多年，我见过太多团队在环境上栽跟头。有的项目代码写得漂亮，结果一部署就崩。有的上线前测试全绿，生产环境却炸了。问题出在哪？

说白了，环境工程没做好。

这一章，咱们先把基础打牢。搞清楚测试环境到底是什么，环境工程要解决什么问题，以及它在整个研发流程里扮演什么角色。

1.1 测试环境的定义

测试环境，不是一台机器，也不是一个IP地址。

它是一个完整的、可运行的软件栈副本。包括操作系统、中间件、数据库、配置、网络策略，以及被测应用本身。

我个人的理解是：测试环境 = 基础设施 + 应用部署 + 数据 + 配置。

你想想看，如果测试环境和生产环境差了十万八千里，那测试结果还有什么参考价值？

1.2 环境工程的目标

环境工程不是简单的“装个机器，部署一下”。它有四个核心目标：

1. 稳定性：环境不能三天两头挂掉。我记得有一次，测试环境每天下午四点准时宕机，查了三天才发现是定时任务把磁盘写满了。
2. 一致性：开发、测试、预发、生产，四套环境要尽量保持一致。差一个JDK小版本，都可能引发诡异问题。
3. 可复现性：测试发现一个bug，环境能随时回滚到那个状态去复现。不能出现“刚才还能复现，重启一下没了”的情况。
4. 快速交付：环境准备时间不能成为研发瓶颈。我曾经见过一个团队，申请一套测试环境要等两周。这还怎么敏捷？

目标维度	关键指标	常见问题
稳定性	环境可用率 > 99.5%	磁盘写满、内存泄漏、依赖服务挂掉
一致性	配置差异项 < 5 个	JDK版本、数据库字符集、内核参数不同
可复现性	环境重建时间 < 30 分钟	数据被污染、配置被手动修改
快速交付	环境就绪时间 < 10 分钟	人工申请流程、资源争抢、依赖未就绪

1.3 环境在研发流程中的位置

环境不是孤立存在的。它嵌在研发流程的每个环节里。

咱们画个图，看看环境在整个流程中的位置：

从图上可以看得很清楚：

• 开发阶段：开发人员在开发环境写代码、做单元测试。
• 测试阶段：测试人员在测试环境做功能、集成、系统测试。
• 预发阶段：在预发环境做最后的验收和回归。
• 生产阶段：正式上线，服务用户。

每个阶段都依赖对应的环境。环境出问题，整个流程就卡住了。

1.4 常见环境类型

咱们详细说说四种常见环境。它们各有各的用途，也各有各的坑。

1.4.1 开发环境

开发人员写代码、调试用的。通常部署在本地或共享开发服务器上。

• 特点：配置灵活，可以频繁重启，日志全开。
• 数据：少量脱敏数据或Mock数据。
• 稳定性：要求不高，挂了就重启。

1.4.2 测试环境

测试人员执行测试用例用的。这是环境工程的主战场。

• 特点：需要稳定、独立、可复现。
• 数据：接近生产的数据量级，但经过脱敏。
• 稳定性：要求较高，不能频繁中断。

1.4.3 预发环境

也叫Staging环境。模拟生产环境，做上线前的最终验证。

• 特点：配置、架构、数据量级都和生产一致。
• 数据：全量脱敏数据，或者生产数据的子集。
• 稳定性：要求高，不能随意变更。

1.4.4 生产环境

正式服务用户的环境。这个不用多说，稳定压倒一切。

环境类型	使用者	数据要求	稳定性要求	变更频率
开发环境	开发人员	少量/Mock	低	高
测试环境	测试人员	脱敏数据	中	中
预发环境	测试/运维	全量脱敏	高	低
生产环境	最终用户	真实数据	极高	极低

嗯，这里要注意一点。很多团队把预发环境和测试环境混为一谈。其实它们的目标完全不同。测试环境是为了“找bug”，预发环境是为了“验证上线流程”。

我个人建议，如果资源允许，一定要把预发环境和测试环境分开。哪怕预发环境只有一台机器，也比没有强。