前言

在UI自动化测试中由于前端界面的改变导致元素无法定位产生的维护工作，
经常让自动化测试人员苦不堪言。无法跟得上敏捷的步伐，为此复出了付出惨痛的代价。
很多公司因此也放弃了UI自动化测试。到底问题出在了哪里？让我们来一起看看吧。

前端代码改变对自动化作业都有哪些影响

1.导致自动化测试用例执行中断。
2.对于中断的测试用例进行分析（是Bug导致还是脚本自身问题)。
2-1.是Bug的话需要进一步分析原因，bug提起。
2-2.脚本问题，修改脚本确保脚本正常运行。

看起来只有两个问题，问题不是很多啊？
现在我们加上假设，再来看看。

• 假设你有100个TestCase
  中断30个，确认30个case中断的原因本身就需要消耗大量的时间（手动测试最多一天能测试10-15个测试用例）如果是由于脚本导致，那么还需要修改脚本之后在调试脚本。
• 假设每天要在一个发布版本上测试一遍
  很可能上一版本上可以执行的测试用例，在最新版本上又中断。
  继续排查中断问题，重复步骤1-2。

最后的结果很可能是，在反复修改自动化测试脚本上花费的大量的时间和精力。并且无法跟得上发布版本的速度。上一版中断的问题还没解决完毕，下一版软件如期而至。

常见的中断问题

1.前端做了修改自动化执行中无法定位该元素。（非时间问题导致）
2.Web自身导致(稳定性和bug加层)。
3.自动化测试框架的健壮性（对于非预期问题的处理能力）。

本文讨论的是第一种也是最常见的一种导致中断的情况，绝大多出现在Web界面元素无法定位。也就是大家经常在console log看到的NoSuchElement的报错信息。无论大家使用哪种定位方式id,name,css,xpath,css..其目的是无非是想当前Web元素能够被找到，并且执行我们脚本中写好的click等动作。能够准确的定位到元素自然是首要的问题。

前端修改和定位的关系

为什么前端发生变动，我们就无法找到之前的定位？
将要了解这些，需要知道前端开发都干了哪些好事。
如id，name，class等这些属性都是除了你用于自动化定位,前端开发工程师同样也需要用这些属性来控制页面的元素。通过dom方式使用这些属性定位获该元素并通过js代码或者css样式（这里的css不是定位中的selector而且css样式表）来改变其显示效果。class属性常用来绑定css样式表。

前端属性的使用
举个例子：通过id来改变改元素显示的文本
<script> document.getElementById("kw").innerHTML="ChinaNo.1"; </script>

也就是说如果前端开发可以灵活添加诸如id，name，class等属性和值方便其前端开发使用。（前端在开发之前是否对于这些属性有详细的添加和修改计划，还请做前端开发的小伙伴看到给我留个言）

自动化测试属性的使用
举个例子：
以百度input框为例。这里假设定位使用class, name和id任意一个属性都是唯一值。我要输入对话框使用id进行定位selenium语句是
driver.findElementById("kw").sendKeys("台湾省");

image.png

image.png

除了上述属性变更之外，UI层级变更也有会同样的问题。自动化测试使用绝对定位带来的维护隐患。同样是定位百度input框。如果定位使用类似这种绝对路径的话。前端只要在层级中删除或者添加一个div，就无法使用该定位来找到input框。
//html/body/div[1]/div[2]/div[5]/div[1]/div/form/span[1]/input

结论

要想降低自动化测试维护的成本，首先要保证元素定位准确。尽可能降低前端变动对于自动化代码的影响。

有如下几点建议：

• 自动化测试脚本开发之前，与前端开发达成约定。哪些属性不会在之后版本变动发生变化。或者加入新的属性值，专门用于自动化测试。
• 定位元素时，尽可能避免使用绝对路径。
• 使用相对路径定位确保上下层级之间使用相关稳定的属性。

上述基于已有经验和理论知识（前端开发以及参考文章)。最佳定位实践，依然在摸索中。之后在有好的经验，还会不定期给大家分享。

参考List
乙醇-自动化测试元素定位最佳实践