回歸測試中的項目質(zhì)量管理應(yīng)用
李東東
1) 回歸測試介紹

在軟件生命周期中的任何一個階段，只要軟件發(fā)生了改變，就可能對該軟件帶來問題。軟件的改變可能是源于發(fā)現(xiàn)了錯誤并做了修改，也有可能是因為在集成或維護(hù)階段加入了新的模塊。在增量型軟件開發(fā)過程中，通常將軟件分成階段進(jìn)行開發(fā)，在一個階段的軟件開發(fā)結(jié)束后將被測軟件交給測試組進(jìn)行測試，而下一個階段增加的軟件又有可能對原來的系統(tǒng)造成破壞。因此，每當(dāng)軟件發(fā)生變化時，我們就必須重新測試原有的功能，以便確定修改是否達(dá)到了預(yù)期的目的，檢查修改是否損害了原有的正常功能。

回歸測試是為了確保對系統(tǒng)進(jìn)行的更改沒有影響到舊系統(tǒng)的正常運(yùn)行。測試用例一般由兩部分組成，一部分是自動測試用例，一部分是手工測試用例。

2) 項目質(zhì)量計劃編制
在測試計劃階段根據(jù)被測系統(tǒng)的特點(diǎn)確定測試用例的集合，由于被測試系統(tǒng)的軟件分幾個階段進(jìn)行Release，需要對系統(tǒng)進(jìn)行分階段測試。在測試計劃階段選定一部分測試用例作為重要的測試用例（Must Have），需要在幾個階段重復(fù)進(jìn)行測試，而另一部分測試用例在整個測試的開始階段和結(jié)束階段要求完全覆蓋，在中間階段根據(jù)被測系統(tǒng)的特性分別選定。而由于自動測試用例一般不需要測試人員的參與，所以可以根據(jù)情況選擇在各個階段全部測試或類似于手工測試用例進(jìn)行部分測試。

由于測試是分階段進(jìn)行的，需要記錄分階段計劃及每一階段需要對被測系統(tǒng)執(zhí)行的測試用例。

確定測試通過的標(biāo)準(zhǔn)，測試意外的處理過程。對于每個分階段的測試又分成測試運(yùn)行階段（ATR）和測試通過階段（ATP）兩個子階段，確定每個子階段測試通過的標(biāo)準(zhǔn)。

3） 質(zhì)量保證
當(dāng)新階段開始的時候，要審查被測系統(tǒng)是否符合測試條件。對達(dá)到標(biāo)準(zhǔn)的被測系統(tǒng)使用計劃中確定的測試用例進(jìn)行測試。比較實際測試結(jié)果同計劃測試結(jié)果的一致性，記錄測試結(jié)果
測試用例的正確性確認(rèn)，分析測試發(fā)現(xiàn)錯誤是否是有效錯誤，提交相應(yīng)的更改錯誤請求（SR），并記錄錯誤原因。

由于系統(tǒng)在不斷的升級，所以系統(tǒng)的需求也在不斷的更新，有些新的需求影響到了以前的測試用例，當(dāng)測試時發(fā)現(xiàn)測試用例同原來需求的結(jié)果不一致的地方，需要和需求進(jìn)行確認(rèn)，如果是被測系統(tǒng)的錯誤提交相應(yīng)的錯誤報告，如果是測試用例的錯誤需要對相應(yīng)的測試用例進(jìn)行更新。

4） 質(zhì)量控制
在測試計劃階段就確定好測試各個分階段需要執(zhí)行的測試用例，從而在實際執(zhí)行測試的階段可以依照選定的測試用例對被測系統(tǒng)進(jìn)行測試。測試結(jié)束只好對測試結(jié)果進(jìn)行分析。由于實際執(zhí)行時被測系統(tǒng)同計劃階段的需求可能會有不一致的情況，對于在執(zhí)行階段執(zhí)行的測試用例同計劃階段要求執(zhí)行的測試用例不一致的地方要進(jìn)行分析和記錄原因，并由相關(guān)負(fù)責(zé)人進(jìn)行確認(rèn)。
對于實際執(zhí)行測試中沒有通過的測試用例的原因進(jìn)行分析，確定原因分布。

5） 測試完成標(biāo)志
當(dāng)回歸測試階段結(jié)束時，測試經(jīng)理要提交各個階段的測試用例分布，測試結(jié)果，測試發(fā)現(xiàn)的錯誤點(diǎn)，發(fā)現(xiàn)的錯誤是否確認(rèn)原因以及發(fā)現(xiàn)的錯誤是否已經(jīng)解決。
測試計劃中確定的測試用例分布和實際測試用例分布對應(yīng)表及意外原因。
對于本階段的測試進(jìn)行經(jīng)驗總結(jié)，以為下一階段的測試作為指導(dǎo)。

【?發(fā)表評論?0條?】