自动化测试框架: 所见即所寻

 经过一段时期的框架准备和javascript:tagshow(event, '%B2%E2%CA%D4');" href="javascript:;" target=_self>测试方案编写，实际的冒烟测试已经开始进行。目前还算比较顺利。当然了，工作忙了一点，所以博客的更新速度也降低了。

        在编写的过程中，发现对于独立的子窗体的处理还是比较方便和简单的。这些窗体的普遍特点就是结构简单，功能单一，所以对应的处理过程也比较方便。但是对于主窗体来讲，就非常不一样了。可以说，一个系统中的绝大多数窗体，都包含在主窗体中，那么，对于主窗体上的控件的定位问题，就没有我们刚开始设想得那么简单了。

        最大的问题，在于重复的问题。我们一般通过控件的一些特征描述，来描述一个控件。但是，在主窗体中，往往拥有相同特征描述的控件不止一个。这是非常有可能存在的事实。

        并且，由于很多控件的重叠特性（有些控件被覆盖住了），导致最初设想的“方位”特性，也有可能出错！这个问题困扰我们很久，不光是难以定位控件，也会让测试代码不易读和维护，且受界面影响的可能性就变得更大了。

        在解决这个问题的过程中，我们考虑到作为人，来识别界面上控件的时候，并没有遇到任何障碍，其中最关键的原因，就是人已经屏蔽掉了所有不可见（包括隐藏和被覆盖的控件）的控件。这样，人在识别的过程中，就少了很多干扰，定位也越发的简单直接。

        判断控件的可见性是非常简单的。但是对于真正不可见的控件的实现，遇到了很多问题，也曾经考虑过绕过去，但是最终我们还是确定，这是一个非常好的原则，必须坚持下去，它将大大改善编写测试代码的简单性和可读性。

        首先遇到的是一种方式，是将控件的位置，设置在远离屏幕的位置，比如说在(-10000, -10000)到(0,0)之间，那么其区域并不在桌面上，最后也必然不可见。

        最复杂的是控件的层叠。在Delphi中，针对Controls，存在一个ZOrder的概念。不同的语言有着不同的处理。Delphi中是不可以直接设置ZOrder的，但是提供了BringToFront和SendToBack两个方法来简单改变ZOrder。我们平时看到的控件层叠，都是通过这个方式来实现的。针对这种层叠方式，我们通过判断其是否被ZOrder更高的控件覆盖来判断。

        通过对几种常见的可见性方式的判断，我们发现主窗体中的控件定位变得非常简单。这为我们下一步的测试代码编写提供了非常好的基础。

        在这过程中，感受最深的就是，好的原则一定要坚持下去。好的设计往往不在于最初的设想，而在于过程中的坚持！

原文转自：http://www.ltesting.net