如果妳點開了鏈接，看到了本文章，我想妳壹定被文章的標題吸引了進來，或許妳們會說又是標題黨。標題黨就標題黨吧，妳們肯定會看完的
剛開始接觸測試的朋友，對測試用例（case)壹定不陌生，它是測試的基本功。或許妳已經被他磨平了棱角. 可能在幾年之前，測試用例的編寫和執行是許多IT公司招聘的必備條件之壹, 可能不少朋友經常使用Excel編寫case 殊不知，隨著項目和時間的推移，Excel的文件大小會越來越大，打開速度也越來越慢。加上項目叠達速度的加快，Excel的效率已經明顯不夠。而且閱讀起來也相對比較吃力，下文我將提到敏捷模式下的測試該如何進行。
壹、開發和測試通性困擾？
面對復雜性（需求）：不斷地修改計計劃、不斷地增加預算、低劣的產品質量……
面對復雜性（項目組成員）：經常加班到深夜、提交的產品不合格……
二、敏捷開發中的敏捷目的
敏捷宣言
個體和交互比過程和工具更有價值；能的軟件比全面的文檔更有價值；顧客的協作比合同談判更有價值；及時響應變更比遵循計劃更有價值。
其核心是:以人為本,發揮人的主觀能動性.
.
三、傳統測試和敏捷測試區分：
3.1 傳統的測試
1.守門員:質量保證者，阻止那些不可靠的、無效的、充滿BUG的版本發布。
2.信息提供者:提供大量積極的、關於項目開發的狀態的信息。告訴大家哪些功能正常工作、哪些功能不能正常工作、哪些BUG必須處理。
3.2、某大廠敏捷測試
測試和開發的角色界線變得模糊。有些人主要做測試工作，有些人主要做開發工作，但是在快速推進的過程中，所有人都會被號召起來測試或支持測試的工作。
更多職責:幫助開發人員理解需求,盡早確定測試規範。
四、敏捷測試用例的設計和評審要素
4.1、基於需求的用例場景來設計測試用例
1.基於需求的用例場景來設計測試用例是最直接有效的方法，因為它直接覆蓋了需求，而需求是軟件的根本，驗證對需求的覆蓋是軟件測試的根本目的。
2.把測試用例當成"活"的文檔,因為需求是"活"的、善變的。因此在設計測試用例方面應該符合敏捷的"及時響應變更比遵循計劃更有價值"這壹原則。
3.測試用例的設計不是壹個階段，測試用例的設計也需要叠代，在軟件開發的不同的階段都要回來重新審視和完善測試用例。
**4.2、敏捷測試用例設計原則
通常我們所看到的測試用例的設計是其中壹項。
測試用例可以寫得很簡單，也可以寫得很復雜。最簡單的測試用例是測試的綱要，僅僅指出要測試的內容，如探索性測試中的測試設計，僅會指出需要測試產品的哪些要素、需要達到的質量目標、需要使用的測試方法等。而最復雜的測試用例就像銀行取款機系統中工作指令系統界面壹樣，會指定輸入的每項數據，期待的結果及檢驗的方法，具體到界面元素的操作步驟，指定測試的方法和工具等等。
測試用例寫得過於復雜或過於詳細，會帶來兩個問題：壹個是效率問題，壹個是維護成本問題。另外，測試用例設計得過於詳細，留給測試執行人員的思考空間就比較少，容易限制測試人員的思維。
測試用例寫得過於簡單，則可能失去了測試用例的意義。過於簡單的測試用例設計其實並沒有進行"設計"，只是把需要測試的功能模塊記錄下來而已，它的作用僅僅是在測試過程中作為壹個簡單的測試計劃，提醒測試人員測試的主要功能包括哪些而已。測試用例的設計的本質應該是在設計的過程中理解需求，檢驗需求，並把對軟件系統的測試方法的思路記錄下來，方便輔導後面的測試。
請看如下壹個例子：
現在有壹個 PC 客戶端的命令行工具，這個工具可以接收三個命令行參數，其中，前兩個是數字，最後壹個是運算符，運算符只支持加減乘除四種，工具的功能就是把前兩個數字使用運算符做下運算，然後輸出運算結果。
我們來看下面的用例：
第壹種風格，完全是遵循腦圖的本來用法，屬於層級遞進式，前面層級都是後面層級的前置條件，需要把每壹個分支的所有層級全部組合到壹起，才是壹條完整的用例
第二種風格，是按照要素歸類的方式，每壹層都是同壹要素的不同類別，細化到的最後壹級就是壹條完整用例，前面的層級只是為了讓分類清晰，為了把後面壹大坨的最終用例更有條理的進行展示。
二種風格的用例各有優點
第壹種風格適合做需求分析，通過思維的邏輯發散，把不同的路徑通過腦圖進行展現，從而激發更多的靈感。
但是測試用例是針對已經固定的需求和實現來做覆蓋，它的前提是固定的，我們用腦圖需要做得，就是把已有的需求和實現，轉換為用例後，再通過合理的方式進行呈現。
我們需要的，壹方面是合理的拆分，比如第二種格式裏的第壹層，我們按照輸入、輸入順序和輸出分成三塊，後續繼續按第壹個參數、第二個參數和第三個參數這種方式進行更細的劃分，所以條理性還是蠻清晰的。
這種格式的用例，在做用例評審時，可以很方便的和需求進行壹壹對應，能夠很快的確認需求覆蓋率。
另壹方面，這種格式的用例，對於用例執行者也是比較友好的，執行者可以只關註用例的最後壹個節點，按照指定策略執行就行了，在這種情況下第二種用例會比第壹種用例效果更好，如果是第壹種格式，需要每次都從頭看到尾，很容易出錯。不過筆者相對來說喜歡第壹種，通過不同路徑腦圖進行展現，激發更多的靈感。
本文部分內容來自 51testing