敏捷開發與敏捷測試

　　根據公司項目目前采用的敏捷開發模式，相應的敏捷測試建議采用以下流程：

　　1. 驗證需求和設計

　　需求和設計具體來說一般包括：（1）由項目經理根據需求文本而編寫的功能設計文本（Functional Design Specification）；（2）由開發人員根據功能文本而編寫的實施設計文本（Implementation Design Specification）包括(Architecture Document, Project Scope Statement, Use Case )。作為測試人員，審核重點是檢查文本對用戶需求定義的完整性、嚴密性和功能設計的可測性.

　　在測試初期，測試人員要學會做靜態測試，做好需求分析，做好對設計邏輯的分析。測試人員要更多的思考需求的可實現性，將自身作為第一用戶積極參與項目和系統的需求分析，設計和開發。積極地參與前期工作，并迅速反饋給設計和開發其靜態測試結果。要盡早的開始測試，不要等待到功能完全做好才開始。

　　產出物:測試需要提交評審結果文檔,可以讓測試更多的參與DB Design,框架的評審中來

　　2. 測試計劃，測試用例

　　2.1 編寫計劃、測試用例

　　在敏捷開發的過程中由于是根據每個user story來估算時間的。開發人員將對本次迭代所需要的完成的user story進行評估。開發人員可以和客戶直接溝通，來確定每個user story的優先級。

　　好處：

　　客戶可以很清楚的了解到哪些user story需要花費多長的時間，以及他們的優先級。

　　問題：

　　在user story的時間估算上，開發人員常會估算過少。引起版本無法按時發布或者必須進行加班才能進行發布。

　　分析：

　　由于版本更新很快，任務的時間都是以小時來進行估算的。開發人員一般會忽略掉開發以外的時間，比如開發中遇到問題的時間，開會，給其他成員提供幫助的時間，等等。

　　舉個例子：

　　開發人員估算某個user story編碼的時間需要1.5天，開發人員自己估算了其他時間為半天。于是開發人員給的估算時間是2天。

　　開發階段實際的花費時間如下，每天花費開例會的時間。在例會中項目的其他成員需要技術上的支持。于是發費了3個小時進行幫助。在開發的過程中遇到了一些沒有預見到的問題，結果解決問題花費了4個小時。（也許更多）。需要處理一些公司突發性的事務等等。

　　所以非常建議大家在估算時間上能充分的考慮到以外的因素，某本XP相關的書上寫到，在時間估算上最好的時間是編碼時間的2－3倍。聽起來很嚇人，但是實際的過程中，的確需要這么多的時間。

　　測試人員根據已審核通過的需求和設計編制測試計劃，設計測試用例。在前面提到的三種文本中，功能設計文本是主要依據。測試的這兩個文本也要被項目經理和開發人員審核。

文章來源于領測軟件測試網 http://www.kjueaiud.com/