迴歸測試中的專案質量管理應用(轉)

ger8發表於2007-08-11
迴歸測試中的專案質量管理應用
李東東
1) 迴歸測試介紹

在軟體生命週期中的任何一個階段,只要軟體發生了改變,就可能對該軟體帶來問題。軟體的改變可能是源於發現了錯誤並做了修改,也有可能是因為在整合或維護階段加入了新的模組。在增量型軟體開發過程中,通常將軟體分成階段進行開發,在一個階段的軟體開發結束後將被測軟體交給測試組進行測試,而下一個階段增加的軟體又有可能對原來的系統造成破壞。因此,每當軟體發生變化時,我們就必須重新測試原有的功能,以便確定修改是否達到了預期的目的,檢查修改是否損害了原有的正常功能。

迴歸測試是為了確保對系統進行的更改沒有影響到舊系統的正常執行。測試用例一般由兩部分組成,一部分是自動測試用例,一部分是手工測試用例。

2) 專案質量計劃編制
在測試計劃階段根據被測系統的特點確定測試用例的集合,由於被測試系統的軟體分幾個階段進行Release,需要對系統進行分階段測試。在測試計劃階段選定一部分測試用例作為重要的測試用例(Must Have),需要在幾個階段重複進行測試,而另一部分測試用例在整個測試的開始階段和結束階段要求完全覆蓋,在中間階段根據被測系統的特性分別選定。而由於自動測試用例一般不需要測試人員的參與,所以可以根據情況選擇在各個階段全部測試或類似於手工測試用例進行部分測試。

由於測試是分階段進行的,需要記錄分階段計劃及每一階段需要對被測系統執行的測試用例。

確定測試透過的標準,測試意外的處理過程。對於每個分階段的測試又分成測試執行階段(ATR)和測試透過階段(ATP)兩個子階段,確定每個子階段測試透過的標準。

3) 質量保證
當新階段開始的時候,要審查被測系統是否符合測試條件。對達到標準的被測系統使用計劃中確定的測試用例進行測試。比較實際測試結果同計劃測試結果的一致性,記錄測試結果
測試用例的正確性確認,分析測試發現錯誤是否是有效錯誤,提交相應的更改錯誤請求(SR),並記錄錯誤原因。

由於系統在不斷的升級,所以系統的需求也在不斷的更新,有些新的需求影響到了以前的測試用例,當測試時發現測試用例同原來需求的結果不一致的地方,需要和需求進行確認,如果是被測系統的錯誤提交相應的錯誤報告,如果是測試用例的錯誤需要對相應的測試用例進行更新。

4) 質量控制
在測試計劃階段就確定好測試各個分階段需要執行的測試用例,從而在實際執行測試的階段可以依照選定的測試用例對被測系統進行測試。測試結束只好對測試結果進行分析。由於實際執行時被測系統同計劃階段的需求可能會有不一致的情況,對於在執行階段執行的測試用例同計劃階段要求執行的測試用例不一致的地方要進行分析和記錄原因,並由相關負責人進行確認。
對於實際執行測試中沒有透過的測試用例的原因進行分析,確定原因分佈。

5) 測試完成標誌
當迴歸測試階段結束時,測試經理要提交各個階段的測試用例分佈,測試結果,測試發現的錯誤點,發現的錯誤是否確認原因以及發現的錯誤是否已經解決。
測試計劃中確定的測試用例分佈和實際測試用例分佈對應表及意外原因。
對於本階段的測試進行經驗總結,以為下一階段的測試作為指導。

[@more@]

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-946114/,如需轉載,請註明出處,否則將追究法律責任。

相關文章