敏捷宣言：
個體和互動比過程和工具更有價值；
能工作的軟體比全面的文件更有價值；
顧客的協作比合同談判更有價值；
及時響應變更比遵循計畫更有價值。
並非每個企業都能嚴格按敏捷的相關開發方法進行專案管理，例如測試驅動、xp、scrum等。也並非都需要按這些方式管理才能實現敏捷。只要我們理解了敏捷的原則和精髓，我認為很多方法、很多地方都可以應用敏捷的思想，實現敏捷的管理。
測試用例的設計是其中一項。
測試用例的粒度
測試用例可以寫得很簡單，也可以寫得很複雜。最簡單的測試用例是測試的綱要，僅僅指出要測試的內容，如探索性測試（exploratory testing）中的測試設計，僅會指出需要測試產品的哪些要素、需要達到的質量目標、需要使用的測試方法等。而最複雜的測試用例就像飛機維修人員使用的工作指令卡一樣，會指定輸入的每項資料，期待的結果及檢驗的方法，具體到介面元素的操作步驟，指定測試的方法和工具等等。
測試用例寫得過於複雜或過於詳細，會帶來兩個問題：乙個是效率問題，乙個是維護成本問題。另外，測試用例設計得過於詳細，留給測試執行人員的思考空間就比較少，容易限制測試人員的思維。
測試用例寫得過於簡單，則可能失去了測試用例的意義。過於簡單的測試用例設計其實並沒有進行「設計」，只是把需要測試的功能模組記錄下來而已，它的作用僅僅是在測試過程中作為乙個簡單的測試計畫，提醒測試人員測試的主要功能包括哪些而已。測試用例的設計的本質應該是在設計的過程中理解需求，檢驗需求，並把對軟體系統的測試方法的思路記錄下來，以便指導將來的測試。
大多數測試團隊編寫的測試用例的粒度介於兩者之間。而如何把握好粒度是測試用例設計的關鍵，也將影響測試用例設計的效率和效果。我們應該根據專案的實際情況、測試資源情況來決定設計出怎樣粒度的測試用例。
軟體是開發人員需要去努力實現敏捷化的物件，而測試用例則是測試人員需要去努力實現敏捷化的物件。要想在測試用例的設計方面應用「能工作的軟體比全面的文件更有價值」這一敏捷原則，則關鍵是考慮怎樣使設計出來的測試用例是能有效工作的。
基於需求的測試用例設計
基於需求的用例場景來設計測試用例是最直接有效的方法，因為它直接覆蓋了需求，而需求是軟體的根本，驗證對需求的覆蓋是軟體測試的根本目的。
要把測試用例當成「活」的文件（effective software testing : 50 specific ways to improve your testing – elfriede dustin），因為需求是「活」的、善變的。因此在設計測試用例方面應該把敏捷的「及時響應變更比遵循計畫更有價值」這一原則。
不要認為測試用例的設計是乙個階段，測試用例的設計也需要迭代，在軟體開發的不同的階段都要回來重新審視和完善測試用例。
測試用例的評價
測試用例設計出來了，質量如何，如何提高測試用例設計的質量？就像軟體產品需要通過各種手段來保證質量一樣，測試用例的質量保證也需要綜合使用各種手段和方法。
測試用例的檢查可以有多種方式，但是最敏捷的應當屬臨時的同行評審。我認為同行評審，尤其是臨時的同行評審，應該演變成類似結對程式設計一樣的方式。從而體現敏捷的「個體和互動比過程和工具更有價值」，要強調測試用例設計者之間的思想碰撞，通過討論、協作來完成測試用例的設計，原因很簡單，測試用例的目的是盡可能全面地覆蓋需求，而測試人員總會存在某方面的思維缺陷，乙個人的思維總是存在侷限性。因此需要一起設計測試用例。
因此，參與到測試用例設計和評審中來的人除了測試人員自己和管理層外，還應該包括終端使用者或顧客代表，還有開發人員。
測試用例資料生成的自動化
在測試用例設計方面最有希望實現自動化的，要當屬測試用例資料生成的自動化了。因為設計方面的自動化在可想象的將來估計都很難實現，但是資料則不同，資料的組合、資料的過濾篩選、大批量資料的生成等都是計算機擅長的工作。
很多時候，測試用例的輸入引數有不同的型別、有不同的取值範圍，我們需要得到測試用例的輸入引數的不同組合，以便全面地覆蓋各種可能的取值情況。但是全覆蓋的值域可能會不可思議地廣泛，我們又需要科學地篩選出一些有代表性的資料，以便減輕測試的工作量。在這方面可利用正交表設計資料或成對組合法設計資料。
可利用一些工具，例如tconfig、pict等來產生這些資料。
在效能測試、容量測試方面，除了設計好測試用例考慮如何測試外，還要準備好大量的資料。大量資料的準備可以使用多種方式：程式設計生成、sql語句生成（基於資料庫的資料）、利用工具生成。
工具未必能生成所有滿足要求的資料，但是卻是最快速的，程式設計能生成所有需要的資料，但是可能是最複雜、最慢的方式。所以應該盡量考慮使用一些簡單實用的工具，例如datafactory等。
敏捷測試用例設計
分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！敏捷測試用例設計 陳能技2007 9 20 敏捷宣言 個體和互動比過程和工具更有價值 能工作的軟體比全面的文件更有價值 顧客的協作比合同談判更有價值 及時響應變更比遵循計畫更有價值。www.agilemanifesto.org 並非每個企業都能嚴格...
敏捷開發 測試用例設計和測試指令碼開發
測試的主要任務是設計功能用例和非功能測試用例，同時要開發自動化測試 或測試腳 本，和指令碼必須要進行review，並應該要調測通過能夠執行，最後才能check in到配 置庫加入到持續整合環境中。用例設計前可能需要考慮必要的測試策略和測試方案。關於功能用例和非功能用例，也許專案現在還無法實現測試自動...
測試用例設計
1.測試用力的概念 測試用例是為特定的目的而設計的一組的測試輸入。執行條件和預期的結果，體現在測試方案 方法 技術和策略。2.測試用例具備的特點 1 正確性 2 完整性 3 準確 4 清晰 簡潔 5 可維護性 6 適應性 7 可重用性 8 其他 3.測試用例基本原則 個人認為比較重要的加黑了。1 基...