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

#1 楼

我最近与开发人员进行了讨论，但没有令人满意的解决方案。

我的情况因以下事实而变得复杂：（对于基于Angular的页面）某些测试是在protractor / javascript中开发的，并且它们可以特定于Angular进行访问，而我们的绝大多数e2e测试都是在开发的

首先，公开：我避免像瘟疫一样使用XPath定位器。它们易碎，缓慢且易碎。

添加ID并非没有后果：ID必须是唯一的，并且添加具有相同ID的其他元素会破坏使用它的旧测试。

基于名称的定位器更为宽容：如果您只有几个具有相同名称的元素（并且准备处理歧义），则可以从列表中找到合适的元素，从而更容易恢复。 ID通常是由窗口小部件本身生成的，例如某些Angular / Material窗口小部件，因此添加自定义ID甚至都不是一种选择。

一种解决方案（对少数幸运的人而言）是与开发人员达成命名约定/最佳实践协议，以添加“名称”属性。如果被接受，则丢失的定位器违反了此类协议（完成的定义），并应要求添加。

另一种解决方案（或针对不在活跃开发中的页面中的定位器，例如是否回填e2e测试现有的旧页面）是要添加一个“伞形”错误以添加定位符，以便开发人员可以添加它们（并有一个错误号可以使用-在我们的过程中，即使是这样小的改动也必须具有相关的错误号）。为您提供了一个良好的开端：它已经被批准，范围和后果是已知的。任何其他错误都必须争夺资源。

OTOH，您可以只使用CSS定位器，它可以使用元素的层次结构，但是比XPath更坚固，更快。当然，其中一些CSS定位器会很长且复杂（比基于名称的定位器还差），但是您不依赖开发人员的合作（或缺乏合作），因此您可以更快地前进，而无需等待开发人员和他们的善意。

时间压力使所有这些复杂化，并且应用程序开发人员和自动测试的编码人员之间可能会分开。因为像自动化测试人员一样，开发人员都有自己的优先级，并且通常使自动化测试编码人员提高工作效率并不是他们关心的指标（这与最近在开发应用程序和测试时有关不同指标的争论有关）。

#2 楼

我的偏好是将其变成小组讨论，以期制定需要使用易于测试的定位器的编码标准。

更改标准可能会遇到阻力，但是测试人员可以通过很多技巧和一点努力来解决这个问题。

非正式对话始终是我的开始点。如果我什么都没做，我开始做笔记：


定位和测试元素X的可用定位器的时间
使用期望的定位器（如ID）将花费的时间
开发人员在编码时将期望的定位器添加到代码中的时间
开发人员在事实发生后将定位器加装到代码中的时间
由于其他问题，调试和更改测试代码的时间到了定位器和潜在的定位器。

通常会出现的情况是，它节省了每个人第一次正确执行此操作的时间，并且在他们编写代码时在每个元素上都添加了唯一标识符。

不幸的是，对于开发人员来说，使用IDE缺省值（不必添加所需的标识符）的速度更快，或者如果需要的话，得到的缺省值会有所帮助。在这种情况下，能够帮助经理们证明开发人员因不这样做而节省的时间远远超过了您失去寻找可用的替代方法的时间，而这浪费了公司的金钱。

#3 楼

就个人而言，我认为通过Jira而不是通过Slack发出请求不会产生任何影响，尽管Jira更加正式且具有更大的知名度和知名度。

我的个人建议是：


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


我们应该对每个元素都进行处理还是以某种方式一次针对整个应用程序进行处理？



这取决于听众。如果这是多个开发人员的通用做法，则需要整体解决。但是，如果这是一个相对孤立的事件，如果我是一名开发人员，我希望有人来我的办公桌前先与我交谈。

#4 楼

我认为这关系到您的团队在开发人员和质量保证之间的良好关系，尤其是特定团队成员之间的良好关系。

是什么帮助我的团队改善了协作并提高了可测试性该产品（不仅是定位器的ID）是：


使开发人员参与编写新的端到端测试并稳定现有测试。当他们发现我们有太多待定的故事时，他们决定提供帮助。这样，他们可以分担我们的痛苦，并从我们的测试中看到更多的价值。
作为回报，我们尝试查看其组件测试并为他们提出新的测试方案。我们也对他们关于如何稳定端到端测试的一些举措持开放态度。

#5 楼

我认为您的问题出在第三点-在代码中添加TODO。像其他许多事情一样，摆脱它们的最好方法是永远不要首先引入它们。如果您需要插入的ID，请从头开始选择一个好的ID，这样就不必回来了。当然，这并不总是那么容易，因此您可能需要提供一些标准的命名方式。


记录下来！最重要的是记录该ID。用它做一个任务，并写下您在该任务中想到的ID －如果您认为它可能需要修订，请找人来审查它，并注明是谁帮助您进行了审查。 Slack在很多方面都很有用，但是如果它是开发过程中的重要组成部分，则需要文档，而Slack不会邀请文档。
复习它！如果很难想到一个名称，则可能要对名称进行一次较小的辩论。设置名称需要满足的条件列表，以便在审核中被接受。确保检查所有ID，直到人们对事物命名为止。
千万不要添加待办事项！认真地讲，一旦您想到了用代码编写TODO的想法，这并不难。文档确实是任何形式的开发中的关键，并且已经有太多人被忽视了很长时间。
摆脱陈旧的任务。如果您没有这样做，并且在3个月内没有人抱怨，那还是不值得这样做。

从目前负责更新UI的软件开发人员的经验来看一个30klos（义大利面条行）组件，没有文档，命名框架不一致，滥用选定的框架，并且原始开发人员已在10年前退休（即行业标准的开发工作）。

#6 楼

对于许多组织来说，这一直是我一个长期的话题。

我最初希望能够要求或添加自己想要自动化的属性。但是，我很快了解到，这将导致与开发人员进行过多的关于正确名称的对话。但是，这导致了重复的工作和对最终用户的超大页面的质疑。自动化开发人员-所有人员都需要共享相同的UI，因此需要共享适当的标识符。也就是说，仍然需要交流的机会，我想到的三个就是代码审查，完成的定义和开发过程的交流。

我还了解到第四个“参与者”-应用框架。例如，在使用ruby on rails的情况下，rails会根据数据库列名称自动生成'qe-'属性，并且对于许多字段而言，它是要使用的适当标识符。

#7 楼

您将如何改善这种情况？


简单，请自己添加，这就是我要做的。编写测试自动化代码的工程师是开发人员。因此，我认为测试工程师不应该将自己需要的定位符添加到前端UI代码中的理由。

团队应该已经有一个代码质量流程（例如代码审查） 。前端代码的任何更改都可以遵循已经使用的过程来保持代码质量。谁添加更改无关紧要，因为我认为整个产品团队都应该实践集体代码所有权。我将创建一个包含我的应用程序更改及其测试的请求请求，要么让开发人员进行审查，要么让另一个测试工程师进行。


我们是否应该要求开发人员正式改善测试人员的标记通过
吉拉（Jira）？


在吉拉（Jira）制作机票感觉像是一大笔浪费。要求开发人员即时执行此操作可能会给生产力带来负面影响，因为上下文切换非常昂贵。我将尝试找到一种消除测试自动化与开发人员之间的小应答的过程。与整个团队讨论选项。


我们应该为每个元素都执行此操作还是以某种方式一次针对整个应用程序解决它？


不，YAGNI。如果您希望开发人员提供更好的可测试应用程序，我会请他们为他们提供的每个功能创建一个快乐路径Selenium测试。之后，自动化团队可以在必要时添加更多案例和负面测试。开发人员应该知道他们交付的产品是如何不可测试的。我会说“使其可测试”是他们工作描述的一部分！

#8 楼

许多人提到了团队协作部分会有所帮助，但是坦率地说，我认为最好的改进方法是改进定位器方法，而不是在标签上增加开发人员的负担。获得扎实的编码标准，但接下来要使定位器更具动态性和关系性，而不是那么静态。您可以在html结构的每个部分中进行搜索，包括引用父级/兄弟级关系。即使您根据应用程序中要提取的内容在页面中动态移动元素，这也使您能够找到它。使用javascript，您可以绕过大多数浏览器部分，并动态修改HTML，这很容易破坏静态定位器，尽管它们具有什么值。使用单个页面应用程序，这很容易破坏所有静态控件，但是，如果您可以找到动态控件存在的范围，然后钻取到控件类型并检查其显示的组件，则可以重新使用相同的xpath（xquery）在更改id，css，值，名称，结构等的情况下仍可以找到确切的元素...

这要求测试人员学习并了解页面生成和修改的方式，然后定位器与支架相关联定位到站点的动态组件，而不是在某个时间点锁定特定元素。然后运行时解释提取元素。

当然，有条不紊的方法是针对特定应用而非通用的，因此任何有此问题的人都将需要特定的帮助，而不是像这样的通用，但是，重点是，只要是标准化和自动化工程师，开发人员就可以设计出最适合该产品的产品学会与产品一起流动。当然，执行id =更容易，但是它并不能提供更好的产品，只是使其在测试中更加静态。一些非常酷的javascript完全接管了HTML，使其在运行时几乎不可预测，它并没有使其成为不良代码，QA需要具有适应性。查看D3，HighCharts，Angular等...，它们看起来不错，但完全弄乱了静态定位器以实现自动化。如果要与开发人员一起扩展而不是限制它们，则将动态自动化与动态站点一起使用是更好的选择。