从容器化到微服务，我们采用了远程工作、敏捷团队，以及云原生使我们能够管理更快的开发和发布周期。
但我们错过了开发周期中的一个关键环节：测试。毕竟，当你每天(或每小时、每分钟……)部署时，还有多少时间测试?而测试对产品交付至关重要，每次都要做好。
当我们开始用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同事，他们会在你需要时为您提供访问权限，但情况肯定并非总是如此。另外，在具体的测试环境中，你可能需要集群访问来运行功能或性能测试，这些测试远远超出了你通常获得的权限。
