１ 回歸測試背景
首先由于軟件總在時刻變化著，軟件的不斷演化，例如軟件的開發、維護、升級都需要修改一些軟件的結構和代碼，而人類對軟件的要求也從未停止過。軟件的每次改變都會引入潛在的風險，這是軟件演化的缺陷。其次，人類對軟件變化有了一些新的要求，關心軟件修改后的功能是否達到預期以及原有的功能是否被損害［１－３］。
針對以上要求，選擇使用回歸測試來解決。回歸測試是一種驗證已變更系統的完整性與正確性的測試技術。
２ 回歸測試的定義及意義
回歸測試是對之前已測試過、經過修改的程序進行重新測試，以保證該修改沒有引入新的錯誤或者由于更改而發現之前沒有發現的錯誤。
回歸測試的意義是：（１） 保證軟件維護時未更改的代碼功能不會受到影響。（２） 保證軟件模塊區域和持續維護過程與回歸測試的協作關系，使得回歸測試成為一個每月、每周、每日的常規活動。（３） 實現軟件整個生命周期的測試。
３ 回歸測試
首先簡單介紹傳統的基于代碼的回歸測試選擇方法的作用，以便了解軟件架構回歸測試選擇方法的基礎。關注于選擇性的回歸測試方法，然后再重新采用相同的邏輯步驟來提出一種基于軟件架構的回歸測試方法（在第四部分提出）。
回歸測試的目的在于驗證修改的軟件并確定不會在先前測試的代碼中出現新的錯誤。傳統的方法是把它分解為兩個階段。（１） 測試軟件Ｐ相對于一種指定的測試集Ｔ。（２） 當推行了一種新版本Ｐ′時，對已修改的版本Ｐ′的回歸測試提出Ｐ′相對于測試組Ｔ′是正確的可靠性。
在最簡單的回歸測試方法中，有一種叫做復制所有的測試。Ｔ′中包含Ｔ中的所有在Ｔ中的測試用例，并且Ｐ′ 運行在Ｔ′上。在回歸測試選擇方法上，Ｔ′被選出作為一種跟Ｔ相關的子集，假設有ｔ∈Ｔ，ｔ包含于Ｔ′，如果它有可能在Ｐ′中生成的結果與在Ｐ中不同。對不同回歸測試選擇方法的實證研究和分析在文獻［４］中提出，加上對不同行為的識別需求。
本文著重研究如何為Ｐ′選擇一種相關的測試用例子集，又叫做回歸測試選擇問題，描述一種回歸測試選擇方法，它是在軟件架構層面上而不是在代碼層面上。換句話說，用選擇架構化的層面測試用例代替選擇代碼層面的測試用例。
４ 基于軟件架構的回歸測試
基于軟件架構的回歸測試包含以下兩個階段：（１） 基于軟件架構的測試。特別地，應用一種基于軟件架構的一致性測試方法。（２） 基于軟件架構的回歸測試選擇。這個階段被分解以滿足目的１和目的２。
圖１總結了基于軟件架構一致性和回歸測試所需要的行為。本文主要研究基于軟件架構的回歸測試。
４．１ 基于軟件架構的一致性測試
這項工作是基于軟件架構一致性測試的一般框架的，目的是測試已給出的軟件架構實施的一致性。
這個框架分為5個步驟，如圖１中間的部分所示。
第０步：它開始于軟件架構規范的拓撲學和行為學，這里的行為通過一種基于機器的形式體系狀態來模仿。下面，利用標簽的過渡（ＬＴＳ）來模仿組件的行為。
第１步：提出了一個通過觀測得到的方法為了實現一種測試標準，這種標準來源于與測試目的相關視角在軟件架構中，而是把無關的行為從這個視角中隱藏起來。標簽的過渡（ＬＴＳ）模型被提取出來，就產生了一種抽象標簽的過渡（ＡＬＴＳ），用來說明只有這樣高層的行為／組件是需要測試的。
第２步：一種基于架構層面的測試用例（ＡＴＣ）以架構事件的有序序列被定義了，這種事件是當一個確定的初始事件執行的時候期望發生的架構事件。此定義分解為兩個關鍵詞：行為序列，它代表了所期望的行為和初始事件，它是允許發生的結構化輸入。獲得一個ＡＴＣｓ充分集合需要得到一個合適的包含了ＡＬＴＳ完整路徑的集合［５］。
第３步：自然地，這樣的ＡＴＣｓ與可執行的代碼層面測試用例截然不同，因為在軟件架構和代碼之間的差距。處理這個問題通過一種“繪圖”方法，它能夠將軟件層面函數的測試轉化為代碼層面測試用例。
第４步：最后，代碼運行在可識別的測試用例上。通過分析執行的蹤跡來決定系統在所選擇的結構測試中實施得是否正確，采用結構化的模型作為一種測試數據庫來識別代碼用例成功或失敗。
這樣的方法已經得到公認，但是重復的測試行為對于系統的發展而言無疑花銷太大了，因此需要以更少花銷開發一種基于軟件架構的測試方法。本文提出一種方法來處理系統的發展，重復使用原始的測試結果來重新測試已修改的結構并以更少的花銷來完成。
４．２ 目的１：測試對于初始軟件架構Ｐ′的一致性
讓假設基于軟件架構一致性的測試已經提出Ｐ符合已給出的軟件架構的一致性。當Ｐ進化到Ｐ′之后，如何來測試Ｐ′對于相同架構的一致性。采用的方法是將基于軟件架構測試方法和現存的基于代碼的回歸測試方法相融合的。通過一種行為圖表，代碼層面的回歸測試能夠與基于軟件層面的一致性測試相融合來選擇一個新的測試套組Ｔ′：
Ａ： 產生圖表Ｐ，大多數普通的用于代碼回歸測試的方法是為了通過圖表來結構化地表達Ｐ。在修改之后，Ｐ′也被描述成一張圖表。在軟件架構中，圖表也通過組合成分行為的ＬＴＳ模型來獲得，同時在結構中結構化那些成分組織。
Ｂ：把ＧＰ和ＧＰ′相比較，在基于回歸測試的傳統代碼中，通過比較Ｐ和Ｐ′的代碼圖表，識別代碼的改變怎樣影響到圖表中。在軟件架構中，這種改變根據在ＬＴＳ中節點和邊來識別。
Ｃ：記錄覆蓋范圍，通過測試用例的執行測試歷史記錄被構建出來。通過測試用例在Ｐ上執行代碼的過程，記錄一連串的節點／電弧。
Ｄ：測試用例選擇Ｐ′。從測試歷史和圖表比較中積累的信息被應用于識別將要在Ｐ′中再次運行的Ｔ中的測試用例。如果在ｔ∈Ｔ中Ｐ的執行包含了在Ｐ′中修改的節點，那么ｔ需要在Ｐ′中重新運行。
一旦Ｔ′被選擇了，ｔ′∈Ｔ′就在Ｐ′中運行并把結果收集起來，然后和一種數據庫相比較來確定測試是失敗還是成功。與基于傳統代碼方法的一種主要的區別是，在基于軟件架構回歸測試的數據庫是軟件結構自己本身。事實上，當ｔ′在Ｐ′中運行的時候，如果它的執行不允許所期望的情況再次出現，那么測試會失敗。更多情況，代碼層面的測試用例總是被形式化的函數和結構化的需求驅動得很好。
期望從這個方法中得到的好處有兩層：（１） 作為傳統的回歸測試，為Ｐ′減少了測試套組的規模，剪掉了所有在Ｐ′中不需要被再次應用的那些測試。（２） 當發現了一致性錯誤的時候，能夠搜集關于如何來適應初始架構的信息。
４．３ 目的２：測試進化得到的架構的一致性
讓再次假設基于軟件架構一致性測試已經聲明了Ｐ的實施應符合已給出的軟件架構。采用的方法是根據比較兩者的架構的規范來識別軟件結構改變／未改變的位置。結構和行為的改變都被考慮在內。特別的，對于Ｓ和Ｓ″的ＬＴＳｓ被比較之后的區別通過兩張圖表（利用一種“ｄｉｆｆ”算法）來識別。在一次與基于回歸測試傳統代碼相似的改革中，無論什么時候一個ＡＴＣ在Ｓ″中被修改的ＬＴＳ軟件架構中遍歷一次的時候，它需要在Ｓ″中重新測試。圖１（最左邊）總結了目的２如何通過不同的行為被意識到。
ａ： 新的軟件架構規則。演變的系統Ｓ″被結構化的規則提出。
ｂ： 測試標準。測試標準（之前應用在Ｓ中）被用在Ｓ″上。
ｃ： 比較。架構的規則與識別出的拓撲改變相比較（也就是增加的／刪除的組件或修改的配置）和行為的改變（也就是經過改變的部件）
ｄ：為Ｓ″選擇結構化的測試用例。那些來自于軟件架構的被結構的改變影響的ＡＴＣｓ被選擇在Ｐ″上重新測試，為了Ｓ″的實施。注意到任何在這步丟棄的ＡＴＣ都可以代表很多被消除的代碼層面的測試用例，因此很大程度上減少了重復測試的花銷。
ｅ： 識別代碼層面測試用例。一旦已經識別了需要用在Ｓ″中的回歸測試ＡＴＣｓ，為了Ｓ″需要把架構的測試用例轉化到代碼層面的測試用例，以便為了Ｐ″選擇Ｔ″。這一步類似于在第三步中基于軟件架構的測試。
ｆ： 測試執行。在Ｔ″已經被Ｓ″選擇之后，需要在Ｐ″中運行Ｔ″然后評估執行基于軟件架構回歸測試的結果。這一步跟第四步中基于軟件架構的測試很相似。
