最近有不少朋友在論壇里問到"QTP如何做回歸測試?"的問題,這里我們有必要來探討一下.首先這個問題中存在一個誤區,事實上回歸測試怎么做,跟自動化工具沒有必然的聯系.所以這里的如何做回歸測試并不是一個QTP的問題,而是一個回歸測試的策略的問題.
我們先來了解一下回歸測試的概念和策略以及一般大致會采用的流程.
那么什么是回歸測試呢?簡單的說,回歸測試是貫穿在整個測試的各個階段的一個測試活動.它的目的是檢驗已經被發現的缺陷有沒有被正確的修改和修改過程中有沒有引發新的缺陷.軟件在測試或者其他活動中發現的缺陷經過修改后,都要進行回歸測試的驗證.
我們在做回歸測試的時候可以采用不同的策略.
策略(1) 可以選擇完全重復測試.把所有的測試用例,全部再完全的執行一邊,以確認問題修改的正確性和修改后周邊是否受到影響.缺點是由于要把用例全部執行,所以會增加項目成本,也會影響項目進度.所以很難來完全執行,所以引出了回歸測試策略(2) 選擇性重復測試.
策略(2) 可以選擇性重復測試.可以選擇一部分進行執行,以確認問題修改的正確性和修改后周邊是否受到影響.那么我們怎樣去選擇用例呢?這里有三個方法:1.覆蓋修改法 針對發生錯誤的模塊,選取這個模塊的全部用例進行測試.這樣只能驗證本模塊是否還存在缺陷,但不能保證周邊與它有聯系的模塊不會因為這次改動而引發缺陷.所以引出第2個方法,即2.周邊影響法.除了把出錯模塊的用例執行之外,把周邊和它有聯系的模塊的用例也執行一邊,保證回歸測試的質量.當然我們還可以用量化的角度去分析模塊的質量,比如:經過上面的一系列回歸測試后,看看遺留的缺陷率是否已經在允許的范圍之內了,那么我們以此為標準可以結束本次回歸測試.也就是我要提到的第三個方法。常笜诉_成法.
回歸測試的流程
1.在測試策略制定階段,制定回歸測試策略
2.確定回歸測試版本
3.回歸測試版本發布,按照回歸測試策略執行回歸測試
4.回歸測試通過,關閉缺陷跟蹤單
5.回歸測試不通過,缺陷單返回開發人員.等重新修改,再次做回歸測試.
那么我們為什么會把工具和回歸測試聯系起來呢?原因是在回歸測試中我們會去做大量的重復的執行測試用例的操作.為了讓測試員能夠從這種重復的工作中解放出來,去測試更多新的用例,我們所以可以選用一些自動化測試工具,來錄制腳本,代替一部分手工操作.但事實上并不是這些工具只能用在回歸測試中,在其他操作上也可以應用.但有一點是工具不能完全代替手工測試,它只是手工測試的一種補助.所以QTP作為一款功能測試工具,可以運用到回歸測試中.
文章來源于領測軟件測試網 http://www.kjueaiud.com/