将遗留测试套件迁移到基于 Kotlin 的 Gauge 框架的经验总结

在Online TestConf大会上，Liran Yushinsky 分享了他们团队如何用统一的 Kotlin + Gauge 框架取代了原本脆弱的 Bash 脚本和 kubectl 测试。他们利用 Fabric8、Terraform 和 Ansible 实现了测试环境的自动化。这一改进将反馈周期从数小时缩短到几分钟，开发人员也积极参与到测试工作中，共同承担责任，从而提升了软件质量和发布速度。

Yushinsky 提到，他们原先的测试体系十分分散，混合使用了 Bash 脚本、kubectl 命令以及基于 SSH 的 Kubernetes 工作负载检查。他表示，这种方式导致测试非常脆弱且难以维护。

他还指出，测试环境之间经常出现配置漂移——例如，在预发环境中能通过的测试，在 QA 环境中却会失败。反馈周期缓慢，一次端到端的测试可能耗时数小时。此外，由于缺乏统一的测试框架，团队新成员上手困难，测试的不稳定性也很高。

随后，Yushinsky 介绍了他们是如何标准化测试环境的：

我们使用Gauge作为测试运行器，用Kotlin构建了一个共享的自动化测试库。我们将原有的 Shell 脚本和 kubectl 命令替换为 Fabric8 Kubernetes 客户端，从而获得了更强的控制力，并显著减少了测试的不稳定性。

 

我们还通过 Ansible 和 Terraform 实现了测试环境的自动部署，确保每次测试都在可复现的环境中运行。在 Jenkins 中，我们将这些测试集成到自动化流水线中，测试结果会自动发送到 Slack，并在 Grafana 中进行可视化展示。

他还提到，团队开展了内部培训、午餐学习会、代码评审以及提供标准化模板，以推动整个公司逐步采纳这一新方法。

Yushinsky 表示，他们首先在一个非关键服务上启动试点项目，以验证该方案的可行性，并构建了一个可复用的测试步骤库，让工程师们无需重复造轮子。随后，他们在内部演示中分享成功案例，并逐步将更多服务迁移到这一框架下。他们还实现了测试报告的自动化，使所有相关人员都能在 Slack 和仪表盘上实时查看测试结果，从而建立起对这套系统的信任。

Yushinsky 提到，起初团队成员习惯于使用自己编写的脚本：

我们通过展示旧方式在手动操作或不稳定测试上浪费了多少时间，来克服这种惯性——有些端到端测试过去需要数小时，如果因不可预测的原因失败，甚至可能阻塞半天的部署流程。同时，我们也展示了新方法能多么迅速地捕获回归问题。

他表示，Kotlin 和 Gauge 的学习曲线相当陡峭。团队通过提供模板、在最初几个测试用例上进行结对编程，并在持续 CI 中快速展示成效，成功克服了这一挑战：

你需要在变革管理上投入时间。仅靠技术本身无法确保成功；你需要创造可见的成果，以身作则地教学，并让其他人能够轻松参与贡献。

Yushinsky 表示，借助这套自动化框架，反馈周期大大缩短。如今他们可以在几分钟内运行完整的端到端测试，而过去需要数小时；部署变得更加可靠，也能更早地发现回归问题。

他解释道，Gauge 编写的可读性场景使测试变成了团队共享的资产。过去，只有 QA 工程师会接触这些测试；而现在，得益于 Gauge 的自然语言规范和 Kotlin 编写的步骤，开发人员在开发功能时也会主动编写和扩展测试——这是一次重大的文化转变：

起初，一些开发人员对“拥有测试”持怀疑态度。但当他们亲身体验到这个框架有多快，以及它如何帮助他们在代码评审前就发现自己的缺陷之后，便欣然接受了。新员工也能更快地上手，因为步骤库本身就充当了活文档。此外，通过 Slack 告警和 Grafana 仪表盘，我们对测试的健康状况和趋势拥有了全面的可见性。

Yushinsky 表示：“推出新的测试框架，关键不仅在于技术，更在于人。通过快速胜利和渐进式推广来建立可信度，而共同承担责任则能防止测试套件变得陈旧过时。”

InfoQ 就自动化测试话题采访了Liran Yushinsky。

InfoQ：你们是如何让 QA 以外的人员参与到自动化测试环境中的？

Liran Yushinsky：我们邀请了开发人员、DevOps 工程师，甚至产品经理参加我们的午餐学习会和内部演示。目的是向大家表明，这些测试并不是“QA 的事”，而是我们整个交付流水线中共同的一部分。

 

这些活动反响很好，因为参与者能立刻看到我们试图解决的痛点——测试的不稳定、手动操作步骤的繁多、反馈周期的漫长。同时，这也让他们有机会参与到框架的设计和演进，发出自己的声音。

InfoQ：是什么促使你们决定采用自动化测试框架的？

Yushinsky：我们希望找到一种既能被 QA 也能被开发人员轻松阅读，又足够灵活、能够编写复杂测试的方案。Gauge 支持实时文档和标签，与 Kotlin 集成良好，并且支持并行执行，有效解决了我们过去测试执行时间过长的问题。此外，它丰富的报告功能和插件生态也让我们能轻松将其集成到 Jenkins、Pact 和 Testcontainers 等我们已经在使用的工具中。

 

下面是一段代码示例，展示了 Gauge 的场景如何与 Kotlin 的步骤定义对应——包括一个规格文件、一个概念以及一个匹配的步骤实现：

InfoQ：你们在处理不稳定的测试时遇到了哪些挑战？又是如何应对的？

Yushinsky： 我们引入了重试机制，并使用 Testcontainers 来隔离依赖项（例如 K3s 集群），将原本动辄数小时的测试运行时间缩短到几十分钟，同时将随机失败的情况减少到仅剩极少数边缘场景。此外，我们还增加了前置检查和针对升级场景的专用测试用例，以便在版本漂移影响生产环境之前就将其捕获。为了确保测试套件的可维护性，我们还通过代码评审强制推行统一的命名规范和标签约定。

原文链接：

https://www.infoq.com/news/2025/12/migrating-test-suite/