让自动化脚本在冒烟前运行

 

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

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

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.

 

这是项目自动化脚本准备的一点心得。欢迎大家同我积极探讨！呵呵

 

时刻谨记目标,每天进步一点点,然后就有一大步!