如何從用例建立測試用例
在建立乙個測試用例之前，你需要為所給用例確定全部的場景。乙個場景是用例的乙個例項。它描述了乙個貫穿事件流的特殊路徑。圖 6是乙個假設的圖表，它描繪了乙個擁有基本流程b和可選流程a1， a2， a3， a4的用例。為了找到全部的場景，我們需要畫出貫穿於此圖的所有場景。
圖6. 在用例中找到場景
每乙個可選流程都有乙個場景，並且每個結合的可選流程都有乙個場景。顯然，這裡場景多於可選流程，因為乙個場景用於a1,另乙個場景用於a2，還有乙個場景用於這兩個的結合。
描述場景最簡單的方法是提供一系列的可選流程，例如，做兩遍流程a2，然後做一遍流程a6：
sc16：a2，a2，a6。
另一種描述場景的方法是列出它的所有步驟，但是這種方法既困難又未必詳細。
如果你陷了無限迴圈(向後迴圈)，這時該怎麼辦？理論上它將產生無限的場景。圖 7顯示了乙個無限迴圈。
圖7. 無限迴圈。
最合理的方法是做一遍基本流程，一遍迴圈流程，然後再做一遍迴圈流程。如果程式能為這兩個迴圈都工作的話，你能假設它能為所有的迴圈工作。
書籍訂閱的例子中包含了乙個基本流程和8個可選流程。它們中的4個向前走，另外4個向後走。如果你想描述全部可能的用例結合，你將有超過4000個場景 (這裡有8個可選流程，我們想讓其中4個做兩次，因為他們向後迴圈，所以是2的(8+4)次冪,，等於4096。很明顯，我們不需要把他們全部做完。
選擇能代表這四千個場景的乙個合理子集。通常，明智的做法是選擇乙個基礎流程，乙個覆蓋了每乙個可選流程的場景，以及一些合理的可選流程的結合。使用表 1的例子，做乙個包含流程a1和a7的場景也許沒有什麼意義，因為它們在圖示上分隔太遠以至於不能互相影響。但是，做a1和a2是有意義的，因為他們互相緊埃，之間互相影響。
表 2 **了選擇的場景：乙個代表基本流程，8個代表每乙個可選流程，6個反射可一些流程的結合(特別是那些擁有兩個距離很近的向後迴圈)。
以下15個場景值得測試：
表2. 值得測試的場景
表2：獲取選擇的場景
場景 1 基礎流程
場景 9 a8
場景 2 a1
changjing 10 a1，a2
場景 3 a2
場景 11 a3，a4
場景 4 a3
場景 12 a4，a5
場景 5 a4
場景 13 a3，a5
場景 6 a5
場景 14 a6， a7
場景 7 a6
場景 15 a7，a8
場景 8 a7
在requisitepro中如何建立乙個場景
在requisitepro中場景不是乙個標準的需求型別，所以你需要增加它成為乙個新的需求種類。為了完成它，去project properties，選擇requirement types 標籤，然後點選 add。接下來，填充到適當的區域 (如圖 8所示)，然後點選ok。
圖8. 增加乙個需求型別場景
建立了這個需求型別之後，我們應當輸入全部的場景並設定從用例到這些場景的追蹤，如圖 9所示。
圖9. 從用例到場景的追蹤
在requisitepro中，你可以用用例的名字和一系列可選流程的名字為場景命名(例如：uc1， a6， a7)。
既然你有了所有的場景，你就需要獲得測試用例。這裡需要完成4個步驟：
為用例的每個步驟確定變數
為每個變數有效地確定不同的選項
在測試用例中測試結合選項
為變數賦值
以下部分描述了這些步驟的細節。
步驟1：為每個用例步驟確定變數
在所給場景的所有步驟中你需要確定全部輸入的變數。例如，在某些步驟中，如果使用者輸入了使用者id和密碼，這就產生了兩個變數。乙個變數是使用者id，另乙個變數是密碼。變數也可以被使用者選擇(例如，儲存更改或取消)。
這裡是書籍訂購例子的全部變數：
在步驟b2中，這裡有兩個變數：電子郵件位址和密碼。它們全是字串。在步驟b3中，搜尋一本書，這個變數是乙個搜尋字串，因此它也是字串。 在步驟b4，我們需要從系統返回的目錄中選擇一本書。在步驟 b8中，我們需要選擇送貨方式。amazon.com 提供了4個選擇。
步驟2：為每個變數有效地確定不同的選項
如果它們引發不同的系統行為，選項將是"明顯不同的"。例如，如果我們選擇大概6到10的字元長的使用者id，以下的輸入顯然是不同的 ：
alex ——因為太短，我們希望顯示乙個錯誤的資訊
alexandria ——因為它是乙個有效的使用者id
alexandrena ——因為太長，我們期待系統可以阻止我們輸入如此長的id
然而，"alexandria" 和 "johngordon" 卻不是明顯不同，因為它們都是有效的使用者id，可以使系統有相同的反應。
以下的指導方針描述了一些特殊的例子。
乙個選項可以認為是非常不同的，如果：
它引發了不同的程式流程 (通常是乙個可選流程)
例如輸入無效的密碼將會引發可選流程2
它引發不同的錯誤資訊
例如如果電子郵件太長，資訊就會是 "電子郵件應當在50個字元以內"
它顯示了不同的使用者介面
例如如果付費的方式是信用卡，在區域裡顯示的是信用卡號輸入號碼，產品有效期和持卡人的姓名。
它使得在下框中有不同的選則可以使用
例如顧客註冊介面包含了 "國家和州/省"的下拉框。"州/省"的下拉框一般是基於國家的選擇：比如美國，它包含了全部的州，加拿大是全部的省，其他國家是預設的。它建立了3個不同的選項：
美國加拿大
其它國家
一些商業規則的輸入
例如假設這裡已有一項規則 "如果實下午6點以後下訂單是，使用者選擇頭天晚上送貨，將會通知這本書將會在後天到達。"，我們有兩個：獨立的選擇
頭天晚上發貨，在下午6點之前下訂單
頭天晚上發貨，在下午6點以後下訂單
這裡有乙個邊緣情況
例如因為密碼應當包含至少6個字元，我們因該測試：
5個字元的密碼
6個字元的密碼
改變某些事情對使用預設
例如在信用卡支付介面，持卡人的名字通常是訂貨人的姓名。這就產生了2個獨立的選項：
保持預設持卡人的姓名
改變持卡人的姓名
沒有明確定義輸入格式，不同的使用者有不同的理解
例如不同的人有不同的書寫**號碼的方法：
使用括號 (973) 123 4567
使用破折號 973-123-4567
數字間使用空格 973 123 4567
不同的國家有不同的規則
002測試用例 2
1.什麼時候使用判定表 在乙個程式中，如果輸入輸出比較多，輸入之間和輸出之間相互制約的條件比較多，在這種情況下應用決策表很合適，它可以很清楚地表達它們之間的各種複雜關係。2.決策表法簡述 決策表是把作為條件的所有輸入的各種組合值以及對應輸出值都羅列出來而形成的 它能夠將複雜的問題按照各種可能的情況全...
測試用例與測試用例的設計方法
測試用例 test case 是為某個特殊目標而編制的一組測試輸入 執行條件以及預期結果，以便測試某個程式路徑或核實是否滿足某個特定需求。目前黑盒測試的測試用例設計方法有5種 等價類劃分 邊界值分析 錯誤推測法 目前黑盒測試 的測試用例 設計方法有5種 等價類劃分 邊界值分析 錯誤推測法 因果圖功能...
黑盒測試用例設計 用例維護（十二）
六 用例維護 經驗用例 當進入執行測試階段時，我們總是能發現一些缺陷的出現是出乎我們意料的，或者說是已有的測試需求和測試用例未能覆蓋的。那麼，對於這部分缺陷，也應當在分析整理後新增到測試需求中，並設計相應的測試用例，以便於下乙個版本迭代時進行參考。其實，對於乙個長期發展的團隊或產品，它的所有東西都是...