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

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

1. 驗(yàn)證需求和設(shè)計(jì)

需求和設(shè)計(jì)具體來(lái)說(shuō)一般包括：

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

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

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

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

2. 測(cè)試計(jì)劃，測(cè)試用例

2.1 編寫(xiě)計(jì)劃、測(cè)試用例

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

好處：

客戶(hù)可以很清楚的了解到哪些user story需要花費(fèi)多長(zhǎng)的時(shí)間，以及他們的優(yōu)先級(jí)。

問(wèn)題：

在user story的時(shí)間估算上，開(kāi)發(fā)人員常會(huì)估算過(guò)少。引起版本無(wú)法按時(shí)發(fā)布或者必須進(jìn)行加班才能進(jìn)行發(fā)布。

分析：

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

舉個(gè)例子：

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

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

所以非常建議大家在估算時(shí)間上能充分的考慮到以外的因素，某本XP相關(guān)的書(shū)上寫(xiě)到，在時(shí)間估算上最好的時(shí)間是編碼時(shí)間的2－3倍。聽(tīng)起來(lái)很?chē)樔?，但是?shí)際的過(guò)程中，的確需要這么多的時(shí)間。

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

2.2 測(cè)試用例的審核

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

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

在迭代后期測(cè)試要抽時(shí)間更新test case。

3. 實(shí)施運(yùn)行測(cè)試

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

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

·單元測(cè)試

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

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

·驗(yàn)證測(cè)試

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

3.1 每日提供bug趨勢(shì)

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

測(cè)試需要考慮：探索性測(cè)試用例的編寫(xiě)

3.2 測(cè)試用例的維護(hù)

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

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

3.3 根據(jù)項(xiàng)目不斷補(bǔ)充Common Sense

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

3.4 控制中間版本

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

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

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

4. 需求管理

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

問(wèn)題：

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

建議：

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

5. 項(xiàng)目開(kāi)發(fā)末期開(kāi)展“bug大掃除”

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