QTP能做什么,例如:QTP自带的飞机系统为什么要用QTP来测试呢,麻烦用自己的经验举例一下，勿复制理论

QTP能做什么,例如:QTP自带的飞机系统为什么要用QTP来测试呢,麻烦用自己的经验举例一下，勿复制理论

要是 让你重复手工走10000遍订票流程..是不是会很累（而且数据不能保证每次都一样）
但是qtp你写完一次脚本 直接跑10000遍，完全没问题

测试一遍的话，用qtp的确没必要。
但是像微软这样的公司，操作系统出了多少个版本啊？光xp就是sp1，sp2，sp3
到win7，那些基本的操作还是一样。
这种测试的重复性就很大啦！ 比如双击打开文件夹这样操作。
就可以录制一次。以后就不用人测了。
qtp就适合于这种版本不断升级，但是多少功能不变的软件

QTP主要是做回归测试时使用的，比如：你正在测试飞机订票系统，而这个系统又升级了，那么你需要将之前运行过的用例全部重新测试，这时就可以使用QTP来进行，而且同样的操作不同的数据只要运行一次QTP脚本都可以完成而手工则需要多次。这样既节省时间也节省人力。

真正做自动化的工程师心里都清楚，要想要QTP发现Bug，几率相当低。
一般QTP用于回归测试或者版本更新时。
回归测试的时候，如果用周边影响法（一般都是这种方法：测试发现Bug的地方以及和他有关系的模块），但是周边很难确定。而且谁也不敢保证Bug一次就能改成功，也很有可能这里改好了，另外一个地方出问题了。这时如果使用QTP，只需要双击一下脚本（比如VBS脚本，让他调用执行QTP），那么你就等着就可以了。如果脚本完全，那么整个项目都会测试一遍。你也可以让它自动执行，比如下班以后，第二天来公司，直接看测试报告就行了。这样总比你自己一边又一边的手工点击测试强很多。
版本更新时也同理，手工测试所有功能，太麻烦，而且出了Bug，改完后还要回归测试。这时也体现出了QTP的好处。
当然，相反，QTP脚本工作量极大，尤其是对对象库的维护更新。而且，QTP脚本都是在界面稳定了（因为QTP是基于界面的测试，经常改动界面，会导致脚本无法执行，必须修改），而且几乎现在很少有公司会等到项目完全做完了在测试，基本项目完成了，Bug也改的差不多了。这时再开始写脚本，即使还有Bug，那么写脚本调试过程中，必然会发现。等到脚本都完成了，写脚本过程中发现的Bug也会改完了。那么脚本执行让他发现Bug。。。太难。。。
现在大多数公司要求测试人员会使用QTP，完全是因为QTP是主流测试工具，哪个公司不要面子。都觉得自动化很牛，很厉害，专门成立自动化测试部门。其实也就是做给客户看的，说白了就是要花很多钱请人来写脚本（自动化工程师的工资肯定会高于普通测试人员，但实际对项目的贡献，微乎其微），打造出自我感觉很厉害的测试部门。
但是不得不说QTP之所以能够流行起来，也是有他自己的独到之处，多研究一下QTP其实乐趣很多，可能疯狂的喜欢上它。其实使用QTP来测试项目，可以让你对项目有更深入的了解。如果使用QTP的话。建议：就当那个录制按钮没有。一定要手写，需要精通VBS，以及DOM，至于最后的测试报告，完全可以自己写个模板，测试报告的支持语言还是比较多的（QTP自带的测试报告看着实在不自然）。
现在大多数公司都需要自动化人员，但是公司压根就没有懂自动化的人，让他们来招自动化工程师。。。小心毁了公司。面试人员但凡会个录制，都能把面试官看傻了。导致的结果就是，现在成批的自动化人员水平极次。甚至压根就不会编程，就知道点个录制，对象库及其混乱，脚本一旦出现问题，神仙也改不回来。
总之，学习QTP没有什么不好，只要会，就比不会强。当然，如果不是公司规定的必须学，那么自己学习的话，也建议看看LoadRunner，它才是真正最有用的。
最后再加一句：其实作为一个合格的测试人员，有义务要将自己所执行过的测试用例，编写成为脚本，以便以后方便测试。做测试的总不能仅仅局限于在界面一通乱点吧。。。

用QTP进行自动化测试能大大降低人力物力，可以用QTP进行参数化，用不同的帐号登陆系统，用不同的数据来测试各个功能。编写脚本，调用服务器，让系统自动的跑流程。飞机订票系统只是一个简单的例子，相对于复杂的系统，就能体现QTP强大的功能和作用了。奥妙自在其中。