基于模型的測試用例生成方法

蒲卿路,王月波, 劉 濤,孫 云,李繼秀

(西南電子技術研究所，成都 610036)

0 引言

目前，隨著科技的進步，軟件的發展。各式各樣的軟件融入人們的日常生活中。購物，游戲，銀行轉賬等活動都成為日常生活的一部分[1]。優秀的軟件能夠吸引大量的客戶，為公司取得收益。同時在大量軟件出現的今天，也對軟件本身提出更高的安全性和穩定性。一款軟件在上線前夕，需要進行大量的測試，以便提升軟件的質量[2-3]。因此，對軟件測試的方法，測試工具的研究為軟件測試的質量帶來了保證[4]。如何快速、高效地進行測試也是每一個測試人員及開發人員都必須重視的問題[5-7]。

目前大部分的測試用例都是由測試人員或者開發人員手工錄入。針對同一類型的測試用例，其區別僅在于數據取值的不同。大量并且重復的測試用例設計，導致測試用例質量不高，不能夠發現軟件深層次的異常。同時，測試對軟件開發的介入，往往需要有一定的代碼基礎才能開展。在軟件需求驗證階段，傳統的測試則不具有可行性。因此，有研究人員提出了基于模型的測試、優化和指導測試工作以及加速軟件開發過程。

基于模型的測試，就是使用工作流程圖、判定表、狀態轉換圖描述出被測對象的實現邏輯。通過對上述模型進行路徑的遍歷，即可得出測試點。如果測試人員按照依據文檔，建立模型時，發現模型不完整，邏輯混亂。也就代表軟件的設計邏輯出現錯誤。使得軟件開發過程與測試活動相結合[8]。在軟件開發的后期，模型中各個路徑的條件逐漸完整，使用參數定義，以及取值明確時，就可以在路徑遍歷的基礎上，加入邊界值與等價類的思想[9]，將參數實例化，從而得出一個完整的測試用例。

目前測試行業主要存在以下問題：

1)測試與開發脫節。測試的開展需要有一定的代碼基礎才能進行，因此測試被至于軟件開發周期的后半段。同時，大部分軟件開發更新過程較快，測試人員開展測試工作時，被測對象的功能與測試需求已經嚴重不符。測試工作難以開展。

2)測試用例需要手動錄入，如果一個測試項包含多個參數，測試用例的設計則需要對每一個參數的取值情況進行全組合。在沒有用例自動生成工具的幫助下，測試人員的工作效率極為低下。

3)開展測試任務時，通常由多個測試人員同時開展測試分析與設計，容易造成測試數據的混亂。測試數據的可追蹤性和恢復性也沒有保障。

針對以上問題，本文基于模型測試，實現了測試用例的自動生成。有效地解決了上述軟件測試中的種種問題，提高了測試人員的工作效率與被測軟件的質量。本文后續內容主要對各個典型模型的生成測試用例的算法與數據結構的設計進行講述。

1 測試需求模型構建

測試需求分析是進行軟件測試的前提和基礎。測試需求是指依據軟件需求，根據測試目標而確定的被測軟件的測試屬性。測試屬性是指軟件測試人員結合測試意圖和被測軟件本身的特點分析得到的測試對象、范圍和內容等要素。測試意圖是通過軟件的測試類型加以實現的，從不同角度驗證軟件的質量屬性[10]。系統測試需求建模是指依據軟件需求規格說明，從測試的角度出發，確定被測軟件的測試屬性，明確被測系統的輸入輸出及其映射關系[11]，建立被測系統的工作流程，判定表，狀態轉換等模型[12-13]。

如圖1所示，傳統的系統開發由一系列的文檔構成，因此需要分析被測軟件的相關文檔，明確軟件的測試屬性并劃分測試項[14]。軟件文檔作為軟件的主要產品之一，為軟件測試提供了主要的信息。從需求文檔中可以提煉出系統的組成、功能、性能，軟件的運行狀態、運行時序，接口信息以及顯性和隱性的軟件質量屬性等。依據軟件功能進行測試項的劃分，確定測試類型，并創建相對應的模型。

圖1 條件解析后生成的二叉樹

2 基于工作流程圖的測試用例生成方法

2.1 模型的創建

首先，將流程圖中的不同節點類型統一劃分為：開始節點、結束節點、動作節點、判定節點。所有流程圖必須具有開始節點和結束節點，代表流程的開始與結束。動作節點，代表流程進行到此處時，需要完成指定的內容，例如設置參數A為True，參數B自增1等。該內容的定義需要測試人員根據需求文檔或者使用說明書，設計方案等進行創建。如果軟件處于需求分析階段，則該節點可不需要與具體參數掛鉤，使用一段文字描述即可。判斷節點，代表流程進行到此處時，需要根據某參數的具體取值，從而走向不同的下一個節點。

節點與節點之間的連線稱為邊。當該邊的起點為判斷節點時，則需要為邊添加條件，代表該條件滿足時，才可經過該邊。這里與傳統的流程圖中的真假分支有一定區別。因為在軟件實現中，邏輯的分支不一定為’if’和’else’，還需要考慮包括使用’else if ’的多個可選邊存在的情況。因此在判斷節點本身不存儲具體的參數判定邏輯，而是在邊上進行聲明。

通過使用上述4種類型的節點的組合與邊，即可完成模型的創建。

2.2 模型的路徑遍歷

工作流模型測試的核心思想是遍歷從開始節點至結束節點的每一條路徑，一條路徑也就對應著一個測試點。如果工作流程中出現環的情況下，生成的路徑中還需要覆蓋到該環或者多個環組合的情況[15-16]。

為解決上述問題，決定采用有向圖的數據結構，對用戶創建的工作流進行底層數據的存儲。每一個節點代表圖中的頂點，節點到節點的路徑中為圖中的邊。這樣，就把用戶畫出的流程圖轉換為數據結構中的有向圖。通過對圖的遍歷，即可完成工作流的路徑遍歷。

遍歷路徑時，首先使用深度遍歷的算法思想，使用一棧或隊列存儲路徑中的節點。從起點開始，遍歷其下一個可到達的節點，并將其入隊，再遍歷該節點的下一個可達節點。并判斷該節點是否為結束節點，或者沒有下一個節點時，則返回，并將棧頂的節點出棧。如果已經到達結束節點，則將棧中的節點存儲在最后的結果中，代表一條完整的路徑。如此循環。利用上述思想能夠得出圖中的所有簡單路徑[17-18](沒有重復節點出現的情況)。但此方法不能將有環的路徑遍歷得到。因此還需要找出圖中的所有環，遍歷所有簡單路徑與環，查看路徑中是否包含環的起點。如果有則將環放入一個臨時的數組中，這樣，就會把該簡單路徑中涉及到的所有相關環進行記錄。最后使用排列組合的思想，將多個環組合后，插入至簡單路徑中。那么一條包含環的復雜路徑即可生成完畢。其流程如圖2所示。

圖2 路徑遍歷算法

2.3 條件的解析與測試用例生成

通過上述的路徑遍歷方法即可得出測試點。而對于測試點，對測試點中不同參數的進行取值，則可得出完整的測試用例。因此用例的生成需要將路徑中的參數實例化，而在實例化時則需要運用邊界值與等價類的思想。

為解決上述問題，決定采用二叉樹與棧對條件進行解析。在解析具體的條件前，首先需要確定符號之間的優先級。本方法采用C語言的語法，用全局變量的形式存儲兩個符號間的優先級關系。在這里要注意的是，不同語言之間的優先級關系可能不一致，如‘a&1==1’，在python中會優先計算‘a&1’，但在C語言中會優先判斷‘1==1’，因此為避免上述問題帶來的干擾，建議測試人員在輸入條件時加上括號，轉變為‘(a&1)==1’。這樣，不管任何語言，都會優先計算‘a&1’。同時，同一個符號在不同語句中的意義不同，優先級的關系也就不同。例如‘a-b>0’，‘-a>0’。‘-’號在第一個表達式中代表減號的意義，第二個代表取反的意義，兩個的符號的優先級在C語言中是不同的。又比如，‘*a’，‘a*b’，‘*’號，在第一個表達式中是指針的含義，第二個表達式則是乘號。

使用括號，對條件的語義進行限制后，即可開展條件的解析。本文采用兩個棧完成條件的解析。

第一個棧用于存儲操作符，第二個棧用于存儲除開操作符的變量名或者數字。首先對條件表達式進行循環，依次判斷該字符是不是操作符。如果是則將其入至操作符棧。并且在入棧之前判斷是否為空，以及當前棧頂的操作符的優先級是否大于即將入棧的操作符。如果大于，則出棧當前棧頂的元素，創建一個新的二叉樹節點，并將操作數棧中的數據連續出棧兩次，將其作為該二叉樹的左右節點。最后再將新節點入操作數棧。如果該字符不是操作符，則將其先加入一個臨時變量中，并進入下一次循環。直到字符為操作符時，先把臨時變量中的數據存入數據棧，并清空臨時變量。再繼續操作符的操作流程。因為用戶定義變量名時可能是多個字符，例如time，count等，并不是簡單的a，b的形式。所以需要一個臨時變量，來獲取完整的變量名，或者是變量的取值。

圖3 條件解析后生成的二叉樹

由上述算法及圖1可知，所有的參數只會出現在樹的葉子節點上，參數節點的父節點即為判斷的條件。參數節點的左右同級節點則為具體取值。得到具體取值后，則可通過邊界值與等價類的思想，生成數據，也即為生成測試用例。

3 基于判定表的測試用例生成方法

3.1 模型的創建

基于工作流的測試模型分析完畢后，判定表的分析則顯得稍微簡單，但也有不同之處。判定表由參數，規則，動作組成。使用表格的方式完成對參數，規則，與動作的定義。表格中的列可分為參數與動作。每一列中的不同單元格(cell)存儲著參數的條件與動作的結果。

表格中的行，即為規則(rule)。可以理解為多個參數判定條件的組合。同工作流程圖，在使用該模型時，也需要對參數的類型，步進等信息進行定義。測試人員在創建模型時，和工作流構建時相同，需提取文檔中的相關信息后，構建判定表。

3.2 判定表測試用例生成

最后將上述表達式使用同工作流條件解析的思想，將其解析為二叉樹后，再提取參數及其取值，并利用邊界值與等價類的思想，生成測試數據后，再使用eval函數去除不合適的數據。那么一條rule的測試數據即可自動生成完畢。

4 基于狀態轉換圖的測試用例生成方法

4.1 模型的創建

狀態轉換圖與工作流類似，可將狀態視為工作流中的節點，狀態至狀態之間的轉換，可以理解為節點至節點的邊。但是狀態轉換圖中并沒有起始節點和結束節點的概念，只存在一個初始狀態的節點[19]。并且狀態轉換圖中測試點的概念也與工作流的的概念不同[20]。在工作流程中，從起始節點至結束節點的一條路徑即為一個測試點。而在狀態轉化圖中，測試的目的是測試不同狀態之間是否按照規定的條件進行轉換，并且可以存在狀態之間的多次循環轉換，循環轉換次數需要由測試人員憑經驗決定。往往在實際測試項目中，簡單的從狀態一轉換至狀態二并不會出現問題。但在循環轉換時，狀態一至狀態二，狀態二再轉換至狀態一，狀態一再轉換至轉二時，會出現錯誤。其他情況同理。

4.2 模型的路徑遍歷

通過上述分析，直接使用狀態轉換圖模型，采用深度遍歷的算法，不能得出的正確的測試路徑。本方法提出將狀態轉換圖轉換至狀態轉換樹，得出狀態轉換樹后再使用深度遍歷的思想。因為狀態之間可以循環轉換，所以該樹可以無限衍生下去。因此需要定義一個深度的概念，該概念與二叉樹的深度不同，當所有狀態都遍歷到，所有狀態至狀態的邊都遍歷到時，此時生成的樹，稱為深度為1的樹。如果測試人員想對循環狀態轉換進行測試，則可以繼續對該樹進行拓展，如進行帶有一次循環狀態測試，則該樹需要向下再拓展一層。因此最后的測試點需要由用戶決定深度后再去生成。一個典型的狀態轉換圖如圖4所示。

圖4 某典型狀態轉換圖

定義狀態1為初始狀態。將狀態圖轉換至狀態樹后，可得如圖5所示。

圖5 深度為1的狀態轉換樹

將狀態轉換圖轉換為狀態樹后，則可開始測試用例的生成，生成方法與工作流類似。

在實際測試過程中，某復雜功能的實現，其夠成的模型可能是狀態轉換圖與工作流模型的組合。假如，上圖中狀態1轉換至狀態2的條件為某工作流。因此需要將工作流與狀態轉換圖進行關聯。最后生成的測試點是狀態圖本身測試點與工作流本身測試點的乘積。

5 實驗結果與分析

為驗證基于模型的測試用例生成方法的正確性與完整性，將該方法應用于實際項目中。某型號項目具有如下處理流程：

1)電臺向顯控盒發送工作參數。

2)顯控盒是否收到ACK/NAK。

3)如果收到ACK，則判斷是否收到工作參數。

4)如果收到NAK或者未收到ACK,則電臺重新發送。超過兩次未收到ACK，或者收到NAK，則流程結束。

5)收到ACK，并且收到工作參數，則進行合法性校驗。校驗成功，則保存至FLASH，并修改參數，流程結束。校驗不成功則回退參數，流程結束。

6)未收到參數，并且未超時，則繼續等待接收參數。超時后，回退參數，流程結束。

5.1 實驗步驟

1)測試人員根據上述流程繪制模型。并檢查模型是否完整。

2)如果模型完整，則使用基于工作流的測試用例生成方法，生成測試用例。

3)測試人員根據自動生成的測試用例，執行測試。

4)測試人員采用手動設計測試用例的方法，進行用例的設計并執行。

5)將自動生成的用例與手動生成的用例進行對比，檢查自動生成用例的完整性與正確性。

5.2 結果分析

上述流程經過建模后結果如圖6所示。

圖6 基于工作流建立的測試模型

模型建立完成，不缺少模型的必須組件，每個判定都具有相應的分支。則可得出設計流程正確。運用測試用例生成方法后，可得出簡單路徑4條，環2個。最終算法運用排列組合的思想，得出完整路徑14條。也即為14個測試用例。其中一個測試用例為：開始→發送工作參數→是否接收ACK/NAK(期望結果，收到ACK) →是否收到工作參數(期望結果，收到參數)→合法性校驗(期望結果，校驗成功)→修改參數，保存至FLASH→結束。其他用例不一一列舉。測試人員根據上述用例，并按照流程執行，即可驗證對應軟件邏輯是否按照預期進行編寫。

測試人員不借助算法，運用常用的用例設計方法手動設計用例14個。并將用例與自動生成的用例進行詳細對比，每個手動設計的用例都與自動生成的用例內容相同。因此，該算法能夠正確生成測試用例，并且在用例完整性，正確性上都得到了保證。

其他現有的測試用例自動生成方法，不能夠用于判定表，狀態轉換圖等模型的用例生成，并且，只對路徑的遍歷進行算法研究，沒有對路徑中判定分支的具體取值進行計算，不能給出經過邊界值與等價類過濾后得出的可選取值。而在上述實驗中，重傳次數小于2(count<2)，通過對表達式的解析，會獲取出2的左右邊界及自己(1，2，3)，并將其作為分支的可選取值對自動生成的用例進行實例化，使得用例不再抽象。

當然，該流程在實際項目中屬于簡單的處理邏輯。當流程較為復雜，分支較多時，采用基于模型的用例生成方法，能夠快速地生成完整的測試用例，不會因為人為的因素，或多或少地生成用例。并且整個測試的時間也會大幅度減少，并有助于理清測試人員的測試思路。提高測試效率。

6 結束語

隨著面向對象的軟件開發技術的不斷發展和廣泛應用，基于模型的軟件測試，不僅可以把軟件測試工作提前到開發過程，因此能夠較早的參與測試，并發現系統設計的不足，減少了后期的維護成本與軟件測試的成本。

本文分別針對工作流，判定表，狀態轉換圖3種模型的測試用例生成進行了詳細的說明。為解決測試行業當前主要問題提供一定的幫助與貢獻。

后期將進一步對算法進行深入優化。如存在并發場景的測試模型，該如何進行測試用例的生成等。