三、QTP框架的生态系统

3.1 UI自动化测试框架生态系统

一个成熟的UI自动化需要包含很多组件,需要有系统的对象识别机制、完善的脚本开发语言、详实的报告等等。笔者在多年的自动化项目实践中,总结如下10个组件,组成了自动化框架的生态系统。

其中方框内部是框架本身提供的功能,外面的两个是推进自动化过程中必须考虑的问题。这个生态系统也适用于接口自动化测试以及单元自动化测试,需要把界面识别替换为请求和测试类别。

1、界面识别。对于UI测试最重要的组件,识别的准确性,运行中的稳定性,以及后续脚本的维护成本是主要考虑的方面。

2、脚本编写。这里主要是指框架的脚本语言,学习成本是不是高,对于项目角度要考虑普及程度,人是不是好招。语言的基本特性也是考虑的一部分,不过能够使用起来的语言,也都没什么问题。

3、集成开发环境。框架提供的IDE是否功能齐全,这点各种框架的差异还是很大的。IDE是否强大,看普及程度即可。用QTP的,没有不用UFT工具的;而用Selenium,基本没有用Selenium IDE的。IDE需要有基本的脚本编写、调试能力,还要有库的管理、脚本工程的管理等等。

4、容错处理。UI自动化的容错非常必要,基本的要求是单个用例失败不影响后续用例(一定程度依赖用例设计)。更高的要求包括是否能够重试、失败能否通过截图、日志保留现场的情况等。

5、用例管理。自动化的过程其实是将原手工用例翻译为自动化脚本的过程,那么多用例的管理就需要框架的支持了。多用例管理是第一步,能否加标签、分组按需执行,可读性是否好也是需要考量的。

6、测试数据管理。测试数据是体现测试人员智慧的一个方面,如何通过更少的数据组合覆盖更多场景,是很有挑战的。自动化框架对于测试数据的管理需要支持数据驱动,方便的对数据进行管理和维护。

7、测试报告。重要性无需多提,好的测试报告要内容丰富、可读性好,同时对于失败的用例有实用的定位信息。最重要一点,要领导喜欢。这个很关键,关系到自动化项目的成败。

8、并发。在自动化初期容易被忽视,越到后面越重要。通过并发提高脚本执行效率,有的框架还支持分布式。

上面8个组件是框架本身需要提供的。多个已有框架的选择,要对比多个框架在上述8个组件上的强弱;自己开发框架,这8个组件都是需要实现的。

另外,扩展性是个双刃剑,封装重的框架说难听了是封闭,说好听了是功能强大。对于扩展性,笔者还是比较期待的,最少留了后路。原有的组件是否能够支持替换、能否在原有的验证点上进行增强、能否支持第三方的库。

最后一点是持续集成的支持。自动化测试不是为了自动化而自动化,目的是快速交付可用的软件,所以框架对CI/CD以及DevOps的支持也很重要。

2.2 QTP的生态系统

之前的文章提到过QTP的生态系统很完备,具体体现就在上述的组件中。如下图所示。

1、界面识别。QTP通过对象的可定位属性进行识别,有很完整的识别机制,是其他自动化框架界面识别的开山鼻祖。

2、脚本编写。VBS脚本,虽然不再流行,语言还是好学又好用的。

3、集成开发环境。自带的UFT工具非常强大,所以说用QTP的,没有不用UFT工具的。

4、容错处理。脚本支持on error resume,框架支持设置场景恢复脚本。重试需要自行编写代码,截图默认有,可配置。日志在测试结果中很详细。

5、用例管理。可以与QC/ALM进行集成,完成用例的管理。对于标签、分组不支持。

6、测试数据管理。Data Table众所周知,就是自带的Excel数据管理,可以配置全局数据和脚本数据。笔者认为Excel是最伟大的发明,只要有Excel,可读性、维护性、易用性都不成问题。

7、测试报告。脚本执行结果稍显专业,缺少统计分析的功能。自带的Result Viewer查看测试结果很清晰。

8、并发。多线程和分布式都不支持,需要编程实现。

9、扩展性。弱,自身的组件几乎不能被替代,验证点的增加需要编程(如自行进行数据库的连接和验证),第三方库可以通过VBS调用COM实现。

10、持续集成。不支持,需要自己动手完成相关的串联。

可以看到,QTP在扩展性、并发和持续集成方面是比较弱的。但其他方面都很完备,所以还是一个很伟大的框架。

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180402G1W5PR00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注腾讯云开发者

领取腾讯云代金券