一句話概括：對被測軟體的需求有深入的理解。
深入理解被測軟體需求的最好方法是，測試工程師在需求分析和設計階段就開始介入，因為這個階段是理解和掌握軟體的原始業務需求的最好時機。
只有真正理解了原始業務需求之後，才有可能從業務需求的角度去設計針對性明確、從終端用戶使用場景考慮的端到端(End-2-End)的測試用例集。
在具體的用例設計時，首先需要搞清楚每一個業務需求所對應的多個軟體功能需求點，然後分析出每個軟體功能需求點對應的多個測試需求點，最後再針對每個測試需求點設計測試用例。
具體到測試用例本身的設計，有兩個關鍵點需要你注意：
從軟體功能需求出發，全面地、無遺漏地識別出測試需求是至關重要的，這將直接關係到用例的測試覆蓋率。 比如，如果你沒有識別出用戶登錄功能的安全性測試需求，那麼後續設計的測試用例就完全不會涉及安全性，最終造成重要測試漏洞。
從軟體功能需求出發，全面地、無遺漏地識別出測試需求是至關重要的，這將直接關係到用例的測試覆蓋率。 比如，如果你沒有識別出用戶登錄功能的安全性測試需求，那麼後續設計的測試用例就完全不會涉及安全性，最終造成重要測試漏洞。
測試用例設計經驗
只有深入理解被測試軟體的架構，你才能設計出「有的放矢」的測試用例集，去發現系統邊界以及系統集成上的潛在缺陷。
作為測試工程師，切忌不能把整個被測系統看作一個大黑盒，你必須對內部的架構有清楚的認識，比如資料庫連接方式、資料庫的讀寫分離、消息中間件Kafka的配置、緩存系統的層級分布、第三方系統的集成等等。【也就是說你要有一定的代碼讀寫能力】
必須深入理解被測軟體的設計與實現細節，深入理解軟體內部的處理邏輯。
單單根據測試需求點設計的用例，只能覆蓋「表面」的一層，往往會覆蓋不到內部的處理流程、分支處理，而沒有覆蓋到的部分就很可能出現缺陷遺漏。在具體實踐中，你可以通過代碼覆蓋率指標找出可能的測試遺漏點。
同時，切記不要以開發代碼的實現為依據設計測試用例。因為開發代碼實現的錯誤會導致測試用例也出錯，所以你應該根據原始需求設計測試用例。
需要引入需求覆蓋率和代碼覆蓋率來衡量測試執行的完備性，並以此為依據來找出遺漏的測試點。