如果一个测试用例值得花费时间和精力进行自动化,那么这是一个有用的指导方针

作者:查尔斯·罗德里格斯和亚历杭德罗·贝拉迪内利

“让我们尽可能多地自动化测试。”这听起来总是一个好主意,对吗?这是整个世界的发展趋势,不是吗?在软件测试中,自动化可以极大地提高生产率,但只有在某些情况下。

在这篇文章中,我们将介绍一种测试自动化目的是根据项目背景确认其可行性。对于测试人员来说,了解什么是自动化以及清楚什么是可自动化的是非常有用的。测试人员应该注意如何优化他们的工作,无论是与其他同事、开发人员合作,还是鼓励自己尝试自动化工具。

我们将介绍一些在您还没有自动化经验时非常重要的概念,并评估它们与手动测试相关的重要性和好处。

什么是测试自动化?

从历史上看,自动化的出现是为了减少可编程系统或机器复制的活动所需的人力,目的是简化繁重、重复或复杂的工作,使其更有效、更高效。这样,就可以节省能源、时间和成本,同时让人们专注于其他工作呃任务。

在软件开发中,这种做法也可以通过自动化手动完成的某些工作来实现。人类遵循的步骤被转换为可重复的脚本,因此他们可以将精力集中在其他提供更大价值和减少执行时间的特定任务上。在某些情况下,自动化允许我们执行orm测试是人类无法完成的,特别是考虑到我们在一定时间内可以执行的执行次数的限制。

当测试人员考虑自动化时,最常见的问题之一是,“什么时候可以自动化?”

了解是否应该实现自动化包括评估潜在的投资、方法、好处,最重要的是,评估目前对手动流程的了解。

我们首先必须充分理解并成为手动过程的专家,只有这样才能实现自动化。手动过程的完整知识是知道什么时候可以自动化的支柱,这意味着手动测试不是完全可以替代的。(关于人工测试即将消亡的问题,经常有争论。它根本不会消亡!)

自动化神话

自动化有其优缺点,取决于项目、时间、成本、质量和方法。

基于以上,另一个非常重要的一点是,除了自动化或不自动化之外,您还必须理解上下文你所做的一切都是基于以最好的方式实现目标,选择和应用适当的方法、工具和技能。

避免陷入这些关于测试自动化的常见误区:

  • 你可以自动化一切
  • 自动化总是导致更好的软件质量
  • 自动化测试比手工测试好
  • 自动化带来了快速的投资回报

当然,有时这些神话中的一个可能是真的,但这是一个例外。

在上下文驱动的测试学校中,解释了以下七项原则,有助于理解测试目标,无论是手动测试还是自动测试:

  • 任何实践的价值都取决于其背景。
  • 有好的做法在上下文中,但没有“良好做法”。
  • 人们一起工作是任何项目环境中最重要的部分。
  • 项目不是静态的,通常采用不可预测的路径。
  • 产品是解决方案。如果问题没有解决,产品将无法工作。
  • 好的软件测试是一个具有挑战性的智力过程。
  • 只有通过判断力和技能,在整个项目中合作实践,我们才能在正确的时间做正确的事情,有效地测试我们的产品。

这些原则是由塞姆·凯恩、詹姆斯·巴赫和布雷特·佩蒂肖德在他们的书中提出的。”软件测试中的经验教训:一种上下文驱动的方法,“这有助于我们掌握适应当前项目情况的能力的重要性。

手动与自动

开始时,我们可能希望自动化所有内容,但是为自动化测试开发和维护脚本的成本不可掉以轻心。

当一个项目押注于自动化时,理想情况下,它应该有一个坚实的基础,从单元测试用例开始,通过即时反馈防止尽可能多的bug,然后继续到不同的层。这样,手动和探索性测试在UI级最有价值,重点放在那些不可能自动化的测试上。

这个概念是由Michael Cohen解释的测试自动化金字塔:

自动化金字塔最佳敏捷测试实践

在左边,我们看到了自动化通常是如何实现的,在右边,我们可以看到理想的方式,单元测试在金字塔中占有最大的权重。

尽管自动测试和手动测试之间存在差异,但它们并不是相互排斥的,而是在寻求更好的软件质量时被视为补充任务。

如果我们考虑测试的投资回报,手动测试新功能可以让您以较低的成本快速了解更多的应用程序。随着知识的获取,测试的库存增加,因此,手动测试的成本也增加。另一方面,自动化具有更高的初始成本,随着自动化的发展,成本会降低。这种行为可以在下图中看到(从这里开始):

自动化与手动测试成本

分析这一点,我们发现自动化在“临界点”之前有着巨大的初始投资,与手动测试相比,我们开始看到它对长期成本产生的积极影响,我们可以评估这两种测试活动完全兼容,产生短期和长期效益。

自动化什么?

现在,我们已经意识到自动化的重要性和好处,我们必须确定我们可以自动化的案例。为此,我们必须考虑正在追求的目标以及在什么水平上,正如我们在科恩金字塔中看到的那样。

尝试回答以下问题:

目标是什么?

我们正在寻找的第一件事是始终旨在实现更高水平的软件质量,并分析项目内的自动化“适合”。

为了回答这个问题,最好对目标进行可行性分析。

以下是一些最有可能实现自动化的场景:

  • 需要消除技术债务
  • 回归测试非常耗时。
  • 该项目是高度复杂和长期的

我们应该自动化哪些测试用例?

正如我们所看到的,并不是所有的事情在上下文中都是自动化的,这就是为什么知道哪些案例适合我们的目的是相关的。从代码级别和开发人员角度考虑,单元测试是最容易生成脚本的。在测试人员方面,我们通常致力于在UI和API级别自动化回归案例,首先考虑最关键和最复杂的流。

以下是可自动化的测试用例:

回归测试

在这种情况下,我们已经定义了一个测试套件,必须在每次产品发布后定期执行,手动运行这些套件的工作变得重复,此外还需要从其他不可自动化的任务中抽出时间,我们可以在这些任务中提供更多价值。

这些回归测试用例高度自动化,特别便于集成到CI/CD模型中。这增加了执行其他任务所需的成本和时间,因为脚本可以在执行其他活动时无人值守地执行。

高风险测试

这些案例通常得到利益相关者的同意,重点放在检查高优先级和关键功能上,如果这些功能失败,将极大地影响业务模型。这就是为什么这种方法被称为“基于风险的测试”。

自动化测试这些功能的案例有助于在每次发布后立即发现必须迅速采取行动的事件,并且可以阻止所述发布的生产。

复杂和/或耗时的测试

在一个项目中,可能会有一些复杂的情况需要手动复制,因此,如果我们将其转换为脚本,那么以自动化的方式执行它们会更容易。如果是一个包含大量数据的表单,可能测试人员更容易出错,尤其是当他或她必须使用多种数据测试同一表单时。我们可以降低出错的概率通过自动化来提高效率。

重复测试用例

正如回归测试成为一项重复性任务一样,在某些特定情况下,我们可以方便地实现自动化。例如,可以这样说,通过手动测试同一流程中的大量数据,这将花费我们相当长的时间,如果我们也必须重复,这将变得有些困难然而,通过自动化此流程,我们可以参数化此数据,而不必手动测试每个值。这也被称为数据驱动测试,其中自动测试是参数化的,并由数据源(如文件或数据库)提供数据。

工具选择

现在我们知道了要自动化什么,我们可以继续选择我们要使用的工具。考虑到可用工具的数量,这项活动可能是最初要分析的最复杂的活动之一,但决策必须考虑项目、预算、知识和经验。

几种开源、商业和定制工具它们的局限性和可能性各不相同。要选择正确的工具,您必须清楚必须满足哪些要求才能继续对其使用进行成本效益分析。

在Ab德赢vwin登入stracta,我们根据项目的上下文选择各种各样的工具,但我们经常使用,阿皮姆,黄瓜,鬼督察GXtest考虑到它们提供的灵活性。

屏幕截图2019-04-18上午11时14分

以下是我们最喜欢的测试自动化工具的简要概述:

  • 硒:作为一种开源工具,它被世界各地广泛接受,用于在不同浏览器和平台上测试web应用程序。
  • 阿皮姆:另一个开源框架(基于Selenium),主要用于在iOS和Android移动设备上自动化测试。
  • 黄瓜:此工具是BDD的一部分(行为驱动开发)接近。Cucumber的主要优势在于它的易用性,因为它非常直观,提供了各种各样的功能,并且是开源的。
  • 幽灵检查员:这个工具最值得注意的一点是,它允许我们在不知道如何编码的情况下实现自动化,这对初学者来说非常好。另一方面,这个工具是商业化的,每月只允许100次免费执行。请参阅我们的全面检讨鬼督察.
  • GXtest:在Ab德赢vwin登入stracta,我们开发了GXtest以一种简单的方式(唯一的一种)为Genexus开发的应用程序实现自动化。它还允许在CI/CD模型中集成测试。

需要注意的是,没有适合所有情况的最佳工具。是的,我们可以在提供更大灵活性的应用程序之间进行选择,尽管这将始终取决于被测试的应用程序和决策标准。

结论

一般来说,我们可以找到不同的方法来指导我们的自动化工作,但是最重要的是要有明确的目的和目标。测试中的应用程序的上下文并不是次要的细节,我们应该知道,并不是所有的东西都是可以自动化的,因为投资回报来自于良好的可行性分析工作。

在任何情况下,如果发生自动化,强烈建议在所有级别进行自动化,并在最低级别(如单元和API测试)进行更大的努力,而不仅仅是在UI级别。

考虑到上述因素,我们将能够防止更多的错误,并伴随手动测试“需要测试人员的能力,从而避免可以编程的重复任务的过度负载。

更多资源

为了深入研究自动化并了解何时自动化测试,以下是一些优秀的资源:

阅读我们的功能测试自动化电子书