image1835×494 102 KB
如上图中在一个前端项目中， 会专门有一个叫 component 的目录（第一张图），该目录里会封装常用的页面组件，比如 button，input，dropdown，link 等。 而每个组件都会编写独立的逻辑代码和 css 代码（第二张图）。 最后在页面中通过调用组件库的组件来完成页面逻辑（第三张图， 页面中调用了第二张图里展示的 LinkButton）。 所以我们在产品界面中才会发现很多控件长得都一样， 连属性都一样， 比如 class 里的值都是一样的。 这是因为他们其实是完完全全的同一个组件。 PS：在 CSS 中比较常用 class 来定位控件。
所以我们在控件中一般能看到各种 class 定义。 这就是现代前端项目的开发模式， 我们总能听到前端研发工程师们说的组件化，其实就是这个了。 这也是为什么我们会专门抽象出一层组件层的原因。 如果研发在迭代过程中修改了组件库， 那么会影响所有的页面。 一般这对 UI 自动化来说是一个很大的打击。 所以为了避免这种情况出现，同时为了简化页面定位成本。 所以 UI 自动化项目中也要对应的封装出一个组件层来专门做元素的定位和操作。 比如我之前曾经在产品中见过这样的情况， 之前我们的 button 都是下面这个样子的。
<button> 确定 </button>
但是突然研发修改了 button 组件库。 于是所有的 button 就变成了下面这个样子：
<button>
<span> 确定 </span>
</button>
在修改之前一切很美好， 我们只需要用 bytext 方法或者用一个 xpath: //button[text()=‘确定’] 就能很方便的找到这个 button 并点击. 但某一天研发的组件库变了， button 不在有文案了， 而是在 button 里加了个 span 的子元素放置文案。 于是在 UI 自动化项目中以前所有页面的所有 button 定位和操作都挂了， 都需要改一遍。所以我们一般在 UI 自动化中通过增加一个组件层来解决这个问题。 如下图：
如上图， 在我们的测试代码中专门有一个名字叫 component 的目录， 里面根据控件的类型划分了很多文件， 每个文件里定义着这个类型的控件常用的定位和操作方式。 第二张图中我们看到的是 input 这个组件在产品中通用的逻辑。 比如拿 form_upload 这个控件来解释， 在产品中绝大部分上传文件的控件是由 input 组件来封装的。 点击上传操作其实触发的就是往一个属性 type=file 的 input 元素写入文件路径。 所以其实所有页面的上传操作都可以调用这个逻辑完成。 特别需要注意一点， 组件层不仅仅是封装元素的定位逻辑的， 也会封装一些常用操作。 还是拿上传控件来说， 用户在前端是要点击上传这个 button 后跳出一个文件选择框来完成上传操作的。
但是这个逻辑在 UI 自动化中是不可行的， 因为跳出这个文件选择框并不是浏览器的行为，而是当前操作系统的行为。 所以这个框实际上不受 webdriver 控制，并且不同的操作系统下这个框的样子也是不一样的。 所以在 UI 自动化中，我们只能通过给这个 input 元素直接写入上传的文件路径来触发文件操作。 但是这个 input 元素的 css 代码中设置了 style.display=none， 把这个 input 元素设置为了隐藏， 而 webdriver 是没办法与隐藏元素交互的。 所以我们需要先通过嵌入一段 js 代码， 把这个 input 修改成可见元素才能完成剩下的操作。 通过这个案例我想说明在组件层除了封装元素的定位方式外， 也会封装元素的操作方式。
原则上，我们所有的页面元素的交互都需要通过调用组件层的函数来完成， 一个是加快元素定位的速度 – 调用者不再需要自己定位了， 只需要调用组件层的方法，传递参数即可。 第二个是通过统一调用， 一旦后续前端组件库发生变化，导致元素定位方式也要改变。 我们只需要修改组件层非常少量的代码即可。 而不是研发动了一行代码， 测试项目这边需要成片的逻辑修改。
页面层页面层与老式的 page object 模式中的页面层基本类似。 一个页面封装成一个 class， 在这个 class 里定义所有的元素和对应的操作。 只不过这类对元素的定位工作基本都是通过调用组件层的能力来完成的。 如下图：
