1.什麼是測試用例？
測試用列(test case)是為了實施測試而向被測試的系統提供的一組集合，這組集合包含：測試環境、操作步驟、測試資料、預期結果等要素。
2.測試用例的要素
測試用例的標題、測試思路、預設條件、步驟、預期輸出
乙個好的測試用例是乙個不熟悉業務的人也能依據用例來很快的進行測試。
評價測試用例的標準：
·用例表達清楚，無二義性
·用例可操作性強
·永獵的輸入與輸出明確，一條用例只有乙個預期結果
·用例的可維護性好
·用例對需求的覆蓋率高
·暴露程式bug的能力強
3.測試用例的好處
·它是測試執行者的依據
·它使得工作可重複，自動化測試的基礎
·評估需求覆蓋率
·用例的復用
·積累測試的方法思路以供後續借鑑
4.測試用例的設計方法
4.1 總體的設計方法
基於需求的設計
基於需求的測試方法rbt(requirements-based testing)是基於需求的測試方法，會使得測試更加有效，它使測試專注於質量問題產生的根源，即需求。
基於需求的測試是一種最根本的軟體測試，它關注以下問題：
·驗證需求是否正確、完整、無二義性，並且邏輯一致
·要從「黑盒」的角度，設計出充分並且必要的測試集，以保證設計和**都能完全符合要求
4.2具體的設計方法
<1>等價類：
依據需求將輸入(特殊情況下會考慮輸出)劃分為若干個等價類，從等價類找那個選出乙個測試用例，如果這個測試用例測試通過，則認為所代表的等價類測試通過，這樣就可以用較少的測試用例達到盡量多的功能覆蓋，解決了不能窮舉測試的問題。
·有效等價類
對於程式的規格說明書是合理的、有意義的輸入資料構成的集合，利用有效等價類驗證程式是否實現了規格說明書中所規定的功能和效能
·無效等價類
根據需求說明書，不滿足需求的集合
等價類只考慮輸入域的分類，沒有考慮輸入域的組合，需要其他的設計方法和補充。
<2>邊界值：
邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分的補充，這種情況下，其測試用例來自等價類的邊界。
例：針對6-15位長度設計測試用例。
有效等價類：6 < x < 15
無效等價類：x < 6 || x > 15
邊界值：5，6，15，16
完整的測試用例：5，6，10，15，16
在有效等價類中任選乙個值代表這個等價類。
為什麼6和15不能代表等價類？
邊界值法要和等價類法結合使用，是互補的，邊界值是等價類的一種補充。有效等價類的選取時，不選邊界值，邊界值單獨寫。
為什麼不用3和4作為邊界值？
3和4可以代表小於邊界的類，但不能代表等於邊界的類，5可以代表等於邊界的類，也可以代表小於邊界的類
資料是有區間的：取邊界值的時候要注意是否包含邊界值，注意開區間和閉區間
[1,50] 邊界值：0,1,50，51
(1,50) 邊界值 ：1,2,49,50
[1,50) 邊界值：0,1,49,50
<3>因果圖
因果圖是一種簡化了的邏輯圖，能直觀地表明程式輸入條件(原因)和輸出動作(結果)之間的相互關係。因果圖法是借助圖形來設計測試用例的一種系統方法，特別適用於被測試程式具有多種輸入條件、程式的輸出又依賴於輸入條件的各種情況。
·恒等
恒等：如果原因為真，那麼結果必定為真
·與
與：只有兩個原因都為真，結果才為真
·或
2個原因中有乙個為真，結果就為真
·非
只有原因為假，結果才為真
因果圖設計測試用例的步驟：
·分析所有可能的輸入和輸出
·找出輸入與輸出之間的對應關係
·畫出因果圖
·把因果圖轉換成判定表
·把判定對應到每乙個測試用例
因果法設計測試用例可以幫助測試人員理清輸入和輸出的關係，但對於比較複雜的輸入和輸出，會耗費大量的時間
<4>正交排列
目的：正交法是為了減少用例數目，ongoing盡量少的用例覆蓋輸入的兩兩組合。
定義：正交試驗設計是研究多因素多水平的一種設計方法，它是根據正交性，由試驗因素的全部水平組合中挑選出部分有代表性的點進行試驗，通過對這部分試驗結果的分析了解全面試驗的情況，找出最優的水平組合，正交試驗設計是一種基於正交表的、高效率、快速、經濟的是試驗。
正交表中的有關概念：
因素(factor)：在一項試驗中，凡欲考察的變數稱為因素(變數)
水平(位級)(level)：在實驗範圍內，因素被考察的值稱為水平(變數的取值)
行數(runs)：正交表中的行的個數，及試驗的次數，用n表示
因素數(factors)：正交表中列的個數，用c代表
水平數(levels)：任何單個因素能夠取得的值的最大個數。
正交表中包含的值為從0到「水平數-1」，或從1到「水平數」，用t代表
正交表的表示形式：
l=行數(水平數*因素數)
l=n(tc)
l 6(25)：代表有6次試驗，5代表有5列，有5個考察的因素，2代表每個因素有2種水平，也就是2種取值
正交表的兩條性質：
·每一列中各數字出現的次數都一樣多
·任何兩列所構成的各有序數對出現的次數都一樣多
<5>場景法
現在的軟體幾乎都是用事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。該方法可以比較生動地描繪出事件觸發時的場景，有利於測試設計者設計測試用例，使測試用例更容易理解和執行。
用業務流把各個孤立的功能點串起來，為測試人員建立整體業務感覺，從而避免陷入功能細節忽視業務流程要點的錯誤傾向。
<6>錯誤猜想法
錯誤猜測法是經驗豐富的測試人員喜歡使用的一種測試方法。基於經驗和直覺，找出程式中你認為可能出現的錯誤，有針對性的設計測試用例。
5.測試用例的有效性
可以正常的發現有bug的程式，或正常的驗證程式是正確的。
6.測試用例的粒度和評價
測試用例的粒度：是指測試用例編寫的詳細程度。
測試用例可以寫得和簡單，也可以寫的很複雜。最簡單的測試用例是測試的綱要，僅僅指出要測試的內容，複雜的測試用例會指定輸入的每項數，期待的結果及檢驗的方法，具體到介面元素的操作步驟，指定測試的方法和工具等。
大多數的測試團隊編寫的測試用例的粒度介於兩者之間，如何把握好粒度是測試用例設計的關鍵，也將影響測試用例設計的效率和效果，應該根據專案的時機情況、測試資源情況來決定設計出怎樣粒度的測試用例。
可以考慮以下的內容：
·產品的質量要求
·專案對用例的要求
·測試時間和資源是否充分
測試用例的評價：
評審分為正式和非正式評審。
·同行評審
·使用者評審
·專案組的評審
總結：
編寫測試用例的時候，要分為正向、逆向、考慮邊界條件、容錯、效能、安全、相容等方面考慮。
怎麼設計完整的測試用例
測試用例的設計一般從分析需求設計說明書開始，了解開發人員設計這個專案的思路 設計的要求 實現的功能等 最好有use case，這樣看起來更清晰 軟體測試的w模型，就要求測試與開發同步，在開發設計需求設計說明書的時候就開始測試流程，一般情況下，討論需求設計的時候需要測試主管或者組員的參與，了解這個專案...
測試用例編號 分享讓測試用例更完整的方法
首先，我們需要知道測試用例是什麼，測試用例 testcase 是為了某個特殊目標而變質的一組測試輸入 執行條件以及預期結果，以便測試某個程式路徑或核實是否滿足某個特定需求。測試用例的編寫是要結合需求文件，結合各種測試方法來編寫。那麼常用的測試方法有哪些呢？1.等價類劃分法 等價類劃分是把所有可能的輸...
再談測試用例的詳細程度
在寫測試部落格之初寫過一篇名為 關於測試用例的詳細程度 的文章，現在看來有些雜亂，也缺乏一定的嚴謹性和條理性，那篇文章更多側重的是有感而發。今天和所帶專案的一位組員 測試用例的時候，關於測試用例的詳細程度發生了明顯的分歧。靜下心來，還是想好好整理一下思路。對於軟體測試用例 只涵蓋功能測試，不包括效能...