|
最近在考虑自动化测试框架的时候发现原来的想法虽然解决了定位及访问控件的困难但是用例代码却因此对程序实现细节有了很强的依赖这些依赖可能对用例代码的开发带来一些困惑 在思考解决这个问题的时候自然的方案就是提供统一地访问控件的方式而不是原来那种直接生成对象的方式比如说提供Controls[ID]的方式统一访问控件那么代码中虽然增加了对ID的输入但是保障了用例代码对软件实现的具体依赖就算实现变了也基本不影响用例代码 以往的对控件的定位往往通过控件的隐含属性包括ClassNameIndexID等等但获取这些属性的前提是使用工具去查看！一个显然的缺点是这样的代码可读性是比较差的！ 于是问题就是如何描述控件 首先是描述的元素选择我将这些可选择的元素约束在必须从界面上可以看到于是也很容易得到这些元素的列表 控件本身的标题性文本 控件之间的相对位置左右上下父子关系 控件标准类型（非ClassName） 控件显示顺序（从左到右从上到下） 针对某些控件特别是常用的文本编辑框网格控件ListViewTreeView等等都是没有标题的所以定位这些控件才是描述中最难把握的地方在这个问题上重点考虑的是利用那些可以描述的控件加上位置的判断共同定位这些控件 基于这些描述元素基本上我们可以完成对所有控件的描述如果实现了这点（假定可以实现）那么我们会发现我们其实可以针对软件的原型进行编写测试用例只不过这时候的校验代码都是失败的但这不是正符合了测试驱动开发的精神了嘛？ 自动化测试框架在这方面的探索还会继续下去！ |
