代码之家  ›  专栏  ›  技术社区  ›  Matthew Dewell

BDD GUI自动化

  •  1
  • Matthew Dewell  · 技术社区  · 7 年前

    我在生活中开始了一个新角色。我曾经是一名前端web开发人员,但现在我开始测试web软件,或者更确切地说,自动化软件测试。我相信我会追求BDD(行为驱动开发)方法。我完全不知道该用什么,以及如何把它拼凑起来。

    正在使用/编写的代码是用Java编写的,用于为要测试的应用程序编写web界面。我有要运行的测试文档,但我一直想知道如何实现自动化。

    我被指示将黄瓜作为一种“语言”来帮助实现自动化。我做了一些研究,并在一个网站上找到了BDD工具/框架的概要, 8 Best Behavior Driven Development (BDD) Tools and Testing Frameworks . 这有点帮助,但后来我对如何实现它有点困惑。在许多用于测试GUI的BDD框架中,Selenium似乎是一个共同点,但它似乎仍然不能帮助描述该做什么。

    然后我遇到了这个词 Functional Testing tool ,我想这让我更加困惑。他们都测试GUI吗?

    我想看起来像是一个包裹的那个 SmartBear TestComplete ,然后是SmartBear的另一个类似应用程序, SmartBear TestLeft ,但我想我看到他们仍然用黄瓜来做装饰。还有一些其他的看起来也可以,但我想另一个问题是,最便宜的路线是什么?

    我想我面临的最大问题是如何使这些测试更具动态性,因为UI/浏览器维度可以很容易地从一个系统更改到另一个系统,如何编写能够处理这一问题的自动化程序,并与BDD方法相结合?

    这里有人有什么建议吗?外面有人这样做吗?

    提前谢谢。

    3 回复  |  直到 7 年前
        1
  •  2
  •   Lunivore    7 年前

    BDD体系结构

    BDD自动化通常由几个层组成:

    1. 自然语言步骤
    2. 将步骤与其定义联系起来的接线
    3. 步骤定义,通常访问页面对象
    4. 页面对象,提供页面或小部件的所有功能
    5. 通常通过GUI对正在执行的实际代码进行自动化。

    自然语言步骤和步骤定义之间的连接通常由BDD工具(Cucumber)完成。

    自动化通常使用自动化工具(Selenium)完成。有时,人们确实会跳过GUI,可能是针对API或MVC层。这取决于网页中的功能有多复杂。如果有疑问,请尝试硒。我已经为桌面应用程序编写了自动化框架;不管怎样,原则都是一样的。

    保持it的可维护性

    为了使步骤易于维护和更改,请将步骤保持在相当高的级别。这通常被称为“声明性”而不是“命令性”。例如,这太详细了:

    When Fred provides his receipt
    And his receipt is scanned
    And the cashier clicks "Refund to original card"
    And the card is inserted...
    

    思考用户想要实现的目标:

    When Fred gets a refund to his original card
    

    通常情况下,一个场景会有几个Givens或Thens,但通常只有一个When(除非您有一些类似于用户交互或时间流逝的东西,其中需要两个事件来说明行为)。

    在这种情况下,您的页面对象很可能是一个“ReturnPageObject”,或者如果太大,可能是一个“ReturnToCardPageObject”。此模式允许多个场景步骤访问相同的功能,而不会重复,这意味着如果功能的使用方式发生变化,您只需要在一个地方进行更改。

    不同的页面对象也可以用于不同的系统。

    开始

    如果您是第一次攻击这个问题,那么从获取一个空的场景开始,该场景只运行并通过,不做任何事情(将步骤设置为空)。完成此操作后,您将成功连接Cucumber。

    编写生产代码 运行场景。(这与通常的做法相反;通常先编写场景代码。但我发现这是一种很好的入门方式。)

    当您可以手动运行场景时,直接将自动化添加到步骤中(此时您只有一个场景)。使用您最喜欢的断言包(JUnit)获得您想要的结果。您可能需要更改代码,以便可以轻松地对其进行自动化,例如:为网页中的元素提供相关的测试ID。

    一旦您运行了一个场景,请尝试先编写任何后续场景;这有助于您思考您的设计和您将要做的事情的可测试性。当您开始添加更多场景时,也开始将该自动化提取到页面对象中。

    一旦有了一些场景,就可以考虑如何处理不同的系统。尽可能避免使用大量“如果”语句;这些很难维护。注入页面对象的不同实现可能更好(到目前为止,框架可能很好地支持这一点;我已经有一段时间没有使用它们了)。

    在添加更多场景时继续重构。如果台阶太大,就把它们分开。如果页面对象太大,请将它们划分为小部件。我喜欢根据用户/干系人的能力(通常与“何时”相关,但有时与“当时”)然后根据不同的上下文来组织我的场景。

    综上所述:

    1. 编写空方案
    2. 编写代码手动通过
    3. 使用自动化工具连接场景;现在应该可以运行了!
    4. 编写另一个场景,这次编写自动化 之前 生产代码
    5. 重构自动化,将其从步骤移到页面对象中
    6. 在添加更多场景时继续重构。

    现在,您已经拥有了一个完全有线的BDD框架,您可以在保持其可维护性的同时继续前进。

    最后的提示

    可以将其视为动态文档,而不是测试。BDD场景很少在好的团队中发现bug;他们捕捉到的任何东西通常都是代码设计问题,所以请在该级别解决它。它帮助人们了解代码做了什么和没有做什么,以及为什么它有价值。

    BDD最重要的部分是就代码如何工作进行对话。如果您正在对已经存在的代码进行自动化测试,那么至少可以找个人谈谈复杂的部分,并与他们验证您的理解。这也将帮助您在场景中使用正确的语言。

    See my post on using BDD with legacy systems for more. 在这个博客上也有很多对初学者的提示。

        2
  •  0
  •   Thomas Sundberg    7 年前

    既然你对从哪里开始感到迷茫,我将向你提示我写的一些博客,其中谈到了你的问题。

    一些类别可能会帮助您:

    这篇很长很旧的帖子也可能给你一些提示:

    http://www.thinkcode.se/blog/2012/11/01/cucumberjvm-not-just-for-testing-guis

    请注意,版本是过时的,但希望它可以提供一些想法,作为太寻找。

        3
  •  0
  •   user9232224    7 年前

    我不是测试自动化方面的专家,但我目前正在从事这方面的工作。因此,让我分享一些想法,并希望在现阶段对您有所帮助。 我们已经使用selenium+cucumber+intellij来测试web应用程序。我们使用testcomplete+cucumber+intellij来测试java桌面应用程序。

    对于web应用程序的测试,我们在web应用程序中提供了一个测试模式,它允许我们获得一些有用的产品和环境的详细信息;还允许我们通过单击按钮并在测试模式下向测试面板输入文本来轻松触发事件。

    我希望这些对你有帮助。