需求：

接上一篇博客：送給佳佳同學的禮物：測試流程及并行測試介紹?， 本次主要介紹測試用例設計，雖然偏理論，但是測試還是需要理論支持的。 本博文的大部分內容來自@淘鄭萼?新人培訓ppt —— 測試用例設計，感謝鄭萼MM對新人的培養。

?

測試用例設計的幾個要點如下：

?

1. 原則： 通常應該避免依賴先前測試用例的輸出；

tips：如果測試用例直接相互依賴，那么當出現測試無法通過時，將很難去定位問題并查找原因。因此，最好是能夠保證一個測試用例針對一個功能測試點；

?

從這一原則還可以衍生出兩點注意點：

a. 測試數據準備：

如在測試數據庫查詢操作時，就必須先在數據庫中準備相應的被查詢數據（測試數據），我們需要保證每個測試用例所使用到的測試數據不會影響到其他測試用例的測試數據。這樣避免因為某個測試用例的誤操作而導致其他測試用例失敗。

b. 測試環境恢復：

在完成每個測試用例的測試過程之后，需要盡量將所用到的測試環境恢復到執行該測試用例之前的干凈的測試環境，這樣也是為了避免測試用例直接的相互干擾。

?

2. 目的：?

a. 促使測試人員深入了解需求；

tips：測試人員在設計測試用例的過程，也是對產品的深入了解的過程，而且我個人認為在執行測試用例的過程，也是對產品深入了解的過程，通過測試過程的交互，再采用探索式測試方式不斷的補充和完善測試用例，從而保證產品的質量。

b. 有利于測試的組織，避免盲目測試并且提高測試效率；

c. 確保功能不被遺漏；

tips：通過測試用例設計，產出下面第四點提出的MM圖或TestCase，從而使測試人員了解當前的測試進度、功能點覆蓋情況等信息，提高測試效率和功能覆蓋面。

d. 有利于測試的重復執行，減少對個人的依賴；

tips：完成測試用例設計及自動化測試代碼編寫之后，能夠使本次測試過程及以后的新版本回歸過程不依賴于特點的測試人員。同樣的每次的測試項目結束之后如果能夠有一些知識沉淀，那么也會更有效的提高新測試人員接受測試項目的效率，節約人員流動成本；

e. 測試過程可量化 —— 特別是在高風險的測試中，能夠證明確實執行了測試計劃；

f. 使軟件測試的實施重點突出、目的明確；

tips：在測試用例設計結束之后，可以進行測試用例評審，在評審過程中可以突出重點、明確目的，并且也便于監控整個測試過程；

?

3. 依據：所有能夠得到的項目文檔或已經達成一致的討論（tips：盡量將討論結果落實成文檔并郵件發出確認）

a. “需求說明”及相關文檔；

b. 相關的設計說明（概要設計，詳細設計等）

c. ?與開發或產品討論并達成共識的郵件或口頭結論（tips：盡量落實成文本，便于以后復查）

d. 已經基本成型的demo

tips：由于互聯網企業的特點是敏捷開發，很少積累下詳細的文檔材料，因此在測試實施過程中經常會發現與最初討論/文檔不符或者沒有記錄的地方，這時候需要積極與相關人員（開發、產品經理）進行溝通確認，并將最終結果完善到相應的文檔中。

?

4. 產出： 形式包括但不限于以下幾種：

a. 功能需求分界MM圖： Free Mind， Xmind；
b. 系統交互圖： Rose；

c. 數據流程圖： Rose；

d. 分析完成的用例思路集合；

e. 接口設計的具體測試用例（接口）

f. ?性能測試的具體測試方案，包括測試場景和模型（性能）

?

幾種形式的優缺點比較：

a. Checklist

-優點： 驗證點較明確，維護成本較低，適用于小需求，且不需要長期維護的項目；

-缺點： 由于沒有執行步驟，所以要求項目組成員對項目比較熟悉，不易管理和傳承；

b. MM圖

-優點： 書寫快速，條理清晰，與checklist相比，模塊之間的層次關系明確；

-缺點： 依然是沒有執行步驟，不過可以采用層次關系來表明執行步驟，但這又會導致層次過于復雜

c. TestCase:

-優點： 測試步驟比較詳細，有明確的優先等級和嚴重級別，能夠很好的指導測試執行人員進行測試，適用于長期維護的大項目；

-缺點： 維護成本較高，TestCase管理難度較大；

?

tips：我個人更喜歡用MM圖來進行用例設計，因為MM圖層次分明，條理清晰，在進行用例評審和自動化測試代碼編寫的時候，能夠有效的將設計思路表達出來，并且如果需要可以很方便的進行修改和補充。在完成所有測試工作并代碼入庫的時候，我會將MM圖轉換成TestCase保存在測試平臺（BugFree[一淘出品]、kelude[淘寶出品]、QC）上；

?

5. 測試用例設計方法：

a. 等價類

定義： 把所有可能的輸入數據，即程序的輸入域劃分成若干部分（子集），然后從每一個子集中選取少數具有代表性的數據作為測試用例；

tips：如果能夠在閱讀產品源碼的基礎上選取代表性數據的話，那將更容易測出問題；

?

原則：

1. 在輸入條件規定了取值范圍或值的個數的情況下，可確立一個有效等價類和兩個無效等價類；

tips：如果有效范圍是{1-10}， 那么無效等價類可以是{1-10范圍之外的數字}, {所有非數字字符}；

2. 在輸入條件規定了輸入值的集合或規定了“必須如何”的條件的情況下，可確立一個有效等價類和一個無效等價類；

tips：有效等價類可以是{輸入A， 才得到B}， 無效等價類可以是{輸入C， 得到其他一些無效值}；

3. 在輸入條件是一個布爾量的情況下，可確立一個有效等價類和一個無效等價類；

tips：即布爾量為true 和 false兩種；

4. 在規定了輸入數據的一組值（假定n個），并且程序要對每個輸入值分別處理的情況下，可確立n個有效等價類和一個無效等價類；

tips：如輸入數據為（1、2） 那么有效等價類{輸入1，返回A}和{輸入2，返回B}， 無效等價類{輸入非1和2的值，返回其他結果}；

5. 在規定了輸入數據必須遵守的規則的情況下，可確立一個有效等價類和若干個無效等價類（從不同角度違反規則）；

tips：如輸入必須為正整數，那么有效等價類{所有正整數}，無效等價類{所有負整數}、{所有小數}、{所有非數字字符，如特殊符號、字母等}等等；

6. 在確知已劃分的等價類中，各元素在程序處理中的方式不同的情況下，則應再將該等價類進一步劃分為更小的等價類；

tips: 如輸入必須為正整數且等于10的倍數時加1，那么有效等價類{所有正整數}可以劃分為{所有非10倍數的正整數}、{所有10倍數的正整數}；

?

轉換成測試用例：

1. 為每個等價類規定一個唯一的編號；

2. 設計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋的有效等價類。重復這一步，最后使得所有有效等價類均被測試用例所覆蓋；

3. 設計一個新的測試用例，使其只覆蓋一個無效等價類。重復這一步使所有無效等價類均被覆蓋；

?

tips： 轉換的思路是：有效等價類，可以用盡量少的用例來覆蓋他們，而無效等價類，要盡量做到一個Case只覆蓋一個無效等價類；

?

b. 邊界值

定義： 是對輸入或輸出的邊界值進行測試的一種黑盒測試，同時也是對等價類的一種補充；

原則：

1. 如果輸入條件規定了值的范圍，則應取剛達到這個范圍的邊界的值，以及剛剛超越這個范圍邊界的值為為測試輸入數據；

2. 如果輸入條件規定了值的個數，則用最大個數，最小個數，比最小個數少1，比最大個數多1的數作為測試數據；

tips：如輸入范圍或個數為（1-10的正整數），那么取值可以是1、10、0、11；

3. 將a和b的原則同樣應用到輸出上，即設計測試用例使輸出值達到邊界及其左右的值；

tips：對輸出的范圍驗證與輸入同樣重要，很多同學在測試的時候會忽略對輸出范圍的驗證，導致輸出結果越界的情況時有發生；

4. 如果程序的規格說明給出的輸入域或輸出域是有序集合，則應選取集合的第一個元素和最后一個元素作為測試用例；

5. 如果程序中使用了一個內部數據結構，則應當選擇這個內部數據結構的邊界上的值作為測試用例；

tips：這種測試也成為灰盒測試；

?

邊界值與等價類配合的方式：

1. 劃分等價類；

2. 確定所有的邊界值；

3. 利用邊界值作為測試數據[min-1;min;min+1;max-1;max;max+1]；

4. 內部邊界值的分析（數值的邊界值；字符的邊界值）；

5. 根據分析出的測試數據設計測試用例；

?

c. 場景

定義：從用戶角度分析SUT所有被事件觸發的流程并形成相應的用例場景，并描述不同的事件流(基本流和備選流)

原則：?

1. 制定User Case(相關的數據和覆蓋這個case所流經的路徑)

2. 通過UC來確定需要測試的場景(一個復雜的場景包含對多個user case的組合，通過控制場景或子場景的執行順序、條件控制、并行或反復處理來組合而成的)

3. 場景需要定義actors, roles, business processes, events以及the goal(s) of the actor(s)

4. 確定每個場景的基本流和備選流

5. 根據基本流和備選流的組合和正反面來確定場景用例

6. 對于所有場景用例進行復審和驗證其準確和適度，并取消多余或等效的場景用例

7. 對于場景用例設定測試數據形成真正的測試用例

?

d. 因果圖

定義：?因果分析是一種利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，它適合于檢查程序輸入條件的各種組合情況

?

原則：

1. 分析需求規格說明的描述中，哪些是原因，哪些是結果

2. 分析需求規格說明的描述中語義的內容，并將其表示成連接各個原因與各個結果的因果圖

3. 在因果圖上使用若干個特殊的符號標明特定的約束條件

4. 把因果圖轉換成判定表

5. 把判定表中每一列表示的情況寫成測試用例

?

6. 測試用例屬性及格式：

a. 屬性：

1. 優先級： 需要為測試用例區分優先級，以保證重點和緊急功能點能夠得到充分測試；

2. 自動化程度： 分為已完成自動、待完成自動化和不需要自動化；

3. 執行結果： 分為Pass、Fail、Block、Not Complete；

4. 編寫者及測試執行者；

5. 編寫時間及與其相對應的項目/產品版本號；

?

b. 格式：

1. 用例編號及標題： 便于用例管理和查找；

2. 前置條件： 每個測試用例執行前所需要準備的前置條件，如測試環境，測試數據準備等；

3. 執行步驟： 每個測試用例所需要的執行過程描述；

4. 預期結果： 在上述前置條件及執行步驟完成結束之后，所期望看到的測試結果；

5. 備注： 對測試環境進行描述，如數據庫信息、瀏覽器信息等；

?

OK， 送給佳佳同學的禮物：測試用例設計介紹完畢，歡迎拍磚。轉發請備注轉自：100continue.iteye.com。 謝謝

總結

以上是生活随笔為你收集整理的送给佳佳同学的礼物：测试用例设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。