除了在床上，我们一天中大概最多的时间就是在测试环境上战斗和工作了。

最近在梳理测试环境和一些测试流程，在这里顺手记录一下，几年以后看过来，应该是会显得幼稚和贻笑大方的吧。

测试环境的责任边界

因为测试环境基本上是属于测试同学安身立命之本了，很多时候由于环境问题造成的漏测和事故是屡见不鲜的，因此测试环境的重要性不言而喻。

那么测试环境应该谁来管理呢？

目前看来比较好的方案是所有的测试环境都由测试同学管理，测试同学掌控发布策略，准入准出规则等等。

另外有条件的话，建议测试同学可以自行搭建测试环境。尽管很难，不过值得一试，因为这种做有如下好处

• 全面了解系统的架构。搭建了环境之后，你可能对数据库，服务器软件，各种中间件和一系列的配置有了一定程度的感性认识。记得我们当年新人来了之后有条件的话都会让他们搭建一下开发或者测试环境，这是熟悉系统架构的快捷方式。

• 了解数据源。很多时候数据源差异也会引起潜在问题。搭建测试环境的时候基本上会准备一些基础数据和小规模的业务数据，如果这些数据跟线上数据相似度高，比如有一定比例的脏数据，那么的话发现缺陷的概率相应的也会高一点把。

• 学习开发技能。这点不用展开了吧。

• 理解环境之前的差异。生产环境和测试环境之间或多或少都会有差异，这些差异其实有可能是缺陷的温床。如果我们能理解这些差异，针对这些差异做一些验证，比如线上环境有集群，而测试环境是单机，可以在集群上验证一下数据一致性的问题，这会使我们的测试用例更加的完善和高效。

综上，还是建议测试环境测试同学负责，好处还是显而易见的。卧榻之侧，岂容他人鼾睡，不是么？

准入准出规则及流程

准入准出其实跟测试环境的分层有一定的关系。不过原则上，我们可以建议在准入之前做一下简单的冒烟测试，提升准入门槛。

提升准入门槛有下面一些好处。

• 给开发敲警钟。很多低级问题其实都是开发质量意识低下所导致的。当然质量意识跟能力是成正比的，能力强的开发往往质量意识比较好。提升准入门槛实际上就是让大部分平均水准的开发多花点心思在功能的质量上，毕竟他们才是质量保障的源头。开发慎重一些，胜过测试点到吐血。

• 节约沟通成本。如果让质量很差的版本轻易的发布到测试环境，那么各种阻塞性的问题是会相当耗费沟通成本的，如果版本打回的话，大家都不开心，所以严格一点，你好我也好。

测试环境分层

有条件的话，建议可以给测试环境分层，层层隔离，每层承担不同的使命。一般来说，测试环境可以分为

• 开发联调测试环境。开发协作进行测试和联调的环境。这个环境可以让开发随便玩，也可以作为下一层环境的准入测试环境。
• 功能或模块测试环境。测试维护的某个功能或者模块的测试环境。可以直接部署分支代码。
• 集成测试环境。所有的功能都合入该环境进行测试，就是一般意义上的测试环境。前两个环境没有其实可以接受，但这个环境是一定需要稳定和可控的。
• uat环境。可以从主干拉uat分支到该环境进行uat测试，缺陷解决后可以合回主干。
• 类生产环境。与生产环境尽量一致。包括代码，软硬件以及数据高度一致。正式发布之前回归策略执行的地方。
• 灰度环境。有条件可以有灰度环境，用来进行灰度策略的实施。
• 独立的性能测试环境。这种环境可能是临时的，性能测试结束之后资源可以释放掉。

一般来说，测试环境的层级越多就代表着越多的角色会参与到测试活动中去，提前发现问题的概率相对会高一点点。

测试环境与自动化

• 多层级的测试环境要求发布过程尽可能高度自动化。如果每次发布都很手工，都很痛苦，那么团队可能会选择维护尽可能少的测试环境来降低工作量，这显然不是我们想要的结果。

• 稳定的测试环境可以进行周期性的自动化回归测试。比如可以在集成测试环境跑接口或ui的自动化。

测试环境与测试及发布流程

测试环境与测试及发布流程强相关，什么样的测试环境分层从客观上会影响整体的测试开发及发布流程。

综上，每个团队不同，所采用的测试环境分层策略也不尽相同，另外作者的水平有限，上面内容仅供参考，欢迎斧正。