從用例到測試用例的追蹤

本文闡述了一種從用例產生功能測試用例的正式方法，包括如何創建一個用例，產生所有場景，并且創建合理的測試用例，以及使用IBM Rational RequisitePro進行從用例到場景和測試用例的追蹤。

需求類型概覽

一個需求被定義成 "系統必須遵從的條件或能力"。

它可以是：

• 一個顧客或用戶所需要的，用以解決一個問題或達成一個目標的能力
• 一個必須被一個系統所滿足和擁有的，用以滿足一個合同、標準、規格、規則或其它正式強制文檔的能力
• 一個被涉眾所強加的限制

 

圖1顯示了帶有不同需求級次的需求金字塔

圖1. 需求金字塔

最高層的是涉眾需求。通常，一個項目包含五到十五個這樣的高層需求。較低層次的是特性，用例和補充規約。不同層次的需求有不同的細節。越低的層次需要越多的細節。例如，一個需求可以是："數據必須是持久的"。特性可以將此需求精化為："系統應當使用一個關系數據庫"。在補充規約層次，需求會更加詳細："系統應當使用Oracle 9i數據庫"。層次越低，需要越詳細的需求。

需求之間的追蹤關系

追蹤是這樣一種技術，在系統中它能為不同層次的需求之間提供關聯。這個技術幫助你確定任何需求的起源。圖 2 闡述了從高層次到低層次需求是如何被追蹤的。每一個需求通常映射到幾個特性，然后這幾個特性映射到用例和補充需求。

圖2. 追蹤需求金字塔

用例描述了功能性的需求，補充規約描述了非功能性的項目。另外，每個用例映射到許多場景。映射用例到場景，是一對多的關系。 場景映射到測試用例也是多對一的關系。另一方面，在需要與特性之間，是多對多的映射。

追蹤起到了幾個重要的作用：

• 驗證一個實現是否完成了所有的需求：用戶要求的每一件事情都被實現了
• 驗證應用程序只做了所要求的事情：不會去實現用戶從未要求的事情
• 有助于變更管理：當一些需求變更后，我們想知道哪些測試用例應當被重新執行以測試這個變化

一個追蹤項是一個項目元素，其需要從另一個元素進行追蹤。按照IBM Rational RequisitePro，它是一個需求類型的實例所表示的任何事情。在RequisitePro中一些需求類型的例子是涉眾需求，特性，用例，參與者，和術語條款。

在RequisitePro中，有一種按照特定視圖展示追蹤性的便利方法。圖3 顯示了將特性映射到用例的一個例子。

圖3. 在RequisitePro中的追蹤關系

這里有一些問題，這些箭頭應指向哪里：是從更低的層次到更高的層次，還是從更高的層次到更低的層次。甚至在RequisitePro中的兩個例子使用了兩個不同的方法。答案是沒有關系，只要你在項目中始終如一地使用它們就可以了。

參與者和用例

參與者是與系統交互的某人或某事。用例是根據操作順序的一個系統描述。它為參與者產生了一個看的見的結果或數據值。以下是用例的一些特征：

• 被參與者初始化
• 模擬參與者和系統之間的交互
• 描述操作的序列
• 獲取功能需求
• 為參與者提供數據值
• 表示完整的和有意義的事件流

用例的目的是促使開發者、顧客和用戶之間對系統應做些什么達成一致。用例在開發者和顧客之間達成了某種契約。它同時也是用例實現的基礎，它在程序設計中起到了非常重要的作用。另外，你可以從用例中產生序列圖，協作圖和類圖。此外，你可以從用例產生用戶文檔。用例可能還在計劃迭代的技術內容方面有幫助，并且使系統開發者更好地了解系統的意圖。最后，你可以使用它們作為測試例程的輸入。

用例圖顯示了參與者和用例之間的關系。在本文我們使用一個在線書店作為項目的一個例子。圖4 展示了這個項目的用例圖。

圖4. 用例圖

用例的通用格式是：

1. 簡要描述
2. 事件流
   • 基本流程
   • 可選流程 1
   • 可選流程 2
3. 特殊需求
4. 前提條件
5. 后置條件
6. 擴展點
7. 環境圖
8. 活動圖

基本流程包括最通常的一系列行為，此步驟發生在每件事正確運轉的時候?？蛇x流程表現了流程的變更，包括不很普遍的情況和錯誤條件。環境圖是用例圖的一部分，向參與者和其它用例顯示了特殊用例之間的關聯?；顒訄D是一個解釋用例的流程圖。環境圖和活動圖不是必須的，但是可以幫助你可視化用例和它在項目中的位置。

在我們的在線書店項目中，用例的基本流程的安置順序也許像這樣：

1. B1 用戶在瀏覽器輸入網站的地址。

   系統顯示登陸界面。

2. B2 用戶輸入電子郵件地址和密碼。

   系統確認正確的登陸，顯示主頁，并且提示輸入搜索字符串

3. B3 用戶輸入搜索字符串—書名的一部分。

   系統返回與搜索標準匹配的全部書籍。

4. B4 用戶選擇一本書。

   系統顯示這本書的詳細信息。

5. B5 用戶把這本書放在購物車中。

   購物車中的貨物顯示給用戶

6. B6 用戶選擇"進入到結帳" 選項。

   系統索要送貨地址。

7. B7 用戶確認送貨地址。

   系統顯示送貨選項。

8. B8 用戶選擇送貨選項。

   系統詢問使用哪種信用卡。

9. B9 用戶確認儲存在系統中的信用卡。

   系統請求最終確認此次訂購。

10. B10 用戶訂購。

    系統返回確認數量。

除了基本流程以外，還有許多可選流程。例如，第一個可選流程描述了當用戶是一個新的用戶時所發生的事情(不是在線書店的已注冊用戶)。在基本流程中，用戶經常擁有一個用戶ID和密碼。相反，可選流程 1 描述了當第一次用用戶需要注冊并提供顧客數據時的情況?？蛇x流程的另一個例子是無效的密碼。用戶輸入了錯誤的密碼，系統顯示錯誤信息。

表 1 顯示了"安置順序"用例中的可選流程：

表 1: 可選流程
A1	未注冊用戶
A2	無效密碼
A3	沒有找到匹配搜索標準的書
A4	下架書籍
A5	在購物車中放入一本書后繼續購物
A6	輸入新的地址
A7	輸入新的信用卡
A8	取消訂單

下列約定用于為事件流命名：

基本流程：B

可選流程：A1，A2， A3，...

在基本流程中的步驟：B1，B2， B3， ...

在可選流程1中的步驟：A1.1， A1.2， A1.3， ...

在可選流程2中的步驟： A2.1， A2.2， A2.3， ...

為得到可選流程，使用活動圖 5。圖 5顯示了描述用例的活動圖。

圖5. 活動圖

基本流程是一條向下的直線，然而可選流程可以是向前或向后的循環線。

如何從用例創建測試用例

在創建一個測試用例之前，你需要為所給用例確定全部的場景。一個場景是用例的一個實例。它描述了一個貫穿事件流的特殊路徑。圖 6是一個假設的圖表，它描繪了一個擁有基本流程B和可選流程A1， A2， A3， A4的用例。為了找到全部的場景，我們需要畫出貫穿于此圖的所有場景。

圖6. 在用例中找到場景
ios in a use case" src="http://www.anti-gravitydesign.com/uploads/2007/05/8_2007052418444329.jpg" width="564" twffan="done"/>

每一個可選流程都有一個場景，并且每個結合的可選流程都有一個場景。顯然，這里場景多于可選流程，因為一個場景用于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. 為用例的每個步驟確定變量
2. 為每個變量有效地確定不同的選項
3. 在測試用例中測試結合選項
4. 為變量賦值

 

以下部分描述了這些步驟的細節。

步驟1：為每個用例步驟確定變量

在所給場景的所有步驟中你需要確定全部輸入的變量。例如，在某些步驟中，如果用戶輸入了用戶ID和密碼，這就產生了兩個變量。一個變量是用戶ID，另一個變量是密碼。變量也可以被用戶選擇(例如，保存更改或取消)。

這里是書籍訂購例子的全部變量：

在步驟B2中，這里有兩個變量：電子郵件地址和密碼。它們全是字符串。在步驟B3中，搜索一本書，這個變量是一個搜索字符串，因此它也是字符串。 在步驟B4，我們需要從系統返回的目錄中選擇一本書。在步驟 B8中，我們需要選擇送貨方式。Amazon.com 提供了4個選擇。

步驟2：為每個變量有效地確定不同的選項

如果它們引發不同的系統行為，選項將是"明顯不同的"。例如，如果我們選擇大概6到10的字符長的用戶id，以下的輸入顯然是不同的 ：

• Alex ——因為太短，我們希望顯示一個錯誤的信息
• Alexandria ——因為它是一個有效的用戶id
• Alexandrena ——因為太長，我們期待系統可以阻止我們輸入如此長的id

 

然而，"Alexandria" 和 "JohnGordon" 卻不是明顯不同，因為它們都是有效的用戶id，可以使系統有相同的反應。

以下的指導方針描述了一些特殊的例子。

一個選項可以認為是非常不同的，如果：

1. 它引發了不同的程序流程 (通常是一個可選流程)

   例如

   • 輸入無效的密碼將會引發可選流程2

    

2. 它引發不同的錯誤信息

   例如

   • 如果電子郵件太長，信息就會是 "電子郵件應當在50個字符以內"
   • 如果電子郵件沒有包含 @ 符號，信息就會是："無效的電子郵件地址"

    

3. 它顯示了不同的用戶界面

   例如

   • 如果付費的方式是信用卡，在區域里顯示的是信用卡號輸入號碼，產品有效期和持卡人的姓名。

    

4. 它使得在下框中有不同的選則可以使用

   例如

   顧客注冊界面包含了 "國家和州/省"的下拉框。"州/省"的下拉框一般是基于國家的選擇：比如美國，它包含了全部的州，加拿大是全部的省，其他國家是缺省的。它創建了3個不同的選項：

   • 美國
   • 加拿大
   • 其它國家

    

5. 一些商業規則的輸入

   例如

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

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

    

6. 這里有一個邊緣情況

   例如

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

   • 5個字符的密碼
   • 6個字符的密碼

    

7. 改變某些事情對使用默認

   例如

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

   • 保持默認持卡人的姓名
   • 改變持卡人的姓名

    

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

   例如

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

   • 使用括號 (973) 123 4567
   • 使用破折號 973-123-4567
   • 數字間使用空格 973 123 4567

    

9. 不同的國家有不同的規則

   例如

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

 

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

• 常規的以及從應用觀點上是合理的數字
• 0
• 負數
• 帶兩位小數的數字
• 能輸入的最大數字(99999999999999 - 輸入最多的9)

 

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

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

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

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

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

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

步驟	變量	測試選項
B1	網站	實際URL
B2	電子郵件	正常	空白	最少允許字符數(1 字符)	最多允許字符數(50 字符)	比允許最多字符多一個字符(51 字符)	非常長 (257 字符)	無效 (缺少 @ 字符)
B2	密碼	正常	空白	太短(5 字符)	最少允許字符數(6 字符)	最多允許字符數 (10 字符)	比允許最多字符數多一個字符(11 字符)	非常長 (257 字符)
B3	搜索字符串	正常	空白	最少允許字符數 (1 字符)	最多允許字符數 (300 字符)	比允許最多字符數多一個字符 (301 字符)
B4	選擇	第一次選擇	最后一次選擇
B5	行為選擇	加入購物車
B6	行為選擇	進行結帳
B7	送貨地址	確認地址
B8	發貨方式	5 天	3 天	2 天	頭天晚上
B9	支付方式	確認信用卡
B10	行為選擇	下訂單

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

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

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

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

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

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

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

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

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

步驟號	變量或者選擇	TC1	TC2	TC3	TC4
B1	網站	實際 URL	實際 URL	實際 URL	實際 URL
B2	電子郵件	正常	最少允許的字符數(1 字符)	最多允許的字符數 (50 字符)	正常
B2	密碼	正常	最少允許的字符數 (6 字符)	最多允許的字符數 (10 )	最少允許的字符數 (6 字符)
B3	搜索字符串	正常	最少允許的字符數 (1 字符)	最多允許的字符數(300 字符)	正常
B4	選擇	第一次選擇	最后一次選擇	第一次選擇	最后一次選擇
B5	行為選擇	添加到購物車中	添加到購物車中	添加到購物車中	添加到購物車中
B6	行為選擇	進行結帳	進行結帳	進行結帳	進行結帳
B7	送貨地址	確認地址信息	確認地址信息	確認地址信息	確認地址信息
B8	送貨方式	5 天	3 天	2 天	頭天晚上
B9	支付方式	確認信用卡信息	確認信用卡信息	確認信用卡信息	確認信用卡信息
B10	行為選擇	下訂單	下訂單	下訂單	下訂單

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

步驟 4：為變量賦值

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

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

表 5：最終的測試用例

步驟號	變量或選擇	值	預期結果	實際結果	通過/失敗	注解
B1	網站	www.amazon.com	登陸界面
B2	電子郵件地址	jsmith@hotmail.com
B2	密碼	Johnsm	主界面
B3	搜索字符串	“Rational”	書本列表
B4	書本選擇	第一次選擇	書本詳情
B5	行為選擇	添加到購物車中	購物車的內容
B6	行為選擇	進行結帳	地址提示
B7	送貨地址	確認地址信息	送貨提示
B8	購物方式	5 天	支付提示
B9	支付方法	確認信用卡信息	確認提示
B10	行為選擇	下訂單	訂單號

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.anti-gravitydesign.com