现代Kubernetes测试的五大挑战

发表于:2022-5-09 09:19

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:佚名    来源:今日头条

分享:
  从容器化到微服务,我们采用了远程工作、敏捷团队,以及云原生使我们能够管理更快的开发和发布周期。
  但我们错过了开发周期中的一个关键环节:测试。毕竟,当你每天(或每小时、每分钟……)部署时,还有多少时间测试?而测试对产品交付至关重要,每次都要做好。
  当我们开始用Kubernetes时,很快就发现集成测试面临着重大挑战,尤其是在持续集成/持续交付(CI/CD)管道中配置测试以遵循GitOps方法时。让我们仔细地看看测试人员在云原生中面临的五大挑战。
  1.紧耦合
  紧耦合的架构有很多优点,尤其是在处理大量数据和许多源的情况下。但它限制了开发人员和测试人员对测试的自由。
  测试和测试执行活动与CI/CD和构建工作流紧耦合,所以你最终不得不在构建的同时运行测试。但是当你需要运行与构建不同步的测试时会发生什么呢?假设你已经更新了一个组件,只想重新运行测试套件的特定部分?或者,当编排与GitHub Actions或Jenkins等CI/CD工具绑定时,你是否需要运行特定的测试?
  2.GitOps
  GitOps让你可以随时了解集群的状态,并可以使用完善的工作流与它们一起工作。如果你使用的是成熟的DevOps方法,再加上坚实的GitOps框架,那么每天都可以在生产中部署数量惊人的代码。但是,测试究竟是在哪里进行的,又是如何进行的呢?
  如何将测试和测试相关工件与使用git管理所有集群状态的想法联系起来?你用同样的方式管理测试吗?将它们应用于每个集群?当你的GitOps CI/CD管道已经在愉快地编写代码时,测试如何融入其中?
  3.测试工具多样化
  今天,我们可以选择自己的语言和工具,甚至是团队中的个人用不同的语言和工具,这很好。我们可以为每项工作选择合适的工具,测试也不例外。我们已经看到团队为了不同的目的使用不同的测试工具——API测试(SoapUI、Postman)、端到端功能UI测试(Cypress、Selenium)、负载测试(JMeter、k6),更不用说用于自动化和集成测试的内部框架了。
  缺点是,这会导致不同的测试框架、工具和库以不同的格式生成结果。一些组织甚至建立了一个特定的框架,可以在一种语言上进行特定的测试,这是非常棒的,直到团队中知道它如何工作的那个人离开。
  作为一名测试人员,你不可能样样精通。但由于测试涉及堆栈的很多部分,因此需要一种易于运行和监控的标准化方法,无论你的语言或工具偏好如何。
  4.测量和监控
  在你看到结果之前,你是否有过第六感,知道为什么构建出现了问题?当你的主要关注点是测试时,很容易培养出对这些事情的敏感度,但组织日益增长的异步性越来越成为一个障碍,就像由独立团队管理的微服务一样,它们都可能有自己的构建管道。这种异步性还揭示了人们不理解测试结果中的模式的问题,使得在事情朝着错误的方向发展时更难检测。
  在使用大量不同类型的组件和服务的组织中,一致跟踪QA和测试通过/失败率的指标非常重要。毕竟,没有标杆,团队如何衡量成功?
  5.访问限制
  我们都遇到过这些问题——当部署到Kubernetes时,这些令人讨厌的网络访问和安全限制,更不用说基于角色的访问控制了,可能会限制你在集群中访问或执行的操作。这些限制也不容易解决。当然,我们中的一些人有幸拥有慷慨的DevOps同事,他们会在你需要时为您提供访问权限,但情况肯定并非总是如此。另外,在具体的测试环境中,你可能需要集群访问来运行功能或性能测试,这些测试远远超出了你通常获得的权限。

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号