• 0
  • 0
分享
  • 为什么微服务的测试必须左移——软件测试圈
  • 恬恬圈 2024-07-29 16:50:59 字数 3001 阅读 256 收藏 0

  左移测试是一种软件测试方法,其中将测试移至开发过程的早期阶段,更接近开发阶段。左移测试的目标是在开发周期中尽早发现并修复缺陷,从长远来看可以节省时间和资源。

  在软件开发中更早地集成测试,可以更早地发现错误,加速反馈循环,并加快部署到生产环境的速度。

  发布代码的最佳途径是什么?一个没有尖峰、没有灭火、没有拼命急于添加快速功能以满足企业客户要求的流程?当一切正常时,该过程如下所示:

1-1.png

  十年前,项目经理嘲笑软件开发生命周期(SDLC)的瀑布式实现,其中阶段是严格定义的,规划阶段的工作从不与开发重叠,测试只有在开发结束后才开始。这种固定的过程意味着发布频率不高,并且需要很长时间才能获得用户反馈。瀑布特别不适合通过互联网交付的软件,在互联网上,敏捷方法可以每天发布软件,并在几周内反映用户的反馈。

  虽然敏捷方法允许这些阶段重叠并强调交付速度,但这些阶段仍然是基于瀑布的,传统的开发、构建和测试方法不太适合现代基于微服务的环境。

  当今测试的两个主要问题

  尽管越来越多的工作负载正在迁移到微服务,但测试仍无法跟上现代开发需求。这里有两个原因。

  QA应该找到回归,而不是回归到瀑布时代

  虽然敏捷方法与在线软件交付的兴起密切相关,但使瀑布流过时的另一个组成部分是质量保证 (QA) 的自动化和民主化。随着自动化测试和 QA 与开发团队的集成程度越来越高,测试等待开发完成是不寻常的。现代流程定义了许多精细的测试等级,从单元测试到端到端测试,并在开发人员编写代码和连接服务时不断提供反馈。

  微服务在某种程度上打破了这种范式,重新打开了通往瀑布世界的大门。从广义上讲,问题是相互依存。微服务非常依赖其他服务,因此在部署服务并与我们的其他组件和第三方 API 交互之前,很难获得准确的测试图。通常,QA 或运营团队是第一个发现微服务代码严重问题的人。

  这种破碎范式的结果是,反馈在周期的后期出现,需要将发布带回开发的最初阶段。虽然这有时会发生在代码投入生产之后,但很多时候,测试的初始部署无法捕获后期阶段出现的问题,或者最终的金丝雀测试发现了应该在流程中更早出现的集成问题。真正的过程更像是这样的:

1-2.jpg

  针对这些问题提供的最常见解决方案是构建单元测试、存根和模拟来模拟所有其他组件,但这种策略很少完全成功。一个可以模拟复杂集群的测试套件要么要求QA对堆栈中的每个服务都非常复杂,要么每个团队都愿意投入大量时间来维护其服务的测试并准确模拟其他服务。

  测试对开发人员来说太慢了

  当尝试模拟整个集群进行测试时,结果慢得令人无法接受。由于您必须在测试环境中运行整个测试套件,因此可能需要 20 分钟到几个小时才能运行所有测试并获得结果。即使是 10 或 20 分钟也足够长,开发人员不会坐下来等待所有测试在一天中运行几次。人们普遍认为,开发人员不会经常运行集成测试,更新后的服务会与集群的其余部分一起工作;相反,他们会等待在部署生命周期的后期运行它。

  由于许多错误是在部署周期的后期发现的,因此还有另一个流程问题让人想起瀑布时代:当另一个团队的工程师发现错误时,诊断、报告和修复问题的过程变得繁琐。运营和 QA 工程师的任务是为每个集成问题提交错误报告,并要求开发人员在带外修复问题。

  左移以修复测试和开发

  若要修复开发和测试代码的过程,请左移:在周期的早期测试代码,并直接向开发人员提供反馈。左移是一种文化和实践的转变,但也包括对共享测试环境设置方式的技术更改。

  更频繁地进行较小的更改

  在理想的微服务 SDLC 中,重点是尽早且经常地集成测试,从开发阶段开始。这种方法强调了小的增量代码更改的重要性。通过将更改限制在范围内,开发人员可以更轻松地理解和测试其修改的影响。这种粒度不仅加快了验证过程,而且使测试更加精确。

  在此模型中,开发人员拥有其代码的开发和测试的所有权。这种所有权明确了责任,从一开始就将质量放在首位。该方法可以在工程团队之间有效扩展,因为每个团队或开发人员都可以独立处理各自的服务或功能,从而减少依赖性。虽然这是一个很好的建议,但在当前的开发环境中实施起来可能很困难:如果将代码发布到共享测试集群的过程花费了太多时间,那么测试小的增量更改似乎不可行。最好实现一个共享的测试环境,开发人员可以在其中测试一些小的更改。

  获得更快的反馈

  该模型中的反馈循环速度很快。由于开发人员边做边测试,因此许多潜在问题会立即得到解决,通常是在它们被识别为传统意义上的错误之前。作为用户查找 bug 和作为开发人员查找 bug 之间的区别是巨大的:当运营或站点可靠性工程师 (SRE) 发现问题时,他们需要找到发布代码的工程师,描述他们看到的问题,并提供一些步骤来复制问题。相反,如果原始开发人员发现了问题,他们可以通过查看输出、找到原因并开始修复来减少所有这些步骤。这种主动的质量方法减少了在开发周期后期需要归档和解决的错误数量。

  从文化上讲,这种 SDLC 模型培养了一种 CI/CD 文化,在这种文化中,代码更改可以快速可靠地集成、测试和交付。这不仅加快了开发过程,还提高了软件的整体质量。尽管 CI 意味着“持续集成”,但在微服务的上下文中,CI 工具以最佳方式提供持续测试,让开发人员尽早了解他们在尝试部署微服务代码时将面临的实际问题。

  测试空间集成

  集成用于预览代码更改的系统是一个关键组件,因为它允许即时反馈更改在实时环境中的行为方式。此类预览对于开发人员以及其他利益相关者(如项目经理和 QA 团队)来说非常宝贵。技术挑战是巨大的,而且没有“插入式”解决方案来创建一个非常准确的生产副本,每个开发人员都可以测试频繁的更改。

  简而言之,任何此类系统的基本要求是:

  · 生产环境的真实副本,包含所有必需的依赖项和由其他团队维护的许多微服务。

  · 将新的小型代码更改部署到此共享环境的简单方法。

  · 一种防止冲突的方法,以便部署到服务的实验性代码不会中断其他开发人员的群集性能。

  通常,承诺仅在需要测试时才建立整个集群副本的解决方案并不令人满意。相反,开发人员需要进行小的增量更改,有时一天部署不止一次。一旦事情变得非常复杂,建立整个集群所需的时间将抑制左移的目标。

  请求左移隔离

  面向开发人员的快速准确的测试环境必须是 Kubernetes 空间的原生环境,以便动态地允许在使用运行生产环境的系统的共享集群中进行更新和测试。许多大型企业团队已经实现了一种称为请求隔离的模型,该模型允许测试服务作为集群的一部分运行,而不会中断其他服务。包括 Uber 和 netflix 在内的团队可以推出服务的测试版本,甚至可以推送到生产环境,该版本只能处理测试请求,但仍然可以向它所依赖的所有其他服务发出请求。

  netflix 允许开发团队在其集群上使用请求隔离技术。通过利用服务网格,工程团队可以仅将测试请求定向到其服务的更新版本。使用测试版本更新服务时,服务的基本版本仍可供其他团队使用,因此他们可以使用相同的测试群集。

  结果使团队能够进行小的增量更改,并针对实际集群进行测试。开发人员自己发现问题,大大缩短了反馈时间并加快了开发速度。


作者:架构摆渡    

来源:http://www.51testing.com/html/30/n-7799030.html

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   在各种各样的公司或岗位上,有着三种人:遵守规则、见识规则、搭建规则的人。  大多数人都处于遵守规则的阶段,也就是执行人员,不论开发、测试等岗位,根据当前的管理体系去熟悉去适应去执行。  小部分人见识过各种各样的规则,这取决于不同公司的规模,为什么大多数公司喜欢大厂背景的人才,就是因为他们见识过完善的制度体系,学习能力快、人员素质高等原因。  最后很少一部分人处于搭建规则,当然搭建规则的人必须有个前提——见识过规则。  每一个公司都有自己的制度流程,从别的地方复制粘贴过来的并不完全能够运行下去,中间会出现各种各样的问题,最后导致断层问题,在不断改进后形成自己的规则体系,使公司更好地运行下去。...
            0 0 1208
            分享
          • 注意:本标题的“自动化测试”包括性能测试与UI级的自动化测试经常会被问到如何解决验证码的问题,在此记录一下我所知道的几种方式。对于web应用来说,大部分的系统在用户登录时都要求用户输入验证码,验证码的类型的很多,有字母数字的,有汉字的,甚至还要用户输入一条算术题的答案的,对于系统来说使用验证码可以有效果的防止采用机器猜测方法对口令的刺探,在一定程度上增加了安全性。但对于测试人员来说,不管是进行性能测试还是自动化测试都是一个棘手的问题。下面来谈一下处理验证码的几种方法。去掉验证码这是最简单的方法,对于开发人员来说,只是把验证码的相关代码注释掉即可,如果是在测试环境,这样做可省去了测试人员不少麻烦...
            15 15 1810
            分享
          •   1 痛点和研究背景  目前随着分布式核心下移和小型机下线的趋势,主流系统架构已逐步演变为CCE+TDSQL。而在这一演进过程中也陆续暴露出来一些痛点难点问题,需要我们着力解决。为此,我们聚焦于分布式架构下需求、架构、数据这三个方面的痛点问题探索解决途径和措施展开了研究。第一,需求缺失的问题,分布式核心下移和小型机下线涉及的系统体量大、业务逻辑复杂,需求说明书持续迭代的情况下说明书内容已逐渐滞后缺失,易导致测试遗漏的出现。第二,架构痛点,分布式事务一致性逻辑复杂,目前主要基于手工测试,依赖于开发人员修改程序构造异常事务场景,导致测试费时费力;多微服务间的参数配置存在关联关系,微服务个数较多时...
            0 0 1032
            分享
          •   日前,沃尔沃首款纯电MPV车型沃尔沃EM90的谍照在网上曝光。据悉,这款特供车将采用和极氪009相同的SEA浩瀚架构,车身长度可能超过5.2米。计划于今年第三季度亮相并投产上市,成为沃尔沃90车系的第四款车型。  根据谍照可以看出,新车外观与极氪009有诸多相似之处,如雷神之锤轮廓的LED大灯组和镀铬饰条点缀的封闭式进气格栅。车身侧面包括悬浮式车顶造型、双层镂空的A柱和C柱的转折点造型以及充电口位置等细节与极氪009几乎一致。然而,由于伪装措施严实,尾部设计等细节尚不清晰可见。  动力方面,沃尔沃EM90将采用纯电驱动系统,可能与EX90采用相同的动力配置:低功率版电机最大功率407马力,...
            0 0 652
            分享
          •  一、工具背景介绍Oracle Database,又名Oracle RDBMS,或简称Oracle。是甲骨文公司的一款关系数据库管理系统。它是在数据库领域一直处于领先地位的产品。可以说Oracle数据库系统是世界上流行的关系数据库管理系统,系统可移植性好、使用方便、功能强,适用于各类大、中、小微机环境。它是一种高效率的、可靠性好的、适应高吞吐量的数据库方案。创建表空间和表它由至少一个表空间和数据库模式对象组成。这里,模式是对象的集合,而模式对象是直接引用数据库数据的逻辑结构。模式对象包括这样一些结构:表、视图、序列、存储过程、同义词、索引、簇和数据库链等。逻辑存储结构包括表空间、段和...
            0 1 1882
            分享
      • 51testing软件测试圈微信