三、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在扩展性、并发和持续集成方面是比较弱的。但其他方面都很完备，所以还是一个很伟大的框架。