云原生时代，传统云端测试平台面临挑战！文章剖析测试自动化演进，从早期专有工具到AI智能测试。Kubernetes原生测试方案如Testkube崛起，利用K8s可扩展性，将E2E、API、负载测试融入CI/CD，降低成本，提升效率。拥抱云原生，测试即服务！
译自：Are the Days of Cloud-Based Testing Platforms Numbered?
作者：Dmitry Fonarev
软件团队通常分为两类：一类是自动化测试的团队，另一类是不自动化测试的团队。还有一些团队根本不做测试，还有一些团队计划进行自动化，但要等到明年。
对于投资于自动化的团队来说，这个等式很简单：投资越大，回报越大，但维护工作也越多。虽然有些组织依赖第三方测试执行平台，但另一些组织则采用 Kubernetes 原生方法，使用旨在编排和管理自身基础设施内部测试的工具。
Testkube 等平台通过使团队能够使用 Kubernetes 高效且大规模地执行测试，简化了这种转变，从而减少了维护开销，同时保持对环境的完全控制。
大规模运行测试自动化的公司是否应该依赖第三方基础设施——本质上是将测试执行环境外包？
答案取决于您要解决的问题：移动应用程序测试？绝对是。Web 应用程序跨浏览器测试？也许是。端到端 (E2E)、API、负载测试？可能不是。
早期：手动测试和专有工具（1970 年代 – 1990 年代）
测试自动化最初是手动测试工作的延伸。早期的工具是特定于供应商的，需要专有脚本。
- IBM 的 PL/I 测试系统（1970 年代）——最早的自动化单元和集成测试工具之一。
- SQA 工具（1970 年代–1980 年代）——早期的回归和验收测试自动化框架。
- Rational Robot（1980 年代）——最早的企业环境功能测试工具之一。
- TestComplete（1980 年代）——支持跨多种语言的基于 GUI 的测试自动化。
- WinRunner（1990 年代）——凭借其脚本语言 TSL 开创了 GUI 测试自动化。
- SilkTest（1990 年代）——旨在用于 Web 应用程序和 GUI 测试。
- LoadRunner（1990 年代）——专注于 Web 应用程序的性能和负载测试。
开源和 Web 测试的兴起（2000 年代 – 2020 年代）
开源框架的出现使测试自动化大众化。Web 应用程序的 Selenium 和移动应用程序的 Appium 等测试框架应运而生。
- JUnit（2000 年代）——彻底改变了 Java 中的单元测试。
- TestNG、NUnit（2000 年代）——加强了 Java 和 .NET 测试生态系统。
- 基于云的测试出现（2010 年代）——Sauce Labs 和 BrowserStack 等平台简化了跨浏览器测试。
- API、E2E 和负载测试的增长——Postman、Selenium 和 JMeter 等工具越来越受欢迎。
智能自动化时代（2020 年代 – 至今）
借助云原生基础设施和 Kubernetes，现代测试自动化变得更加复杂和异构：
- 左移测试工具——Cypress、Playwright、K6 等提供了以代码为中心的 E2E 和负载测试方法。
- 云和本地混合测试——组织集成最佳工具。
- 测试中的 AI——机器学习有助于生成、维护和调整测试。
- Kubernetes 用于测试执行——企业使用容器化的测试执行环境来实现可扩展性。
如果您的应用程序是移动应用程序，则基于云的平台是针对众多真实设备进行验证的必备工具。在内部管理数十种 iOS 和 Android 变体是不切实际的。
对于 Web 应用程序，Sauce Labs 和 BrowserStack 等平台传统上提供并行执行来加速测试。但是，在云原生世界中，对第三方测试基础设施的需求正在减少。组织正在转向 Kubernetes 驱动的测试编排，使用 Testkube 等解决方案，而无需依赖外部测试执行提供商。这种方法不仅优化了成本，还通过将所有内容保留在开发人员自己的环境和本地环境中，从而提高了测试可靠性和调试能力。
多年来，Web 浏览器变得越来越标准化，从而在不同平台上实现了更加一致和可靠的 Web 体验。过去，开发人员经常面临重大挑战，需要确保网站在多个浏览器上正确呈现，因为每个浏览器都有其自身的怪癖和不一致之处。
但是，随着 Web 标准的采用以及 Chrome 的 Blink、Firefox 中的 Mozilla 的 Gecko 和 Apple 的 WebKit 等现代浏览器引擎的演进，这些问题已大大减少。 因此，跨浏览器渲染问题正变得越来越少见。HTML5、CSS3 和现代 JavaScript API 等标准化技术的广泛应用，有助于简化开发流程。现在，各项特性和功能在不同浏览器中的表现更加一致，从而减少了对大量兼容性测试和复杂变通方法的需求。
尽管在极端情况下或使用较新的 Web 技术时，可能仍然会出现细微的差异，但整个 Web 生态系统已经发展到这样一个阶段：开发人员可以更加专注于创建无缝的用户体验，而不是解决浏览器之间的不一致问题，最终也减少了所需的测试。
基于高度分布式且通常松散耦合的组件构建的云原生应用程序架构的转变，正在慢慢瓦解传统的“单一管道”软件交付方式；使用单一 CI/CD 工具（例如 Jenkins 或 GitHub Actions）定期构建和部署应用程序的日子已经一去不复返了。相反，现代平台工程团队正在转向事件驱动且同样分布式的构建和部署管道，通常由 GitOps 驱动，以最大限度地提高其应用程序交付能力。
基于云的测试平台与软件交付的这种转变并不一致。自动化测试执行现在需要深入嵌入到构建和部署管道中，而不是由独立的（和基于云的）软件解决方案处理，在这些管道中，测试由基础设施事件触发并用作质量门，最好是利用 Kubernetes 自定义资源定义 (CRD) 等云原生结构来实现 GitOps 兼容性，并利用持续交付事件 (CDEvents) 来实现异步构建和部署管道。
团队可以利用现有的 Kubernetes 基础设施，而不是依赖外部云平台，从而改变测试自动化执行的方式。前端、端到端、API 和负载测试可以作为 Kubernetes 作业在应用程序所在的同一集群中动态启动，从而无需外部执行环境。
然而，Kubernetes 的潜力远不止于此。K8s 为软件应用程序带来了许多优势，例如：
- 可扩展性和负载均衡
- 高可用性和容错能力
- 高效的资源利用率
- 简化的部署和自动化
- 安全性和隔离
为什么不将这些应用于测试自动化呢？
- 在集群中以 Kubernetes 作业的形式运行测试自动化。将测试存储为 CRD，以实现 GitOps 兼容性。这将创建测试到特定集群（开发、暂存、生产或特定团队，这些团队可能在集群中拥有自己的命名空间）的映射。
- 定义和编排不同类型的测试，无论是 Postman 还是 Playwright 还是 Cupress 还是 K6，现在这些都只是“作业”。
- 触发您的测试不仅仅是在 CI/CD 构建之后或使用 GitHub Action，还可以在计划的时间、Kubernetes 事件或任何其他外部事件时触发。
- 分配测试以在并行 Kubernetes 节点上运行，以加快执行速度，并在完成后关闭这些资源。
- 收集所有类型的已运行测试的结果和工件，集中在一个位置，以便更快地进行调试，并提高团队和管理报告的透明度。
组织构建和部署软件的方式正在发生变化，他们进行测试自动化的方式也在发生变化。当基础设施是静态的，管道是单体的，并且扩展测试环境需要大量的运营工作时，依赖于基于云的测试平台是有意义的。但在 Kubernetes 原生的世界中，外包测试执行的传统模式正变得不必要的成本和约束。
现代软件团队不再需要在第三方解决方案和高维护的内部框架之间做出选择。转换应用程序部署的相同原则（可扩展性、自动化和自我修复基础设施）现在可以应用于测试。Kubernetes 不仅仅是应用程序的运行时；它是测试自动化的强大引擎。
组织不应将测试视为与基础设施隔离的单独流程，而应将其直接嵌入到其 Kubernetes 环境中。测试工作负载可以像任何其他工作负载一样进行调度、扩展和优化。这种转变不仅仅关乎效率，还关乎创建一种与现代软件交付相一致的测试执行模型。
像 Testkube 这样的解决方案正在推动这种转变，它们提供了一个框架，可以将测试作为 Kubernetes 作业执行，并以云原生方式与现有管道无缝集成。这不仅仅是工具的改变，更是团队思考测试执行方式的根本转变。