几年前，云原生测试工具的想法似乎很疯狂。

既然每个可能的测试场景都有这么多优秀的产品可用，为什么还需要特定的工具呢？然后，Kubernetes出现了，并永远改变了游戏规则。

今天，当我们在分布式云基础设施中运行复杂的微服务架构和孤岛服务时，测试系统变得非常困难，这些分布式云基础设施通常由远程全球区域的团队管理。

什么使测试工具云原生？

云原生测试工具是专门为云原生环境开发的。最重要的是，它们允许你在集群中部署测试，执行是超级可伸缩的，并且它们不耦合到任何CI/CD框架，如Jenkins、GitHub Actions等。

你将能够执行测试、查看结果并管理整个端到端测试流程，而无需进入CI/CD。

笔者将云原生测试工具视为将集群转变为现代汽车。现代汽车对自己进行诊断测试，向驾驶员显示出什么问题。为什么不让集群也这样做呢？

为什么应该开始以云原生方式进行测试？

有了所有优秀的测试工具，从Postman到Cypress，以及介于两者之间的所有工具，你可能会想，“我只是将它们改装到我的用例中。”这绝对没问题！事实上，很多人只是在非常简单的场景中这样做。然而，当转向云原生测试时，会留下很多繁重的工作。

将测试工具与CI/CD去耦

大多数实现的测试与其CI/CD管道紧密耦合，这增加了许多复杂性，并降低了灵活性。这里有一些迹象表明，你可能需要重新思考设计CI/CD管道的方式，通过解耦测试使其更加灵活：

——本来只需要一次测试的时候，你却需要重新运行整个测试套件，甚至是整个CI/CD工作流。这意味着耦合过多。

——不能跨多个CI/CD工具和工作流重复使用测试管道。

——插入CI/CD工作流时，不同测试工具的执行和报告不一致。

使测试云原生意味着它们不再依赖CI/CD系统进行编排。如果希望或需要，CI/CD可以并且将能够触发测试，但这不再是绝对必要的。

扩展测试

云原生测试在扩展方面非常出色——通常使用Kubernetes来扩展执行，而CI/CD工具在需要执行大量并发测试时不具有可扩展性。

无需编写脚本或添加样板代码

在当前的设置中，对于要添加到测试工作流中的每个测试工具，很有可能需要执行大量脚本、样板代码或一些复杂的配置，以自动化测试并使其成为CI/CD工作流的一部分。通过云原生测试，复杂性降低了几个数量级。它们可以在云中无缝运行，无需额外的工作。

使用Testkube进行云原生测试

考虑到测试的所有挑战，我们决定构建Testkube，目标是使所有类型的测试都成为云原生测试。它的基本原则之一是，通过消除与测试自动化和集成相关的复杂性。

除了将CI/CD从测试中去耦、扩展和消除对自定义配置的需求之外，在集群中运行Testkube等测试框架还有一些额外的优势，即消除了对测试进行容器化的需要，并避免了对要测试的环境的访问受限的问题。

标准化报告

当在拥有无数不同类型组件和服务的全球团队中工作时，一致跟踪QA和测试通过/失败率指标非常重要。毕竟，如果没有基准，如何衡量成功？TestKube就是这样做的。因为它知道所有测试和结果的定义，所以你可以使用它作为集中的位置来监控测试的通过/失败率。此外，它定义了一种通用的结果格式，因此你可以在所有类型的测试中获得一致的结果报告和分析。

容器化测试

如果你在云中以非无服务器的方式运行应用程序，并且不使用虚拟机，此时你可能会使用容器，可能会面临将所有测试容器化的挑战。好吧，使用Testkube中的云原生测试，这是不必要的。你只需将测试文件导入Testkube并立即运行它们。

管理对受限环境的访问

限制进入需要测试或修补的环境是大多数人在职业生涯的某个阶段面临的问题。这并不一定意味着这些环境的管理员不信任你，但对于有可能发生数据泄漏或影响业务的事故的环境，一定要防止这种情况发生。因此，最好的方法是在这些环境中公开Testkube API，并使用它来管理你的测试活动，而不需要具有相同的访问权限。

试一试

有许多优秀的测试库/工具可以无缝集成到Testkube中，如Postman、Cypress、k6、soapUI等。这些都是非常好的工具，但是当你使用Testkube以一种简单和云原生的方式运行它们时，会变得更好。

运行Testkube的集群能够测试自己，而不需要复杂的CI/CD。它允许你全面查看所有测试和集群状态。而且别忘了，它是开源的。