让自动化脚本在冒烟前运行，我想很多人都曾想过，也曾试验过，为什么最后放弃了？

　　我能够收集到的原因有以下几种：

　　1、代码开发没有完成。

　　2、程序不稳定，页面布局变动大。

　　3、编写脚本的时间紧张！

　　我作此尝试的初衷是为了：

　　1、拉长WEB应用程序测试时间（测试时间是软件质量保障最重要的手段之一）

　　2、让自动化测试脚本代替一部分手工测试，不是全部。

　　3、将数据库中数据校验部实现自动化。

　　所有的人都知道自动化测试脚本不可能100%替代手工测试，既然这样，能代替多少就多少。

　　总是能节约时间的，也能为日后的自动化测试回归脚本作准备。

　　所有测试都知道，测试介入越早越好，事情越早解决越好。

　　测试用例本来是要时时更新的，为什么测试脚本就不能时时更新呢？

　　我暂时采用的工具是QTP：

　　1、使用对象库

　　2、让能跑起来的都跑起来，不能跑起来的暂时不管

　　3、先采取固化脚本的思路写脚本

　　4、通过URL访问开发人员本机（因为开发人员只开发本应用，其他调的是DAILY能实现）

　　5、并行编写自动化脚本

　　6、采用单浏览器

　　7、在测试计划里合理安排出编写脚本的时间

　　在实际运作过程中取得的经验：

　　1、编写QTP脚本的目的是提高效率，如果不能提高效率，就是暂不要作，别浪费宝贵的时间（这恰恰是太多使用自动化工具的人的误区，一定要完美的用它解决所有问题）

　　2、修改脚本时，错误大多类似，按照功能写成函数，便于修改

　　3、编写脚本，当开发页面大体出来时，要善于利用开发人员的边角时间，比方说上班前半小时（这个时候开发在看邮件，或开晨会），或利用开发开周会时间，只要有1，2个小时，足够我们将页面对象获取了。

　　4、编写脚本，分成三步走

　　a. 先编写简略版脚本。例如bwr().page().weblist(”状态“).select “”，先按这种方式写一个思路的初稿，特别是SQL语句要完成。

　　b. 当页面大体出来时，获取开发的完成页面（对象），此时再替换一下脚本，修改一下，找出一些难点，衡量一下难度，如果有难度，就不要编写，弹出一个MSGBOX让人工去校验。

　　c. 临冒烟了，在搭环境时，将所有的脚本放出来跑一跑，抓紧时机对对脚本作修改，相信大多数的脚本此时都能够跑起来了。

　　d. OK，开始冒烟了！，最让人期待的时候来了，（此时脚本的准确性，是让很多人为之担心的）那好，让脚本单步运行！我们盯着它！看看他实际运行情况。相信这样一种结合方式，自已能够放心。也让开发能够采信我们的结果。

　　5、运行脚本时，被测试的页面程响应较QTP脚本速度慢，当一个操作会更新数据库时，让脚本WAIT 一下，再去取数据。

　　6、在QTP中去数据库取数时要用精确比较，不要用LIKE。