軟件回歸測試及其實(shí)踐----回歸很重要的

軟件回歸測試及其實(shí)踐----回歸很重要的

回歸測試作為軟件生命周期的一個(gè)組成部分，在整個(gè)軟件測試過(guò)程中占有很大的工作量比重，軟件開(kāi)發(fā)的各個(gè)階段都會(huì )進(jìn)行多次回歸測試。在漸進(jìn)和快速迭代開(kāi)發(fā)中，新版本的連續發(fā)布使回歸測試進(jìn)行的更加頻繁，而在極端編程方法中，更是要求每天都進(jìn)行若干次回歸測試。因此，通過(guò)選擇正確的回歸測試策略來(lái)改進(jìn)回歸測試的效率和有效性是非常有意義的。

一、 軟件回歸測試的概述

在軟件生命周期中的任何一個(gè)階段，只要軟件發(fā)生了改變，就可能給該軟件帶來(lái)問(wèn)題。軟件的改變可能是源于發(fā)現了錯誤并做了修改，也有可能是因為在集成或維護階段加入了新的模塊。當軟件中所含錯誤被發(fā)現時(shí)，如果錯誤跟蹤與管理系統不夠完善，就可能會(huì )遺漏對這些錯誤的修改；而開(kāi)發(fā)者對錯誤理解的不夠透徹，也可能導致所做的修改只修正了錯誤的外在表現，而沒(méi)有修復錯誤本身，從而造成修改失??；修改還有可能產(chǎn)生副作用從而導致軟件未被修改的部分產(chǎn)生新的問(wèn)題，使本來(lái)工作正常的功能產(chǎn)生錯誤。同樣，在有新代碼加入軟件的時(shí)候，除了新加入的代碼中有可能含有錯誤外，新代碼還有可能對原有的代碼帶來(lái)影響。因此，每當軟件發(fā)生變化時(shí)，我們就必須重新測試現有的功能，以便確定修改是否達到了預期的目的，檢查修改是否損害了原有的正常功能。同時(shí)，還需要補充新的測試用例來(lái)測試新的或被修改了的功能。為了驗證修改的正確性及其影響就需要進(jìn)行回歸測試。

回歸測試在軟件生命周期中扮演著(zhù)重要的角色，因忽視回歸測試而造成嚴重后果的例子不計其數，導致阿里亞娜5型火箭發(fā)射失敗的軟件缺陷就是由于復用的代碼沒(méi)有經(jīng)過(guò)充分的回歸測試造成的。

回歸測試作為軟件生命周期的一個(gè)組成部分，在整個(gè)軟件測試過(guò)程中占有很大的工作量比重，軟件開(kāi)發(fā)的各個(gè)階段都會(huì )進(jìn)行多次回歸測試。在漸進(jìn)和快速迭代開(kāi)發(fā)中，新版本的連續發(fā)布使回歸測試進(jìn)行的更加頻繁，而在極端編程方法中，更是要求每天都進(jìn)行若干次回歸測試。因此，通過(guò)選擇正確的回歸測試策略來(lái)改進(jìn)回歸測試的效率和有效性是非常有意義的。

二、 回歸測試策略

對于一個(gè)軟件開(kāi)發(fā)項目來(lái)說(shuō)，項目的測試組在實(shí)施測試的過(guò)程中會(huì )將所開(kāi)發(fā)的測試用例保存到“測試用例庫”中，并對其進(jìn)行維護和管理。當得到一個(gè)軟件的基線(xiàn)版本時(shí)，用于基線(xiàn)版本測試的所有測試用例就形成了基線(xiàn)測試用例庫。在需要進(jìn)行回歸測試的時(shí)候，就可以根據所選擇的回歸測試策略，從基線(xiàn)測試用例庫中提取合適的測試用例組成回歸測試包，通過(guò)運行回歸測試包來(lái)實(shí)現回歸測試。保存在基線(xiàn)測試用例庫中的測試用例可能是自動(dòng)測試腳本，也有可能是測試用例的手工實(shí)現過(guò)程。

回歸測試需要時(shí)間、經(jīng)費和人力來(lái)計劃、實(shí)施和管理。為了在給定的預算和進(jìn)度下，盡可能有效率和有效力地進(jìn)行回歸測試，需要對測試用例庫進(jìn)行維護并依據一定的策略選擇相應的回歸測試包。

1、測試用例庫的維護

為了最大限度地滿(mǎn)足客戶(hù)的需要和適應應用的要求，軟件在其生命周期中會(huì )頻繁地被修改和不斷推出新的版本，修改后的或者新版本的軟件會(huì )添加一些新的功能或者在軟件功能上產(chǎn)生某些變化。隨著(zhù)軟件的改變，軟件的功能和應用接口以及軟件的實(shí)現發(fā)生了演變，測試用例庫中的一些測試用例可能會(huì )失去針對性和有效性，而另一些測試用例可能會(huì )變得過(guò)時(shí)，還有一些測試用例將完全不能運行。為了保證測試用例庫中測試用例的有效性，必須對測試用例庫進(jìn)行維護。同時(shí)，被修改的或新增添的軟件功能，僅僅靠重新運行以前的測試用例并不足以揭示其中的問(wèn)題，有必要追加新的測試用例來(lái)測試這些新的功能或特征。因此，測試用例庫的維護工作還應包括開(kāi)發(fā)新測試用例，這些新的測試用例用來(lái)測試軟件的新特征或者覆蓋現有測試用例無(wú)法覆蓋的軟件功能或特征。

測試用例的維護是一個(gè)不間斷的過(guò)程，通?？梢詫④浖_(kāi)發(fā)的基線(xiàn)作為基準，維護的主要內容包括下述幾個(gè)方面。

(1)、刪除過(guò)時(shí)的測試用例

因為需求的改變等原因可能會(huì )使一個(gè)基線(xiàn)測試用例不再適合被測試系統，這些測試用例就會(huì )過(guò)時(shí)。例如，某個(gè)變量的界限發(fā)生了改變，原來(lái)針對邊界值的測試就無(wú)法完成對新邊界測試。所以，在軟件的每次修改后都應進(jìn)行相應的過(guò)時(shí)測試用例的刪除。

(2)、改進(jìn)不受控制的測試用例

隨著(zhù)軟件項目的進(jìn)展，測試用例庫中的用例會(huì )不斷增加，其中會(huì )出現一些對輸入或運行狀態(tài)十分敏感的測試用例。這些測試不容易重復且結果難以控制，會(huì )影響回歸測試的效率，需要進(jìn)行改進(jìn)，使其達到可重復和可控制的要求。

(3)、刪除冗余的測試用例

如果存在兩個(gè)或者更多個(gè)測試用例針對一組相同的輸入和輸出進(jìn)行測試，那么這些測試用例是冗余的。冗余測試用例的存在降低了回歸測試的效率。所以需要定期的整理測試用例庫，并將冗余的用例刪除掉。

(4)、增添新的測試用例

如果某個(gè)程序段、構件或關(guān)鍵的接口在現有的測試中沒(méi)有被測試，那么應該開(kāi)發(fā)新測試用例重新對其進(jìn)行測試。并將新開(kāi)發(fā)的測試用例合并到基線(xiàn)測試包中。

通過(guò)對測試用例庫的維護不僅改善了測試用例的可用性，而且也提高了測試庫的可信性，同時(shí)還可以將一個(gè)基線(xiàn)測試用例庫的效率和效用保持在一個(gè)較高的級別上。

2、回歸測試包的選擇

在軟件生命周期中，即使一個(gè)得到良好維護的測試用例庫也可能變得相當大，這使每次回歸測試都重新運行完整的測試包變得不切實(shí)際。一個(gè)完全的回歸測試包括每個(gè)基線(xiàn)測試用例，時(shí)間和成本約束可能阻礙運行這樣一個(gè)測試，有時(shí)測試組不得不選擇一個(gè)縮減的回歸測試包來(lái)完成回歸測試。

回歸測試的價(jià)值在于它是一個(gè)能夠檢測到回歸錯誤的受控實(shí)驗。當測試組選擇縮減的回歸測試時(shí)，有可能刪除了將揭示回歸錯誤的測試用例，消除了發(fā)現回歸錯誤的機會(huì )。然而，如果采用了代碼相依性分析等安全的縮減技術(shù)，就可以決定哪些測試用例可以被刪除而不會(huì )讓回歸測試的意圖遭到破壞。

選擇回歸測試策略應該兼顧效率和有效性?xún)蓚€(gè)方面。常用的選擇回歸測試的方式包括：

(1)、再測試全部用例

選擇基線(xiàn)測試用例庫中的全部測試用例組成回歸測試包，這是一種比較安全的方法，再測試全部用例具有最低的遺漏回歸錯誤的風(fēng)險，但測試成本最高。全部再測試幾乎可以應用到任何情況下，基本上不需要進(jìn)行分析和重新開(kāi)發(fā)，但是，隨著(zhù)開(kāi)發(fā)工作的進(jìn)展，測試用例不斷增多，重復原先所有的測試將帶來(lái)很大的工作量，往往超出了我們的預算和進(jìn)度。

(2)、基于風(fēng)險選擇測試

可以基于一定的風(fēng)險標準來(lái)從基線(xiàn)測試用例庫中選擇回歸測試包。首先運行最重要的、關(guān)鍵的和可疑的測試，而跳過(guò)那些非關(guān)鍵的、優(yōu)先級別低的或者高穩定的測試用例，這些用例即便可能測試到缺陷，這些缺陷的嚴重性也僅有三級或四級。一般而言，測試從主要特征到次要特征。

(3)、基于操作剖面選擇測試

如果基線(xiàn)測試用例庫的測試用例是基于軟件操作剖面開(kāi)發(fā)的，測試用例的分布情況反映了系統的實(shí)際使用情況?；貧w測試所使用的測試用例個(gè)數可以由測試預算確定，回歸測試可以?xún)?yōu)先選擇那些針對最重要或最頻繁使用功能的測試用例，釋放和緩解最高級別的風(fēng)險，有助于盡早發(fā)現那些對可靠性有最大影響的故障。這種方法可以在一個(gè)給定的預算下最有效的提高系統可靠性，但實(shí)施起來(lái)有一定的難度。

(4)、再測試修改的部分

當測試者對修改的局部化有足夠的信心時(shí)，可以通過(guò)相依性分析識別軟件的修改情況并分析修改的影響，將回歸測試局限于被改變的模塊和它的接口上。通常，一個(gè)回歸錯誤一定涉及一個(gè)新的、修改的或刪除的代碼段。在允許的條件下，回歸測試盡可能覆蓋受到影響的部分。

再測試全部用例的策略是最安全的策略，但已經(jīng)運行過(guò)許多次的回歸測試不太可能揭示新的錯誤，而且很多時(shí)候，由于時(shí)間、人員、設備和經(jīng)費的原因，不允許選擇再測試全部用例的回歸測試策略，此時(shí)，可以選擇適當的策略進(jìn)行縮減的回歸測試。

3、回歸測試的基本過(guò)程

有了測試用例庫的維護方法和回歸測試包的選擇策略，回歸測試可遵循下述基本過(guò)程進(jìn)行:

(1). 識別出軟件中被修改的部分；

(2). 從原基線(xiàn)測試用例庫T中，排除所有不再適用的測試用例，確定那些對新的軟件版本依然有效的測試用例，其結果是建立一個(gè)新的基線(xiàn)測試用例庫T0。

(3). 依據一定的策略從T0中選擇測試用例測試被修改的軟件。

(4). 如果必要，生成新的測試用例集T1，用于測試T0無(wú)法充分測試的軟件部分。

(5). 用T1執行修改后的軟件。

第(2)和第(3)步測試驗證修改是否破壞了現有的功能，第(4)和第(5)步測試驗證 修改工作本身。

三、 回歸測試實(shí)踐

在實(shí)際工作中，回歸測試需要反復進(jìn)行，當測試者一次又一次地完成相同的測試時(shí)，這些回歸測試將變得非常令人厭煩，而在大多數回歸測試需要手工完成的時(shí)候尤其如此，因此，需要通過(guò)自動(dòng)測試來(lái)實(shí)現重復的和一致的回歸測試。通過(guò)測試自動(dòng)化可以提高回歸測試效率。為了支持多種回歸測試策略，自動(dòng)測試工具應該是通用的和靈活的，以便滿(mǎn)足達到不同回歸測試目標的要求。

在測試軟件時(shí)，應用多種測試技術(shù)是常見(jiàn)的。當測試一個(gè)修改了的軟件時(shí)，測試者也可能希望采用多于一種回歸測試策略來(lái)增加對修改軟件的信心。不同的測試者可能會(huì )依據自己的經(jīng)驗和判斷選擇不同的回歸測試技術(shù)和策略。

回歸測試并不減少對系統新功能和特征的測試需求，回歸測試包應包括新功能和特征的測試。如果回歸測試包不能達到所需的覆蓋要求，必須補充新的測試用例使覆蓋率達到規定的要求。

回歸測試是重復性較多的活動(dòng)，容易使測試者感到疲勞和厭倦，降低測試效率，在實(shí)際工作中可以采用一些策略減輕這些問(wèn)題。例如，安排新的測試者完成手工回歸測試，分配更有經(jīng)驗的測試者開(kāi)發(fā)新的測試用例，編寫(xiě)和調試自動(dòng)測試腳本，做一些探索性的或ad hoc測試。還可以在不影響測試目標的情況下，鼓勵測試者創(chuàng )造性地執行測試用例，變化的輸入、按鍵和配置能夠有助于激勵測試者又能揭示新的錯誤。

在組織回歸測試時(shí)需要注意兩點(diǎn)，首先是各測試階段發(fā)生的修改一定要在本測試階段內完成回歸，以免將錯誤遺留到下一測試階段。其次，回歸測試期間應對該軟件版本凍結，將回歸測試發(fā)現的問(wèn)題集中修改，集中回歸。

在實(shí)際工作中，可以將回歸測試與兼容性測試結合起來(lái)進(jìn)行。在新的配置條件下運行舊的測試可以發(fā)現兼容性問(wèn)題，而同時(shí)也可以揭示編碼在回歸方面的錯誤。

原文轉自：http://kjueaiud.com