“好的”測試用例一定是一個完備的集合，它能夠覆寫所有等價類以及各種邊界值，而跟能否發現缺陷無關
舉栗子
被測軟體——魚塘
軟體缺陷——魚
測試用例集——漁網
“好的”測試用例集就是一張能夠覆寫整個魚塘的大漁網，隻要魚塘裡有魚，就能給撈上來；
如果漁網本身是完整合格的，那麼撈不到魚，就證明魚塘中沒有魚，而漁網的好壞與魚塘是否有魚無關
整體完備性：一定是一個完備的整體，是有效測試用例組成的集合，能夠完全覆寫測試需求
等價類劃分的準确性：對于每個等價類都能保證隻要其中一個輸入測試通過，其他輸入頁一定測試通過
等價類集合的完備性：需要保證所有可能的邊界值和邊界條件都已經正确識别
等價類劃分
邊界值分析
錯誤推斷法：基于對被測試軟體系統設計的了解、過往經驗以及個人直覺，推測出軟體可能存在的缺陷，進而有針對性地設計測試用例方法。強調的是對被測軟體的需求了解以及設計實作的細節把握
最核心的測試點：驗證軟體對需求的滿足程度
如何做到：在需求分析階段和技術設計階段就開始介入
成效：設計出從終端使用者使用場景考慮的端到端的測試用例集，主要驗證各個業務需求是否被滿足，基于黑盒的測試設計方法
重點：在具體的用例設計時，首先要搞清楚每一個業務需求所對應的多個軟體功能需求點，然後分析出每個軟體功能需求點對應的多個測試需求點，最後再針對每個測試需求點設計測試用例
繞嗎？？？(；´д｀)ゞ
首先先看看【使用者登入】功能的映射關系圖
從軟體功能需求出發，全面地、無遺漏地識别出測試需求是至關重要的，這将直接關系到用例的測試覆寫率。 比如，如果你沒有識别出使用者登入功能的安全性測試需求，那麼後續設計的測試用例就完全不會涉及安全性，最終造成重要測試漏洞。
對于識别出每個測試需求點，需要綜合運用等價類劃分、邊界值分析和錯誤推測方法來全面設計測試用例。
首先對“使用者名”和“密碼”兩個輸入框分别進行等價類劃分，對于無效等價類的識别可采用錯誤推測法（如：使用者名包含特殊字元）
然後補充輸入框的邊界值用例，如：為空、使用者名長度剛剛大于限定長度
必須對内部的架構有清楚的認識，比如：資料庫連接配接方式、資料庫的讀寫分離、消息中間件的配置、緩存系統的層級分布、第三方系統的內建
隻根據測試點設計測試用例隻能覆寫“表面”一層，往往内部處理流程、分支處理無法覆寫完全；在具體實踐中，可以通過代碼覆寫率名額找出可能的測試遺漏點
後續介紹
【需求合理性測試】即使用者體驗測試也是現在很重要的一點
在快速疊代的靈活開發節奏下，無需把每條用例都寫的這麼複雜，重要的是把測試點寫清楚，不是要把那些顯而易見的步驟，環境，預期寫的十全十美