測試用例
是測試工作的核心。測試工作是講究投入產出比的工作，這也是測試用例設計的指導思想。
測試用例有度的概念，正如亞里斯多德在《倫理學》中討論道德為例：道德意味著過與不及之間的狀態。面向測試用例，網上流傳著這麼一句話：「不同的機構會有不同的測試目的；相同的機構也可能有不同測試目的，可能是測試不同區域或是對同一區域的不同層次的測試」
下面就列舉測試用例設計的方方面面，看不同的團隊，不同的測試目的，如何把握測試用例設計之度。
顆粒度：
顆粒度的粗細，有無標準？什麼是粗？什麼是細？
1、以功能點劃分？
僅僅覆蓋所有的功能性需求為粗？
僅僅正向覆蓋所有的功能需求（功能、效能）為粗？
正向/負向覆蓋所有的功能需求（功能、效能）以及正向覆蓋效能需求為粗？
正向/負向覆蓋所有的需求為細？覆蓋到產品包，涵蓋相容性、公升級、安裝、易用性為細？
2、以step劃分？
每條用例有乙個step為粗，三？五？十為細？以上為細？
以測試設計思路的體現？
只採用正向為粗？只採用正/負向為粗？考慮應用場景為細？考慮業務邏輯為細？
3、以數量級？
百條？千條？萬條？
4、以資料覆蓋？
等價類是粗？窮舉是細？
每個人、每個機構判定測試用例粗細的標準都不一樣，沒有標準的答案。所以測試用例顆粒度的粗細，本身就是乙個相對而言的標準。
嘗試用圖示來表示顆粒度粗細的常規概念：
測試用例顆粒度粗、細的特點是什麼？
用例設計分析：
粗顆粒度面向巨集觀，面向正向的功能點、大的功能模組和整體性，體現測試用例的設計思路；細顆粒度面向微觀，面對具體的乙個個功能點的正向/負向邏輯，體現測試用例的細節和完備性。
面對測試執行人員：
粗顆粒度用例不容易被測試新手執行，因為很多約定成俗的操作、現象，甚至行業術語都不清楚。細顆粒度用例相對較易被測試新手執行。
覆蓋度：
粗顆粒度覆蓋度可能小於細顆粒度用例（粗顆粒度只覆蓋全部正向和部分負向，細顆粒度覆蓋全部正向、負向、其他等）；但還有一種可能性，就是粗細用例均覆蓋全面，但是深度不同。類似下雨的降雨量不同，對農作物（產品）的意義不同。
可維護性：
毫無疑問，測試用例和需求的匹配，測試用例本身的維護是大多數團隊的工作難點重點，粗顆粒度便於維護，方便和需求保持高度一致；細顆粒度用例，越細越不容易維護，維護成本過大，特別是需求頻繁變更會導致不可維護。
類似的概念，比如自動化測試環節，gui不停改變導致的指令碼重寫類似。
粗顆粒度構架和評審的時間較短，適合週期較緊的專案；細顆粒度構建和編寫的時間較長，適合週期寬鬆或更傾向於質量的專案。
資源：
粗顆粒度占用資源較少（人力、評審、會議室等），適合小團隊或同一團隊多專案模式；細顆粒度占用資源較多，適合大團隊或單一專案模式。
風險：
毫無疑問，粗顆粒度用例的風險是漏測，存在很大概率漏測的風險，依賴於測試人員的個人素質；細顆粒度也存在漏測，不過相對更可能是測試人員自己的想當然跳過用例不執行。
細顆粒度用例最大的風險就是可維護性，或者投入產出比。
軟體測試之測試用例
測試環境 操作步驟 測試資料 預期結果 標題 測試模組 重要性 測試前提 1 評估需求覆蓋率 2 後輩借鑑 3 可以重複利用 等價類概念 依據需求將輸入 特殊情況下會考慮輸出 劃分為若干個等價類，從等價類中選出乙個測試用例，如果這個測試用例測試通過，則認為所代表的等價類測試通過，這樣就可以用較少的測...
測試用例之測試大綱法
測試大綱 提綱 法 一 基本概念 1 適用場合 程式包含多個視窗，每個視窗中有多個操作，視窗之間有一定的關係，為了弄清楚視窗之間的關係使用測試大綱法 二 使用測試大綱法測試的步驟 步驟1 分析需求 列出視窗以及視窗中的操作 列大綱 步驟2 根據大綱，找到視窗操作之間的關係，編寫測試用例 1 哪個最簡...
功能測試之測試用例設計
功能測試入門到精通 作為測試新人，如何實現測試用例的設計一直是我的乙個疑惑，在工作中寫過幾個專案的測試用例，嘗試總結乙個測試用例的設計步驟。前提 編寫測試用例之前我們需要對專案的需求有清晰的了解，對要測試什麼，按照什麼順序測試，覆蓋哪些需求做到心中有數，作為測試用例的編寫者不僅了解要有常見的測試用例...