文/秋之川
第二十八章 独立测试环境的投入是否值得？
场景一：
准备了半天的测试数据，点击提交按钮时，页面直接抛出 Error 404，之前还好好的，怎么就不能访问了呢？我截了个图发到研发群里。
“页面怎么不能访问了？五分钟前还是好的。”我问道。
一个服务端开发回复我说：“我刚才改了点东西，重新部署了，正在重启服务器。”
“。。。”
这个场景你是不是看着眼熟？你们是不是也跟开发共用着一套环境？
场景二：
这次上线的所有功能在测试环境都通过验证了，但到了生产环境，就各种功能不能正常使用，排查半天之后，不是配置文件错了，就是数据库表少了个新增字段。也有因为测试环境的某些配置项跟生产环境不一样，导致有些问题到了生产环境才被发现。
在遇到了几次类似上述场景之后，我就跟老大提出，我们得申请独立的测试环境，并附上了我的理由：
- 开发环境：
- 供开发工程师做单元测试、集成测试；
- 只需要满足最精简的环境需求即可；
- 可以多个服务共用一台服务器；
- 测试环境：
- 供测试工程师使用的，且唯一认可的测试环境；
- 服务器的硬件配置可以略低于生产环境；
- 程序配置文件需要和生产环境保持一致；
- 该环境由测试工程师维护；
- 按测试计划部署测试版本；
- 预上线环境：
- 迷你版的生产环境；
- 服务器的硬件配置可以略低于生产环境；
- 配置文件和相关环境因子都必须跟生产环境保持一致；
- 供测试工程师和运维工程师做预发布验证；
- 作为运营和市场人员做内测使用；
- 用于减少场景二里80%的意外情况；
- 生产环境：
- 供真实用户使用的现网环境；
- 测试人员在部署之后做核心业务的验证测试；
- 测试人员用于重现测试环境无法重现的用户问题；
随着生产规模的扩大和对质量的要求越来越高，为了避免或减少场景一和场景二里的问题发生，投入相应的成本搭建独立的测试环境，不管是从短期效果，还是从长期的结果去看，都是值得的。
在实际的测试体系规划中，其实还有两种环境也是建议独立出来的：
- 自动化测试环境：
- 用于每天自动运行自动化脚本；
- 为了保持环境的纯净，脚本运行前后可以执行环境初始化脚本和数据清理脚本；
- 性能测试环境：
- 硬件的配置建议跟生产环境保持比例关系；
- 系统环境变量等参数保持跟生产环境一致；
- 数据库的数据可以基于生产环境的数据做复制和扩展；
- 保持纯净的数据备份，用于每个轮次之后的数据初始化；
最后，从成本角度出发说一个小建议，就是这几类环境中，有些是可以考虑采用虚拟服务器去搭建的，比如本地的开发、测试和自动化测试环境，其实预发布环境和生产环境也都可以采取虚拟服务器搭建，不过当下大多数都是用的阿里云服务，这个就不在我们考虑的范围了。
《告诉你如何从执行测试到管理测试》带你迈出第（28）步！，点击这里可查看完整地图
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
