前面有曰：測試結果的準確性取決於測試用例的設計，故測試用例設計顯得尤爲重要。今天就好好梳理下，測試用例的相關內容.
重要性：Test Case貫穿整個測試執行過程，分兩大類：數值計算類和數據處理類
概述：編寫一組前提條件，輸入，執行條件，預期結果的組合方案。完成對某個特定需求或目標的測試，體現測試方案，方法，技術和策略的文檔。
1：什麼是測試用例，爲什麼要編寫？
測試用例就是編寫一組條件，輸入，執行條件，預期結果的並完成對特定需求或目標的測試，體現測試方案，方法，技術和策略的文檔。
由於測試用例是把整個測試的執行過程分解爲若干測試步驟，並仔細的檢查，驗證所編寫程序的正確性。它是軟件測試的核心部件，是測試環節執行的基本依據。
2：主要包含哪些內容？需要哪些資料？
通常如下內容：
測試用例的編號
測試日期
測試設計人員和測試人員
測試用例的優先級
測試標題
測試目標的描述（描述它需要實現的功能，包括性能等）
測試環境的描述（eg：硬件條件，軟件條件，網絡條件等）
輸入數據/動作的編寫（具體的執行過程）
測試的步驟（測試數據具體的執行過程）
測試的預期結果
測試審查人員
資料：
軟件需求說明書
軟件設計說明書
軟件測試需求說明書
成熟的測試用例（案例庫或財富庫）
3：有什麼作用？
投入小，易積累，回報大。如何在最短時間內以最少的人和資源投入發現軟件自身的缺陷，完成高效率測試並交出優質產品，是每個軟件公司探求的目標。因此每個項目都需要有一套完整，高效，優質的測試方案和測試方法，如果有了測試用例和測試用例庫則可以預防部分或減少潛在風險的發生，另外，若公司事先要求編寫測試用例和建立相關測試用例庫，測試人員發生流動時，對測試和項目進度的影響就會降到最低程度。
(1)實施測試指導的作用
在實施測試時一定要嚴格按照測試用例規定的用例項目和測試步驟逐一測試，並把測試中的各種情況記錄下來（最好用測試管理軟件）。以便書寫測試結果文檔（建議用測試管理軟件自動生成）
注意：測試用例是指導測試人員進行測試，通過用例發現更多的缺陷，而不是限定測試人員的思維。
(2)指導測試數據規劃的作用
測試用例數據一般都保存在數據庫中，只有進行測試用例設計時才從數據庫中調出一組或若干組測試用例的數據和標準測試結果。eg:報表等一些對數據的正確性要求較高的測試，要事先對測試的數據進行規劃，報表橫向，縱向多少內容。表輸出的格式要求等，進行規劃設計要做到事先有準備，測試操作時有案可查。除了這些標準數據，有時候還需要根據測試用例設計大量邊界值&越界值。
(3)指導腳本編寫的作用
軟件測試逐步走向人工測試和自動化測試並行發展。而自動化測試的核心就是測試腳本，自動化測試腳本編寫的依據就是測試用例。
(4)作爲評判基準的作用
測試工作完成後需要評估並進行定論，判斷軟件是否合格，然後出報告。以測試用例爲依據進行評審。總結如下：
測試中檢測到Bug數目
有效的Bug數目
無效的Bug數目
有爭議的Bug數目等
(5)作爲分析缺陷的基準的作用
測試目的就是發現Bug，測試結束後對得到的Bug進行復查，並對測試用例不斷的補充，完善，最終交付給用戶一個高質量的軟件產品。
4：測試用例的設計流程，白盒測試用例的設計和目的？
一般流程包括：制定測試計劃，編寫測試用例，執行測試，跟蹤測試缺陷，編寫測試報告。
需注意：用例應該從系統最高級向最低級逐一展開，每個用例單獨放在文檔中，所有功能都應該對應到用例中，需依據需求進行設計。最好是有豐富經驗的測試人員來設計。用例是多樣化，複雜中簡單化。
白盒測試設計方法：
邏輯覆蓋 ①判定覆蓋②條件覆蓋③判定/條件覆蓋和多條件覆蓋，邏輯值必須測試真，假兩個分支,需要在邊界值內和可操作範圍內至少循環一次，並檢查數據的內部結構，保證其有效的實現預定功能。
基本路徑測試 每個模塊中的獨立路徑至少被執行一次
5：黑盒測試用例的設計和目的？
設計-等價類劃分，邊界值分析，錯誤推測，因果圖
目的-檢查功能是否實現或遺漏，交互界面是否出錯，數據庫讀取，更新操作是否出錯，性能和特性是否得到 滿足。
6：綜合設計方法
實際操作設計測試用例一般“先黑後白”，即先採用黑盒技術設計測試用例，再用白盒技術做一些補充。
步驟：如果規格說明書中包含輸入條件，則用因果圖法設計；如果源碼中遇到輸入輸出邊界，則用邊界值分析法；同時爲輸入和輸出識別有效和無效等價類；使用錯誤推測法增加測試用例
5點原則和注意項：
①測試用例的正確性②測試用例的代表性③測試結果的可判定性和可重現性④足夠詳細，準確，清晰的步驟
⑤不能把測用例設計等同測試輸入數據的設計⑥務追求測試用例設計一步到位。7務將多個測試用例混在一個 用例中，最好不是無經驗的人員設計測試用例。
7：測試用例設計需關注7大要點
（1）單元測試用例需注意
在一組單元模塊設計完成後就開始的測試，單元測試以程序設計說明書爲指導。測試模塊範圍內的主要控制路徑，以揭露錯誤。重心放在代碼審查，測試用例，測試特性，用例描述，測試總結上。後期我會對單元測試進行補充說明。
被測單元模塊聲明初始狀態時，即此模塊單元測試的開始。
正面測試：依據設計說明書設計用例，用等價劃分設計用例
負面測試：錯誤猜測和邊界值分析
覆蓋率：分支覆蓋/條件覆蓋
（2）功能測試用例設計要點
首先考慮等價劃分類，邊界值共用，並用錯誤推測法補充；如果業務流程清晰可採用場景法設計；若程序有詳細的因果關係，應該一開始就採用因果圖法；如果是文件配置類型的測試，考慮功能圖法
（3）集成測試用例設計要點
按詳細設計說明書來設計，測試用例數據來源於UC，內部邏輯結構分析按單元測試進行。
（4）性能測試用例，需要不斷的迭代完善的過程，一個完整的性能測試通常包括：預期指標性能測試，獨立業務性能測試，組合業務性能測試，疲勞強度性能測試，大數據量性能測試，網絡性能測試，服務器（操作系統，Web服務器，數據庫服務器）性能測試，一些特殊的測試。
預期性能測試用例依據需求和設計文檔明確的性能要求進行設計
獨立業務性能從單個模塊功能和性能要求出發設計
組合業務性能從需求，設計文檔，現場調查，系統採集數據方面進行用例設計
疲勞強度性能測試需要編寫不同參數或者負載條件下設計測試用例
大量數據性能需考慮數據處理能力，用邊界值分析法設計用例
網絡性能測試使用工具調整網絡設置
服務器測試一定要和前面的測試結合起來進行
（5）系統測試用例根據需求分析來檢驗軟件是否滿足功能，行爲，性能，系統協調性等方面的要求。
使用的數據應具有代表性，並與真實數據的大小和複雜性相當
（6）驗收測試用例設計
應該在研發階段測試用例基礎上重新編寫，而不能直接拿來使用；需與客戶需求相對應，面向客戶；把握客戶的關注點並適當展示軟件的獨特性。
（7）迴歸測試用例設計要點
不需要重複設計，只需選擇以前的測試用例，針對最重要或最頻繁使用的功能測試用例
綜上描述需要結合實際工作運用實踐，精益求精![]()
。趕快行動吧~
。趕快行動吧~