在敏捷方法中，XP方法強調(diào)測試在整個項目開發(fā)過程中的重要性。針對敏捷開發(fā)方法的敏捷測試不同于以往針對傳統(tǒng)開發(fā)模式的測試,在敏捷團隊中,測試是整個項目組的“車頭燈”，它告訴大家現(xiàn)在到哪了，正在往哪個方向走。測試人員為項目組提供豐富的信息，使得項目組基于這些可靠的信息作出正確的決定。不僅是測試人員要保證質(zhì)量，而是整個項目組的每一個人都要對質(zhì)量負責(zé)。測試人員不跟開發(fā)人員糾纏錯誤，而是幫助他們找到目標(biāo),共同為達到項目的最終目標(biāo)而努力。敏捷測試也需要高度迭代工作、頻繁得到客戶的反饋，需要動態(tài)調(diào)整測試計劃、測試的執(zhí)行。并且，敏捷測試人員參與到了更多的敏捷生產(chǎn)活動中，積極的影響了團隊做出的決定和計劃。

根據(jù)目前流行的敏捷項目管理方法我們總結(jié)了敏捷測試流程規(guī)范：

1. 驗證需求和設(shè)計

需求和設(shè)計具體來說一般包括：

（1）由項目經(jīng)理根據(jù)需求文本而編寫的功能設(shè)計文本（Functional Design Specification）；

（2）由開發(fā)人員根據(jù)功能文本而編寫的實施設(shè)計文本（Implementation Design Specification）包括(Architecture Document, Project Scope Statement, Use Case )。作為測試人員，審核重點是檢查文本對用戶需求定義的完整性、嚴(yán)密性和功能設(shè)計的可測性.

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

產(chǎn)出物：測試需要提交評審結(jié)果文檔,可以讓測試更多的參與DB Design,框架的評審中來

2. 測試計劃，測試用例

2.1 編寫計劃、測試用例

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

好處：

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

問題：

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

分析：

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

舉個例子：

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

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

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

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

2.2 測試用例的審核

為使開發(fā)人員能參與到Test Case的Review中來，以保證TC的質(zhì)量和可行性，確保測試工作的順利進行，讓開發(fā)人員迅速地了解測試的重點并給出相應(yīng)的意見和建議，測試人員在出TC的同時，應(yīng)出一份TC_Matrix（Test Case跟蹤矩陣），其中注明TC已覆蓋了哪些Features，具體每個Features對應(yīng)的TC的編號，這樣在測試經(jīng)理和PM對TC進行Review的時候，能夠?qū)C的覆蓋率一目了然，對覆蓋率不足（如某個重點Feature的Test Case不夠）的地方能夠及時給出意見。

另外，在每天早上的Morning Meeting上，測試人員可以簡潔地講述一下當(dāng)天測試的重點部分，以及項目中存在哪些嚴(yán)重的bug，讓開發(fā)人員了解當(dāng)天測試的重點是什么，怎樣進行測試，并提出自己的意見和建議。這樣做加強了開發(fā)與測試人員的交流和溝通，使測試工作能夠更加有效，更加順利地開展。

在迭代后期測試要抽時間更新test case。

3. 實施運行測試

在敏捷方法中，測試有兩種：單元測試和接收測試。單元測試是由開發(fā)人員來完成的，接收測試是由客戶代表來完成。

由于我們客戶無法在現(xiàn)場，我們采取了，開發(fā)人員做單元測試，測試人員做驗證測試，最后由客戶進行接收測試。在每個版本發(fā)布給客戶之前必須由測試人員進行測試，發(fā)布版本之后由客戶做接收測試，提出需要修改的地方。需要修改的地方將在下一個發(fā)布完成。

·單元測試

在daily build版本給測試前，開發(fā)首先要做單元測試，提前告知軟件中的薄弱環(huán)節(jié)，幫助測試人員調(diào)整測試重點。Unit test

做單元測試的好處是可以提高版本質(zhì)量，減輕測試的工作量，減少淺層次的bug的發(fā)生率，使測試人員能夠?qū)⒏嗟木ν度氲綄ふ疑顚哟蔚腷ug上面。

·驗證測試

測試人員的驗證測試從總體上說就是將上一步設(shè)計的測試用例按計劃付諸實施的過程。這一階段的測試必須在周密的計劃下進行。這種計劃性首先體現(xiàn)在開發(fā)和測試的相互協(xié)調(diào)配合，根據(jù)產(chǎn)品的架構(gòu)和功能模塊的依賴關(guān)系，按照項目的總體計劃共同推進。從測試的過程來看，測試執(zhí)行的一開始可以是針對部分功能的，之后可以逐步擴展。接著開始采用迭代的過程完成測試任務(wù)，即將測試任務(wù)劃分為多個周期，一開始可以做些關(guān)鍵的功能性測試，可以對代碼中的可復(fù)用部分（組件，構(gòu)件）做完整的測試。接著的迭代周期可以做邊緣化的功能測試和其他測試，最后的幾個迭代應(yīng)該用于回歸測試，和關(guān)鍵的性能和穩(wěn)定性測試。

3.1 每日提供bug趨勢

為方便衡量項目的進度，測試可每天測試完畢后提供測試的bug趨勢，即將每天新生成的Bug數(shù)和每天被解決的Bug數(shù)標(biāo)成一個趨勢圖表。一般在項目的開始階段新生Bug數(shù)曲線會呈上升趨勢，到項目中后期被解決Bug數(shù)曲線會趨于上升，而新生Bug數(shù)曲線應(yīng)下降，到項目最后，兩條曲線都趨向于零。PM會持續(xù)觀察這張圖表，確保項目健康發(fā)展，同時通過分析預(yù)測項目Bug，對于每個版本的bug，開發(fā)都應(yīng)該想想為什么會出現(xiàn)這樣的問題，特別是很低級的bug，對于同類的bug，是否可以避免。

測試需要考慮：探索性測試用例的編寫

3.2 測試用例的維護

在執(zhí)行測試階段中，測試人員需要對已有的測試用例進行及時的維護。通常以下兩種情況下要新增一些測試用例：一是對于當(dāng)初測試設(shè)計不周全的領(lǐng)域，二是對于外部的Bug（比如從Beta客戶報告來的），

沒有被現(xiàn)有測試用例所覆蓋。當(dāng)產(chǎn)品的功能設(shè)計出現(xiàn)更改時（敏捷項目中功能設(shè)計的更改頻繁），所涉及的測試用例也要相應(yīng)地修改，使測試用例保持和現(xiàn)有的功能需求同步。

3.3 根據(jù)項目不斷補充Common Sense

在項目進行過程中，測試人員需要不斷積累經(jīng)驗，不斷補充、完善各類目的Common Sense標(biāo)準(zhǔn)。例如，由CTTS項目總結(jié)出的Common Sense for USA標(biāo)準(zhǔn)，在以后的美國項目中要嚴(yán)格按照它來執(zhí)行測試，保證以前出現(xiàn)過的失誤在以后的項目測試中不會再出現(xiàn)。在保證項目質(zhì)量的同時，不斷積累新的經(jīng)驗。

3.4 控制中間版本

為更好地保證軟件質(zhì)量，規(guī)避風(fēng)險，必須加強對中間版本的控制。例如，客戶要求或者計劃周五要提交版本，則周三一定要提交一個中間過程的版本進行測試，也就是控制中間版本，避免所有的工作都壓到后期最緊急的時候去完成。以前的項目中出現(xiàn)過項目前期很輕松，到后期bug越來越多，開發(fā)人員和測試人員都異常忙碌，經(jīng)常加班的情況。為減少后期工作量，規(guī)避風(fēng)險，建議開發(fā)進行Daliy Build，或者按照完成一個feature就進行一次build，針對這個feature進行測試，這樣就可以有效避免后期bug越來越多的狀況發(fā)生，后期工作量也就會相應(yīng)減少，項目的質(zhì)量也會更有保證。

3.5 發(fā)布版本前編寫Release Note

在每次發(fā)布版本之前，測試人員要根據(jù)待發(fā)布的版本情況編寫Release Note，使客戶對發(fā)布的版本情況一目了然。Release Note主要包括三方面的內(nèi)容：Fixed，New Features，Known Problems。其中，F(xiàn)ixed部分寫明此版本修復(fù)了上個版本中存在的的哪些比較大的bug；New Features部分寫明此版本新增加了哪些功能；Known Problems部分寫明此版本尚存在哪些比較大的問題，有待下個版本改善；或者列出需求不太明確的地方，有待客戶給出明確答復(fù)意見，在下個版本中完成。

4. 需求管理

采用敏捷開發(fā)模式的項目中，客戶對于需求的變更很頻繁。因此，需求管理是十分必要和重要的工作。整個項目進行過程中，對不斷變化的需求，一定要作跟蹤，每次的需求變更都要有相應(yīng)的歷史記錄，方便后期的管理和維護工作?？蓪⒚看蔚淖兏碛涗浀叫枨蟾櫸臋n中，并使該文檔始終保持最新更新的狀態(tài)，與需求的變化保持同步。

問題：

客戶可能會在一個功能點上來回修改他們的需求，也許開始需要某個功能，結(jié)果做完以后又覺得不好，于是讓去掉這個功能。后來又由于一些原因，又需要加上。在整個過程中可能來回修改了很多次。那一定要記錄下變更的內(nèi)容和日期?？赡芎笃诳蛻魰X得一個功能怎么會花那么多的時間，不是以前很早就做過了嗎？這時這些記錄才是解決客戶疑慮的最好證明。說白了，是有證據(jù)證明我們做了很多的變更。大家可能覺得，怎么會有這個問題。其實當(dāng)一個項目長達半年以上，也許大家的記憶力都不可靠了。

建議：

目前采用的是vss工具，對每天的Email中提到的需求變更做一次backup，文檔以當(dāng)天收到Email的日期命名

5. 項目開發(fā)末期開展“bug大掃除”

在項目開發(fā)的末期，可以開展“bug大掃除”活動。劃出一個專門的時間段，在這期間所有參與項目的人員，集中全部精力，搜尋項目的Bug。注意以下要點：（1）盡管這是一個測試活動，但參與者并不僅限于測試人員。項目經(jīng)理，開發(fā)人員甚至于高層管理人員都應(yīng)參加，如同全民動員。目的是要集思廣益；（2）要鼓勵各部門，領(lǐng)域交叉搜索，因為新的思路和視角通常有助于發(fā)現(xiàn)更多的Bug；（3）為調(diào)動積極性，增強趣味性，可以適當(dāng)引入競爭機制，比如當(dāng)活動結(jié)束時，評出發(fā)現(xiàn)Bug最多，發(fā)現(xiàn)最嚴(yán)重Bug的個人，給以物質(zhì)和精神獎勵。（4）可以分專題展開，比如安全性、用戶界面可用性、國際化和本地化等等。