從用例到測試用例的追蹤(5)

　　測試用例的分配可以在測試用例分配表格中描繪，如表 4所示。

　　表 4 描述了圖11中每列包含不同的測試用例。每一行相應的是用戶輸入的變量。

　　步驟 4：為變量賦值

　　在此步中，你替換如"一個非常長的名字" 或"擴展很長的電話號碼"這樣的占位符為像"Georgiamitsopolis" 和 "011-48 (242) 425-3456 ext. 1234"這樣實際有價值的東西。在此步，你還可以分裂表 4所示的表格中的測試用例，為每個測試用例創建獨立的表格。

　　如書籍訂購使用用例的測試用例 1，你就可以創建一個像表 5這樣的表格。這就給你的測試者創建一個文檔。測試者將跟隨總隊2和3的方向，并且記錄縱隊5，6，7的結果。

　　表 5：最終的測試用例

　　RequisitePro再一次幫助你創建追蹤關系。在產生了全部的測試用例以后，你可以設置從場景到測試用例的追蹤。

　　圖 12顯示了全部的場景：從不同的可選流程合并中產生21個場景。

　　圖12 ：追蹤矩陣

　　在設置了場景和測試用例之間的追蹤關系后，我們可以創建一個顯示從用例到測試用例全部追蹤方法的追蹤樹。

　　這里有兩個選項。第一個選項——如圖 13顯示——用于追蹤到用例外，用來顯示上層的用例并且追蹤場景和測試用例。

　　圖 13：用例的追蹤樹

　　第二個方法是測試用例中的追蹤，如圖14所示。在此種情況下，追蹤樹看起來會有不同：你從測試用例開始，然后追蹤場景和用例。

　　圖 14：測試用例的追蹤樹

　　進行這種追蹤的一個最主要的原因--并且花費時間將其加入到RequisitePro中--是為了讓你知道當一些事情發生變更時需要重新測試什么。追蹤和所謂的可疑關聯，如圖 15所示，為你顯示了由于先前的場景和用例發生了變化，哪些測試用例也要隨之改變。

　　圖 15：可疑關聯

　　映射到IBM Rational統一過程

　　如何映射到IBM Rational統一過程(RUP)呢?它們大多數發生在過程中的先啟和精化階段。只要你有了用例之后，我們就可以開始建立場景和測試用例。圖 16描述了這些活動對應于RUP方法論中的哪些地方。

　　圖 16：映射到RUP階段的追蹤活動

　　當建立場景和測試用例時，你可以給用例設計者反饋并且精煉一下需求。這有助于在過程中盡早改變一些任務，并且最終為團隊盡快完成任務做出貢獻。在整個精化階段以及幾乎是整個構造階段中都會使用測試用例。

　　總結

　　本文介紹了一種從用例中產生功能測試用例的方法。這是使用此方法的一些益處：

　　用更自動化的方法產生測試用例

　　避免重復測試

　　更好的測試覆蓋

　　簡化了測試進度的監控

　　簡化了測試人員之間的工作負載平衡

　　簡化了回歸測試

　　通過把一些任務從構造階段移到精化階段來縮短項目時間

　　能夠幫助盡早地發現缺失的需求

　　你創建的測試用例能夠用于人工測試，也可以用于像IBM Rational Robot這樣的自動化測試。這種方法已經在許多項目中獲得了成功。

原文轉自：http://www.uml.org.cn/Test/200607073.htm