现代Kubernetes测试的五大挑战

作者：易捷行云EasyStack 2022-03-15 14:55:34

云计算

云原生 过去几年的发展变化超出了许过去几年的发展变化超出了许多人的想象，这主要是因为一个名为Kubernetes的项目以及向云原生的转变。多人的想象，这主要是因为一个名为Kubernetes的项目以及向云原生的转变。

从容器化到微服务，我们采用了远程工作、敏捷团队，以及云原生使我们能够管理更快的开发和发布周期。

但我们错过了开发周期中的一个关键环节：测试。毕竟，当你每天(或每小时、每分钟……)部署时，还有多少时间测试?而测试对产品交付至关重要，每次都要做好。

当我们开始用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同事，他们会在你需要时为您提供访问权限，但情况肯定并非总是如此。另外，在具体的测试环境中，你可能需要集群访问来运行功能或性能测试，这些测试远远超出了你通常获得的权限。