QTP脚本与开发同步
本人最近做了一个项目，总是以为QTP需要在项目稳定后进行，但是实际过程中留给QTP的时间不是很多，在自动化实现的过程中效果不是很好，往往当你脚本录制完毕人家手工测试都N个build结束了，于是在新的项目中我有一个新的想法就是QTP录制与开发同步，有句话说只有想不到没有做不到，事实证明QTP脚本与开发同步是可以实现的。接下拉把我的心得和大家分享下。不正之处请指正。
1：QTP介入一般在项目模型初期阶段，很多模块并不稳定和修改，因此在录制准备我已经充分考虑好这个问题的解决办法。在录制脚本的过程中尽量作到功能模块的扩展性，如对象仓库的维护（这很重要，一定要有条理，命名一定要规范要不然到后期维护非常麻烦，well began half done。就是这个道理，我们把前面的东西都有条理的组织好，然后进行操作。
2：在对象的使用上，对于能不用对象的我们不用对象，也就是使用描述性，尽量减少对象的管理成本，维护对象仓库是一件非常麻烦的事情。同时使用描述性在操作的扩展性上有着很好的作用。
3：我们是没日构件，早上上班的第一件事情就是把前一天的代码回放一次，当然偶尔会遇见错误，只要项目的框架没有很大变动。我们的代码基本上不会有很大的问题，当然问题是存在的，这就需要我门在项目的过程中对脚本的管理了。本人基本上都是这么做的每天早上就把自动化脚本跑下就当是冒烟测试了，不会花费很厂的时间，当到后期你的脚本已经形成规模，模块分割很清楚，修改和维护都非常简单。
4：自动化框架的选择，这是对整个自动化项目的框架的设计了。建议使用几种框架一：QC，TD，QTP的组合。次组合适合项目较大的项目，条理清楚方便知识库的积累，一般需要2个自动化测试人员的组合，工作两比较大。二：1个测试人员就可以了 比如我 呵呵，使用纯数据驱动的方式完成。关于数据驱动的好处就是上手快简单，速度快啊。
5：这个自动化项目本人已经完成，其他的手工测试人员只需要依据需求在我给出的EXCEL表中设定数据 RUN 什么都不用管拉，速度狂快啊。给其他手工测试的同时腾出了大量的工作时间。呵呵，相对我们来说也是个人价值的体现，有成功感啊。
还等什么呢。只有想不到，没有做不到。开始吧，以上只代表本人观点，呵呵不正之处请指正，欢迎大家一起讨论交流和学习。 你发个能用的框架来看看，我正想跟你学习呢。
:o 这个需要自己去研究了 呵呵 楼主把自动化引入了冒烟测试，是值得称赞的，但是目前难题是如何引入回归测试，恐怕国内没有几家能做得到的。 越早介入脚本维护越难啊！！ 初期开始阶段肯定会遇到维护起来比较麻烦的事情 但是越到后面越简单. 关键需要的还是和开发人员的沟通 和对项目变更的即时把握 1、最大的问题来源于需求上的变更.
2、最痛苦的事情来源于业务操作流程超长.
3、偶尔还会因自己对QTP不了解而受伤，走弯路.
一句话，成长的代价是巨大滴...
页:
[1]
