一、 概述
5 u/ `8 m) J) O' h( G4 n1 U
' a# T& X* X1 {4 E; r在軟件生命周期中的任何一個階段，只要軟件發(fā)生了改變，就可能給該軟件帶來問題。軟件的改變可能是源于發(fā)現(xiàn)了錯誤并做了修改，也有可能是因為在集成或維護(hù)階段加入了新的模塊。當(dāng)軟件中所含錯誤被發(fā)現(xiàn)時，如果錯誤跟蹤與管理系統(tǒng)不夠完善，就可能會遺漏對這些錯誤的修改；而開發(fā)者對錯誤理解的不夠透徹，也可能導(dǎo)致所做的修改只修正了錯誤的外在表現(xiàn)，而沒有修復(fù)錯誤本身，從而造成修改失敗；修改還有可能產(chǎn)生副作用從而導(dǎo)致軟件未被修改的部分產(chǎn)生新的問題，使本來工作正常的功能產(chǎn)生錯誤。同樣，在有新代碼加入軟件的時候，除了新加入的代碼中有可能含有錯誤外，新代碼還有可能對原有的代碼帶來影響。因此，每當(dāng)軟件發(fā)生變化時，我們就必須重新測試現(xiàn)有的功能，以便確定修改是否達(dá)到了預(yù)期的目的，檢查修改是否損害了原有的正常功能。同時，還需要補(bǔ)充新的測試用例來測試新的或被修改了的功能。為了驗證修改的正確性及其影響就需要進(jìn)行回歸測試。 ; ]$ v6 C$ |/ T8 F" E& ~
( J) d# J. j9 i0 r
回歸測試在軟件生命周期中扮演著重要的角色，因忽視回歸測試而造成嚴(yán)重后果的例子不計其數(shù)，導(dǎo)致阿里亞娜5型火箭發(fā)射失敗的軟件缺陷就是由于復(fù)用的代碼沒有經(jīng)過充分的回歸測試造成的。
; f1 v0 t& R9 B) c  n7 n- a. C# F$ K1 S1 a, B
回歸測試作為軟件生命周期的一個組成部分，在整個軟件測試過程中占有很大的工作量比重，軟件開發(fā)的各個階段都會進(jìn)行多次回歸測試。在漸進(jìn)和快速迭代開發(fā)中，新版本的連續(xù)發(fā)布使回歸測試進(jìn)行的更加頻繁，而在極端編程方法中，更是要求每天都進(jìn)行若干次回歸測試。因此，通過選擇正確的回歸測試策略來改進(jìn)回歸測試的效率和有效性是非常有意義的。 ! {1 ~, G* e2 d) {5 x% m. i# Z

2 ]2 w% p' X' Y5 m6 N& O二、 回歸測試策略 9 s4 H" E( @$ X
. v; P2 n: m: P/ N' a* _; {! Y
對于一個軟件開發(fā)項目來說，項目的測試組在實施測試的過程中會將所開發(fā)的測試用例保存到“測試用例庫”中，并對其進(jìn)行維護(hù)和管理。當(dāng)?shù)玫揭粋�軟件的基線版本時，用于基線版本測試的所有測試用例就形成了基線測試用例庫。在需要進(jìn)行回歸測試的時候，就可以根據(jù)所選擇的回歸測試策略，從基線測試用例庫中提取合適的測試用例組成回歸測試包，通過運行回歸測試包來實現(xiàn)回歸測試。保存在基線測試用例庫中的測試用例可能是自動測試腳本，也有可能是測試用例的手工實現(xiàn)過程。 2 }) v+ D. O$ o# V0 V( Y7 a

% k" B7 j3 d, \, Q( I7 X" q回歸測試需要時間、經(jīng)費和人力來計劃、實施和管理。為了在給定的預(yù)算和進(jìn)度下，盡可能有效率和有效力地進(jìn)行回歸測試，需要對測試用例庫進(jìn)行維護(hù)并依據(jù)一定的策略選擇相應(yīng)的回歸測試包。 % [7 D4 E6 Q: Y# t& a

. u1 H; s9 A$ {$ x. Z4 D1 \1、測試用例庫的維護(hù) " X5 b4 y* O& R% W
( [% D) V8 `( e% i
為了最大限度地滿足客戶的需要和適應(yīng)應(yīng)用的要求，軟件在其生命周期中會頻繁地被修改和不斷推出新的版本，修改后的或者新版本的軟件會添加一些新的功能或者在軟件功能上產(chǎn)生某些變化。隨著軟件的改變，軟件的功能和應(yīng)用接口以及軟件的實現(xiàn)發(fā)生了演變，測試用例庫中的一些測試用例可能會失去針對性和有效性，而另一些測試用例可能會變得過時，還有一些測試用例將完全不能運行。為了保證測試用例庫中測試用例的有效性，必須對測試用例庫進(jìn)行維護(hù)。同時，被修改的或新增添的軟件功能，僅僅靠重新運行以前的測試用例并不足以揭示其中的問題，有必要追加新的測試用例來測試這些新的功能或特征。因此，測試用例庫的維護(hù)工作還應(yīng)包括開發(fā)新測試用例，這些新的測試用例用來測試軟件的新特征或者覆蓋現(xiàn)有測試用例無法覆蓋的軟件功能或特征。 ' {2 ~! n! W0 e" n5 @$ q/ S; B- N

3 c" U2 G5 W' V! L6 V% e! b測試用例的維護(hù)是一個不間斷的過程，通�？梢詫④浖�開發(fā)的基線作為基準(zhǔn)，維護(hù)的主要內(nèi)容包括下述幾個方面。 / J* Y; h+ C# k! h, X; B
) d/ S8 N+ A0 \4 `6 u
(1)、刪除過時的測試用例
& p5 n$ c! C. @/ g+ W% E
) n8 a+ _/ ~+ W; ~* E. n6 Q) d- [: ~因為需求的改變等原因可能會使一個基線測試用例不再適合被測試系統(tǒng)，這些測試用例就會過時。例如，某個變量的界限發(fā)生了改變，原來針對邊界值的測試就無法完成對新邊界測試。所以，在軟件的每次修改后都應(yīng)進(jìn)行相應(yīng)的過時測試用例的刪除。
8 |5 z& n3 T" b0 E* E! S7 I' ~1 k5 S& Q+ H" i% ^) H
(2)、改進(jìn)不受控制的測試用例 / N! y* }& k+ y" T" Z

# O, j; u! p1 m隨著軟件項目的進(jìn)展，測試用例庫中的用例會不斷增加，其中會出現(xiàn)一些對輸入或運行狀態(tài)十分敏感的測試用例。這些測試不容易重復(fù)且結(jié)果難以控制，會影響回歸測試的效率，需要進(jìn)行改進(jìn)，使其達(dá)到可重復(fù)和可控制的要求。
2 s, m* R8 J1 }& m, }) ]9 P$ D* Z& i) g9 v- j
(3)、刪除冗余的測試用例
7 F8 E9 n3 R! w+ e  R+ b8 ?0 _) y, {% {/ Q
如果存在兩個或者更多個測試用例針對一組相同的輸入和輸出進(jìn)行測試，那么這些測試用例是冗余的。冗余測試用例的存在降低了回歸測試的效率。所以需要定期的整理測試用例庫，并將冗余的用例刪除掉。
. @0 J+ W8 v2 \* i. Y3 x1 j6 Q/ F9 `8 c) F! \
(4)、增添新的測試用例
! h0 e; |. Y5 S; D- {( P% t3 `& O$ F5 O) K
如果某個程序段、構(gòu)件或關(guān)鍵的接口在現(xiàn)有的測試中沒有被測試，那么應(yīng)該開發(fā)新測試用例重新對其進(jìn)行測試。并將新開發(fā)的測試用例合并到基線測試包中。 : m: J9 e9 X' V1 q3 D0 K8 S
4 L2 T' T) k5 f0 h
通過對測試用例庫的維護(hù)不僅改善了測試用例的可用性，而且也提高了測試庫的可信性，同時還可以將一個基線測試用例庫的效率和效用保持在一個較高的級別上。
! p* ]; @. E. C# p) P( u# C( ~" X, W0 e1 z! b
2、回歸測試包的選擇 ! F" r: ?4 e1 W8 I

# d9 B& \) R! x  c! F1 V在軟件生命周期中，即使一個得到良好維護(hù)的測試用例庫也可能變得相當(dāng)大，這使每次回歸測試都重新運行完整的測試包變得不切實際。一個完全的回歸測試包括每個基線測試用例，時間和成本約束可能阻礙運行這樣一個測試，有時測試組不得不選擇一個縮減的回歸測試包來完成回歸測試。 . N, K6 ~9 o7 C6 ?

5 b" i9 k* S. t) }" N& L回歸測試的價值在于它是一個能夠檢測到回歸錯誤的受控實驗。當(dāng)測試組選擇縮減的回歸測試時，有可能刪除了將揭示回歸錯誤的測試用例，消除了發(fā)現(xiàn)回歸錯誤的機(jī)會。然而，如果采用了代碼相依性分析等安全的縮減技術(shù)，就可以決定哪些測試用例可以被刪除而不會讓回歸測試的意圖遭到破壞。
& M# l) r( @: b' r; `5 p) ^& K9 x( ?" ~$ a, Q
選擇回歸測試策略應(yīng)該兼顧效率和有效性兩個方面。常用的選擇回歸測試的方式包括： 2 |& d6 D0 t& s) _" V
; P; f; a& u9 F  m# k2 V% z
(1)、再測試全部用例
+ Q# e) @" |, C
" P) `8 h2 \2 A2 F( H  l選擇基線測試用例庫中的全部測試用例組成回歸測試包，這是一種比較安全的方法，再測試全部用例具有最低的遺漏回歸錯誤的風(fēng)險，但測試成本最高。全部再測試幾乎可以應(yīng)用到任何情況下，基本上不需要進(jìn)行分析和重新開發(fā)，但是，隨著開發(fā)工作的進(jìn)展，測試用例不斷增多，重復(fù)原先所有的測試將帶來很大的工作量，往往超出了我們的預(yù)算和進(jìn)度。 , M  m  {5 _. ^& J2 x
, [# U2 l2 y9 X- E  u3 C# O! A
(2)、基于風(fēng)險選擇測試 ! A1 [4 l* i7 D8 v. l% y

: {3 ?+ z% F) r: W) H6 F可以基于一定的風(fēng)險標(biāo)準(zhǔn)來從基線測試用例庫中選擇回歸測試包。首先運行最重要的、關(guān)鍵的和可疑的測試，而跳過那些非關(guān)鍵的、優(yōu)先級別低的或者高穩(wěn)定的測試用例，這些用例即便可能測試到缺陷，這些缺陷的嚴(yán)重性也僅有三級或四級。一般而言，測試從主要特征到次要特征。
) N% e- z, G# c5 ^0 I! }
& L3 b) F( R3 n- z6 j4 y(3)、基于操作剖面選擇測試 ! j$ c0 W% T" V( f

. e1 B0 @5 z+ U5 V' _# X/ g如果基線測試用例庫的測試用例是基于軟件操作剖面開發(fā)的，測試用例的分布情況反映了系統(tǒng)的實際使用情況�；貧w測試所使用的測試用例個數(shù)可以由測試預(yù)算確定，回歸測試可以優(yōu)先選擇那些針對最重要或最頻繁使用功能的測試用例，釋放和緩解最高級別的風(fēng)險，有助于盡早發(fā)現(xiàn)那些對可靠性有最大影響的故障。這種方法可以在一個給定的預(yù)算下最有效的提高系統(tǒng)可靠性，但實施起來有一定的難度。 * {" t3 Q! y( @7 z  ?9 [! n1 }& o
7 V! A$ \4 M% I( f% W* w2 A' g4 E1 K. U
(4)、再測試修改的部分
) _/ ^9 z3 G7 S8 N* E% q/ _8 h* k* k$ t% R' m) y
當(dāng)測試者對修改的局部化有足夠的信心時，可以通過相依性分析識別軟件的修改情況并分析修改的影響，將回歸測試局限于被改變的模塊和它的接口上。通常，一個回歸錯誤一定涉及一個新的、修改的或刪除的代碼段。在允許的條件下，回歸測試盡可能覆蓋受到影響的部分。 ( I+ J, a6 X8 o
+ i% r, P& x. }
再測試全部用例的策略是最安全的策略，但已經(jīng)運行過許多次的回歸測試不太可能揭示新的錯誤，而且很多時候，由于時間、人員、設(shè)備和經(jīng)費的原因，不允許選擇再測試全部用例的回歸測試策略，此時，可以選擇適當(dāng)?shù)牟呗赃M(jìn)行縮減的回歸測試。
' s' o6 W& ^- Z0 k" F
% e& n9 K9 s% G3、回歸測試的基本過程 8 X+ b" x! E" Y. `( E1 t
7 S5 p% q; o- J+ _
有了測試用例庫的維護(hù)方法和回歸測試包的選擇策略，回歸測試可遵循下述基本過程進(jìn)行:
2 W0 N8 T3 H5 \9 O1 @) b3 U, x; G7 m" g3 c' w! W% e% g
(1). 識別出軟件中被修改的部分；
# j: l2 T6 ^: T, X2 o( f/ X' w2 E6 Q* L1 f# ^
(2). 從原基線測試用例庫T中，排除所有不再適用的測試用例，確定那些對新的軟件版本依然有效的測試用例，其結(jié)果是建立一個新的基線測試用例庫T0。
4 Z2 A0 C. t9 x' G! \+ u
# `4 x& @, f8 `' K8 V(3). 依據(jù)一定的策略從T0中選擇測試用例測試被修改的軟件。 ' r6 Q/ |' O6 g& O
5 C# N5 b; Y! D+ I
(4). 如果必要，生成新的測試用例集T1，用于測試T0無法充分測試的軟件部分。 7 _- N: x1 P: h2 J5 Y
/ a6 M3 Q" F; H5 a
(5). 用T1執(zhí)行修改后的軟件。
9 i( |: `* ]) z& C( F4 W& Z; Z
/ ?6 V8 }" ?, n3 }8 e第(2)和第(3)步測試驗證修改是否破壞了現(xiàn)有的功能，第(4)和第(5)步測試驗證 修改工作本身。
" P1 d7 ^  r7 [  u! i: o
7 e/ Q5 L* [4 @! U4 H. l7 V3 P2 w) T三、 回歸測試實踐 $ ^2 y1 h  {% c6 q0 M- a
' D4 I1 B# ~* R' n" P0 I7 V$ T+ z
在實際工作中，回歸測試需要反復(fù)進(jìn)行，當(dāng)測試者一次又一次地完成相同的測試時，這些回歸測試將變得非常令人厭煩，而在大多數(shù)回歸測試需要手工完成的時候尤其如此，因此，需要通過自動測試來實現(xiàn)重復(fù)的和一致的回歸測試。通過測試自動化可以提高回歸測試效率。為了支持多種回歸測試策略，自動測試工具應(yīng)該是通用的和靈活的，以便滿足達(dá)到不同回歸測試目標(biāo)的要求。
) ~4 E3 [) b( P+ p1 _  Q. U
' W0 f! V$ H3 ]! b9 Y在測試軟件時，應(yīng)用多種測試技術(shù)是常見的。當(dāng)測試一個修改了的軟件時，測試者也可能希望采用多于一種回歸測試策略來增加對修改軟件的信心。不同的測試者可能會依據(jù)自己的經(jīng)驗和判斷選擇不同的回歸測試技術(shù)和策略。 0 N! k# A. M& m- q( {( M3 f
1 f5 h, C3 Q6 r" I" X) x$ Q# ~# o
回歸測試并不減少對系統(tǒng)新功能和特征的測試需求，回歸測試包應(yīng)包括新功能和特征的測試。如果回歸測試包不能達(dá)到所需的覆蓋要求，必須補(bǔ)充新的測試用例使覆蓋率達(dá)到規(guī)定的要求。 6 M7 ^6 Y4 F2 B/ ~4 j) U, G

- X8 l; E* n4 h, z回歸測試是重復(fù)性較多的活動，容易使測試者感到疲勞和厭倦，降低測試效率，在實際工作中可以采用一些策略減輕這些問題。例如，安排新的測試者完成手工回歸測試，分配更有經(jīng)驗的測試者開發(fā)新的測試用例，編寫和調(diào)試自動測試腳本，做一些探索性的或ad hoc測試。還可以在不影響測試目標(biāo)的情況下，鼓勵測試者創(chuàng)造性地執(zhí)行測試用例，變化的輸入、按鍵和配置能夠有助于激勵測試者又能揭示新的錯誤。 9 S2 _* Y+ h, H4 L$ j- S' {9 F/ k
+ z, B! @9 ^6 e
在組織回歸測試時需要注意兩點，首先是各測試階段發(fā)生的修改一定要在本測試階段內(nèi)完成回歸，以免將錯誤遺留到下一測試階段。其次，回歸測試期間應(yīng)對該軟件版本凍結(jié)，將回歸測試發(fā)現(xiàn)的問題集中修改，集中回歸。
* C. O6 o9 ^! D' Y" I( W  m6 J% j. {, Z8 X
在實際工作中，可以將回歸測試與兼容性測試結(jié)合起來進(jìn)行。在新的配置條件下運行舊的測試可以發(fā)現(xiàn)兼容性問題，而同時也可以揭示編碼在回歸方面的錯誤。
, i' i# _) j: N" i( C' s1 H6 V/ ~- u' u$ X5 z/ R' y