測試用例的基本要素
概念：
測試用例（Test Case）是爲了實施測試而向被測試的系統提供的一組集合，這組集合包含：測試環境、操作步驟、測試數據、預期結果等要素。
評價測試用例的標準：
- 表達清楚，無二義性。
- 可操作性強。
- 輸入與輸出明確。
- 一條用例只有一個預期結果。
- 可維護性好。
- 對需求的覆蓋率高。
- 暴露程序Bug的能力強。
測試用例的好處
- 是測試執行者的依據
- 使得工作可重複，是自動化測試的基礎
- 評估需求覆蓋率
- 用例的複用積累
- 測試的方法思路以供後續借鑑
使用中帶來困擾
測試用例的設計是費時費力的工作，還存在如下問題：
- 不知道是否較全面的測試了所有功能
- 測試的覆蓋率無法衡量
- 對新版本的重複測試很難實施
- 存在大量冗餘測試，影響測試效率
測試用例的設計方法
總體設計方法
基於需求的設計
RBT( Requirements-Based Testing)是基於需求的測試方法，會使測試更加有效，因爲它使測試專注於質量問題產生的根源，即需求。
基於需求的測試是一種最根本的軟件測試，重點關注以下兩大關鍵問題。
- 驗證需求是否正確、完整、無二義性，並且邏輯一致。
- 從“黑盒”的角度，設計出充分並且必要的測試集，以保證設計和代碼都能完全符合需求。
具體的設計方法
等價類
思路：輸入的集合是無窮的, 不能全都覆蓋到。
依據需求將輸入（特殊情況下會考慮輸出）劃分爲若干個等價類，從等價類中選出一個測試用例，如果這個測試用例測試通過，則認爲所代表的等價類測試通過，這樣就可以用較少的測試用例達到儘量多的功能覆蓋，解決了不能窮舉測試的問題。
- 有效等價類
對於程序的規格說明書是合理的、有意義的輸入數據構成的集合，利用有效等價類驗證程序是否實現了規格說明中所規定的功能和性能 - 無效等價類
根據需求說明書，不滿足需求的集合。
等價類只考慮輸入域的分類，沒有考慮輸入域的組合，需要其他的設計方法和補充。
邊界值
邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作爲對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。
因果圖
因果圖是一種簡化了的邏輯圖，能直觀地表明程序輸入條件（原因）和輸出動作（結果）之間的相互關係。因果圖法適用於被測試程序具有多種輸入條件、程序的輸出又依賴於輸入條件的各種情況。
- 恆等
如果原因爲真，那麼結果必定爲真。 - 與
只有2個原因都爲真，那麼結果爲真。 - 或
2個原因中有一個爲真時，結果就爲真。 - 非
只有原因爲假，結果才爲真。
因果圖法設計測試用例的步驟：
- 分析所有可能的輸入和可能的輸出。
- 找出輸入與輸出之間的對應關係。
- 畫出因果圖。
- 把因果圖轉換成判定表。
- 把判定表對應到每一個測試用例。
因果法設計測試用例可以幫助測試人員理清輸入和輸出的關係，但是對於比較複雜的輸入和輸出，會耗費大量時間。
正交排列
正交法的目的是爲了減少用例數目。用盡量少的用例覆蓋輸入的兩兩組合。
正交試驗設計(Orthogonal experimentaldesign)是研究多因素多水平的一種設計方法，它是根據正交性，由試驗因素的全部水平組合中挑選出部分有代表性的點進行試驗，通過對這部分試驗結果的分析瞭解全面試驗的情況，找出最優的水平組合。
正交試驗設計是一種基於正交表的、高效率、快速、經濟的試驗。
- 因素（Factor）：在一項試驗中，凡欲考察的變量稱爲因素（變量）
- 水平（位級）（Level）：在試驗範圍內，因素被考察的值稱爲水平（變量的取值）
正交表的構成：
- 行數(Runs)：正交表中的行的個數，即試驗的次數,用N代表。
- 因素數(Factors)：正交表中列的個數，用C代表。
- 水平數(Levels)：任何單個因素能夠取得的值的最大個數。正交表中的包含的值爲從0到1
- “水平數-1”或從1到“水平數”，用T代表。
正交表的表示形式： L=行數(水平數*因素數) L=N(TC)
正交表性質：
- 每一列中各數字出現的次數都一樣多。
- 任何兩列所構成的各有序數對出現的次數都一樣多。
正交法設計測試用例的步驟：
- 有哪些因素（變量）
- 每個因素有哪幾個水平（變量的取值）
- 選擇一個合適的正交表
- 把變量的值映射到表中
- 把每一行的各因素水平的組合作爲一個測試用例
- 加上你認爲可疑且沒有在表中出現的用例組合
場景設計法
現在的軟件幾乎都是用事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。
該方法可以比較生動地描繪出事件觸發時的情景，有利於測試設計者設計測試用例，使測試用例更容易理解和執行。典型的應用是用業務流把各個孤立的功能點串起來，爲測試人員建立整體業務感覺，從而避免陷入功能細節忽視業務流程要點的錯誤傾向。
錯誤猜測法
基於經驗和直覺，找出程序中你認爲可能出現的錯誤，有針對性地設計測試用例。經驗可能來自於在對某項業務的測試較多，也可以來自於售後用戶的反饋意見，或者從故障管理庫中整理bug。梳理出產品以往哪些地方容易出現問題，問題越多的地方，潛在的bug也就越多。
測試用例的有效性
測試用例對應的功能已刪除，不可操作了
執行一條測試用例未發現BUG，實際該處有BUG
執行一條測試用例發現了BUG
執行一條測試用例未發現BUG，實際該處BUG已修改
測試用例的粒度和評價
測試用例的粒度
粒度：指測試用例編寫的詳細程度。
測試用例的設計的本質應該是在設計的過程中理解需求，檢驗需求，並把對軟件系統的測試方法的思路記錄下來，以便指導將來的測試。如何把握好粒度是測試用例設計的關鍵，也將影響測試用例設計的效率和效果。
- 測試用例寫得過於複雜或詳細，會帶來兩個問題：一效率問題，二是維護成本問題。測試用例設計得過於詳細，留給測試執行人員的思考空間就比較少，容易限制測試人員的思維。
- 測試用例寫得過於簡單，可能失去了測試用例的意義。
應該根據項目的實際情況、測試資源情況來決定設計出怎樣粒度的測試用例。主要考慮可以參考如產品的質量要求、項目對用例的要求、測試時間和資源是否充分。
測試用例的評價
測試用例的質量保證需要綜合使用各種手段和方法。
- 同行評審
最敏捷的應當屬臨時的同行評審。同行評審，尤其是臨時的同行評審，應該演變成類似結對編程一樣的方式。從而體現敏捷的“個體和交互比過程和工具更有價值”，要強調測試用例設計者之間的思想碰撞，通過討論、協作來完成測試用例的設計，原因很簡單，測試用例的目的是儘可能全面地覆蓋需求，而測試人員總會存在某方面的思維缺陷，一個人的思維總是存在侷限性。因此需要一起設計測試用例。 - 用戶檢查
應該儘量引入用戶參與到測試用例的設計中來，讓用戶參與評審，從而體現敏捷的“顧客的協作比合同談判更有價值”這一原則。 - 項目組評審
由測試負責人組織協調開展會議，用例編寫人對用例進行講解，參會人員有異議的當場提出。