几乎所有组件上都是这种情况页面，但更重要的是，可单击元素的情况使我的生活变得更加艰难（因为我无法执行
findElement(By.id(myId))且必须使用XPath才能发挥创造力）。我正在考虑询问开发人员在每个可点击的元素中添加ID或名称，而不是根据您之前输入的内容而更改的不可点击的元素。
问题
我在这里滥用权力吗？如果不是，我可以使用什么参数使他们看到这是有效请求？
#1 楼
这是一个很好的要求。如果质量检查部门决定主要使用id定位器进行测试（因为很难维护多种定位器类型），并且开发人员同意这一点，那么没有id定位器的前端功能实现不应成功通过质量检查，因为它们不会遵循设定的标准。当前没有id的元素基本上是bug，因为它们预期具有id以便进行测试。关于在元素上实现
id的参数...： br />如果规范中指出该功能应在必要的地方加上id标记，而没有id，则表明它是一个错误，应这样对待。您是一家公司。您应该找到回报/成本比最大的解决方案。在测试中，XPath比
id更慢，更难实现。老实说，我不认为在用id标记元素期间花费的成本会超过在测试中使用XPath的总成本。但是，这是项目经理应该决定的事情。它使您可以创建更具维护性的测试，并减少误报的数量。 DOM比前端的一般布局和设计更频繁地更改。但是如果使用
id s联系表单，无论表单有多少字段或联系表的哪个部分，总是会有类似<button id="send-message">Send</button>这样的内容。这使你们俩的生活更加轻松。您将能够更快地编写更好的测试，因此您可以将更多的时间用于其他类型的测试，例如探索性测试，发现更多错误。反过来，开发人员可以获得更快的反馈，并且能够更快地修复错误。
#2 楼
这是正常的做法。您只应该记住，在现代用户界面中，许多元素是动态生成的，因此您的开发人员的功能可能在该区域受到限制。它还可能取决于您的开发人员用于构建UI的特定框架。#3 楼
xPath表达式越复杂，将来在某处被破坏的可能性就越大。例如：将
div更改为span ，将在结构中添加附加的
div 更改
class的名称或引入附加的class 。
在所有这些情况下，都应更新测试，另一方面，如果将适当的
id分配给被测元素，则该测试可以正常工作而无需采取任何措施。 #4 楼
一种替代方法是尝试通过Xpath将选择器基于用户可见的文本。然后，元素的位置是否发生变化，大小或颜色或可见文本以外的任何其他方面都没有关系。如果在某些情况下很难做到这一点，那么一定要为特定元素要求一个特定ID。但关键是在大多数情况下您可能不需要这样做。
xpath = "//label[text() = 'Print Book']"
评论
但是，如果文本更改了怎么办？我正在测试Beta版，因此更改文字的可能性确实不大。
–心爱的傻瓜
19年1月10日在14:17
然后选择目标。如果情况经常发生变化，请不要尝试像这样进行测试。等待它们稳定（即已注销），然后对其进行测试。自动化测试不能轻易针对不断变化进行维护。
–Paul Collingwood-Futrli
19年1月10日在16:15
#5 楼
至少可以从中获得一些好处。测试将运行得更快（通过id查找比通过xpath查找要快）
测试将当用户界面更改时，不会失败太多，而维护它们的时间也会缩短。
还有一些事情会使您的请求无法执行：
当页面上的项目是自动生成的（并且不能静态命名）时。
如果开发站点的框架/语言不支持，开发人员将需要太多的时间来实现。
br />
因此，基本上最好的方法是与开发人员交谈，并询问他自己可以进行多少命名（或向您展示如何自己添加这些名称/ id。）
评论
如果可能，请避免使用ID，而应使用数据属性。具有多种隐式语义的ID重载是灾难的根源。当我编辑模板并看到ID需要更改时，如何发现测试依赖项？