测试自动化：预防还是治疗？

本文要点

• 自动化 UI 测试被人们吹捧得神乎其神，然而真实并非如此。
• 相比自动化测试，探索性测试仍然具有很多好处。
• 把工作分解成更小的任务可以帮助你更快地发布。
• 了解敏捷的含义可以帮助团队做出更好的决策。
• 让团队在工作时仍有时间学习，这是一种在组织中培养持续学习文化的更好方法。

介绍

往往很多团队都认为自动化测试是一种加速软件交付的方式，这通常是团队内部感知到的瓶颈，但如果他们将开发实践作为一个整体更加深入地看待它，可能会得到更好的认知。

预防缺陷

测试（特别是在 UI 级别的测试自动化）往往都发生在软件交付流水线的末端，通常试图捕获那些可能溜进现场环境并对最终用户产生不利影响的 Bug(就像病菌一样！)。测试在此检测 Bug 的症状，由开发人员部署修复的补丁。这差不多类似我们等着系统生病之后，再试图做些什么。

这种方法对于团队来说是行之有效的，然而，当前的工作环境迫使我们用更少的人做更多的事情，而且还经比以前做得更快。因此，从长远来看，这种方法就支撑不起来了。这就是预防的用武之地了，而不是事后治疗。

通过调整构建系统的方式，我们能够在问题发生之前就检测到 Bug，或者更好情况的是，使它们一开始就更不容易被开发出来 (预防)。这意味着我们正在预防错误的发生，而不是试图在以后的某个时间去治疗它。常言道，预防胜于治疗。

我们的测试自动化之旅

我是与构建和管理我们的点播 (视频点播) 产品的移动团队一起开始的。在那个时候，我们所有的测试都是手工执行的，我们平均每年只在每个平台上发布 2 到 3 次。我们知道，我们想要加快速度，而最明显的瓶颈是测试。每个回归测试周期将花费近两周的时间，而且那是在没有发现任何问题的情况下。如果发现了问题，那么开发团队将需要理解问题，确定一个修复方案，然后去执行它。那么已经执行的所有测试可能就无效了，因此需要重新启动该过程，导致整个测试周期要花费两倍的时间。

所以我们开始着眼于自动化更多的 UI 测试。我们希望从小处着手，看看这是否会将我们引向所希望的方向，所以选择只自动化新功能。一旦证明和希望一致，我们将寻求将系统的现有部分或或已知存在问题的部分自动化。

我们使用“3 个朋友”作为一个团队来理解我们想要构建什么，以及该特性的关键验收标准应该是什么。这为我们提供了一个出发点，让我们了解如何分解该特性以及哪些用户旅程需要自动化。

在此基础上，我们确定了可以用来自动化测试的工具 (Calabash 和最终的 Appium)，并在实际环境中运行测试。对我们来说，这是在真实的手机上，而不是仿真器或模拟器，为此我们建立了自己的设备测试场，以更好地利用我们的移动设备，但也允许它跨整个组织予以扩展。

在我的博客上可以找到更多的细节，自动化 BBC iPlayer 移动测试 第一部分 ：用 3 个朋友来识别用例， 第二部分 ：自动化过程， 第三部分 ：遗留系统与新特性。

测试自动化带给我们的好处

起初，自动化帮助很大，因为我们现在可以快速可靠地运行简单的场景，并得到我们想要的快速反馈。但是随着时间的推移，在最初找到一组 Bug 之后，所能发现的问题就越来越少了，除非我们再实打实地去编写那些寻找它们的自动化测试用例。

我们还注意到有些问题仍然存在，因为有些场景我们无法自动化。例如，任何与可用性相关的东西都必须手工测试。因此，我们最终拿出了一个混合的解决方案，其中自动化将快速运行一些关键场景，例如让团队知道他们没有明显破坏掉任何东西，然后对任何新特性进行探索性测试，待时机成熟了，这些测试也可以自动化。因此，测试很有难度。我们在尝试测试时很容易出错，或者手工测试花费的时间太长。

但是，也出现了一个意想不到的好处，它与我们的自动化之旅间接相关，当我们开始更快地发布时，它使我们更加关注我们想要实现的目标。这促使我们将新功能分解成可以独立工作的小块，以便实现自动化。这样，我们就能够更快地将这些小块发布到现场环境中，并开始从最终用户那里获得真实的反馈。起初大家都没有注意到，因为我们仍在尝试确定自动化场景。只是在事后，团队才看到他们无意中做到的这一点。总之，我们开始将工作分解为一小批最终用户价值了。

调查我们的开发生命周期

我们开始意识到自动化 UI 测试并没有真正给我们所希望的回报。正因为如此，我们开始研究开发过程中的其他领域，看看是否可以做出什么改进。但作为一个团队，我们的问题之一是，我们太接近流程了，以至于无法客观地看到哪些是有效的，哪些是无效的。考虑到当局者迷，旁观者清，所以我们请来了一位敏捷教练来帮助我们的团队，以克服这个问题。准确来说，我们请来了两个：一个帮助团队理解他们正在使用的流程，另一个帮助我们更好地理解我们实际上是如何构建我们的系统的。

由于他们身处团队之外，使得他们可以触及我们系统中某些部分的痛处，而不用担心冒犯什么人，通过问一些简单的问题，以让我们了解我们工作方法背后的原因，并将我们从“我们一直都是这样做的”惯性思维中解脱出来。例如，用于管理我们工作的站立板通常有待办事项、接下来、开发、等待测试、正在测试和完成等列，但是我们从来没有想过问问为什么我们有接下来和等待测试列。我们的教练能够提供帮助的是，我们为什么让工作在这些栏中积压，为什么开发和测试被视为两个不同的活动。教练的方法并不是简单地改变我们的过程，而是帮助我们明白正在导致些什么问题 (未发布的价值戴着“接下来”和“等待测试”的面具呆在那里排起长龙)，让团队看到，通过消除开发和测试列，以一个简单的和自解释的“正在进行”列取而代之，令工作更简洁明了地直到“完成”。您可以在我的专栏文章《 在测试列中 》中找到更多关于使用这种方法的好处。

我们学到了什么

我们发现的最大问题之一是，就敏捷开发实践而言，我们的团队中存在大量的货物崇拜。仅仅因为我们有站立会，在小型团队中工作，并在迭代结束时发布些什么，并不意味着我们实际上是敏捷的。这只是意味着我们有一些仪式，让我们看起来像是“敏捷”的。事实证明，并不是每个人都很清楚我们为什么要这么做，甚至不清楚我们在哪里能得到什么好处。我们所做的第一件事就是澄清什么是敏捷。它更多的是基于客观反馈的可持续软件交付，而不是试图尽可能快地发布你所能发布的任何东西，并期望最好的结果。我们通过读书俱乐部和组织团队讨论来使团队内部达成共同的理解。这有助于团队成员更好地掌握敏捷实践背后的原则，并在他们的工作方式中做出更好的决策。

我们还开始研究我们在代码层实际上是如何构建系统的，并试图可视化开发人员是如何在哪里提交代码的、提交的频率有多少频繁，以及提交的规模有多大。这并不是试图让开发人员感到羞耻，而是帮助他们理解作为一个团队，他们是如何影响代码库的，并试图鼓励开发人员养成更高效的习惯，比如定期进行较小规模的提交，而不是在一天结束时提交一大堆。如果他们确实做了大量的提交，那也可以，但是要让其他开发人员知道他们为什么这样做，从而了解其中的原委。

我们对团队最大的改变之一是鼓励结对编程，因此没有一个开发人员单独开发一个特性。这不仅加快了代码评审的速度，而且当大家被要求承担责任时，他们也不太可能走捷径。它还有助于更快地提高我们团队中较年轻成员的技能和知识，相比于在虚拟项目上做一做，再由更资深成员把关的传统方法，他们能更快地提高生产能力。

我对更有成效和更健康的开发生命周期的建议

作为一个团队开展工作，并且在这个团队中确定一个高效、健康的开发过程是什么样的。

可以先考虑建立一个团队视频俱乐部，这是开始这些讨论的一个有用的方法。这让团队能够从日常活动中抽出一些时间来学习构建软件的新 工具 或新方法。在每次会议结束时，由会议负责人 (项目经理、技术负责人或将想法带给团队的人) 组织团队讨论，以探索他们如何使用这些概念来帮助推动团队尝试新事物。

然后选择一个概念，对应该有什么样的结果有一个清晰的想法，在此基础上开展工作。那么，如果我们以更好的单元测试为例，就要先弄清楚单元测试对团队意味着什么? 更好的单元测试会给团队带来什么? 一旦你对这些问题有了答案，就可以想出达到这个目的的多种方法，这样你就可以选择一个可以让你快速而客观地检验结果的方法。你需要弄清楚，你所使用的新过程或新技术是否真的帮助你在规定的时间内实现了你的目标。如果做到了，那就太好了。如果没有，你需要停止吗? 还是要继续做得更多? 或者需要做些调整? 您还需要决定由谁来实际运行这个实验，以及他们将如何与团队的其他成员进行沟通。

记住，如果你想让任何新流程或想法在团队中站稳脚跟，那么它们都需要大家的参与。否则，一旦露出困难的迹象，这个想法将被停止或举步维艰，只有投身其中，大家才能得到回报。

作者简介

Jitesh Gosai拥有超过 15 年的测试经验，曾与各种各样的公司合作，从移动制造商到操作系统构建者和应用程序开发人员。他目前是电视和广播部门的首席测试人员，与 BBC 的移动、电视和 Web 平台团队合作，帮助他们确定测试方法，以及这些团队如何迁移到 DevOps 以及后续工作。

查看英文原文： Test Automation: Prevention or Cure?