當文本使用案例文件創建特別是使用文件模版時直接運行，當涉及到複雜案例和測試設想時這些文件很快就變得難以控製，這些複雜案例和設想包括多元的和嵌套的選擇流程。隨著複雜性的提高，測試設計者可能會在從這些文件中提取他的測試程序過程中忽略重要的測試設想。一種更簡明的抽象、演變和傳達的測試設想通過行為圖表得以描述，因而，我們提供UML編輯工具幫助用戶快速將現存文檔轉化為UML行為圖表。
1.2 行為圖表
行為圖表是可以通過劃分“泳道”，很好的反應用戶輸入和係統響應。第一對泳道顯示了典型的測試設想、交互作用流程或適當的路徑，其餘的泳道表示了其他供選的通道。
下麵描述的測試要求代表了大量的在整個過程中產生的和功能存儲界麵獲得的首先影響測試生成過程的圖表注釋，還有許多可選擇的和有代表性的沒有出現在圖表的我們也一一標出。
2 相關研究
使用UML自動生成測試案例的研究在近幾年已經廣泛地開展，許多文獻討論了與麵向個人和輔助係統成員的自動測試程序的生成和執行相關的程序，這些程序更適用於單位和整體測試。
我們的方法中列出了更多的討論UML應用於係統測試的文獻和集中研究基於圖形用戶界麵（GUI）測試程序生成的文獻，包括西門子公司研究的早期的缺少目的性的非正式的操作指南等。
例如Beer等描述了麵向GUI測試的整體設計和自動測試案例生成環境（IDATG），IDATG支持案例生成是基於：1）模型描述特定的用戶任務；2）模型捕捉用戶界麵行為。這一工具也支持基於商業捕捉-釋放工具的測試案例執行。Menon也發展了相似的環境，包括測試生成、存儲、執行、Oracle創新和回歸分析特征。
後兩種方法和我們的方法最大的區別在於，在我們的案例的目標是通過GUI使係統功能和商業標準更為有效，而不是盡可能多的測試和存儲用戶界麵功能。因此，為了測試案例生成，我們不僅需要開發行為模型，而且需要應用強大的數據模型技術（通過使用TDE完成）。更進一步的區別是我們在測試生成中使用UML行為模型，而其他兩種方法則使用自己定義的模型符號。
3 結論
我們的方法得益於使用COTS工具，如Rational Rose、測試模型和成熟的內部工具，如TDE。他們共同為我們在預期的本技術的應用效果實驗研究持續進行打下了堅實的基礎。
本研究還確定了未來研究的主題：首先，我們要改進測試案例生成步驟地性能和文件執行的可靠性；第二，更加精確的數據存儲的測定技術的應用也很重要，特別是當我們想要改進測試數據創建和數據在測試文件執行中的應用過程時；第三，適用特定的測試設想來檢驗係統的商業規範性，這些規則詳細指定了對係統的限製，他們可以通過詳細的使用概要更有效的檢驗其規範性。最後，我們為更進一步的編寫和簡化行為圖表、獲得更簡明的係統測試模型建立更好的執行機製。
參考文獻
【1】王先國.UML統一建模實用教程【M】.清華大學出版社，2010.
【2】汪青青.UML 2.0學習指南【M】.清華大學出版社，2007.