关注留言点赞，带你了解最流行的软件开发知识与最新科技行业趋势。

2018 年，发布团队比现在小得多，发布还没有定期进行，公司的所有 QA 工程师都参与了发布前检查。但是，这非常耗时，并且显着减慢了整个开发过程。决定对发布的每个应用程序的测试将由发布团队单独进行。

当时，发布周期持续了两周。该团队有 3 名 QA 工程师，他们每周花 2-3 天全职时间检查其中一个交替平台的发布版本。除了检查发布，这些人还忙于简化发布流程、编写文档、引导新人以及更新 TMS 中的测试用例。

这种方法有很多缺点：

• 缺陷只能在检查的 2-3 天内发现，因此需要更多时间来修复它们，并且上市时间 (TTM) 也会增加。
• 如果团队中的任何人都无法参与发布的测试，那么其他团队成员的工作量就会大大增加，检查所需的时间也会增加。
• 长时间发布的检查很乏味，遗漏缺陷的可能性也会增加。
• 跨设备的覆盖率较低，这意味着特定缺陷更有可能被遗漏。
• 在检查期间，您必须掌握所有新功能以及配置测试环境以适应它们的方法。因此，测试用例和其他文档必须在功能进入发布之前完美编写。否则，检查过程会减慢：大量时间会浪费在澄清所有细微差别上。

更改发布检查流程

2021 年底，我们决定将发布检查扩大到所有团队的 QA 工程师。我们决定，从 2022 年开始，我们将每周同时检查两个移动平台，并停止使用 TMS TestRail 来支持 Qase，因为前者非常慢并且一直在下降。

由于移动应用程序的自动分支切割和发布构建的形成过去在周五晚上进行，因此选择周一作为检查发布的最合适的日子。每个团队的技术负责人都知道，在星期一的四个小时里，QA 工程师将只负责发布检查。在这四个小时里，技术主管不得不取消或至少减少任何本应由 QA 工程师参与的团队活动。

反过来，在检查开始时，发布团队将准备相关的测试环境，形成测试运行并将它们分发到所有案例。从而解决了上述问题：

• 所有错误报告都是在星期一的前四个小时内编译的，因此，修复程序会在更早的阶段放入发布版本中。
• 如果几个 QA 工程师无法参与发布检查，这实际上对发布检查的执行速度没有影响。
• 释放检查不会超过四个小时——而且在这种时间间隔内保持注意力和警觉性要容易得多。
• 跨设备的覆盖水平上升了好几倍。
• 某些非常具体的新功能最初由其“所有者”检查，然后逐渐在整个团队中推广。

发布团队还与开发各种测试工具的 QA 自动化团队一起编写 UI 自测试。为此，使用了以下工具：

• 阿皮乌斯
• 科特林，JUnit 5
• 硒
• 引诱

结果

目前，UI 测试已经覆盖了验收集中所有测试用例的大约 30%。它们在发布分支上的剪切后立即启动，并且它们的结果以 Allure 报告的形式由机器人发送给 Slack。随着这个自动化过程的展开，测试用例被从发布运行的池中取出。在发布检查期间，值班 QA 工程师手动检查失败的测试，并在必要时编写错误报告：

为了让测试保持绿色并提前发现错误，它们每晚都会在开发构建中启动。之后，值班 QA 在一个特殊的仪表板上输入新的测试更新任务或错误报告。任何人都可以在 GitHub Actions 的帮助下启动一系列测试。

由于上述更改，构建发布检查的持续时间从大约 72 小时减少到 4 小时，而不会牺牲任何产品质量。

发布团队遇到的问题之一是时区问题。我们的员工分布在不同的城市和国家，这使得同时发布检查远非易事。不过考虑到大部分工程师都分布在三个时区，考虑到大家的作息时间，决定让检查的时间尽量接近。例如，在阿拉木图，发布检查从早上开始。

另一个问题与这样一个事实有关，即为了让大量工程师参与同一过程，需要在组织方面做出特别的努力：

• 拟定参与发布的人员名单，将假期和休息日考虑在内。
• 如果有人在通过它们时遇到任何问题，请在发布过程中重新分配案例。
• 及时检查和准备测试环境，并用交付应用程序构建的方法做同样的事情，这样就没有停机时间。
• 检查以确保开发人员及时着手解决发布版本中发现的任何缺陷。
• 回答参与流程的人员提出的任何问题，并处理任何意外情况。

为了解决这个问题，发布团队中的一位QA工程师引入了每周职责流程，他承担了上述所有职责，并独立地从头到尾陪伴发布。

首先，很难确定发布检查需要多长时间。为了校准其持续时间，它正在处理的案件的进展情况会每小时记录一次。事实证明，四个小时的间隔非常适合这项任务，并使每个人都能以舒适的速度完成发布。

此后，发布团队在流程中留下了记录发布进度的要求。下表显示了在发布检查的特定阶段已完成的发布运行案例的百分比。可以看出，检查总耗时逐渐下降：

现在，检查应用程序发布版本所需的时间正在逐渐减少。过渡到此流程后，产品功能的 TTM 显着降低，同时提高了检查质量。与此同时，发布过程对所有其他团队来说变得更加可预测和透明。