只要做过一次测试，一定知道测试环境，但测试环境是如何搭建和维护的呢？不一定所有人都明白了。
　　测试环境的搭建，每个公司都有不一样的流程和方法。一种是运维或者开发负责搭建和维护，另一种是测试人员进行搭建和维护。
　　大部分复杂的测试环境都是由开发搭建的，开发知道任何配置文件需放在哪个路径，搭建起来相对容易。如果是运维搭建，得根据开发提供的安装手册进行搭建和维护，手册中一般会有固定的维护方法。如果是测试搭建，其实和运维干的差不多。
　　安装手册非常重要，特别是环境比较多的时候，比如有一套开发环境，一套功能测试环境，一套性能测试环境。虽然可能写起来篇幅很长，也不一定有人看，但是如果没有，一旦出了问题，没有办法及时维护了。随着时间的推移，安装手册也要保持不断地更新。
　　拿到安装手册，一般是Linux系统，可以依托Jenkins或者独立编写一堆Shell脚本自动执行：把安装文件拷贝到指定目录，服务做一个启动，日志做一个更新；若伴随有数据库配置，要执行一些SQL，使新配置的数据生效；若遇到服务器硬盘不够，需要根据手册上日志路径去删无用的测试日志。如果水平不够，不会编写Shell脚本，也可以手工执行编译、拷贝命令进行的更新或者维护，只是效率不高。
　　这是为什么有的招聘需要测试精通Linux、懂数据库，很可能需要测试人员自定义搭建和维护测试环境。大规模的测试团队，有配置管理员来承担测试环境的运维工作，这对个人锻炼Linux操作和数据库方面知识有不错的效果。
　　测试环境搭建时，尽可能和上线的环境一致。小公司如果没有条件，可以同比例缩小。比如一套环境有三层：应用服务器、缓存服务器和数据库服务器，可以每层取两台，基本能够模拟分布式结构。实在不行，每层一台也可以，但是这样无法模拟分布式，看对测试质量的要求了。
　　后有一点提醒：测试环境没有问题是不是上线后没有问题了？答案显然是否定的。测试环境和生产环境总有或多或少的差异，所以在线上环境先发一个灰度版本，做一版冒烟测试或者一些跟踪的测试后，再正式发布比较保险。