51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3252|回复: 5
打印 上一主题 下一主题

[原创] 深入测试环境管理

[复制链接]
  • TA的每日心情
    开心
    2018-2-2 15:14
  • 签到天数: 2 天

    连续签到: 2 天

    [LV.1]测试小兵

    跳转到指定楼层
    1#
    发表于 2018-2-2 15:16:16 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    原创作者: 九宸@到家 DeepTesting
    测试过程中,一套合理的环境管理流程是发布过程中很重要的一环。如何在测试过程中让环境为你服务而不是在环境维护过程投入过多人力,其实还是挺重要的一个工作。
    在现在互联网模式下,微服务化架构盛行,毫不夸张的说,好的环境管理流程是事半功倍的。
    环境管理的分类
    一般的互联网公司环境分为三套:
    • 测试环境 提供各应用的统一集成测试环境,其中关键核心底层组件例如DB、Cache、MQ为一套统一提供服务。
    • 预发环境 提供预发布测试的统一集成环境,预发布理论上和线上使用相同的数据库,避免因为数据源原因不足导致的测试漏测和发布失败。
    • 线上环境 真实应用的线上部署环境

    环境管理角色之坑
    以上三种环境基本上都是互联网公司的必备的开发测试流程中很重要的三套环境。其实这里面有几个坑点需要特别注意
    • 坑点一:测试环境是开发维护、预发和线上是运维维护

    • 测试环境是开发维护,所以测试人员在环境过程中一点没有参与过程,对环境部署和系统架构一点无参与,直接导致测试无法参与到问题排查过程;
    • 开发维护测试环境部署过程都会比较随意,因此系统复杂之后,部署过程非常耗费时间。

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

    • 测试环境的部署方案和线上不一致,导致测试环境在发布过程中,有可能出现因为环境依赖而导致的问题无法在测试环境复现;
    • 测试环境的部署都是测试进行,测试在过程中成为瓶颈;

    • 坑点三:运维统一维护三套环境

    • 开发和测试都对环境过程不介入,导致环境导致的问题调查成本高
    • 同坑点一,测试角色介入度太浅

    按照上面来说,看起来开发、测试、运维三个角色好像都不合适对测试环境进行管理,那怎么是一个合适的方案呢?
    我认为合适的方案要有如下要素:
    • 测试维护测试环境的部署脚本
    • 环境部署脚本模板运维统一提供,保障线上、预发、测试三套环境的模板只是配置项不同,其他依赖环境的版本等均一致
    • 测试环境的管理可以通过一套工具平台来进行统一的部署

    所以,其实对于测试环境的管理来看,合理的方案是要有一套可标准化的管理工具、部署模板。
    认识测试环境的部署方案的发展
    测试环境为了方便部署,一般在项目部署过程中一般有如下几种方案:
    测试环境部署方案一:每个项目相关的测试应用都单独部署环境
    这种部署方案一般适用于小型项目团队快速开发,且并行度不高的情况,因为部署应用的数量和深度都不高,所以通过Jenkins等定义好部署脚本,随时使用新agent就可以快速重新部署一套环境。
    但是,如果环境复杂度增高之后,这种成套的部署方案会出现如下几个问题点:
    • 依赖的配置项管理越来越复杂
    • 成套的并行环境管理方案,在项目联调增多之后,会导致环境部署成为项目开发的瓶颈,即因为环境套数的原因,同时只能并行有限多的项目
    • 环境的运维成本越来越复杂,这个成本按照上节提到的,无论是增加给测试、开发还是运维,都是越来越重的负担

    此时,我们需要寻求解决方案:
    测试环境部署方案二: 一套统一的标准环境,所有其他项目环境都依赖标准环境进行测试
    以上这种方案通过增加标准环境解决了环境依赖的问题,也是基本上互联网公司使用的标准化测试环境的方案。不过,这里面还是有一些问题点存在:
    • 项目之间的环境互相依赖,需要一套系统解决环境指向问题。(这就是配置中心存在的原因)
    • 环境中的每个应用部署方案,都必须要有部署脚本统一进行。(这就是测试环境部署平台存在的原因)
    • 测试机器上部署的应用要做好规划,减少因环境依赖和资源冲突等问题。

    如上,为了解决这两个问题,整个针对环境管理需要两个新的工具平台来承载。好在一般的发展到一定规模的公司,开发这两个平台的实力还是有的。
    但是时间长了,第三个问题就会越来越痛,以至于随着测试团队规模的增加,我们需要出一个子团队(1~2个人)长期对环境进行管理维护,随时应对各种环境问题导致的部署失败和冲突问题。苦不堪言~
    因此测试环境在近几年进入第三套部署探索方式
    测试环境部署方案三: 基于Docker的标准化测试环境部署方案
    Docker的引入,让环境的标准化问题解决了,环境的维护成本会减少,但这个方案是不是最后的方案了,其实我认为也不是因为其实docker解决了环境问题,又引入了几个新问题:
    • 业务关系编排和docker的IP管理维护较为复杂,原来这个不突出的问题成为新问题点
    • 自己搭建的docker环境,虽然有K8s这样比较成熟的开源工具来做,但是理论上又引入了一个新的不可控制的点

    其实环境随着一步步的解决问题,技术的复杂度是越来越高了。有时候其实考虑如果完全docker生成一套隔离环境,可能会是更好的方案,在不计成本的情况下完全抛弃测试标准环境。
    所以测试环境管理和维护这条路,其实是随着解决的问题深入,需要有很深入的思考和解决问题能力的,而且对技术的要求也越来越高。

    今天就先写这两个点的环境问题,其实对于测试环境来说,如何和持续集成更好的互动、配置中心、环境监控、日志收集等等都会是可以深入讨论的问题点。
    但,考虑到此账号会持续更新,因此关于测试环境就先写这一篇,以上提到的问题,待以后再逐一深入分析下。

    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏3
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-24 16:57 , Processed in 0.071739 second(s), 22 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表