QTP自动化项目实战心得
1、有扎实的QTP基础（熟练运用QTP编写代码，各种各样的东西都要会，能举1反10，不是录制）2、理解一定的自动化测试框架（了解下即可，中国的框架形同虚设）
3、能独自将前2者运用起来，做的不好没关系，可以改！（QC+QTP先用好即可，或者自己兴趣一高，VBS小小编写下玩玩）
4、脚本写的越简单越好，注释该加的别漏加，还一定要直观，多用WITH，不错的，据说还能增加性能
5、编写脚本，最好还是符合“高内聚，低耦合”的软件工程理念比较好，我们自动化测试也是需要的
6、能重用的脚本坚决要重用，不然就是浪费时间，浪费金钱
7、脚本细分化大家都会，但是它是一门很深的技术
8、场景恢复要到位，多思考
9、搞不定的控件也尽量少用虚拟对象、对象映射等技术，多用旁门左道去搞定，至少比前两者来的稳定
10、写脚本，会举一反三
11、尽量别用数据库检查点（WUGECAT补充）
12、写好测试用例（WUGECAT补充）
13、涉及到设计层（思想层）的东西都比较难 实现层（代码层）就会好很多（蓝天伟补充）
大家一起补充。。。
[ 本帖最后由 yujie6832 于 2010-3-9 16:53 编辑 ] 顶一下 路还很长，加油！ 1、有扎实的QTP基础
-->什么叫扎实的QTP基础？
2、理解一定的自动化测试框架
-->复杂度低的工作何须所谓的框架?不是使用了QTP COM，自定义了Report就叫框架了
5、编写脚本，最好还是符合“高内聚，低耦合”的软件工程理念比较好，我们自动化测试也是需要的
-->怎么样才能“高内聚，低耦合”？
实在是不想说了。。。 你都说的这么全面了,让别人怎么补充??:lol 11.尽量别用数据库检查点
回复 4# 的帖子
那就别说了，兄弟~我知道，您是高人~技术呆子！其实我可以回驳你N句，但是我也实在不想说了~最近又有新的对于技术的理解了，技术就是大蒜和咖啡的区别 会做和会说是2回事，不光要会做，还要把自己理解的东西分享给别人，有可能是不对，但至少敢于提出，和别人分享。支持yujie6832 支持~~:) 12.写好测试用例 个人觉得涉及到设计层（思想层）的东西都比较难 实现层（代码层）就会好很多 原帖由 lantianwei 于 2010-3-9 16:45 发表 http://bbs.51testing.com/images/common/back.gif
个人觉得涉及到设计层（思想层）的东西都比较难 实现层（代码层）就会好很多
恩，这点遗漏了，我补充下~设计的确是后期证明实力的精华，代码写多了都会写:handshake
回复 10# 的帖子
恩，两条先补充上去，过段时间，大家一起总结总结，呵呵来说下吧
其实，没有挑起事端的意思，只是觉得这样总结有很多混淆的地方，这个坛子现在新人太多了，而LZ本身又是版主，很多新人对于LZ的话必然信服，唯恐对他（她）们造成误导。1、有扎实的QTP基础
-->扎实的QTP基本，这点上理解就比较难。怎么叫扎实的QTP基本？一般大家都认为QTP的主要原理是DOM+HOOK，通过HOOK记录页面的操作，然后IE支持的接口进行回放。当前在点击页面对象时候也是DOM的分析。但用得多了，就会更多的觉得QTP更接近一款IDE，是我们的一个编程工具。既然是编程工具，可能它只是解析执行用户的代码，具体代码的内容是什么是用户自己要保证的事情了。
我刚开始的时候用QTP做FTP新版本的下载工作，根本就没有任务UI或者WEB测试的内容，就是纯粹的把他当作IDE。到这里，如果想要用好，就不是简单的VBS和VBS的内置对象和函数就能满足你的需求了吧？
起码的只是DOM(HTML,XML)，COM，一些基本的操作系统的知识，可能还有一些特殊的需求，比如我之前写过连LINUX后台的，连数据库的，写SQL等等，就到要有了解了。
这一点在帖子如何成为QTP程序员中有体现，也是我最近关于技术的感悟：技术是立体的。想做要一点，必须要有面的知识，这样来龙去脉才都了解。
2、理解一定的自动化测试框架
说说框架，现在测试框架真的很热，但基本上我们这个板块看到的所有框架都同根同源，来自于之前见过的一个轻量级自动化测试框架，当然可能是更前的，就不太记得了。这样的框架能称之为框架吗？之前有过很多的论战，我一直是坚持在Shanxi一边的。最近柳胜出了本书《软件测试化测试框架设计与实践》大家可以借鉴。或者直接download Selenium去分析人家的自动化测试框架。
当我们的需求复杂度根本不高的时候，是没有意义去做框架的，我们现在也在做一款框架，叫做Helium，当然是山寨Selenium的意思，然后是因为我们需要这个框架是实现类似QC的功能，要集成对QTP,Selenium，Autoit等工具的调用，当然也要控制虚拟机，完成SVN自动打包，完成产品的自动安装等等较多的功能，其实功能罗列再多也不能称之为框架，而是你的东西是不是符合框架的概念。
我刚来公司的时候有个人说：框架就是给你一个入口，然后后续的操作由它来完成。而我们公司的产品基本都是在自由框架上开发的，它的存在的确给工作提供了便利和指导意义。
所以，当我们再次提及框架的时候，要想想是否框架的开发给工作带来了实际的意义并能指导后续别人的工作？
先去阿凡达，晚上再说
我喜欢和别人探讨，可能这也是当前这个板块缺少的，希望大家都能把自己的想法说出来回复 14# 的帖子
我觉得您写的太复杂了，这样更不利于新人，这个等级甚至连我，有的都没接触过，比如你说的连LINUX后台，让新人们一步步来吧，我知道您技术强~但是别动不动就那种态度，你现在态度还行~咱们还能沟通回复 17# 的帖子
呵呵，如果觉得我态度不好，我道歉，别误会 原帖由 xiaoyaoke 于 2010-3-9 17:39 发表 http://bbs.51testing.com/images/common/back.gif说说框架，现在测试框架真的很热，但基本上我们这个板块看到的所有框架都同根同源，来自于之前见过的一个轻量级自动化测试框架，当然可能是更前的，就不太记得了。
这样的框架能称之为框架吗？之前有过很多的论战， ...
我很包容的对新人说了一句：框架先随便用着，就算错也没关系，吸取个教训，就是考虑到国内的框架。。。，所以才这么说的，说的不对吗？呵呵，如果你觉得对，那请你把不客气的语气编辑掉，谢谢，我们还是可以多探讨探讨，或者说我多像你请教请教，不过，本来我的确什么都不想说了
