自动化测试框架
看了精通QTP----自动化测试技术领航一书后仔细体会，脑袋里蹦出一堆问题来了，里面最后一章讲自动化测试框架，讲的是作者原创的一个框架“用例解析驱动测试”，讲的就是如何实现自动解析用例，自动生成脚本，自动执行并自动出报告等一系列技术。那是不是自动化测试框架就是“用例解析驱动测试”呢，感觉应该不是，框架是一种思想，“用例解析驱动测试”只是一个思想的一个具体形式，不同的项目、不同的测试对象，使用的框架肯定不一样，应用的思想也不一样，那还有没有其他的比较常见的已有的自动化测试框架呢？
这里讲的还只是基于QTP的自动化测试框架，我想自动化测试框架肯定不仅仅是基于QTP的，比喻一些后台软件的自动化测试，没有界面，也可以进行自动化测试，那肯定就不是基于QTP 了，那么还有哪些自动化测试思想或框架是应用比较广泛的呢？
但是反过来想，“用例解析驱动测试“这一思想实现了测试中最基本的一些流程，自动解析用例，自动生成脚本，自动执行，自动出报告，感觉自动化程度已经很高了，难道还要实现自动设计用例吗，那感觉暂时是不可能的，那这样一来，“用例解析驱动测试“不就是进行自动化测试的一个最基本的框架了吗？
没实际做个自动化测试，以一个做了几年的手工测试的角色和角度来考虑的，还望自动化测试的高人大师们点拨 自动化测试框架是一个很广泛的话题，你看到的是基于QTP的，还有其他很多自动化测试工具，比如说Selenium, SoapUI等等。框架的设计模式也是多种多样的，主要根据工具的特性，但还是要遵循一些基本原则。
1. 测试数据和测试代码分离。一般我们在编写自动化测试工具是，都会把测试数据分离，提供使用者一个template。使用者不用关心代码部分，只需要添加，修改测试数据就可以了。这样写测试工具的人和使用测试工具的人可以是不同的团队。
2. 易于扩展。框架做好之后，会去automate很多test case。新的test case添加进来，要非常容易在框架下扩展。 框架是自动化场景需求的一种公共抽象，在不同层次上含义也不一样，所以测试业界对于“框架”这个概念比较混乱。
对于初学者来说，可以从工具入手，但框架也不能过分依赖于工具。学会了框架思想，能够很快地切入新的工具，搭建起来自动化测试解决方案。
页:
[1]
