測試用例
是軟體測試的基礎，是測試人員和開發團隊其他成員深入了解產品開發需求的介質之一，也是產品質量的保障。因此合理設計測試用例不僅有助於掌握客戶的產品真實需求，使得研發團隊所有人員對需求的理解處於同一平面上，也確保產品在整個動態的研發過程中，始終符合用例的設計，實現使用者最終期望的功能。
在傳統開發模式中，需求分析往往占用較長時間，分析階段由核心的開發人員和測試人員參與。在進入研發階段後，將需求傳遞給其他開發和測試人員，測試人員根據需要在設計完測試用例和開發完成以後，進行各種型別的測試。這樣的結果往往由於測試人員沒有參與最初的需求討論，因此對需求的理解存在一定偏差，很多用例的編寫基於測試人員的假設。而且因為開發周期較長，最終交付的功能已經發生改變。
在敏捷開發模式中，測試人員和開發人員的節奏是同步的，即開發人員增量地開發功能的同時或甚至之前，測試人員也增量地設計相應的測試用例，等功能完成後馬上可以對功能性測試。對於還未開始開發或者需求暫不明確的功能，不進行測試用例的深度分析工作。這樣就能把更多的精力投入到最重要功能上去。
功能性測試用例和需求的關聯
在敏捷測試中，需求一般以使用者故事的形式存在，是將使用者的需求用例項或者故事的方式記錄到待辦事項列表中（backlog）。 測試用例和使用者故事之間是緊密關聯的，在產品經理（po）設計、解釋完成使用者故事後，測試人員根據使用者故事設計測試用例。測試用例可以是對使用者故事驗收標準的細分，也可以把多個使用者故事進行串聯形成乙個用例，這取決於使用者故事和測試用例設計的粒度大小。由於使用者故事會隨著需求的細化和拆分，因此很難對使用者故事和測試用例做一一對應，而且後期維護成本較高，因此需要在使用者故事和測試用例中增加模組屬性，來管理測試用例和使用者故事之間的關聯關係。而且兩者應該在乙個統一平台進行維護和更新。
非功能性測試用例和需求的關聯
對於非功能性的測試用例，往往並不關聯具體功能模組，但是會有對應的使用者故事，例如：效能需求，安全需求等，建立這類測試的測試用例的時候，可以通過建立效能模組，安全模組等並不存在的模組，和其他用例等同處理。
單元/元件測試用例的關聯
敏捷軟體開發的其中乙個非常有用的實踐是測試驅動開發，這需要開發人員編寫單元測試，在單元測試過程中，對於複雜邏輯的函式或者元件，也需要設計單元測試用例。這些測試用例本身不以實際文件的形式存在用例庫中，往往和測試人員一起討論並參考測試人員設計的測試用例來進行編寫簽入到單元測試中。因此做測試用例個數統計時，需要包括單元/元件測試測試用例數量，或者為單元測試/元件測試單獨設立統計指標。同時沒有特別必要和模組或者使用者故事做關聯。
敏捷測試用例設計
敏捷宣言 個體和互動比過程和工具更有價值 能工作的軟體比全面的文件更有價值 顧客的協作比合同談判更有價值 及時響應變更比遵循計畫更有價值。並非每個企業都能嚴格按敏捷的相關開發方法進行專案管理，例如測試驅動 xp scrum等。也並非都需要按這些方式管理才能實現敏捷。只要我們理解了敏捷的原則和精髓，我...
敏捷測試用例設計
分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！敏捷測試用例設計 陳能技2007 9 20 敏捷宣言 個體和互動比過程和工具更有價值 能工作的軟體比全面的文件更有價值 顧客的協作比合同談判更有價值 及時響應變更比遵循計畫更有價值。www.agilemanifesto.org 並非每個企業都能嚴格...
敏捷開發 測試用例設計和測試指令碼開發
測試的主要任務是設計功能用例和非功能測試用例，同時要開發自動化測試 或測試腳 本，和指令碼必須要進行review，並應該要調測通過能夠執行，最後才能check in到配 置庫加入到持續整合環境中。用例設計前可能需要考慮必要的測試策略和測試方案。關於功能用例和非功能用例，也許專案現在還無法實現測試自動...