问要求UI开发人员调整标记以改进自动化测试

EN

我最近正和我们的开发人员讨论过这个问题，但我没有令人满意的解决方案。

我的情况很复杂，因为(对于基于角度的页面)一些测试是用量角器/javascript开发的，它们可以访问特定于角的测试，而我们的e2e测试绝大多数都是用Python开发的，不能访问这些角度特定的定位器。

首先，公开:我像避免瘟疫一样避免XPath定位器。它们是片状的，缓慢而易碎的。

添加ID并不是没有后果的:ID必须是唯一的，添加具有相同ID的附加元素会破坏使用ID的旧测试。

基于名称的定位器更宽容:如果您有几个同名元素(并且您已经准备好处理歧义)，那么从列表中找到正确的元素会更容易恢复。ID通常是由小部件本身生成的，就像一些角度/材料小部件一样，因此添加自定义ID甚至都不是一个选项。

名称可以很好地工作，例如行，其中列中的每个项都可能有相同的名称，并且可以通过其他属性来区分。

一个解决方案(对于少数幸运儿而言)是与开发人员有一个命名约定/最佳实践协议，以添加"name“属性。如果接受，丢失定位器正在违反这样的协议(已完成的定义)，并根据请求添加。

另一种解决方案(或者对于未在积极开发中的页面中的定位器，例如，如果对现有旧页进行e2e测试的话)是有一个“伞式”bug来添加定位器，这样开发人员就可以添加它们(并且有一个可以使用的bug编号-在我们的过程中，即使是这些微小的更改也必须有相关的bug号).Such伞错误给了您一个先机:它已经被批准了，范围和后果是已知的。任何其他的bug都需要竞争资源。

OTOH您可以只使用CSS定位器，它可以使用元素的层次结构，但是比XPath更坚固、更快。当然，有些CSS定位器会很长很复杂(比基于名称的定位器更糟糕)，但是您不依赖于开发人员的合作(或缺乏合作)，所以您可以更快地前进，而无需等待开发人员和他们的善意。

这一切都是复杂的时间压力，并可能在应用程序开发人员和程序员之间的自动测试。因为与自动化测试人员一样，开发人员也有他们自己的优先级，并且经常让自动化测试代码器更有效率并不是他们所关心的度量标准(这与最近在开发应用程序和测试它时关于不同度量的争论有关)。

我倾向于将其转化为团队讨论，目的是使编码标准到位，从而要求使用对测试友好的定位器。

可能会有更改标准的阻力，但通过大量的机智和努力，测试人员可以完成这一任务。

非正式的谈话总是我的出发点。如果这让我一无所获，我就开始做笔记：

• 查找和测试元素X的可用定位器的时间
• 使用像ID这样的预期定位器所需的时间
• 开发人员在编码时向代码中添加预期定位器的时间
• 是时候让开发人员对定位器进行改造，以便在事实发生后进行编码。
• 调试时间，然后更改为测试代码，因为其他问题与不需要的定位器和潜在。

通常出现的情况是，第一次正确地执行它可以节省每个人的时间，并且在编写代码时在每个元素上添加唯一的标识符。

不幸的是，对于开发人员来说，使用IDE默认值更快，因为IDE不一定要添加所需的标识符，或者如果添加了标识符，则会得到帮助不足的缺省值。在这种情况下，能够向经理证明，开发人员通过不这么做节省的时间远远超过了你试图寻找一个可用的替代方案的时间--而这段时间正在耗费公司的资金。

就我个人而言，我不认为通过吉拉而不是通过斯拉克提出请求会有任何不同，尽管吉拉更正式，有更多的宣传和知名度。

我个人的建议是：

• 投入一些精力研究开发人员为什么只提供不那么理想的定位器？在测试人员和开发人员之间，对于理想的定位器是什么有不同的看法吗？
• 捕获不那么理想的定位器的最佳方法是在开发人员之间进行代码评审。是否有可能在现有的代码评审过程中引入定位器评估？

我们应该为每一个元素做这件事，还是为整个应用程序一次解决这个问题？

• 这取决于观众。如果这是几个开发人员的普遍做法，则需要作为一个整体来处理。但如果这是一个相对孤立的事件，如果我是一个开发人员，我希望有人来我的办公桌，并与我交谈的第一。