如何将棘手问题转化为策略，并在迁移所有测试的同时做到这一点

照片编辑由作者。Ruby标志的版权 © 2006, Yukihiro Matsumoto，Java标志由 LogoEps 提供。所有资源均获许可使用。

软件工程组织在其生命周期中的某个时刻往往会面临的一个重大挑战是无法偿还的技术债务。即使怀着最好的意图，这种情况确实可能发生，原因多种多样，其中之一是随着时间的推移，技术栈发生了变化，或者某种语言或框架在十年乃至二十年间失去其光彩。再加上不可避免的人才流失现象，这就形成了一个迁移的三重挑战。

在过去几年里，工程团队之间持续讨论的是我们用Ruby编写的庞大Cucumber回归（E2E）测试套件。随着时间推移，Ruby逐渐成为了我们技术堆栈中的被遗忘的孩子。最初它备受期待，团队中也有相当广泛的技能基础。Ruby和Cucumber都很受欢迎，所以大家也很喜欢用Ruby编写测试。直到某一天，这一切都不再那么受欢迎了。到了2021年，一提到我们的Cucumber测试，大家都会感到一种压抑的恐惧。大家都想摆脱它们，但没人有时间和精力去解决这个问题。毕竟，涉及的测试大约有200个。

到了2023年底，公司在Ruby技能上几乎没什么人才了，无论是基础设施还是开发。

重要的是要记住，回归测试不仅仅在真空环境中或本地机器上运行。编写和更新它们只是问题的一半。另一半则是一个完整的基础设施，使得这些测试可以作为你CI流水线的一部分运行。此时，不只是开发人员，甚至有开发者直接引用原话说“把它烧了”。我们负责维护 Ruby 基础设施的开发体验团队 (DX) 也因这种昂贵且不可持续的维护感到疲惫不堪，更不用说有些依赖项可能不再被支持，这将带来风险，进而阻碍我们产品关键版本的发布。我指的是这些 gem，无论是字面上还是比喻上。

Ruby 2.5: 发布日期: 2017-12-25, 终止支持日期: 2021-04-05  
Chrome 75: 发布日期: 2019-06-04, 版本号: 131  
Bundler gem v1.17.3: 发布日期: 2018-12-27, 最新版本: 2.5.23  
Cucumber 3.1: 发布日期: 2017-11-28, (最新版本未提供)

就像我的DX团队中的一位队友恰当地说的那样，那是一个随时可能爆炸的时间炸弹。上次我听到这话时，我不得不将整个前端从Angular 1迁移到React，同时还要将一个单体应用拆解成微前端（详情请参见此链接：文章）。

但说真的，我也经常会被那些长时间未解决的挑战吸引。也许这是一种自我肯定，这样的红色能量，或者就像我的一个治疗师朋友所说的“红能量”。

如果你曾经用愤怒来推动积极的变化，那就是你在利用红色的能量。

到2024年春天，这件事就确定下来了。我决定将所有Ruby Cucumber测试迁移到我们基于Java的E2E框架上，作为我个人今年的目标。我决定不惜一切代价完成这件事情。让我意想不到的是，我的同事Turu，来自QA团队的成员，有着相似的热情，有着非常相似的目标。我知道“协同效应”这个词90%的情况下都用得很没必要，在谈话中让人厌烦，但这次协同效应是真的存在。我本就需要QA团队的支持，看到我们的目标一致——喜欢这种会议上的行话，对吧？ 🙂 ——真是大大松了一口气，这意味着我们可以更均匀地分担任务，更快地完成——现在是我们的共同目标。信不信由你，有时候多一些人来帮忙确实能解决问题。虽然我非常欣赏Fred Brooks的软件工程经典之作《人月神话》，但它并不总是适用。

简单来说，我们可以称之为“环游世界八十天”的策略。我可以说我们设定期限为80天，但这听起来很无聊，把我们的成功与《环游世界八十天》联系起来听起来更有趣。无论你怎么称呼它，尤为关键的是，事后看来，这个过程对于顺利完成这次迁移至关重要。

我通过做很多概念验证项目和黑客松学到了这一点。设定一个不可动摇的限制——设计师对此深有感触——会激励人们。创意开始涌现，人们突然变得更有活力和适应性，并开始专注于真正重要的事情——在某个截止日期前实现目标。在这个案例中，我们给自己设定了大约80天的时间，目标就是全部迁移。

在80天内搞定所有迁移。怎樣做都行，關鍵是想辦法，同時保持務實，快點把它搞定。

任何从事软件开发的人都知道，优先级设定是一件棘手的事情。很多事情都取决于它。我在本地运行了所有的Cucumber测试后，很快意识到我们需要聪明地决定迁移的项目、时间和原因，以确保我们保持高效。

• 我联系了各个团队，了解他们是否有冗余或已经不再适用的测试。一些团队确实有，所以我将它们标记为删除。
• 我查看了当前通过的测试，并创建了第一批需要迁移的测试。这些测试被优先迁移，因为它们运行在实时软件上，供数百万客户使用，如果由于某种原因我们突然时间紧迫，至少我们也能确保最重要的测试迁移完成。
• 然后我创建了第二批测试，而我的质量保证同事已经开始帮忙将它们迁移到我们自己的测试自动化框架(TAF)。第二批测试包括所有不稳定的测试，这些测试由于各种原因失败或被禁用。
• 最后还有一组测试，覆盖了一些我们的A/B测试。最初，我差点犯了错误，从这些测试开始迁移，但后来意识到到迁移结束时，大多数A/B测试已经结束。事实确实如此，在大约20个测试中，我们只需要为其中三个编写新测试。

一旦优先级确定后，QA团队（部分时间）和我自己（全职）开始着手实施。一次接一次，一天接一天，我们能够看到进展。我们使用了交通灯系统。迁移完成的测试我们标记为绿色 🟢，正在处理中的测试标记为琥珀色 🟠，我们发现不需要迁移的测试则标记为红色 ❌。在整个过程中，每个人都知道每个人在处理哪些测试。我尽量减少在Jira上的时间，更多地使用Confluence文档进行跟踪。

我们在节约时间的措施上是否非常坚决？但我们是否按时完成了工作？毫无疑问啊！

一旦所有测试迁移完成，QA 进行了最后的检查，确保所有标记无误、没有遗漏任何重要的测试案例，并且我们创建了一个日志表，显示每个 Cucumber 测试最终迁移到哪个 TAF 测试上。仅在迁移几天后，工程师们已经开始利用这个日志表，因为他们需要找到这些旧的 Cucumber 测试用例的新位置。

作者在Freeform中创建的整个过程的图表。

策略的最后一步是正确配置 CI。我们希望确保这些测试能够并行运行，但在这样做的过程中，我们必须考虑到基础设施成本。我们的 Ruby 测试虽然在其他方面是个麻烦，但使用的资源相对较少，而 Java 测试则资源消耗稍微大一些。但 DX 找到了一个合适的资源与测试比例来控制成本。有了这些措施，我有幸点击仓库归档按钮并向全公司宣布我们终于全面淘汰了所有的 Cucumber 测试。

回首过去，试着在我的脑海里梳理一下哪些做得好，我们是怎么最终成功完成这次迁移的。有几点浮现在我的脑海里，我觉得这些对于任何未来的成功项目都是关键。

我们有一个共同的目标。这一点的重要性怎么强调也不过分，即大家需要朝着同一个方向努力。这使那些正在工作的人能够集中精力并做得更好。因此，我的团队和QA团队的支持至关重要。我们的高级自动化QA专家Turu也将这次迁移作为他个人的第三季度目标，就像我一样，所以我们都非常致力于成功完成这项工作。

零浪费的时间。 除了与QA进行几次初步会议，以及我和我的团队讨论我们想要达成的目标及一些历史背景之外，我们唯一的会议是每周我和Turu之间的一个小时同步会。在整个十周的项目中，这大约只相当于一天的会议时间。这并不是说会议不好，只是有时候它们可能会拖累项目，而我们负担不起这种奢侈。

心里清楚目标是什么，目标非常明确：尽可能高效地在我们拥有的时间内将所有测试迁移完毕。有时，这需要我们将更多的测试场景合并成一个，或者将一个测试合并到现有的测试场景中，而不是作为一个独立的测试。

对于每个测试，我们根据情况采取了最合理的方法，而不是机械地照搬，而是灵活应对。

但这是一部工程（包括质量保证）的成功案例，并且正如我在《如何向产品经理销售工程需求》中提到的，作为工程师，我们应当把工程需求转化为商业需求。我也会尽量避免那些没有商业价值的工作，虽然我不是首席财务官，也不打算成为首席财务官，但如果某个工作没有商业价值，我也会觉得不舒服。但也没有项目只是为了“阿提拉觉得合适”而进行，所以，让我们把这个特定的工程需求转化为商业需求。

如果你用的是一种没人懂或没人愿意去学的语言来写测试，这些测试要么编写得很差，要么根本就没有编写。这会增加客户遇到严重问题而不被及时发现的风险，直到客户支持发现问题时才发现，到那时已经太晚，花费巨大。因此，编写更完善的产品会减少客户支持电话，也就是说节省了开支。

另一个缺点是维护旧的测试基础设施，因为这些基础设施已经严重过时。理想情况下，软件公司希望尽可能少地花费在维护上。特性和A/B测试更有趣，它们也能带来更多收入。维护成本是理想成本的10倍，是财务上的浪费，会降低士气，甚至可能成为无法招聘新工程师的原因。工程资金有限，我们更愿意将资金花在新工具或增加人员上，而不是维护那些已经严重过时的基础设施。

简化真的能提升速度，就是这样。

正如我们的DX团队反复强调的，我们一直在一个定时引爆的炸弹上。每天醒来都面临我们依赖的Ruby-Cucumber代码库因年代久远而被移除的风险，这些代码库支撑着我们产品的核心功能，如注册、支付和分析。这种状况可能导致产品严重中断，A/B测试的时间浪费，客服成本会变高，甚至持续数周甚至数月。这绝对不行，尤其是在公司处在增长阶段的时候。

最后，这次迁移也极大地促进了效率，是一个巨大的推动因素。在几周内完成之后，我们将所有测试集中在一起，就已经能够识别出可以提高测试效率的地方，减少在持续集成中花费的时间，并对正在测试的内容更有信心——也就是真正了解并提升我们的覆盖率。这只能意味着一件事：在2025年及以后更快的速度，而产品经理最想听到的莫过于更高的吞吐量了。😉

当我和QA完成迁移工作时，我不禁得出了某些相关的结论，我认为这些结论将会让许多软件工程师和质量工程师在未来几年中深思。

虽然对包括我在内的一些人来说，完成这样的迁移是一项令人兴奋的机会，但对于大多数工程师来说，他们不会自愿去做这样的迁移，这有充分的理由。迁移可能是一堆棘手的问题，你将接触到从未见过且不了解的遗留代码。你可能是在摸着石头过河。

然后还有工作中的单调性。特别是编写端到端测试时，一旦框架中的所有内容都准备就绪，编写测试本身可能会让人感觉有些单调，这让我想到了我的下一个观点以及一个有趣的发现，即。

有一次，纯粹是运气好，我下载了支持全行代码补全功能的IntelliJ最新版本。几分钟后，IDE就开始提示我下一行该写什么代码了，不管是新的页面对象还是断言，结果常常都是对的！这让我在迁移过程中省了不少时间，有时候能省下两三天。这不就是机器学习在人类监督下的应用嘛，这让我开始思考……

如果要说未来我最想让生成式AI接手的工作，那就是维护和迁移工作。

要是能让模型接收我们的 Cucumber 和 TAF 测试，让它识别出缺少的内容，迁移这些测试用例，运行这些测试并几乎不需要人工干预地部署，那该多好。这正是我非常愿意支持的事情，谁知道呢，再加上一些健康的“红能量”，这一切也许很快就会变为现实。 😉

阿提拉·瓦戈 — 软件工程师，通过一行行代码改变世界。自小就是科技迷，代码、博客和书籍的创作者。作者。网站可访问性倡导者，乐高迷，黑胶唱片爱好者。热爱精酿啤酒！在这里阅读我的“Hello”故事！__订阅 __获取更多关于 乐高,[科技](https://medium.com/@attilavago/list/technology-tech-news-a2d2d509b856),编程和[可访问性](https://medium.com/@attilavago/list/accessibility-4b67c1d08ef3)_方面的故事！对于那些不太经常阅读我的文章的朋友，我也会写一些关于_[各种话题](https://medium.com/@attilavago/list/the-random-stuff-96bfc5a222e5)和写作_的文章。