自动化测试框架: 用原型编写用例？

最近在考虑自动化测试框架的时候，发现原来的想法，虽然解决了定位及访问控件的困难。但是，用例代码却因此对程序实现细节有了很强的依赖。这些依赖可能对用例代码的开发带来一些困惑。

在思考解决这个问题的时候，自然的方案，就是提供统一地访问控件的方式，而不是原来那种直接生成对象的方式 ( 参考 自动化测试框架：测试编程框架 ) 。这种访问控件的方式，就好比访问网页一样，输入一个 URL ，就可以得到想要的控件。以此为基础，编程过程中的代码中虽然增加了对 URL 的输入，但是却因此去除了用例代码对软件实现的具体依赖。以后就算实现代码变了，也基本不影响用例代码。

对比一下以往的对控件的定位方式，往往通过控件的隐含属性：包括 Text 、 ClassName,Index,ID 等等。但获取这些属性的前提是使用工具去查看！这种方式的一个显然的缺点是，这样的代码，可读性是比较差的，而且和控件的绑定将变得更加紧密！

分析了这些情况，选定了方案。那么，问题就剩下如何描述控件。

描述的首先是元素选择。在选择的过程中，我将可选择的元素约束在那些可以从界面上观察到的属性。经过分析，得到下面这些元素的列表：

1.     控件本身的标题性文本。一些不含标题性文本的控件，可以通过提取一些内容信息，作为标志。

2.     控件之间的相对位置。左右上下、父子关系。针对某些控件，特别是常用的文本编辑框、网格控件、 ListView 、 TreeView 等等都是没有标题的。所以定位这些控件才是描述中最难把握的地方。在这个问题上，重点考虑的是利用那些可以描述的控件，加上位置的判断，共同定位这些控件。

3.     控件标准类型（非 ClassName ）。我们可以给各种控件进行归类，这样，在编写脚本的时候，根据这些类型去定位控件，就比较容易了。特别是那种同类型只有一个的控件，就可以直接用类型定位了。

4.     控件显示顺序（从左到右，从上到下）

基于这些描述元素，基本上我们可以完成对所有控件的描述。

回过头来想一下，如果实现了这点（假定可以实现），那么我们会发现，我们其实可以针对软件的原型进行编写测试用例。这是可以理解的，因为原型和软件，相同功能的控件都是同一类型的，这对我们用例的编写，无疑提供了统一的平台！只要利用好这个平台，工作效果不可限量啊。

只不过这时候的校验代码都是失败的，但这不是正符合了测试驱动开发的精神了嘛？但不可否认，这是一个非常棒的想法！

最后，有关自动化测试方面的思考，是一个慢慢细化的过程。在这方面的探索，我们还会继续下去！