持续交付 36 讲
王潇俊
携程系统研发部总监
39681 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 42 讲
开篇词 (1讲)
结束语 (1讲)
持续交付 36 讲
15
15
1.0x
00:00/00:00
登录|注册

08 | 测试环境要多少?从现实需求说起

如何优化测试环境
测试环境中最让你痛苦的一点
环境昂贵,需权衡成本、效率、可管理性
好用的测试环境需满足核心用户需求
互联网公司通常包括5套环境
环境需满足用户需求以保证软件质量
核心使用者需求决定好的测试环境
不同测试环境的用户和需求
常见环境模型:开发环境,功能测试环境,验收测试环境,预发布环境,生产环境
原因:人员增多提高项目并行度,应用架构逐渐微服务化
大多数公司存在多套环境及子环境
公司规模较小时,测试环境维护相对容易
测试环境问题导致浪费大量时间
项目初期对测试环境问题的忽视
环境管理容易被忽略
测试环境的易用程度直接影响软件的交付速度
思考题
总结
什么是好的测试环境?
互联网公司测试环境的结构
从现实需求的角度,谈到底需要多少套测试环境
参考文章

该思维导图由 AI 生成,仅供参考

在整个持续交付生命周期中,测试环境的易用程度会直接影响软件的交付速度,但因为以下两点,它又是最被容易忽略的一环。
我们总是把环境理想化,忽略了其管理的难度;
我们也很少设立专职的环境管理员,导致环境长期处于混乱状态。
通常,我们在项目初期并不会关注测试环境的问题,然而在回顾时却发现在环境问题上浪费的时间非常惊人:硬件资源申请困难,测试环境配置繁琐,测试应用更新困难,基础设施稳定性差,服务调用异常,多项目并行造成互相干扰等等问题。
而不管你是开发人员还是测试人员,相信你都或多或少地碰到过这些问题。
在接下来的《环境管理》系列文章中,我会和你聊聊构建一整套好的测试环境的关键点以及具体实施方案。今天,我就先跟你说说和测试环境相关的两个问题:
测试环境的结构一般是怎样的?
什么才是好的测试环境?

互联网公司测试环境的结构

当公司规模较小时,测试环境的维护相对容易。开发和测试共用一套数据库缓存等基础设施,因为应用数量不多,开发环境可以是单机的,无论是手动或半自动化的更新测试环境的应用,花费的时间都还在可接受范围内。
这时,公司环境的结构很简单,分为开发环境,测试环境,生产环境即可。
但实际上,我看到的大多数公司的研发过程及配套环境并没有这么简单,一般都会存在 5 套以上的大环境以及更多的子环境,每个环境的机器数量可能有数十台甚至更多。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

在持续交付生命周期中,测试环境的重要性不容忽视。然而,由于环境管理的难度和缺乏专职环境管理员,测试环境常常被忽略,导致浪费大量时间和资源。针对互联网公司的测试环境结构,通常包括开发环境、功能测试环境、验收测试环境、预发布环境和生产环境。每个环境都有不同的用户和需求,因此构建好的测试环境需要考虑满足不同角色的需求,包括可得性、快速部署、独立性、稳定性和高仿真。好的测试环境应该最终满足核心使用者的需求。文章将在接下来的系列文章中深入探讨构建一整套好的测试环境的关键点以及具体实施方案。测试环境的目的是要保证最终将交付的软件产品的质量,所以好用的测试环境,不能从规模、性能和作用的角度来评判,而应该是从它能否满足用户需求去保证软件质量的角度进行定义。环境是昂贵的,不仅涉及单一的机器资源成本,环境副本数的增加也意味着更难管理,更复杂的流程,所以仅仅考虑单套使用者的体验是不够的。在下一篇文章中,将会分享多环境带来的成本问题,以及如何在成本、效率、可管理之间权衡取舍。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《持续交付 36 讲》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(22)

  • 最新
  • 精选
  • 齐涛-道长
    置顶
    最痛苦的是防火墙问题。公司只有一套Jenkins在生产环境网段,公司策略又不允许生产环境访问测试环境,于是乎目前还遗留的仅能访问的个别测试机器极其宝贵,后续一旦这些机器被换掉,那就真是完全隔离了。另外公司的网络策略现在限制不允许开22端口,于是乎我可以预见到不远的未来我们将从Jenkins自动化部署转变为全部自己动手部署了

    作者回复: 你提的问题很好,我也确实忘了这一块的内容。其实比较好的网络划分是为持续交付或部署系统之类的工具划分出专用的工具网段,此网段可同时访问测试和生产,反之则是受控的。虽然从网络管理角度来说会复杂一些,但结构和用途就更清晰了

    2018-07-22
  • Xiangjun
    如何利用开源红利,快速搭建一套持续交付平台。 在这一部分,我会手把手地,带你真正去搭建一套最小集合的持续交付平台。 什么时候讲干货?

    作者回复: 哈哈,其实那些只是“知其然”,还是要看“知其所以然”的带问号的几讲呢

    2018-07-21
    6
  • pein
    感觉讲的比较皮毛,问题提的很尖锐,比如多个开发团队并行开发的话环境怎么保证,但是说的方案只是五个串行环境的方案,并不能解决之前作者提出的问题,还是希望作者可以多讲一些百度查不到的信息

    作者回复: 环境问题会有多讲,作为第一讲,力求先把问题解释清楚,后续自然会有更清晰的解答。也可以关注一下全部目录哦,定位自己特别关注的部分,毕竟读者的背景,经验都会有所不同,还是需要照顾全面:)

    2018-07-23
    3
  • 卿卿
    “到了预发布阶段,应用已经进入了生产网络,和真实的生产应用共享同一套数据库等基础设施。” 如果涉及到数据库变更,某些情况下回与当前生产环境冲突应该如何解决?一直觉得数据库的变更才是持续交付的难点所在。

    作者回复: 需要避免类似冲突的情况,数据和代码逻辑都可以做一些兼容,还可以利用开关

    2020-05-11
    1
  • MsgR
    一般我只做四套环境。每套环境都是应需求而生,统一的本地开发环境,环境与线上一致的的测试场景,使用环境和数据与线上一致的预发布环境,生产环境。按照老王的分法,我们应该是把验收测试与预发布环境合一了。

    作者回复: 环境的多少主要还是遵循研发需求,只有最适合,没有最好

    2018-10-28
  • jacky
    王总,请问SaaS用微服务架构合适吗?

    作者回复: 微服务,说到底就是为了解耦,把复杂问题简单化,只要是这个目标,就是合理的了

    2018-07-25
  • 旭东(Frank)
    现在测试环境和开发环境的网络互通,经常因为开发的配置问题导致与测试的服务一起启动,造成服务被掳走到开发环境。

    作者回复: 下一讲中就会讲到解决方案

    2018-07-24
  • 叶子
    要部署这么多不同的环境,在开发资源上会不会需要投入的成本如何控制呢

    作者回复: 下一讲就会提到成本和如何做的问题

    2018-07-23
  • 不需往后看
    老师你好,对于 java 这块的自动化测试一直有个困惑 - 即,如何组织测试代码、如何管控单元测试/集成测试。 比如单元测试和集成测试的目录结构是什么样的? 再比如集成测试我知道通常有两种组织方式,一种是和单元测试代码放在一起,通过文件夹以及类名后缀来和单元测试区分,另一种是把集成测试独立为一个 maven 模块,但是这样会存在不同环境模块依赖问题(比如ide 下没问题,但测试环境下报依赖找不到的错误)。到底哪种组织方式更好? 再比如单元测试和集成测试具体如何和持续集成交织在一起?这块是不是后面会讲到 🙈🙈 希望老师能指点一二,感谢

    作者回复: 毕竟不是专门讲测试,讲不到很透,但一般我们是分开目录结构的,单元测试和集成测试将会在两个隔离环境进行,而依赖问题还是要看具体案例用标准的方式来解决,当然集成测试还要善用mock

    2018-07-23
  • Edward
    目前多套环境的隔离,意味着终端也要配置5套切换的环境,然而这种推动难度很大

    作者回复: 移动client的话,可以通过配置不同Gateway来解决

    2018-07-23
收起评论
显示
设置
留言
22
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部