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

　　美國

　　加拿大

　　其它國家

　　一些商業規則的輸入例如

　　假設這里已有一項規則 "如果實下午6點以后下訂單是，用戶選擇頭天晚上送貨，將會通知這本書將會在后天到達。"，我們有兩個：獨立的選擇

　　頭天晚上發貨，在下午6點之前下訂單

　　頭天晚上發貨，在下午6點以后下訂單

　　這里有一個邊緣情況例如

　　因為密碼應當包含至少6個字符，我們因該測試：

　　5個字符的密碼

　　6個字符的密碼

　　改變某些事情對使用默認例如

　　在信用卡支付界面，持卡人的名字通常是訂貨人的姓名。這就產生了2個獨立的選項：

　　保持默認持卡人的姓名

　　改變持卡人的姓名

　　沒有明確定義輸入格式，不同的用戶有不同的理解例如

　　不同的人有不同的書寫電話號碼的方法：

　　使用括號 (973) 123 4567

　　使用破折號 973-123-4567

　　數字間使用空格 973 123 4567

　　不同的國家有不同的規則例如

　　信用卡有效日期的格式在美國和加拿大就不同

　　如果我們測試數字，我們會考慮以下選項：

　　常規的以及從應用觀點上是合理的數字

　　0

　　負數

　　帶兩位小數的數字

　　能輸入的最大數字(99999999999999 - 輸入最多的9)

　　你怎么知道區域內能夠輸入的最大和最小的長度?這個需求可以從不同的來源得到。有時，它來自于商業的分析或顧客。例如，如果我們輸入Dun 和 Bradstreet 數字，這就被看成是一個公司，它總是包含9個數字。這是商業的需求。

　　然而，它一般不會來自于顧客和用戶。如果你問客戶姓名區域有多長，它們會告訴你不用擔心長度，只要要合理即可。在此例中，設計步驟決定了變量的長度而不是需求步驟所決定的。

　　另一種情形，數據分析師或者數據庫設計者會提出建議——例如，在如果公司的全部應用軟件中姓名應在30個字符以內，你的申請的用戶名就得依照這個標準。

　　不管需求的來源是何處，在我們做測試用例之前它都要被同意并且備份。

　　這里有一個關于上述討論的需求應該在哪里進行文檔化的問題。在用例中一個增加這個需求的地方是被稱為 Special Requirements的地方。另外一個可以放置這種需求的地方是術語表或者數據字典。另外，你可以詳細說明一個獨立的文檔類型，在那里你可以描述全部應用程序中的所有變量。在許多用例中如果同樣的變量出現在許多界面中時，這就變得特別有意義，因此你可以在一個文檔里說的所有名字截止在30個字符以內，全部的地址截至在100個字符以內。然而，如它們對一個用例是特殊的，最好把它們加到那個用例的特殊需求中。

　　表 3顯示了在示例項目的基礎數據流程中為變量確定的選項：

　　步驟 3：將待測試選項合并到測試用例中

　　在前面的步驟，你確定了所有的選項。在此步驟，你需要在一系列的測試用例中使它們結合在一起。

　　圖 10用圖描述了測試的選項。每一個縱隊都有一個需要測試的變量，每一行是一個選項：R 是正常， E 是空, 然后是一個字符，50個字符，51個字符，等等。 "L" 代表非常大， "I" 代表非法的。

　　圖 10：每個步驟的待測試選項

　　后面有妨礙的選項把用戶從基本流程中拋離出去：它們表示在可選流程中描述的一些錯誤。因為你一般為第一個場景設計特殊用例，所以你可以移動它們(在一些其它的場景中測試它們)。 無論剩下了什么，你需要創建最小數量的覆蓋全部情形的測試用例。

　　通過連接圈創建測試用例，如圖 11所示。

　　圖 11：合并選項以創建測試用例

　　為了創建第一個測試用例，你可以選擇并連接任何選項。當你創建第二個測試用例時，跳出第一個用例沒有使用的選項。繼續增加測試用例直到全部圖的節點(如圖 11所示)被覆蓋。通常你需要從4到6測試用例去覆蓋全部需要測試的選項。然而，一些特殊的情形需要的更多。

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