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

原文链接：

https://thenewstack.io/top-5-challenges-in-modern-kubernetes-testing/