我需要在工作中为我们的产品建立很多回归测试,并且我计划使用Selenium。我担心构建测试会因我们产品开发的快速步伐而迅速过时和破坏。


以哪种方式构建/构造测试的最佳方法是什么?会随着产品的变化和改进而最大限度地减少保持测试最新状态所需的工作?


评论

您正在使用哪个版本的Selenium?

@RandallBohn,为什么这么重要?

目前还没有。

#1 楼

您可以尝试使用Page Object模式构建Selenium测试,有关更多信息,请访问:
https://github.com/SeleniumHQ/selenium/wiki/PageObjects

评论


PageObjects几乎是您最好的选择。只需轻松更改获取或定义元素的方式即可。每个页面都有一个字典,该字典将键和元组配对。元组包含我们要如何选择元素(id,xpath,class_name),然后是实现该元素所需的实际选择器。最困难的部分是以这样的方式定义元素,即几乎没有什么变化就不会强制重写。您可以引用的最糟糕的东西是xpath。

–杰森·沃德(Jason Ward)
2011年5月3日21:52

关于Python及其在功能测试框架中的应用,有一些关于Page Objects的精彩视频。这个us.pycon.org/2009/conference/schedule/event/13和这个vimeo.com/10127202。

– terryp
2011年5月4日,11:54

#2 楼

我了解到许多关键事项,它们是易于维护,可靠的自动化测试的关键。映射到单个位置,因此,如果控件发生更改,则只需在单个位置进行更改。如果开发人员重新映射控件,则将其放在一个位置可以更改一行代码。我还映射了控件类型,以便开发人员可以从链接更改为按钮,而我要做的就是更改此控件文件。

尽可能抽象测试自动化工具

基本上,我有99%的时间执行三个动作,即Invoke,Setvalue和GetValue。调用将单击链接或按钮,选中或取消选中复选框等。SetValue会将值放入控件中,例如将文本放入文本框。 GetValue从控件获取数据,这些数据主要用于验证。

每个自动化操作(例如执行搜索)将仅调用这些invoke,Set和get方法。这几乎可以完全底层自动化工具的抽象,还可以使您在代码中的单个位置调用较低级别的控件特定方法。

使用正则表达式映射控件名称

我以前使用的一种商用工具可以将控制字符串切成256个字符。许多应用程序(例如asp.net)可以根据其在页面控制器中的位置来动态创建控件名称。使用正则表达式使您可以定义控件,使开发人员可以将其移动到页面上的任何位置,并且测试仍将运行。

创建测试数据对象以保存您的测试数据

我创建了测试数据对象,这些对象通常与页面上的控件之间的映射关系接近1:1,然后创建一个预期的和实际的对象,然后将这些对象传递给堆栈中的各个层。这样,在某些情况下创建其他测试就可以像使用具有不同数据的现有测试一样简单。

将测试与实现分开

关注点分离是关键的技术设计您应该从测试中应用的原则。应将测试用例的意图与与页面进行交互的物理实现尽可能分开。例如,代替...

[Test] 
public void SearchOnGoogle()
{
  using (var browser = new IE("http://www.google.com"))
  {
    browser.TextField(Find.ByName("q")).TypeText("Stack Exchange");
    browser.Button(Find.ByName("btnG")).Click();

    Assert.IsTrue(browser.ContainsText("Stack Exchange - Free, Community-Powered Q&A"));
  }
}


您的测试应该在最高级别上具有特定于域的API。 />
...

[Test] 
public void SearchOnGoogle()
{
    SearchEngine.WebSearch("Stack Exchange");
    SearchEngine.Verifcation.WebSearch("Stack Exchange - Free, Community-Powered Q&A");
  }
}


有关此主题的详细信息,请阅读Michael Hunter的“捕获测试用例的本质”

#3 楼

IMO的关键问题是要确认您的页面需要进行调整才能进行测试。要解决Selenium问题,而不是使用XPath来构造选​​择器,请在页面中添加ID并在测试中使用它们。 :


在Web应用程序的UI中,您的测试与某些区域交互。 Page Object只是将它们建模为测试代码中的对象。这减少了重复代码的数量,并且意味着如果UI更改,则仅需要在一个地方应用此修复程序。


#4 楼

我反复运用三个原则:

隐藏偶然的细节。与测试目的没有直接关系的任何细节都属于测试之外的其他地方。将其隐藏在某个地方,例如在变量或方法中,并给它起一个好名字。

为每个重要的想法命名。为什么测试代码以“ F.D. Gumby”身份登录,而不是以其他用户身份登录?因为那是雇用您要添加到工资单中的员工的经理?然后将“ F.D. Gumby”放在变量中,并称其为招聘经理(或其他名称)以表达其意图。

消除重复。重复数据的每一位都是一个变量,它等待诞生并被赋予一个具名的名称。重复的测试步骤的每个序列都是一种等待诞生的方法,并且要赋予它一个具有表达性的名称。

应用这些原理可使自动回归测试在需求或实现发生变化时更容易修复。有关更多详细信息和示例,请参阅我的文章“编写可维护的自动验收测试”(PDF)。另请参阅鲍勃·马丁(Bob Martin)关于这些相同想法的精彩视频。

评论


+1隐藏偶然的细节是很重要的一点。它掩盖了测试用例的复杂性,使其易于阅读并指向重点。

– Aruna
2012年9月5日在6:24

#5 楼

与开发人员预先讨论自动化测试需求通常会有所帮助。

开发人员不应担心会破坏我们的测试,而对应用程序不了解,但如果他们可以主动做出能够做出选择的设计对于我们来说,维护它们更容易,那么这可以节省大量时间。

#6 楼

首先,请记住:总会有一些维护。无论您使用哪种方法,您的测试都会随着时间而变化。许多人会建议跳过GUI自动化,因为它非常脆弱。在某种程度上是对的。很多时候,这只是他们从某人那里听到的。有时人们会说,因为他们已经尝试过一次,所以期望可以立即使用某些解决方案。有时,他们希望他们一次编写一些测试,并且不管应用程序如何更改,它们都可以工作到结束。与低级测试相比,GUI测试仍然受更多因素的影响。

对于您的测试,我建议对框架设计进行以下阅读。

Patrick的第一个博客威尔逊

其次是以下材料:


快速概览
更大的解释

以上所有内容的启示和少量pdf描述它的文件


#7 楼

创建强大的自动化框架的成功在于将测试框架嵌入您的开发框架中。

推荐的一项常见操作是为每个对象创建唯一的单独属性(例如,对于Web项目,屏幕上的任何内容均由唯一的ID标识,例如TestAutomationdId =“ HelpMeButton”)。

这样可确保对该对象的任何更改(除了删除该对象之外)都不会影响您的脚本。

#8 楼

我认为,默认情况下会破坏自动UI测试,这是您创建测试的第二秒。我不愿冗长地回答为什么,因为其局限性已经众所周知-维护性是最关键的。

我最近参加了关于所谓的“智能”测试的讨论。 。这意味着仅需遵循流程中几个步骤的重复,琐碎的内容即可实现自动化,而UI测试,产品集成测试等内容应由“智能”代理人来完成。

它的主要理念是使一个人完成的工作自动化实际上是测试过程的退化。在这里您可以找到有关它的几句话。

因此,请回答您的问题-快速,敏捷地开发,快速且经常地构建,在每次构建和创建之后执行稳定的(基于API的)自动测试一个团队来处理UI测试。添加/移动的每个新按钮不仅意味着您将对测试进行大量维护,还意味着用户可能会滥用无数种其他方式-您确定您将能够跟上维护和创建自动UI测试的步伐每种可能的组合/路径的情况如何?

评论


我完全同意。精心设计的自动化框架可以实现关注点分离,并且非常健壮和可靠,而维护费用却很少。测试应该写在业务领域中,并且与被测试的应用程序的交互应该在一个地方轻松,快速地更新。有关如何获得更多信息,请访问thebraidytester.com

–布鲁斯·麦克劳德(Bruce McLeod)
2011年5月4日13:26



@Bruce:在业务领域中设计良好的自动化框架= API测试,恕我直言,这很棒。 Selenium和其他UI测试工具依赖于检查当前页面源并寻找特定类/具有特定ID /位于屏幕上特定位置的元素。

– pnt
2011年5月8日,12:26

就业务领域而言,我并没有考虑N层体系结构中的应用程序业务逻辑层。我说的是您可以用业务主题专家介绍的测试用例,并且您可以隐式阅读和理解它们,它们是用特定领域的语言编写的。

–布鲁斯·麦克劳德(Bruce McLeod)
2011年5月9日晚上8:55

尽管有缺点,但UI自动化也有好处。但是,认为自动化UI测试是“测试过程的降级”的说法盲目地忽略了可能有益的上下文。附带说明:智慧是“具有或显示出巨大的智慧或正确的判断力”。有用的提供价值的UI自动化测试需要精明的测试人员来设计和开发,行为和探索类型的测试也是如此。当然,并不是所有的自动化测试都是由智能测试人员开发的,但是人类“尝试并观察”也不一定反映出智商。

– Bj Rollison
2011年6月3日,下午5:21

#9 楼

当重点放在UI上时,Selenium非常适合测试UI。如果您对测试功能感兴趣,我建议您使用NUnit和Moq之类的工具通过代码自动进行尽可能多的功能测试:http://o2platform.wordpress.com/2011/04/05/mocking- httpcontext-httprequest-and-httpresponse-for-unittests-using-moq /

#10 楼

由于不可能创建不间断的测试用例,因此我要给出的最重要提示是将项目结构化为:
灵活且可扩展
,例如:
-使用id并通过独特的属性来检索它们(当更改时,您将只更新一个键)来使用它们。
-创建操作的通用方法,切勿直接在测试命令(如selenium.click等)内部使用,而创建另一个这样做的方法。将来您可能决定使用其他的selenium命令,不必更改测试用例,只需更改方法的代码即可。
-通过使用自定义方法创建测试框架,您将能够自定义结果在执行后得到,因此您可能会花更多时间分析结果。

#11 楼

约定使我们的生活更轻松!尝试创建用于标记页面(HTML)的标准,并确保团队中的每个人都知道所决定的约定。您的约定可能应该包括:


使用了哪些元素以及在何处使用
如何确定id和class属性的名称

我也将建议已经使用一些人建议的PageObject模式。

#12 楼

这是一个很好的问题,其要旨也适用于其他类型接口(例如协议,API,文件格式)的自动化测试。当实现易于更改但接口稳定时,自动化才是最有意义的。相反,当界面不稳定时,它的意义最小。

我试图客观地对待自动化测试与手动测试的价值。反复修复损坏的测试的成本;如果我不修复自动化测试,我可以做的其他智力上较少挑战的手动测试工作的价值;我希望看到的测试突破性变化的数量;甚至是开发人员在将可测试性纳入产品中的同情心。很高兴地说,我可以量化所有这些变量并将其插入公式中,但实际上我不能。我尝试对自己诚实,尽我所能,然后继续前进。

很难一字不漏地声明使您免受变化影响的技术,因为所有变化都不相等。例如,使用页面对象可能使您免受页面内结构上,语义上中立的更改的影响,但是当以更加戏剧性的方式重新组织UI时,它的用处将不大,甚至是一个障碍。 >就我个人而言,我不会自动执行我认为仍在快速变化的UI部分。我手动测试这些零件,然后一旦一切看起来稳定下来,就重新评估。但是那时我是我们这家初创企业中唯一的质量检查人员。如果我是一个大型质量检查团队中的自动化专业人员,那么我可能会做出不同的决定-尽管我仍然对针对不稳定的问题进行自动化测试持怀疑态度。