qtp工作的一些疑惑

zhaoxing12

本人愚钝，在发贴得到版主的回复后，依然没有搞懂QTP的工作原理
我的疑惑是：一、QTP是来用做回归测试的，其实也是为了节省劳力！但是问题在于，我的脚本是在什么时候录制呢？是在回归测试前还是回归中，如果是回归测试前，那它的回放的脚本与我的新版本的程序有什么联系呢。如果是在回归测试中进行，那么它不就失去意义了么，因为它是否起不了节省劳力的作用了？
            二、录制的过程我感觉其实就是一种手工测试的过程，那么如果我在进行录制的过程中发现了BUG，是否意味着我的录制就该结束？如果意味着结束，那接下来该如何呢？
            
我在这两点上老是纠缠不清！请诸位帮忙解惑，我的悟性实在太低，始终想不通！

hsjzfling

简单点说，自动化测试主要用在软件开发的中后期，至少软件UI与主要功能都已经基本稳定，每次发布新版本都只会影响到某个相对独立的局部问题，这个时候开展自动化测试才有意义。当然，还要考虑到软件规模，软件特性等因素，衡量下成本投入与收益，优先保证重复度高的部分实现自动化，比如做冒烟测试的主流程。

回到LZ的问题，
1、 QTP既然用于回归测试，那么当然是在大规模回归测试之前设计好脚本。总不会每次发布个新版本，就把软件完全改头换面了吧。
2、 录制过程中都能发现bug，那只能说明软件还不够成熟，或者你录制的模块还不成熟，还不适合进行自动化测试。

leelmars

当然,不一定必须要使用在回归测试中,比如冒烟测试,也可以使用自动化

zhaoxing12

谢谢诸位回答，2楼回答的很棒，但有一点我还是想搞清楚：我录制的脚本与我的新版本程序之间的关系的问题。好比之前录制时功能a是可以的，但实际上在新版本中a出了问题，这样的情况下，我回放的还是旧版本的功能A呀！脚本怎么能发现新的问题呢？

babyou1st

自动化测试脚本是用来在版本升级后，验证之前已经成熟的软件功能是否依然OK，总不能每发行一个新的版本就把以前的功能全部手工测一编。发现BUG也是好事，虽然自动化测试的目的不是发现bug,但如果你要对现有系统生成一个脚本，那么你就得停下来等BUG解决了。

babyou1st

原帖由 zhaoxing12 于 2008-7-4 15:20 发表
谢谢诸位回答，2楼回答的很棒，但有一点我还是想搞清楚：我录制的脚本与我的新版本程序之间的关系的问题。好比之前录制时功能a是可以的，但实际上在新版本中a出了问题，这样的情况下，我回放的还是旧版本的功能A呀！ ...

刚才没看到这一点，这种情况你就等着它Fail么，既然你已经知道这里要出错，也是需求之内，那么它Fail了不是正好？

zhaoxing12

回复5楼的，从宏观上讲，我在回归测试前录制好了相对稳定的脚本；我在回归测试中手工发现了原本稳定的功能A不好了，那自动化脚本应该就没必要回放了吧，因为它回放的是之前的录制的程序脚本。我说的也就是录制的脚本和新版本程序的联系，回放之前的脚本，肯定是通过的呀！

zhaoxing12

我说的也就是你指的验证之前稳定的功能是否OK，它如何验证呢？是回放吗？如果是回放，回放的是之前的脚本

zhaoxing12

原帖由 babyou1st 于 2008-7-4 16:03 发表


刚才没看到这一点，这种情况你就等着它Fail么，既然你已经知道这里要出错，也是需求之内，那么它Fail了不是正好？

我其实并不知道哪里会出错，只是我在手工回归时才发现这里居然错了！那么我的录制的脚本有什么用呢？它的回放无法验证我的新版本的一些功能依然OK呀！

babyou1st

验证之前稳定的功能是否OK，它如何验证呢？
当然是之前的脚本，因为你之前是在稳定的基础上录制的。

我其实并不知道哪里会出错，只是我在手工回归时才发现这里居然错了！
这句话我没怎么看懂。。。你的意思是一千录制的时候这里本身就不符合需求，是错误的？
如果这样的话，那么你之前的脚本本身就是有BUG的，肯定不能用来回放了撒。

sayusayme

我不知道是不是理解了楼主的意思啊，
我把我所知道的关于QTP的用法大致讲一下了

QTP主要是用于回归测试，也就是说在需求相对稳定，不会经常改动的情况下，且软件也做的差不多了，接近后期了

比如软件有a,b,c,d,e五个模块组成的，
现在如果要发布的时候突然发现e模块有个小BUG，让软件开发人员修改好，测试人员测试了e模块关于这个BUG没有问题了，但是这个BUG会不会影响到其他的a，b，c，d四个模块呢，为了安全起见也得测试一下，然后测试人员手工测试了a，b，c，d四个模块。
若在e模块又发现了bug，修改后，测试人员又需要重新测试其他的模块，如此几次，测试人员会非常疲惫，且测试的质量和效率都会降低。
这样，QTP就有用处了，在软件都正常运行的情况下，你可以事先录制a，b，c，d四个模块，以后只要测试这几个模块，你就可以让QTP自己回放，看看修改e模块是否会影响这四个模块，这样，你就可以减轻手工测试的劳动量了

sayusayme

录制的过程我感觉其实就是一种手工测试的过程，＝＝录制的过程就是一个手工测试的过程，不过前提是心中有谱出错的可能性不很大。
那么如果我在进行录制的过程中发现了BUG，是否意味着我的录制就该结束？＝＝是的，如果有BUG了，就不要录制了，等改正确以后再次录制就好了。
如果意味着结束，那接下来该如何呢？＝＝接下来就等开发人员改好了你再次录制吧
            
（我录制的脚本与我的新版本程序之间的关系的问题。好比之前录制时功能a是可以的，但实际上在新版本中a出了问题，这样的情况下，我回放的还是旧版本的功能A呀！脚本怎么能发现新的问题呢）＝＝＝＝这个很容易啊，比如你在录制前输入同样的数据a是可以的，若因为修改其他的模块输入同样的数据造成a不可以了，这样正好问题就出来了啊，叫开发人员改啊

我其实并不知道哪里会出错，只是我在手工回归时才发现这里居然错了！那么我的录制的脚本有什么用呢？＝＝＝你录制的脚本没有用了，只有等它改好了，再次录制正确的脚本了。
它的回放无法验证我的新版本的一些功能依然OK呀＝＝对，是的，此时的脚本是无法验证新版本的功能的。所以你要等程序改好后重新录制的。