最近有不少朋友在论坛里问到"QTP如何做回归测试?"的问题,这里我们有必要来探讨一下.首先这个问题中存在一个误区,事实上回归测试怎么做,跟自动化工具没有必然的联系.所以这里的如何做回归测试并不是一个QTP的问题,而是一个回归测试的策略的问题.

     我们先来了解一下回归测试的概念和策略以及一般大致会采用的流程.

     那么什么是回归测试呢?简单的说,回归测试是贯穿在整个测试的各个阶段的一个测试活动.它的目的是检验已经被发现的缺陷有没有被正确的修改和修改过程中有没有引发新的缺陷.软件在测试或者其他活动中发现的缺陷经过修改后,都要进行回归测试的验证.

    我们在做回归测试的时候可以采用不同的策略.

策略(1) 可以选择完全重复测试.把所有的测试用例,全部再完全的执行一边,以确认问题修改的正确性和修改后周边是否受到影响.缺点是由于要把用例全部执行,所以会增加项目成本,也会影响项目进度.所以很难来完全执行,所以引出了回归测试策略(2) 选择性重复测试.

策略(2) 可以选择性重复测试.可以选择一部分进行执行,以确认问题修改的正确性和修改后周边是否受到影响.那么我们怎样去选择用例呢？这里有三个方法：１．覆盖修改法　针对发生错误的模块，选取这个模块的全部用例进行测试．这样只能验证本模块是否还存在缺陷，但不能保证周边与它有联系的模块不会因为这次改动而引发缺陷．所以引出第２个方法，即２．周边影响法．除了把出错模块的用例执行之外，把周边和它有联系的模块的用例也执行一边，保证回归测试的质量．当然我们还可以用量化的角度去分析模块的质量，比如：经过上面的一系列回归测试后，看看遗留的缺陷率是否已经在允许的范围之内了，那么我们以此为标准可以结束本次回归测试．也就是我要提到的第三个方法　３．指标达成法．

　　　回归测试的流程

１．在测试策略制定阶段，制定回归测试策略

２．确定回归测试版本

３．回归测试版本发布，按照回归测试策略执行回归测试

４．回归测试通过，关闭缺陷跟踪单

５．回归测试不通过，缺陷单返回开发人员．等重新修改，再次做回归测试．

    那么我们为什么会把工具和回归测试联系起来呢?原因是在回归测试中我们会去做大量的重复的执行测试用例的操作.为了让测试员能够从这种重复的工作中解放出来,去测试更多新的用例,我们所以可以选用一些自动化测试工具,来录制脚本,代替一部分手工操作.但事实上并不是这些工具只能用在回归测试中,在其他操作上也可以应用.但有一点是工具不能完全代替手工测试,它只是手工测试的一种补助.所以QTP作为一款功能测试工具,可以运用到回归测试中.

此文来源于51testing博客，转载请注明出处
原始链接：http://blog.51testing.com/?26649/action_viewspace_itemid_4603.html