挺久没有继续写博客了，一方面是因为忙，一方面也是因为懒了。
现在开始逐渐恢复吧，记录下自己的学习历程。
————————————————————————————————————————————————————————————————————-----
UI自动化测试，首要考虑的是我们所选用的测试工具或框架对测试程序的支持如何。而这个支持，则主要是通过对控件的识别和操作来体现的；但是，不管一个测试工具或者框架对测试程序的支持程序如何，它执行测试程序时最终都是以屏幕的绝对坐标来定位执行的，尽管我们平时都能听到很多人在说，尽量避免用坐标。
尽量避免用坐标和最终通过坐标来识别，这个看起来有点冲突，但是却又不会冲突，是不是有点类似太极的感觉了。
坐标，通常分为两类：绝对坐标和相对坐标。
1. 通常我们所说的坐标都是基于屏幕左上角的绝对坐标。测试工具和我们人的操作最终也都是通过这个坐标来进行测试程序操作的，只不过有的我们知道，有的我们不知道，仅此而已。
通俗的讲：我们人手动来点击屏幕的时候，只是在点击的位置<x,y>发送一个屏幕点击事件，这个屏幕点击事件通过windows库定位到当前活动的窗体，再对这个窗体的一个具体位置传递点击事件，从而获得响应。这个过程，在我们的感官和需求中，我们只需要直接对活动窗体的进行操作的结果，至于定位，who care？
自动化测试本质上就是来模拟人的行为的操作，所以实现过程大致类似。它首先通过我们在代码中编写的id、text、index、class等来定位到我们要操作的控件，然后再读取这个控件的x、y属性来发送点击事件。但是，在使用层面，我们只看到了通过id来点击，至于其他获取坐标这些，leave them alone。
2. 说到相对坐标，这个就稍微有点复杂。目前已知的相对方式有相对左上、左下、右上、右下、中上、中下、居中；并且根据是否随着父窗口变化而变化，又可分类为：不扩展、同步扩展(和父窗口一起放大/缩小)、按比例扩展(父窗口扩大3倍，该对象也扩大3倍)。
举个例子来说，屏幕上有一个记事本窗口“记事本.txt”，它的坐标绝对坐标是400,600，这个记事本的开始菜单栏，它的坐标是450,700。如果假设记事本窗口的坐标为<x,y>，那么这个开始菜单栏就可以描述为：相对于窗口"记事本.txt"的坐标为50,100，绝对坐标就可以表示为<x+50,y+100>；再假设菜单栏中的编辑按钮绝对坐标为500,700，那么它就可以描述为：相对于菜单栏的坐标为50,0，绝对坐标就可以表示为<x+50+50,y+100+0>。这样的话，这个窗口上的所有坐标就都可以用一个坐标来维护了，如果窗口位置发生变化，我们也只需要修改一个最上层父窗口的坐标就可以动态适配所有按钮的坐标了。
上面就是相对的解释。其实说白了，所谓相对坐标，就是一种优化的坐标计算方式，可以让我们用尽量少的改动去适应更多的变化。
至于它的相对方式和扩展方式，则就只是其中的一些计算方式，在这里就不一一举例了。
那么，了解了上面的这些，我们可以做些什么呢？
平时在开展自动化测试时，总是会遇到一些不能识别的自定义控件，尤其是app类型程序。那么这时候我们就可以通过上面的坐标适配来完善解决一下。
下面，我来简单说一个基于坐标的控件识别的简单实现思路：
1. 实现思想：通过虚拟截图的方式来提供一个快速定位虚拟控件的坐标系，并对齐赋予一些额外的识别参数；嵌入到其他测试工具中直接使用。
2. 首先，通过调用windows api或者其他截图程序，对测试程序的全窗口截一个半透明的截图（可以按比例缩放）；
然后，获取测试程序的坐标，并监控这个截图上的拖拽事件来计算控件的坐标系，并写入xml文件；
其次，将这个xml文件导入到测试工具的对象库中进行使用。这里需要注意，有的测试工具不支持外部自定义对象，所以需要做一些转换。
3. 代码：以后再传吧。这块东西最好做成可视化的，比较易于操作