前言：如果問乙個問題，如何設計測試用例，恐怕會貽笑大方，因為剛入測試這一行的同學也都能噼里啪啦說上十分鐘不歇氣。但是如果追問下去，比如專案快速迭代時怎樣讓測試用例保持有效新鮮？什麼是更高效的設計方式？恐怕能回答上來的人不多了。
在如今的軟體迭代過程中，在測試用例上投入的大量時間和亟需提公升的研發效率正在成為日益凸顯的巨大矛盾。如何在兩者之間取得平衡，筆者總結了敏捷化設計測試用例的十條建議，認為測試用例應該具備以下特點：
一、獨立性
所謂獨立性是指每組（個）測試用例可以單獨維護、執行，不影響其他的測試用例組，如果測試用例之間是強耦合的，考慮對它們進行合併。這樣設計的好處是當迭代出現變更時，可以對測試用例組進行增刪改的操作而不相互影響。例如一些操作是針對登入使用者的，那麼登入相關的用例和這些操作用例就是強耦合的。或者在乙個場景中，存在上下文資料的傳遞關係，必須組合使用，但是單獨任何乙個步驟拿出去都是不可執行的，那麼這種場景就需要設計成乙個完整的測試用例，因為每個步驟都是不可分割的。
二、易用性
，例如上文的測試用例可以用如下的一句話測試用例來代替：「新註冊使用者首次進入主頁則展示引導蒙層，手指點選螢幕任何地方即可領取獎勵，且彈窗展示成功」，這樣的用例就大大提高了用例的設計速度，大概完成乙個需要兩分鐘，所以每小時能夠完成三十個用例設計，每天就能完成二百四十個用例。較傳統方法提高了四倍效率。
三、有效性
測試用例的有效性是有幾個要點可以闡述的。首先測試用例不是空想得來，必須**於真實的產品需求，否則就是無效的測試用例；其次測試用例應該是對產品核心的充分理解，不應該是對產品文件的複述，否則就是無效的測試用例，很多初級的測試人員就是辛苦的搬運工，把產品經理的文件拆解成一條條再搬運到測試用例的系統，你不能說它是錯誤的（wrong），但是其實它就是無效的（no use）；然後每組測試用例對應乙個獨立產品模組，產品模組變更觸發用例變更（新增、修改、刪除），如果不能跟隨變化，就是無效的測試用例，這一點尤為常見，大多數國內公司的測試人員每天都疲於設計新的測試用例，但是資料庫中堆積了數萬數十萬的廢棄測試用例無人問津。
四、進化性
建議測試人員盡量早的交付乙個測試用例版本，並隨著客戶需求的變化而層層遞進，這個最早的版本一定是較為粗獷和簡約的，但是它為將來的細化設定了「錨點」（注3），後續的設計工作都將由這些錨點展開。測試人員應該定期反思和回顧測試用例的設計，時間週期上可以跟隨迭代，不斷的對譬如顆粒度、資料流向、場景，進而調整設計策略。同理，由於測試用例的設計是基於需求的，所以測試用例設計絕對不是一次性工作，因此需要「欣然面對需求變化」，跟隨迭代不斷優化。
每組測試用例可以單獨維護、執行，不影響其他的測試用例組；
如果測試用例之間是強耦合的，考慮對它們進行合併；
每組測試用例之間可以傳遞資料、狀態；
測試用例應該是盡量簡潔，易於理解的；
好的測試用例應該是對產品核心的充分理解，不應該是對產品文件的複述；
每組測試用例對應乙個獨立產品模組，產品模組變更觸發用例變更（新增、修改、刪除）；
盡量早的交付乙個測試用例版本，並隨著客戶需求的變化而層層遞進；
測試用例的設計應該是基於需求的，所以不是一次性工作，因此需要「欣然面對需求變化」，跟隨迭代不斷優化；
應該定期反思和回顧測試用例的設計，譬如顆粒度、資料流向、場景，進而調整設計策略；
邀請開發、產品和其他團隊的測試參加測試用例評審，避免個人盲區；
注2：思維導圖，the mind map，也俗稱為腦圖，是一種圖形化的發散式思維工具。
注3：錨點，anchor又叫做錨記，可以幫助人們迅速定位，找到需要訪問的位置。
如何設計測試用例
測試基礎 測試用例 測試用例 test case 是為某個特殊目標而編制的一組測試輸入 執行條件以及預期結果，以便測試某個程式路徑或核實是否滿足某個特定需求。測試用例作用 檢驗是否滿足客戶需求 度量測試人員的工作量 展現測試用例的思路。測試用例包含 用例編號 唯一的編號。用例名稱 言簡意賅，描述準確...
如何設計測試用例
用例設計原則 存在關聯業務的測試點的考慮 常用測試設計方法 測試型別分析法 將乙個功能點按照不同的測試型別進行劃分，針對每乙個測試型別都進行測試點設計的分析方法。舉例說明 功能測試 效能測試 壓力測試 可靠性測試 相容性測試 安全性測試 容錯測試 功能測試常規測試點 基本流程測試 單個輸入框測試 邊...
如何設計測試用例
網路 測試工作最為基礎核心的內容就是設計測試用例，什麼樣的測試用例是好的測試用例？我們一般會認為數量越少，發現缺陷越多的用例就是最好的用例。那麼我們如何才能設計出好的測試用例呢？乙份好的用例是設計出來的，是測試人員思路和方法的集合，而非測試邏輯和需求的羅列。測試用例設計的幾個準則 1 用例設計 思路...