如何管理软件测试环境?坑点和方案

如何管理测试环境?这是软件开发过程中的一个痛点,按理似乎该交给测试人员管理?但往往是开发管理,当开发不想管时又推给了运维。往往的后果是:测试环境维护困难、混乱不堪。

这时,一套合理的环境管理流程在软件发布过程尤为重要。如何让环境为你服务,而不在环境维护过程投入过多人力,这是挺重要的一项工作。

在现在互联网模式下,微服务化架构盛行,毫不夸张的说,好的环境管理流程事半功倍。

环境管理的分类

一般互联网公司软件项目环境分为:

测试环境:提供各应用的统一集成测试环境,其中关键核心底层组件例如DB、Cache、MQ为一套统一提供服务。

预发布环境:提供预发布测试的统一集成环境,预发布理论上和线上使用相同的数据库,避免因为数据源数据不实导致的测试漏测和发布失败。

线上环境(也称 生产环境):真实应用的线上部署、运行环境。

环境管理角色之坑

以上三种环境基本上都是互联网公司开发测试流程中必备的三套环境。

这里面有几个坑点需要特别注意:

坑点一、测试环境是开发维护,预发布和线上是运维维护 

1、测试环境是开发维护,所以测试人员在环境过程中一点没有参与过程,对环境部署和系统架构一点无参与,直接导致测试无法参与到问题排查过程; 

2、开发维护测试环境部署过程都会比较随意,因此系统复杂之后,部署过程非常耗费时间(普遍存在的现象);

坑点二、测试环境是测试维护、预发布和线上是运维维护 

1、测试环境的部署方案和线上不一致,导致测试环境在发布过程中,有可能出现因为环境依赖而导致的问题无法在测试环境复现; 

2、测试环境的部署都是测试进行,测试在过程中成为瓶颈;

坑点三、运维统一维护三套环境 

1、开发和测试都对环境过程不介入,导致环境导致的问题排查成本高;

2、同坑点一,测试角色介入度太浅;

按照上面来说,看起来开发、测试、运维三个角色好像都不合适对测试环境进行管理,那怎么才是一个合适的方案呢?

我认为合适的方案要有如下要素:

  • 测试维护测试环境的部署脚本;
  • 环境部署脚本模板运维统一提供,保障线上、预发布、测试三套环境的模板只是配置项不同,其他依赖环境的版本等均一致;
  • 测试环境的管理可以通过一套工具平台来进行统一的部署;

所以,其实对于测试环境的管理来看,合理的方案是要有一套可标准化的管理工具、部署模板。

认识测试环境的部署方案的发展

测试环境为了方便部署,一般在项目部署过程中一般有以下三种方案:

方案一:每个项目相关的测试应用都单独部署环境

每个项目相关的测试应用都单独部署环境

这种部署方案一般适用于小型项目团队快速开发,且并行度不高的情况,因为部署应用的数量和深度都不高,所以通过Jenkins等定义好部署脚本,随时使用新agent就可以快速重新部署一套环境。

但是,如果环境复杂度增高之后,这种成套的部署方案会出现如下几个问题点:

①依赖的配置项管理越来越复杂;

②成套的并行环境管理方案,在项目联调增多之后,会导致环境部署成为项目开发的瓶颈,即因为环境套数的原因,同时只能并行有限多的项目;

③环境的运维成本越来越复杂,这个成本按照上节提到的,无论是增加给测试、开发还是运维,都是越来越重的负担。

此时,我们需要寻求解决方案:

方案二:一套统一的标准环境,所有其他项目环境都依赖标准环境进行部署测试

一套统一的标准环境,所有其他项目环境都依赖标准环境进行测试

以上这种方案通过增加标准环境解决了环境依赖的问题,也是基本上互联网公司使用的标准化测试环境的方案。

不过,这里面还是有一些问题点存在:

①项目之间的环境互相依赖,需要一套系统解决环境指向问题。(这就是配置中心存在的原因)

②环境中的每个应用部署方案,都必须要有部署脚本统一进行。(这就是测试环境部署平台存在的原因)

③测试机器上部署的应用要做好规划,减少因环境依赖和资源冲突等问题。

如上,为了解决这三个问题,整个针对环境管理需要两个新的工具平台来承载。好在一般的发展到一定规模的公司,开发这两个平台的实力还是有的。

但是时间长了,第三个问题就会越来越痛,以至于随着测试团队规模的增加,我们需要出一个子团队(1~2个人)长期对环境进行管理维护,随时应对各种环境问题导致的部署失败和冲突问题。苦不堪言~

因此测试环境在近几年进入第三套部署探索方式

方案三:基于Docker的标准化测试环境部署方案

基于Docker的标准化测试环境部署方案

Docker的引入,让环境的标准化问题解决了,环境的维护成本会减少,但这个方案是不是final方案?我认为也不是,因为Docker解决了环境问题,又引入了两个新问题:

①业务关系编排和Docker的IP管理维护较为复杂,原来这个不突出的问题成为新问题点;

②自己搭建的Docker环境,虽然有K8s这样比较成熟的开源工具来做,但是理论上又引入了一个新的不可控制的点;

其实环境随着一步步的解决问题,技术的复杂度是越来越高了。有时候其实考虑如果完全Docker生成一套隔离环境,可能会是更好的方案,在不计成本的情况下完全抛弃测试标准环境。

所以测试环境管理和维护这条路,其实是随着解决的问题深入,需要有很深入的思考和解决问题能力的,而且对技术的要求也越来越高。



留言