谈谈测试环境管理与实践

测试环境这个话题对于开发和测试同窗必定不陌生，你们几乎天天都会接触。可是说到对测试环境的印象，却鲜有好评:

• 环境不稳定，测试五分钟，排查两小时
• 功能建设不全，致使验证不充分，遗漏缺陷
• 多人共用，互相踩踏
• 随手改动不入库，消极对待，缺少敬畏之心

这些问题在行业内其实家常便饭。我甚至有听过运维同窗"脏乱差"的评价。这里先不说他的评价是否有偏见，可是起码我认为，针对测试环境的管理有较大的改进空间，这是不争的事实。

而本文将重拾这个看起来老生常谈的话题，但愿能系统化的阐述个人认知，以期与你们对齐。若是不对或者不完善的地方，欢迎提出，笔者将很是乐于与你们讨论。

首先咱们要清晰的认知到，测试环境管理作的很差，不光有严重的质量风险，还会很是影响迭代效率，因此这件事情很重要。那在解决它以前，咱们首先要去想一想，对于测试环境咱们到底有哪些诉求？

咱们对测试环境的本质诉求是什么？

很明显，测试环境的定位就是知足产研侧的测试需求，保障产品迭代质量。因此从使用类型上，通常要支撑集成测试，系统测试，压力测试，甚至故障测试等。

而这些环境背后，其实都伴随着 非功能性要求 ，重点体如今:

• 从使用者角度
  • 想用就有，不要等待
  • 要低维护，高稳定
    • 维护角度 - 我只关心个人测试需求，我不想干其余维护性工做
    • 稳定角度 - 我依赖的其余服务和业务要稳定，不要影响我测试
• 从企业角度
  • 低成本，高效率
    • PS: 测试环境管理追求的是更高的研发迭代效率，可是成本是底线

除此以外，其实还有个很是关键的问题就是，要定义清楚测试环境管理的主体责任人是谁。这点很关键，没有责任人天然会滋生乱象。

• 研发 虽常用测试环境，但从投入产出比上，组织通常仍是但愿研发同窗能多投入精力作更多创造性的事情
• 运维 自己负责线上环境的运维，可能有企业也会以为把测试环境交给他们运维会顺水渠成，且现实确实是有很多企业就是这么干的。不过从人性的角度去分析，相比于线上环境，运维同窗对测试环境的重视程度必定不够。而这也是为何，不少企业的测试环境管理，也只是达到将就能用的水平的缘由。
• 测试 测试同窗算是测试环境的主要使用者，对测试环境的管理理应负有直接责任。不过现实中，常常看到的是，测试同窗因自己测试任务较多，且测试环境管理也要求具有必定的系统运维能力。致使相对而言，测试同窗要想作好测试环境管理，也不容易。

不过，不论是哪一个角色负责，其实症结还在ROI上。只要有充足的预算和人力，这些都不是问题。反之，就须要不断的优化和调整。

固然人力成本是组织层面的考量，今天咱们先按下不表。这里重点聊聊如何从技术上解决这些问题。

业界的思路？

先来看看业界是怎么玩的。

阿里

阿里讲测试环境的文章很多，其中有一篇来自云效的文章，挺有借鉴价值。其重点聚焦了两个方向:

• 经过项目环境复用公共基础环境的模式，来解决资源问题
  

• 经过链路识别，请求染色，作到联调测试不串流量
  

固然，这些是借助阿里内部中间件实现的。不过在云原生环境下，其也开源了两个工具kt-connect和virtual-environment，虽产品化程度作的不够，但总体仍是比较有想法的。

百度

百度有篇文件介绍了其中间件技术在测试中的应用。文章说的比较清晰，这个中间件的架构是相似istio的模式，本质是经过代理来托管系统流量，从而实现控制链路的能力。而有了这个能力，对测试联调和环境复用天然就不在话下。一样的，对于录制/回放/mock/混沌等测试场景的能力实现上也能顺水渠成。

不过这个平台看起来有浓浓的背景局限，尤为是其控制平面的逻辑设计，感受要玩转起来，须要一系列的基础设施的配合。因此这个应该是强百度业务和技术环境背景下的产物，对于使用者，也应该有必定的学习和理解成本。

商业化？

其余企业若有赞、喜马拉雅等，基本上也都是采用改造服务，经过路由策略来实现隔离组，从而达到环境复用的能力。

不过以上都是技术人的玩法，我在想测试环境管理这个方向有没有商业化价值呢？

你们看下图，来自站点www.testenvironmentmanagement.com:

(PS: 2019年4月发布)

见名识意，这些都是国外主打Test Environment Management(TEM)方向的企业，其中Plutora在2011年创立，2016年融了1340万$. Enov8 始于2008年，正式创立于2014年。总体感受活的都还不错。

研究这些企业会发现，他们会把价值重点落地在操做自动化，过程Visibility，以及自服务和下降成本上。尤为是下降成本这块，会推出计算器，让企业主一目了然的看到，使用了他们的TEM方案会下降多少人力成本，多少资源成本等等。

另外，在TEM方向上，这些企业都会比较重视测试环境资源的自动或预定回收能力，以达到节约成本。这一点，感受国内的玩家重视程度不够。

固然，目前国内互联网ToB Saas企业也开始方兴未艾，好比我前老大的创业公司www.koderover.com，其拳头产品云原生持续交付平台，也有关注TEM方向，值得推荐。

认知自醒，咱们须要坚守哪些原则？

测试环境抛开全局管理一说，我认为做为使用者，最重要的仍是坚守如下原则:

• 重视服务部署环节，尽量的遵循线上部署模式，好比：

  • 基础系统一致(系统版本，内核版本等)

  • 中间件版本和部署姿式一致 - 千万不要想固然

  • 部署工具一致(PS: 坚定抵制那种经过apt-get install在机器上随意安装的行为)。

  • 部署逻辑一致 - 模拟真实场景，避免测试遗漏(The wider the gap between test and production, the greater the probability that the delivered product will have more bugs/defects.), 包括:

    • 服务版本
    • 配置写法
    • 实例个数
    • 机房or区域状况等等

  (PS: 切勿图省事，无脑部署最简单模式用于测试验收)

• 谨记使用规范 - 改动必定要 入库, 入库, 入库

您以为呢？

参考资料

• https://developer.aliyun.com/article/755512
• https://mp.weixin.qq.com/s/rjToB9qxv47rUrwcBhzpjA
• https://tech.youzan.com/web-https-engineering-2/
• https://www.heguang-tech.com/2020/solution/ximalaya/
• https://www.testenvironmentmanagement.com/test-environment-management-tools-compared/
• https://www.enov8.com/roicalculator/

往期推荐

• 咱们是如何作go系统覆盖率收集的？
• 聊聊Go代码覆盖率技术与最佳实践

以为不错，欢迎关注：