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