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

本文探讨了一种改进的自动化测试框架设计方案,旨在降低测试用例对软件实现细节的依赖。通过引入基于URL的控件访问机制,使测试脚本更加灵活且易于维护。文章还讨论了如何基于控件的特性来描述并定位控件。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

最近在考虑自动化测试框架的时候,发现原来的想法,虽然解决了定位及访问控件的困难。但是,用例代码却因此对程序实现细节有了很强的依赖。这些依赖可能对用例代码的开发带来一些困惑。
在思考解决这个问题的时候,自然的方案,就是提供统一地访问控件的方式,而不是原来那种直接生成对象的方式 ( 参考 自动化测试框架:测试编程框架 ) 。这种访问控件的方式,就好比访问网页一样,输入一个 URL ,就可以得到想要的控件。以此为基础,编程过程中的代码中虽然增加了对 URL 的输入,但是却因此去除了用例代码对软件实现的具体依赖。以后就算实现代码变了,也基本不影响用例代码。
对比一下以往的对控件的定位方式,往往通过控件的隐含属性:包括 Text ClassName,Index,ID 等等。但获取这些属性的前提是使用工具去查看!这种方式的一个显然的缺点是,这样的代码,可读性是比较差的,而且和控件的绑定将变得更加紧密!
分析了这些情况,选定了方案。那么,问题就剩下如何描述控件。
描述的首先是元素选择。在选择的过程中,我将可选择的元素约束在那些可以从界面上观察到的属性。经过分析,得到下面这些元素的列表:
1. 控件本身的标题性文本。一些不含标题性文本的控件,可以通过提取一些内容信息,作为标志。
2. 控件之间的相对位置。左右上下、父子关系。针对某些控件,特别是常用的文本编辑框、网格控件、 ListView TreeView 等等都是没有标题的。所以定位这些控件才是描述中最难把握的地方。在这个问题上,重点考虑的是利用那些可以描述的控件,加上位置的判断,共同定位这些控件。
3. 控件标准类型(非 ClassName )。我们可以给各种控件进行归类,这样,在编写脚本的时候,根据这些类型去定位控件,就比较容易了。特别是那种同类型只有一个的控件,就可以直接用类型定位了。
4. 控件显示顺序(从左到右,从上到下)
基于这些描述元素,基本上我们可以完成对所有控件的描述。
回过头来想一下,如果实现了这点(假定可以实现),那么我们会发现,我们其实可以针对软件的原型进行编写测试用例。这是可以理解的,因为原型和软件,相同功能的控件都是同一类型的,这对我们用例的编写,无疑提供了统一的平台!只要利用好这个平台,工作效果不可限量啊。
只不过这时候的校验代码都是失败的,但这不是正符合了测试驱动开发的精神了嘛?但不可否认,这是一个非常棒的想法!
最后,有关自动化测试方面的思考,是一个慢慢细化的过程。在这方面的探索,我们还会继续下去!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值