ALAC

ALAC(Act-like-a-customer)測試： ALAC測試是一種基於客戶使用產品的知識開發出來的測試方法。ALAC測試是基於複雜的軟體產品有許多錯誤的原則。最大的受益者是用戶，缺陷查找和改正將針對哪些客戶最容易遇到的錯誤。

基本介紹

• 外文名：Act-like-a-customer
• 簡稱：ALAC
• 屬性：測試方法
• 最大受益者：用戶

基本方法

單元測試的基本方法

單元測試的對象是軟體設計的最小單位模組。單元測試的依據是詳細設計描述，單元測試應對模組內所有重要的控制路徑設計測試用例，以便發現模組內部的錯誤。單元測試多採用白盒測試技術，系統內多個模組可以並行地進行測試。

單元測試任務

單元測試任務包括：1 模組接口測試；2 模組局部數據結構測試；3 模組邊界條件測試；4 模組中所有獨立執行通路測試；5 模組的各條錯誤處理通路測試。

模組接口測試是單元測試的基礎。只有在數據能正確流入、流出模組的前提下，其他測試才有意義。測試接口正確與否應該考慮下列因素：

1 輸入的實際參數與形式參數的個數是否相同；

2 輸入的實際參數與形式參數的屬性是否匹配；

3 輸入的實際參數與形式參數的量綱是否一致；

4 調用其他模組時所給實際參數的個數是否與被調模組的形參個數相同；

5 調用其他模組時所給實際參數的屬性是否與被調模組的形參屬性匹配；

6調用其他模組時所給實際參數的量綱是否與被調模組的形參量綱一致；

7 調用預定義函式時所用參數的個數、屬性和次序是否正確；

8 是否存在與當前入口點無關的參數引用；

9 是否修改了唯讀型參數；

10 對全程變數的定義各模組是否一致；

11是否把某些約束作為參數傳遞。

如果模組內包括外部輸入輸出，還應該考慮下列因素：

1 檔案屬性是否正確；

2 OPEN/CLOSE語句是否正確；

3 格式說明與輸入輸出語句是否匹配；

4緩衝區大小與記錄長度是否匹配；

5檔案使用前是否已經打開；

6是否處理了檔案尾；

7是否處理了輸入/輸出錯誤；

8輸出信息中是否有文字性錯誤；

檢查局部數據結構是為了保證臨時存儲在模組內的數據在程式執行過程中完整、正確。局部數據結構往往是錯誤的根源，應仔細設計測試用例，力求發現下面幾類錯誤：

1 不合適或不相容的類型說明；

2變數無初值；

3變數初始化或省缺值有錯；

4不正確的變數名（拼錯或不正確地截斷）；

5出現上溢、下溢和地址異常。

除了局部數據結構外，如果可能，單元測試時還應該查清全局數據（例如FORTRAN的公用區）對模組的影響。

在模組中應對每一條獨立執行路徑進行測試，單元測試的基本任務是保證模組中每條語句至少執行一次。此時設計測試用例是為了發現因錯誤計算、不正確的比較和不適當的控制流造成的錯誤。此時基本路徑測試和循環測試是最常用且最有效的測試技術。計算中常見的錯誤包括：

1 誤解或用錯了算符優先權；

2混合類型運算；

3變數初值錯；

4精度不夠；

5表達式符號錯。

比較判斷與控制流常常緊密相關，測試用例還應致力於發現下列錯誤：

1不同數據類型的對象之間進行比較；

2錯誤地使用邏輯運算符或優先權；

3因計算機表示的局限性，期望理論上相等而實際上不相等的兩個量相等；

4比較運算或變數出錯；

5循環終止條件或不可能出現；

6疊代發散時不能退出；

7錯誤地修改了循環變數。

一個好的設計應能預見各種出錯條件，並預設各種出錯處理通路，出錯處理通路同樣需要認真測試，測試應著重檢查下列問題：

1輸出的出錯信息難以理解；

2記錄的錯誤與實際遇到的錯誤不相符；

3在程式自定義的出錯處理段運行之前，系統已介入；

4異常處理不當；

5錯誤陳述中未能提供足夠的定位出錯信息。

邊界條件測試是單元測試中最後，也是最重要的一項任務。眾的周知，軟體經常在邊界上失效，採用邊界值分析技術，針對邊界值及其左、右設計測試用例，很有可能發現新的錯誤。

單元測試過程

一般認為單元測試應緊接在編碼之後，當源程式編制完成並通過複審和編譯檢查，便可開始單元測試。測試用例的設計應與複審工作相結合，根據設計信息選取測試數據，將增大發現上述各類錯誤的可能性。在確定測試用例的同時，應給出期望結果。

應為測試模組開發一個驅動模組（driver）和（或）若干個樁模組（stub）,下圖顯示了一般單元測試的環境。驅動模組在大多數場合稱為“主程式”，它接收測試數據並將這些數據傳遞到被測試模組，被測試模組被調用後，“主程式”列印“進入-退出”訊息。

驅動模組和樁模組是測試使用的軟體，而不是軟體產品的組成部分，但它需要一定的開發費用。若驅動和樁模組比較簡單，實際開銷相對低些。遺憾的是，僅用簡單的驅動模組和樁模組不能完成某些模組的測試任務，這些模組的單元測試只能採用下面討論的綜合測試方法。

提高模組的內聚度可簡化單元測試，如果每個模組只能完成一個，所需測試用例數目將顯著減少，模組中的錯誤也更容易發現。

綜合測試的基本方法

時常有這樣的情況發生，每個模組都能單獨工作，但這些模組集成在一起之後卻不能正常工作。主要原因是，模組相互調用時接口會引入許多新問題。例如，數據經過接口可能丟失；一個模組對另一模組可能造成不應有的影響；幾個子功能組合起來不能實現主功能；誤差不斷積累達到不可接受的程度；全局數據結構出現錯誤，等等。綜合測試是組裝軟體的系統測試技術，按設計要求把通過單元測試的各個模組組裝在一起之後，進行綜合測試以便發現與接口有關的各種錯誤。

某設計人員習慣於把所有模組按設計要求一次全部組裝起來，然後進行整體測試，這稱為非增量式集成。這種方法容易出現混亂。因為測試時可能發現一大堆錯誤，為每個錯誤定位和糾正非常困難，並且在改正一個錯誤的同時又可能引入新的錯誤，新舊錯誤混雜，更難斷定出錯的原因和位置。與之相反的是增量式集成方法，程式一段一段地擴展，測試的範圍一步一步地增大，錯誤易於定位和糾正，界面的測試亦可做到完全徹底。下面討論兩種增量式集成方法。

1 自頂向下集成

自頂向下集成是構造程式結構的一種增量式方式，它從主控模組開始，按照軟體的控制層次結構，以深度優先或廣度優先的策略，逐步把各個模組集成在一起。深度優先策略首先是把主控制路徑上的模組集成在一起，至於選擇哪一條路徑作為主控制路徑，這多少帶有隨意性，一般根據問題的特性確定。以下圖為例，若選擇了最左一條路徑，首先將模組M1，M2，M5和M8集成在一起，再將M6集成起來，然後考慮中間和右邊的路徑。廣度優先策略則不然，它沿控制層次結構水平地向下移動。仍以下圖為例，它首先把M2、M3和M4與主控模組集成在一起，再將M5和M6 和其他模組集資集成起來。

具體步驟

自頂向下綜合測試的具體步驟為：

1 以主控模組作為測試驅動模組，把對主控模組進行單元測試時引入的所有樁模組用實際模組替代；

2 依據所選的集成策略（深度優先或廣度優先），每次只替代一個樁模組；

3 每集成一個模組立即測試一遍；

4 只有每組測試完成後，才著手替換下一個樁模組；

5 為避免引入新錯誤，須不斷地進行回歸測試（即全部或部分地重複已做過的測試）。

從第二步開始，循環執行上述步驟，直至整個程式結構構造完畢。下圖中，實線表示已部分完成的結構，若採用深度優先策略，下一步將用模組M7替換樁模組S7，當然M7本身可能又帶有樁模組，隨後將被對應的實際模組一一替代。

自頂向下集成的優點在於能儘早地對程式的主要控制和決策機制進行檢驗，因此較早地發現錯誤。缺點是在測試較高層模組時，低層處理採用樁模組替代，不能反映真實情況，重要數據不能及時回送到上層模組，因此測試並不充分。解決這個問題有幾種辦法，第一種是把某些測試推遲到用真實模組替代樁模組之後進行，第二種是開發能模擬真實模組的樁模組；第三種是自底向上集成模組。第一種方法又回退為非增量式的集成方法，使錯誤難於定位和糾正，並且失去了在組裝模組時進行一些特定測試的可能性；第二種方法無疑要大大增加開銷；第三種方法比較切實可行，下面專門討論。

2自底向上集成

自底向上測試是從“原子”模組（即軟體結構最低層的模組）開始組裝測試，因測試到較高層模組時，所需的下層模組功能均已具備，所以不再需要樁模組。

自底向上綜合測試的步驟分為：

1 把低層模組組織成實現某個子功能的模組群（cluster）;

2 開發一個測試驅動模組，控制測試數據的輸入和測試結果的輸出；

3 對每個模組群進行測試；

4 刪除測試使用的驅動模組，用較高層模組把模組群組織成為完成更大功能的新模組群。

其它含義

ALAC 即Apple lossless audio codec的縮寫，是蘋果公司開發的一種無損音頻格式，蘋果在Apache v2.0許可證下開源了“蘋果無損音頻編解碼器（Apple Lossless Audio Codec，縮寫ALAC）”。詳情可以參考 ALAC格式 詞條。