MFQ&PPDCS 大型嵌入式軟件系統的測試分析和測試設計(5)

　　“組合“特性包括：

　　存在大量的參數(數據)

　　每個參數有很多值

　　參數之間可能存在一些邏輯關系

　　2)應用步驟

　　Step1：建模

　　”C-組合“可以使用因子狀態表，組合測試【2】或者正交測試技術可以參考。

　　例如，給定四個因素，測試所有組合需要72個測試用例。我們可以通過確保每個因素的每個值和其他任何一個值的組合至少被測試過一次的方法來減少測試用例數量同時盡可能帶來的風險。

　　Step2：設計基礎用例

　　在http://www.pairwise.org/tools.asp站點里有很多關于結對測試的工具。其中，PICT是一款非常好用的工具。

　　使用PICT設計基礎用例的的過程，就是使用PICT特殊的”語言“形成的表格。一旦我們定義這些規則，我們可以在DOS環境下運行這些腳本。所有的基礎測試用例自動生成。

　　舉例說明，在”model_test.txt”文件中定義了下面的規則：

　　Factor A：A1，A2

　　Factor B：B1，B2，B3

　　Factor C：C1，C2，C3，C4

　　Factor D：D1，D2，D3

　　當我們執行下面命令：

　　C:\>pict model_test.txt > output.xls

　　下面12個基礎測試用例會被自動保存在output.xls中：

　　這12個組合就是我們所需要測試的確保每個因子的每個值都至少跟其他因子的值組合測試過一次。

　　Step3：補充測試數據

　　針對每個基礎測試用例，為涉及到的每個參數定義一個值。例如，如果“A1″代表”>50″，那么用60代替。

　　Step4：拓展測試

　　基于經驗補充特殊的測試用例。

　　F S-State

　　1) 應用條件

　　如果測試對象的設計規格中存在”狀態“特征，”S-狀態“方法可以被用來建模。

　　”狀態“的特性包括：

　　測試對象的行為變化基于它內部的狀態

　　確定的事件觸發測試對象的狀態

　　2)應用步驟

　　Step1：建模

　　”S-狀態“可以通過”狀態圖“建模，可參看”基于狀態測試“的技術。

　　在一個狀態圖中，狀態可以通過節點表示，事件可以通過連接節點的弧表示。

　　建模步驟如下：

　　從規格中識別行為對象

　　對這些行為對象確定所有可能的狀態

　　對每個狀態，畫出節點

　　識別所有在狀態之間的節點傳輸

　　針對每個傳輸，確定觸發的事件

　　針對每個事件，畫出相關節點的鏈接

　　Step2：設計基礎用例

　　很多方法可以用來設計基礎用例覆蓋狀態圖。其中之一就是Chow的方法【10】

　　TableXI 列舉了用Chow’s的0-Switch的覆蓋方法針對上圖生成的基礎測試用例。TableXII列舉了使用Chow的1-Switch覆蓋方法的基礎測試用例。注意，基礎測試用例的增加是考慮單個傳輸還是成對的傳輸路徑。

　　distinguish=49AE1A9C29384643A18286B2962A6C6D data-media-type=image data-inited=true v:shapes=”_x0000_i1041″>

　　Step3:補充測試數據

　　針對每個基礎數據，我們識別涉及的相關變量然后通過等價類劃分和邊界值定義測試數據。這個結果在每個抽象的測試用例里可以被擴展成一個或者多個可執行的具體測試用例。

　　Step4：拓展測試

　　基于經驗補充特殊的測試用例。

　　這個章節講述的是關于PPDCS方法。簡單功能的測試分析和測試設計，第一件事就是識別簡單功能(或稱為單元或組件)的數目。針對每個簡單功能，需要哪種測試分析：通過PPDCS方法建模，設計基礎用例來覆蓋模型，針對每個測試用例補充更多的測試數據，然后通過基于經驗設計其他的測試用例。

　　V 結果

　　在華為，一些實驗性質的項目開發者被教導使用MFQ&PPDCS方法。表格XIII在產品的一個特性使用傳統設計方法和使用PPDCS方法比較了M 部分(MFQ框架的簡單功能部分)的結果。

　　開發人員使用傳統的測試方法(主要是基于經驗的測試方法)設計了86個測試用例。由于在測試用例設計過程之前沒有明顯的測試分析過程，該特性的2個部件在開發人員設計測試用例過程被忽視了。(識別簡單功能的數量的步驟沒有施行好)。運行這86個用例后，只有1個缺陷被檢測出來。

　　為了比較傳統測試設計方法和PPDCS的新的測試方法的效用，一個新的測試者被指派重新使用PPDCS方法來進行這個特性的設計。結果是，設計了102個測試用例。4個部件全部被識別到，而且該特性的更多功能點被測試用例覆蓋。測試分析和測試設計過程結束后，即便那個時候還沒有測試用例執行，已經檢測到5 個缺陷。

　　distinguish=7AD5CC13BCA641AEA3312622B9C09C5D data-media-type=image data-inited=true v:shapes=”_x0000_i1042″>

　　結論：

　　開發人員可以很快學會，然后在PPDCS的幫助下，單元測試分析和測試設計做得很好，即使之前只有一點點的測試設計知識基礎。

　　很多潛在的缺陷在建模階段就被發現和預防了，而傳統的測試需要測試者在軟件實現完成以后發現。這是因為建模的過程同時也是測試分析的過程，測試規范通常在測試分析階段會被審查一遍，然后潛在問題在早期就被發現。

　　因為PPDCS是黑盒測試方法，當結合白盒測試方法(例如：通過白盒測試技術比如狀態覆蓋、分支覆蓋、路徑覆蓋等等來補充測試用例)，可以獲得更好的覆蓋率。

　　開發人員可以很容易將測試分析過程合并到軟件分析過程，使得軟件設計更加完善。

　　VI 總結

　　綜上所述，針對大型嵌入式軟件系統的測試分析和測試設計過程是：

　　在低級別的測試，比如單元測試，簡單功能(“M”Part)要徹底測試。在高級測試級別，比如系統測試、功能交互(“F”part)和質量屬性(“Q”部分)需要徹底地測試。然后，這并不是絕對的。

原文轉自：http://hejiajie.cn/archives/472