自动化测试，从入门到跑路-3
上篇文章大概说了下接口测试的思路，所谓技多不压身，最近又开始做起了UI层面的自动化测试，谁叫我是个有追求的测试工程师。
提及UI层面的测试，就绕不开传说中的测试金字塔：
看样子有点丑，但是很说明问题，如果按照数量推荐的程度来说，一般都会推荐少做UI层面的，尽可能多的去做代码层面的单元测试。
为什么这么说呢？
因为，UI测试本身的不稳定性。
对于我来说，UI测试一般分为两种：
- 通过自动化软件，录制测试流程，并生成可执行文件等；
- 通过脚本、工具，模拟测试流程，并对结果进行处理、比对等操作。
总而言之，大致分成两类：“软件类”和“脚本类”。
软件类
软件类里面就包含了很多，不过按录制原理，一般可以分成两类：“基于位置的”和“基于界面元素的”
基于位置
如果把屏幕看做象限，以任意两条相交的边作为横纵坐标，就可以按照（x,y）的格式，获取当前操作的元素、指令，在象限内的相对位置。
举个栗子：device.touch(60,300,'DOWN_AND_UP')
获取坐标后，模拟用户的使用，在当前坐标下进行单击、双击、右键、拖拽等操作。
PS：这种方式遇到的比较少，这么多年，只是了解和听说过，基本没有使用过，更多的是“基于界面元素”的方式。
基于界面元素
这里暂时只介绍B/S端和C/S端的情况，APP移动端接触的不是很多，更多的是自己的野路子，不敢随便传道，担心会把萌新引上弯路。
B/S端和C/S端区别在于图形库的获取方式，C端更多的会使用专门的图形库进行开发，所以需要按照当前软件的界面，进行获取元素；而B端是基于浏览器或浏览器内核进行开发，我们所看到的界面，都是可以直接操作的元素，不需要再次获取。
说到C端获取图像的工具，我们的“巨硬”公司提供了一款超级方便的工具：Spy++
可以直接抓取软件界面的基本属性，UFT(QTP)也是基于此工具，进行了拓展，开发出了适合自己本身的元素抓取工具。
而B端呢，则比较推荐Selenium IDE，是一款浏览器插件，目前Firefox和Chrome均已兼容，只需要去对应的应用市场，下载安装即可。
个人认为这个工具方便的地方有两处：
- 可以按照对界面的操作，录制可重复执行的脚本；
- 支持导出多种格式的脚本。
脚本类
关于脚本类的自动化测试，其实比较笼统，不是很好分类，这里只是简单介绍下在工作中实际应用过的方法或工具。
C端
因为手头上没有windows的环境，电脑的空间有限，就不折腾虚拟机演示了，这里只是大概介绍下之前是怎么使用的吧。
C端，之前使用过的是一种名叫VB的语言，很古老的语言，其中细分下来，用的比较多的是VBS，这种脚本语言的有点在于，可完美运行在任意windows的电脑上，不要安装环境。
还不是我巨硬系统自带环境
也不需要什么编辑器，TXT写完之后，手动修改文件后缀，从“.txt”修改成“.vbs”，双击文件即可使用。
此外还有一个原因是，UFT默认脚本的语法，和VBS极其相似。
这里就不过多介绍了，毕竟已经不再是主流的语言。如果有兴趣，可以自行Google，偷偷告诉你，VBS除了可以整蛊朋友外，还可以做一些dark的事情。
B端
除去JS和DOM，这里介绍下在众测试中广为流传的一种框架：Selenium
其实还有简化版的框架：Splinter
虽然简化，但是常用的功能一个都不少，而且函数封装的比较方便、简洁。如果只是轻度使用，能满足基本的操作。
问：网页获取页面元素，总共分几步？
答：第一步，打开浏览器；第二步，找到要定位的元素；第三步，鼠标右键，选择检查。
就这么简单的三步走，甭管前端用的是什么库和框架，天下武功，为此不破。
定位后，通过对不同元素的操作，模拟用户实际的使用流程，从而进行测试。这种也是目前较为主流的测试模式，万变不离其宗，不管用的是什么语言、什么框架、什么工具，其主要思想都是，用某种方式去模拟实际的使用操作，以达到测试的目的。
综上所述，不管是用到了那种方式，都是不稳定的，只要界面出现调整修改，就可能会引起脚本的崩溃，特别是需求变动频繁的时候，墙裂推荐，佛系测试，先写单元，再写接口，最后再考虑UI。