跳到主要内容

1 篇博文 含有标签「测试环境」

查看所有标签

谈谈测试环境管理与实践

· 阅读需 10 分钟
CarlJi
CarlJi
Coder|Blogger|Engineer|Mentor

测试环境这个话题对于开发和测试同学一定不陌生，大家几乎每天都会接触。但是说到对测试环境的印象，却鲜有好评:

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

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

而本文将重拾这个看起来老生常谈的话题，希望能系统化的阐述我的认知，以期与大家对齐。如果不对或者不完善的地方，欢迎提出，笔者将非常乐于与大家讨论。

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

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

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

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

  • 从使用者角度
    • 想用就有，不要等待
    • 要低维护，高稳定
      • 维护角度 - 我只关心我的测试需求，我不想干其他维护性工作
      • 稳定角度 - 我依赖的其他服务和业务要稳定，不要影响我测试
  • 从企业角度
    • 低成本，高效率
      • 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: 切勿图省事，无脑部署最简单模式用于测试验收)
  • 谨记使用规范 - 改动一定要 入库, 入库, 入库

您觉得呢？

参考资料​

往期推荐​

觉得不错，欢迎关注：​