2009-08-05 45 views
2

我项目上的测试人员希望在每个页面元素上都有一个唯一的HTML ID,以使他们的自动化测试更容易。如何自动验证我在每个元素上都有一个HTML ID?

这是我很难记得要做到这一点,因为我不需要的ID进行开发。我怎样才能确保我不会忘记?

我想,也许是这样的Checkstyle能告诉我,甚至在的IntelliJ“检查” - 但他们都不似乎支持这一功能。

任何想法?

+3

消防测试人员。他们显然不能胜任这项工作。 – NickFitz 2009-08-05 11:47:36

+2

在页面元素上具有唯一的HTML ID *可以*增加可测试性。要求他们存在不*意味着无能。不知道其自动化测试框架的上下文以及页面元素对框架的外观是什么...... – 2009-08-05 14:32:59

+0

正确,它是针对自动化测试框架的。 – 2009-08-05 22:03:55

回答

7

想到两个想法:1.让他们告诉你什么没有它。如果这不起作用,2.获得新的测试人员。 ;)

什么样的测试引擎的要求每一个元素的ID的?

+0

这是一个自动化测试框架。据我所知,大多数自动化测试框架都依靠独特的ID来获得一致的结果 - 我希望以前有些开发人员不得不适应这种情况? – 2009-08-05 22:00:32

+0

我已经使用了多个Web测试框架,并且唯一需要输入ID的时间是输入字段。无论如何,它们应该有它们。 – NotMe 2009-08-05 22:49:03

+1

事实证明,每个元素都不需要id,只是用作输入的元素。大多数输入字段都有一个id或名称 - 我们需要他们作为开发人员绑定到我们的模型!所以在审查之后,只有少数东西没有像按钮和链接这样的ID,并且没有验证工具就相对容易做到。 – 2009-08-06 23:02:24

4

如果你想要javascript中的东西,你可以使用jQuery。 $("*:not([id])").css('backgroundColor', 'yellow');

会给任何没有ID黄色的东西着色,在那里你只需通过Firebug来源并寻找颜色为黄色的东西。

$.each($(*:not([id])), function(){ 
    $(this) 
     .css("backgroundColor", "yellow") 
     .addClass("no-id"); 
}); 
+0

这只会检查元素是否有ID。不是这些ID是唯一的。但是,您可以将其与W3C验证一起使用。 – 2009-08-05 01:27:56

+0

对。这假定所有的ID都是唯一的,因为验证,无论如何都应该运行,以使测试人员更容易。 – 2009-08-05 01:34:02

1

ID加入到每一个元素没有任何意义可言。但是,如果他们坚持,可以添加一个小的JavaScript代码,将Id添加到您可以在生产站点中省略的测试站点。

大厦Chacha102的想法

$(document).ready(function() { 
    var index = 1; 
    $.each($(*:not([id])), function(){ 
     $(this).attr("id", "id1000" + index++); //or some other unique generator 
    }); 
} 

只要确保这个测试工具之前运行!

+0

为了使自动化测试框架正常工作,ID需要在不同的构建中保持一致,因此生成ID可能不起作用。 – 2009-08-05 22:03:20

+0

正是。没有得到与每个版本一致的ID这个概念的人真的不知道如何制作可测试的代码。 – 2016-08-19 00:35:55

2

每一个页面上的每一个元素上设置ID似乎是一个不错的计划给我。

  1. 的ID应该是唯一的。
  2. 这将增加大量的膨胀到您的网页
  3. 如果这些生成...我认为他们需要每次都是相同的这个测试工具?
  4. 这个测试工具的名称是什么?这似乎很奇怪的是,ID是每个元素
  5. 。假定每个页面可能包含稍有不同的数据每次访问时间上的“必需的”,这似乎是一个后勤恶梦管理
+0

我认为这个工具是Ax:http://www.odin.co.uk/product_axe.html不是每个元素都需要一个id,只是那些在功能上使用的元素,比如按钮,下拉菜单,链接等。我希望在那里可能是一个工具,我可以定义哪些页面元素需要id和相应的验证。 – 2009-08-05 22:07:38

2

的原因工具不支持这是它是一个相当奇怪的要求。我去过那儿。上述

jQuery的解决方案将让他们什么,他们问for--但他们(或者你作为一个团队)需要也许不是什么。我肯定会回到测试人员(不要开除他们!),并尝试多了解一下这个要求。元素真的是吗?看看几页,看看有什么遗漏 - 也许他们只是沮丧,需要更多的ID比他们有。

它也很难相信,一个测试工具只能够通过ID,以解决DOM元素;看看是否有将工作得很好,哪些是你可以自愿加入到支持它们的其他选项。(这将肯定会超过无处不ID加入更容易。)

最后,如果ID是唯一的出路,基于东西会比元素更长久考虑分配的ID count--某种的innerHTML的散列,元素的父+索引或类似的东西。

另一件需要考虑的事情 - 如果你需要生成ID--做服务器端。根据您使用的语言,在那里做起来可能更容易,并且不会影响浏览器的性能。

祝你好运!

+0

根据经验,问题在于团队不断更改包含感兴趣元素的嵌套div标签。因此,每个其他测试周期测试人员都必须重新编写脚本,以考虑结构的变化。当感兴趣的东西有独特的ID时,那么你的硒(或其他)测试只是简单地引用这些ID。 – 2016-08-19 00:35:16

4

正如有人谁在测试自动化工作作为日常工作: 独特的ID添加到被相互作用与元素的要求是要很多的稳定性增加了自动测试套件。

将一个ID添加到DOM中的每个元素当然是一个荒谬的开销。

大多数框架都可以使用CSS或XPath甚至图像匹配。当开发人员和测试人员之间没有沟通渠道时,这是一个很大的倒退。但是,如果这些团队之间存在沟通 - 添加这些团队是有道理的。

作为一个开发团队,您应该从这些测试中获得很多价值。在将变更部署到测试环境后,他们应该给你几乎即时的反馈。如果测试是有风险的 - 它们的价值将会直线下降。让测试尽可能可靠是符合每个人的利益的。良好的ID在这方面是无价的。

就像一个笔记 - 自动生成ID的建议充满风险。这些很容易给人一种虚假的安全感,可能比没有安全感更差。关键是ID要稳定可靠。如果新元素添加到上面的DOM中,增量生成的ID将会改变。如果标签等有一个小的变化,基于内容哈希的ID将会改变...

另外作为一个测试者 - 花费半个小时写一个xpath来唯一标识一个元素是一个糟糕的用法的时间,如果添加ID将采取开发5分钟..... :)