 07年我参加了软件测试工程师培训课程（课程中包含自动测试工具，功能：QTP，性能：LR），QTP课程主要讲解了QTP的关键字视图相关的内容（专家视图部分没有涉及），培训完以后，我对QTP的认识是：QTP使用起来很简单，就是一个录制、回放（不通过就调试）、细化脚本、再回放（不通过就再调试）、出报告的过程，那时候对QTP的认识很肤浅，也和一些朋友一样对QTP产生过类似的质疑：QTP能满足实际项目包罗万象的需求吗？当时感觉QTP只能应用在主要流程的验证上，而且没有真正意义上做到测试的自动化（当然以上都是07年对QTP的认识）于是我停止了继续深入学习QTP……
09年9月左右，由于项目人手少，测试时间又短，所以每次版本更新后，只对新增功能和相关模块进行测试，而比较稳定的模块只走一个正常流程（甚至时间太紧连正常流程也来不及走了），另外由于我所在项目和另外一个项目都是一个大项目的子项目，所以另外一个项目的修改也可能导致本项目的一些功能不可用，下面有个实际项目中遇到的例子：有一次另外那个项目修改了数据库结构，数据库中删除了一个字段，导致我这个项目的一些特别稳定的功能中查询该字段的所有地方都报“黄页”（当然这些地方都做了安全处理，只抛了个自定义的页面，没有把代码抛出来），当时吓出了一身“冷汗”，还好每次更新我都会挑一些没有修改模块进行抽查，这次运气好，刚好抽到了，俗话说：“吃一堑长一智”，就算完全没有修改的模块也应该验证一下，但是目前的时间和人力只够对新功能的测试，我又想到了QTP，于是我安装了QTP，将老功能的业务流程录制成脚本，每次更新后，跑一下流程，验证一下老功能是否可用，成功案例：有一次QTP回放当中发现2个地方报“黄页”，后来才知道是因为另外一个项目更新了WEBSERVICE，而我这个项目的那2个地方刚好要调用那个WEBSERVICE，所以会报错，由于这一次的经历让我忽然对QTP产生了兴趣，对QTP脚本进行了更深入的学习，从07年的完全自动录制到现在的手动写脚本，从脚本依赖对象库到脱离对象库，从求助别人到帮别人写实际项目的自动化测试脚本，从各个测试脚本相互独立，到自己编写自动化测试框架……2个月前自己写了个测试框架，实现了运行一个VBS脚本，就可以打开QTP（脱离对象库）并按照CASE优先级从高到低运行所有需要运行的CASE，运行结束自动将结果写入文件中……2个星期前重新设计框架提高脚本开发效率和简单易用性。
下面写下现在我对QTP的看法：在没有接触自动化测试框架之前，我所有的脚本都是都是相互独立的，即：每个功能作为一个TESTCASE，这样就导致每次都要手动把每个脚本运行一遍，然后看报告，感觉自动化一点也不自动化，而且脚本的可重用性也很不好。于是我就在想，怎样才能做到真正意义上的自动化呢？可不可以通过运行一个驱动脚本打开QTP然后自动运行所有指定的脚本用例呢？后来在网上查了相关资料，开始自己搭建自动化测试框架：
我的第一个框架：由依赖对象库到脱离对象库，由自动录制到手动编写测试脚本。这个框架思想是学习于51
论坛中的《轻量级自动化测试框架》，只不过在此基础添加了一些功能，比如用例执行优先级。当时觉得这个框架很好用，全部使用描述性编程这样可以使用例不依赖对象库运行，提高了脚本的可移植性，但是随着对QTP认识的不断的深入，渐渐的发现描述性编程的弊端：脚本开发效率太低，同样开发一个测试脚本，完全使用描述性编程和自动录制+手动增强脚本相比，录制一个同样的功能，需要的时间大约3-4倍，甚至更长，因为使用描述性编程需要对对象的各个属性特别熟悉，另外完全使用描述性编程的调试效率也很低，使用哪些属性作为识别该对象的依据又需要一个判断过程，这样都会降低测试脚本的开发效率，还有描述性编程对编程基础有一定要求，所以我觉得脚本开发应该以自动录制+手动增强脚本为主，以描述性编程为辅。因为在有的项目中有些步骤可能通过自动录制是录制不到的，这时候描述性编程就起到很好的辅助作用。
我的第二个框架：由脱离对象库到依赖对象库，由手动编写测试脚本到自动录制+手动增强脚本（以描述性编程为辅）。由于第一个框架的弊端，所以我在想怎样避免这个弊端，提高脚本开发效率，自动录制是开发脚本最快的一种方式，而且对脚本开发人员的要求很低，于是我开始把目光回归到QTP这一最简单最基本的功能上。开始设计一个属于我们“菜鸟”的测试框架。（其中借鉴了《QTP项目应用与进阶》中测试用例模板）
这个框架（相对于第一个框架）的优点：1、降低人员素质的要求，使用例的脚本开发人员不需要懂得太多QTP方面的专业知识，只要掌握简单的录制回放过程和脚本增强就可以，这样避免有些人整天忙有些人“没事”做了，从而达到资源的充分利用。2、提高脚本开发效率。
这个框架（相对于第一个框架）的缺点：调用外部ACTION相对复杂一点，需要明确知道该ACTION所在脚本的位置，不过这一点可以通过文档解决这个问题，制作一个 ACTION列表就可以了。2、对象库维护比较烦琐。假设页面元素的属性发生变化，那就要UPDATE所有使用到该页面元素的脚本中的对象。
由于这个框架写在了“丫头”的毕业论文中，目前她还没答辩，为了避免不必要的麻烦，所以这里就不详细写了（大家看了附件的框架实例就应该能明白我的思路了）本实例是使用QTP10.0录制的，重点阐述的是一种思想，脚本中很多功能未加入。例如：自动加载插件的功能，不过大家可以自己加一下（QTP自动化对象模型参考中有加载插件的代码），另外QTP版本比较低的朋友可以自己录制下脚本替换掉Script文件夹下对应的脚本试下。若要设置脚本运行时QTP可见，可以将函数driver（）中的qtapp.visible=False修改为qtapp.visible=True
最后，如果哪位朋友有什么好的建议或觉得哪里需要改进，可以给我留言，如果有时间我会试着改进一下，另外写的不好的地方也请多多指正，谢谢！
向大家推荐2本QTP相关的很不错书：
《QTP项目应用与进阶》 E测工作室（风过无息、斐明哲、黄先容、韩柳、俞戴龙 化学工业出版社
《QTP自动化测试实践》 陈能技 电子工业出版社
第一本书我买了而且前段时间看了，感觉很不错，思路很清晰，而且包含编码规范等自动化以外的的知识，感觉写的蛮好的。
第二本书最近才了解到这本书，不过没看过，朋友说很不错，正打算买呢，另外看了作者博客里的资料，感觉写的很好，所以就推荐大家看看，希望能对大家有所帮助，谢谢！
[ 本帖最后由 feiyunkai 于 2010-2-23 17:46 编辑 ] | 
/1 
关于我们
发表于 2010-2-22 15:36:11
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
微信
收藏
置顶服务
换色服务
楼主
这也是我对中国的测试界未来3年的展望，希望能看到自动化在大多数公司都有用武之地了！
