一個基于UML協作圖的集成測試用例生成方法(二)(3)

　　測試模式是一個測試策略，是建立在測試模型基礎上的，而測試模型應該是被測軟件系統的一個表示，能夠從測試模型上獲取測試需求，導出測試規約，從而生成測試用例。協作圖是對象、組件、子系統、系統范圍需求的良好來源，對系統的一個有限片斷來說，提供了實現的抽象視圖，它通常是過多或過少細節之間的一個良好的折中，可以用于在不同抽象級別和粒度級別建立軟件系統的模型。由于協作圖是描述的對象之間的交互，而系統的功能正是通過這些交互實現的，所以要考慮將設計描述的協作圖作為生成集成測試的測試用例的測試模型。協作圖上包括了對象間傳遞的消息及其順序，這正是設計級的控制流和數據流信息，以往數據流和控制流只能從程序源碼中分析得到。數據流和控制流對生成測試有很大的作用，所以我們利用協作圖生成測試用例，就是要從協作圖上提取出相應的數據流和控制流信息，利用傳統的數據流、控制流生成測試用例的方法，生成可用于集成測試的測試用例。所以本文使用作為系統設計描述的協作圖作為測試行為的測試模型，避免重新構造測試模型或者進行模型轉換。

　　2.1中分析了協作圖中描述的信息，這也是作為測試模型的協作圖中包含的對生成測試用例有用的信息，這些信息是規約在轉變成實現時必須保持的，這些信息也是測試時要確認在軟件實現中是否正確保持的設計信息，因此這就是測試工作第一步要獲取的測試需求。測試需求的正確實現要求也就是測試規約，它規定了能讓軟件執行并正確反應測試需求的測試用例。如果我們能夠用足夠的測試用例執行了程序，并證明協作圖上所有測試需求都在軟件中正確保持了，就可以說測試充分了，本文主要關注協作圖表示的系統的動態交互行為，而協作圖上用于表示交互行為的主要是消息及其偏序序列，所以本文研究的測試方法的充分性準則是協作圖上所有的消息及其偏序關系都被測試用例覆蓋。表1中的協作圖的集成測試需求說明至少有一個測試用例測試對應的關系來檢查測試需求是否滿足。

　　符號 關系 集成測試需求

　　實線實心箭頭 扁平控制流 發送者與接受者之間的偏序

　　實線刺狀箭頭 過程調用

　　條件過程調用

　　迭代過程調用

　　遞歸過程調用 發送者發送消息到接受者并返回

　　發送者發送消息到接受者并返回，

　　發送者不發送消息到接受者

　　發送者重復發送消息到接受者并返回

　　發送者發送消息到自己

　　虛線刺狀箭頭 從過程調用返回 可不考慮

　　表1 消息對應的集成測試需求

　　一個場景路徑上由消息激活的方法序列表示了我們要測試的行為，路徑上對象間的消息傳遞描述了要實現相應的功能對象間必要的交互，協作圖上場景路徑的構造能夠滿足表1描述的協作圖對應的集成測試需求，這樣我們就可以把問題轉換到滿足協作集成測試需求的場景路徑的分析和處理上。我們在協作圖上遍歷生成場景路徑的同時，很容易基于路徑覆蓋準則獲取相應場景執行過程中的控制流和數據流、覆蓋路徑的條件，然后可以確定每一路徑所需要的輸入和狀態條件，當滿足所有路徑條件時線程就會沿著該路徑執行，測試用例的定義需要滿足路徑條件的特定輸入和狀態。為了確定測試用例的值，需要分析每條路徑上的謂詞，從第一個謂詞開始，選擇滿足相應路徑條件輸入和狀態值。直到完成所有的路徑條件，最后確定每個測試用例的預期結果，包括方法調用序列。第3部分詳細描述從協作圖構造場景路徑，然后基于場景路徑生成測試用例的方法。

原文轉自：http://www.kjueaiud.com