簡介
同是企業(yè)WEB應用程序項目，一個用敏捷，一個用瀑布流程，它們的測試策略會有何不同？在二者中，測試的關注點都在于告訴業(yè)務客戶這個應用程序做了哪些事情，同樣也要消除應用程序作為產(chǎn)品交付以后的失敗風險。它們的主要區(qū)別不是測試本身，而是何時執(zhí)行測試、由誰執(zhí)行測試。測試的每個階段都可以在系統(tǒng)就緒后隨時開始，無須等待前一個測試階段完成。
從未涉足敏捷項目，或是剛啟動某個敏捷項目并在尋找指導建議的讀者都可以看看這篇文章，它正是為你們而寫。文中的信息雖并非筆者新創(chuàng)，但也是收集整理的結(jié)果，希望這些信息能幫助你們朝著更為敏捷的過程邁進。
敏捷項目的測試階段跟瀑布項目的測試階段幾乎毫無二致。每個階段都有準出標準，但是在進入某個測試階段之前，是不需要等待整個應用程序完成的。只要應用程序所完成的部分足以進入下一個測試階段就行。因為測試的對象是一個已完成的功能，而不是一個發(fā)布，所以測試階段是在持續(xù)并行進行的。于是就有了一大堆回歸測試。這便也意味著回歸測試是測試自動化的基礎。對于敏捷項目而言，環(huán)境與資源也是要注意的地方，因為對測試環(huán)境的需求會來得更早、更加頻繁。
“快速失敗”是敏捷項目的一句格言，它的含義是盡可能早地判斷出應用程序無法滿足業(yè)務需求。要做到這一點，就需要不斷地對解決方案是否滿足業(yè)務需求進行檢測，一旦不滿足，就要盡早把問題解決。敏捷團隊成員-開發(fā)人員、測試人員、架構(gòu)師、業(yè)務分析師以及業(yè)務代表等人都關注于盡早交付業(yè)務價值。所以，測試需要所有團隊成員協(xié)力來做， 它不僅僅是測試人員的責任。
測試分類
敏捷項目跟瀑布項目的測試分類幾乎是一樣的。其差別主要在于大部分精力投入的地方和每個測試階段所執(zhí)行的時機。敏捷項目傾力關注單元測試和功能測試，從而為稍后執(zhí)行的測試階段創(chuàng)造出高質(zhì)量的代碼，于是后期就不會發(fā)現(xiàn)本應在早期發(fā)現(xiàn)的缺陷，并能專注于所需要測試的領域。而瀑布項目就有一個常見的問題，后期測試的焦點總是放在找出本來應該在前期發(fā)現(xiàn)的缺陷身上。于是修復缺陷的成本提高了，測試工作的投入翻番了，測試的關注點也偏離了。
瀑布項目和敏捷項目另外一個巨大的不同在于測試自動化。敏捷項目力求在所有測試領域內(nèi)都達到100%自動化。測試跟持續(xù)構(gòu)建系統(tǒng)集成在一起，于是當代碼發(fā)生變化時，這個變化會被自動檢測到，應用程序被構(gòu)建起來，然后所有的測試都會被執(zhí)行。
測試驅(qū)動開發(fā)（TDD）在敏捷項目中很常用，用這種方法的時候，測試用例比代碼要先一步創(chuàng)建。于是我們就可以越來越多地看到為代碼和功能創(chuàng)建的測試用例。用自動化測試來驅(qū)動開發(fā)，然后消除重復，這種做法可以保證無論復雜度多高，任何開發(fā)者都可以寫出可靠的、沒有bug的代碼。TDD常用的地方是單元測試，但也同樣可以用于功能測試、集成測試、用戶驗收測試和性能測試。
單元測試
單元測試又稱白盒測試，它要測試所開發(fā)出來的每一個模塊。瀑布項目不關注這個測試階段，而且大多數(shù)時候即便有的話也是隨意為之。敏捷項目強調(diào)單元測試，而且會把所有單元測試都自動化。自動化的單元測試是敏捷項目的基礎，對持續(xù)集成和重構(gòu)起輔助作用。
單元測試應當考慮以下幾點：
1、用stub和mock來消除對外部接口的依賴。
2、由創(chuàng)建代碼的開發(fā)人員編寫單元測試。
3、單元測試要能自動化執(zhí)行，而且要被包含在持續(xù)開發(fā)構(gòu)建中。
4、單元測試之間不能有依賴，讓每一個單元測試都能獨立執(zhí)行。
5、任何開發(fā)人員都要能在他自己的機器上執(zhí)行單元測試。
6、用代碼覆蓋率來判斷哪些部分的代碼沒有被單元測試覆蓋。
7、在檢入代碼的修改之前，要保證單元測試100%通過。
任何測試失敗都表示構(gòu)建失敗。
功能測試
功能測試常常跟系統(tǒng)測試相關聯(lián)，它的重點是測試應用程序的功能（包括負面測試和邊界條件）。在瀑布項目中，測試團隊一般是在這個階段開始測試工作。測試團隊的成員會一直等下去，直到開發(fā)者完成了所有的功能，并通過所有的單元測試之后才進入功能測試階段。 敏捷項目把功能拆分成故事，每次迭代開發(fā)一定數(shù)量的故事。每個故事都有一些驗收標準，這些標準一般都是由業(yè)務分析師和測試分析師制定的，它們也可以看作跟測試條件類似。測試分析師會根據(jù)驗收標準創(chuàng)建測試用例，用它們來檢測代碼行為的完成程度。故事一旦編碼完成，而且單元測試運行通過以后，就可以運行功能測試來判斷是否滿足驗收標準了。這就意味著在敏捷項目中，只要第一塊功能已經(jīng)完成編碼，功能測試就可以啟動，而且會貫穿整個項目的生命周期。
功能測試應當考慮以下幾點
1、要能自動化執(zhí)行，并且進入持續(xù)構(gòu)建（如果測試運行時間很多長，也可以只在開發(fā)持續(xù)構(gòu)建中包含一小部分精挑細選的功能測試，而在系統(tǒng)集成持續(xù)構(gòu)建中包含全部功能測試）。
2、在編碼之前寫下測試意圖，代碼完成后對測試進行實現(xiàn)。
3、把通過所有功能測試作為故事完成的條件。
4、在應用程序安裝到另外一個環(huán)境（如試機環(huán)境或產(chǎn)品環(huán)境）上的時候需要執(zhí)行功能測試。
任何測試失敗都表示構(gòu)建失敗。
探索性測試
探索性測試又稱為隨機測試。瀑布項目在它們的測試策略中沒有這種測試類型，不過大多數(shù)測試人員都會多少做一些探索性測試。在敏捷項目中這是個很關鍵的測試階段，因為它可以用來檢測自動化測試的覆蓋率，并收集對于應用程序質(zhì)量的反饋。它為測試人員和業(yè)務分析師提供了一種結(jié)構(gòu)化的方式去使用、去探索系統(tǒng)，從而找到缺陷。如果探索性測試在某個功能區(qū)域內(nèi)找到了大量缺陷，那這部分的自動化測試用例就要被審核。
探索性測試應當考慮以下幾點：
1、在系統(tǒng)集成環(huán)境中執(zhí)行。
2、在較高的層次上監(jiān)測探索性測試活動。
3、用自動化的環(huán)境設置方式來減少搭建環(huán)境的時間。
4、將破壞性測試作為探索性測試的一部分。
集成測試
應用程序在作為產(chǎn)品部署的時候，需要各個部分的協(xié)作；集成測試就是把這各個獨立的部分集成起來進行測試。瀑布項目不但會把應用程序的各個獨立模塊進行集成，還會把那些雖然不屬于項目的一部分，但是要開發(fā)當前應用程序就必須用到的一些應用程序也做集成。在敏捷項目中，獨立模塊間的集成是被持續(xù)構(gòu)建所覆蓋的，所以集成測試的關注點就是那些不屬于當前項目的外部接口。
集成測試應當考慮以下幾點
1、在執(zhí)行集成測試的時候，需要考慮到當前迭代還沒有開發(fā)的功能。
2、寫一些集成測試來定位特殊的集成點，以協(xié)助代碼調(diào)試，即便功能測試會調(diào)用到這些集成點也無妨。
3、將集成測試自動化，放到系統(tǒng)集成持續(xù)構(gòu)建中。
任何測試失敗都表示構(gòu)建失敗。
數(shù)據(jù)驗證
如果項目需要移植既有數(shù)據(jù)的話，就要進行數(shù)據(jù)驗證。它可以保證現(xiàn)有的數(shù)據(jù)被正確地移植到新的Schema中，新的數(shù)據(jù)被添加進來，舊的數(shù)據(jù)被移除。這種類型的測試在瀑布項目和敏捷項目中是被同等對待的，除了敏捷項目會盡力把它自動以外。
數(shù)據(jù)驗證應該考慮以下幾點：
1、在系統(tǒng)集成環(huán)境、試機環(huán)境和產(chǎn)品環(huán)境中都要執(zhí)行。
2、盡可能地自動化。
3、要把測試放到系統(tǒng)集成持續(xù)構(gòu)建中。
任何測試失敗都表示構(gòu)建失敗。
用戶驗收測試（UAT）
UAT關注的是完整的業(yè)務過程，它用來確保應用程序能按照業(yè)務的處理方式工作并能滿足業(yè)務需求。它同樣還要從客戶、消費者、管理員等各種用戶的角度出發(fā)考慮應用程序的可用性。在瀑布項目中，這個階段通常就被用來找出應該在早期階段就被發(fā)現(xiàn)的bug。業(yè)務人員也會在這個階段驗證開發(fā)團隊交付的應用程序的質(zhì)量。敏捷項目用UAT來確保應用程序滿足業(yè)務需求，因為等到進入這個測試階段的時候，代碼質(zhì)量已經(jīng)較高了。在敏捷項目中，業(yè)務人員從早期的測試階段就開始參與，所以他們對交付的東西有更多的信心。
UAT應該考慮以下幾點：
1、首先進行手工測試，等它驗證了系統(tǒng)行為以后再把它自動化。
2、把自動化測試放到系統(tǒng)集成持續(xù)構(gòu)建中
3、讓應用程序的最終用戶親自將整個程序運行一遍，不過項目的測試人員要在旁邊協(xié)助。
4、在試機環(huán)境下執(zhí)行UAT， 用作驗收。
5、只要完成了一個業(yè)務過程或者一個主要的UI組件，就要執(zhí)行UAT。
任何測試失敗都表示構(gòu)建失敗。
性能測試
性能測試涵蓋的范圍比較大，不過一般可以分成以下三類。
1、容量測試：獨立測試核心功能組件的容量。例如， 可以支持多個用戶并發(fā)檢索？一秒種能做多少次？等等。容量測試被用來精確度量系統(tǒng)的極限，還可以對容量規(guī)劃和系統(tǒng)的擴展性起輔助作用。
2、負載測試：側(cè)重于系統(tǒng)在負載下的表現(xiàn)。負載應該要體現(xiàn)出用戶所期望系統(tǒng)可以經(jīng)受得住的流量。
3、壓力測試：關注系統(tǒng)在壓力下的表現(xiàn)。比較常用的技術是浸泡測試（soak test）；在浸泡測試中，系統(tǒng)會在一定的負載下持續(xù)運行一段時間，用來找出長期問題，如內(nèi)存泄漏、資源泄漏等。壓力測試還會覆蓋故障轉(zhuǎn)移和恢復，例如正在工作的集群中的一臺服務器出現(xiàn)問題，檢查是否可以做到故障轉(zhuǎn)移和恢復。
瀑布項目直到項目接近尾聲的時候才做性能測試，這個時候應用程序已經(jīng)“完成了”開發(fā)，通過單元測試和功能測試。而敏捷項目則會盡快啟動性能測試。
性能測試應該考慮以下幾點：
1、在功能測試中設置一些性能度量，例如一個測試第一次運行要花多長時間，接下來每次又要花多久，把這些時間所占的百分比做一下比較（上升表示有問題，下降表示良好）
2、把一些性能測試放到系統(tǒng)集成持續(xù)構(gòu)建中去做。
3、一旦一個業(yè)務過程，或是某個規(guī)模比較大的功能或接口完工，就要做性能測試。
4、只有在試機環(huán)境中運行的時候才簽收性能測試。
任何測試失敗都表示構(gòu)建失敗。
非功能性測試
非功能性測試所涵蓋的范圍很廣，性能測試通常也屬于這個話題。但是因為性能測試是企業(yè)解決方案中很重要的一部分，而且需要不同的資源和技能集，所以就被劃出來單獨成為一個測試階段。非功能性測試一般都包含有這些內(nèi)容：可操作性（包括監(jiān)控、日志、審計/歷史記錄）、可靠性（包括故障轉(zhuǎn)移，單個組件故障，完整故障，接口故障）以及安全性。無論瀑布項目還是敏捷項目，在這個測試階段都會遇到重重阻礙，二者的差異不太突出。
非功能性測試應該考慮以下幾點：
1、非功能性需求一般都是很難捕獲的，而且即便被捕獲，也很難進行度量。（例如：99.9%的無故障時間）
2、盡可能讓所有的非功能測試都自動化執(zhí)行，把它們也都放到系統(tǒng)集成測試環(huán)境中。
3、在定義測試用例的時候，讓真正要監(jiān)控產(chǎn)品環(huán)境并對其提供支持的人也參與進來。
4、在應用程序成為產(chǎn)品以后，非功能測試或監(jiān)控還要繼續(xù)。
回歸測試
在瀑布項目中，回歸測試無論從時間上還是費用上來看，都算得上是成本最高的測試階段了。如果在項目晚期（如UAT階段）發(fā)現(xiàn)了缺陷，再構(gòu)建應用程序的時候，就得把所有單元測試、功能測試和用戶驗收測試重新運行一遍。因為大多數(shù)瀑布項目都沒有自動化測試，所以回歸測試的開銷就很大。敏捷項目以持續(xù)構(gòu)建和自動化測試來應對回歸測試，使每次構(gòu)建都可以進行回歸測試。
回歸測試應該考慮這一點：
每次迭代結(jié)束時都做一下手工測試，收集早期反饋。
產(chǎn)品校驗
產(chǎn)品校驗會在把產(chǎn)品交付給用戶使用之前，審查產(chǎn)品環(huán)境中的應用程序，看看所有內(nèi)容是否否都已經(jīng)正確安裝，系統(tǒng)的操作性如何。而有些測試還是只能到了產(chǎn)品環(huán)境中才能完整運行的，最好盡快將其完成。無論是瀑布項目還是敏捷項目，產(chǎn)品校驗的方式并無二致。
產(chǎn)品校驗應該考慮以下幾點：
1、讓最終用戶來做產(chǎn)品校驗測試。
2、趁著產(chǎn)品系統(tǒng)還沒有正式上線，從這個測試階段的早期就要盡可能多地執(zhí)行自動化回歸測試。
瀑布項目和敏捷項目的測試階段還是很相似的，主要差異就是每個測試階段關注的重點和執(zhí)行時機。敏捷項目中有大量的自動化測試，用持續(xù)集成來減少回歸測試對項目帶來的影響。在瀑布項目中，如果發(fā)現(xiàn)應用程序的質(zhì)量低下，那么在晚期再去執(zhí)行前期的測試就是很常見的事情（如在UAT的時候做功能測試）。敏捷項目可以減少測試中的浪費，在早期發(fā)現(xiàn)問題，讓團隊在交付應用時增強信心。
環(huán)境
在開發(fā)過程的各個階段都要用到測試環(huán)境，從而確保應用程序的正常運行。越到后期，測試環(huán)境與預期的產(chǎn)品環(huán)境就會越相似。測試環(huán)境一般都會包括一個開發(fā)環(huán)境，讓開發(fā)者集成代碼并運行一些測試。系統(tǒng)集成環(huán)境跟開發(fā)環(huán)境有些類似，不過它會集成更多的第三方應用程序，也許還有大批量的數(shù)據(jù)。試機環(huán)境幾乎是產(chǎn)品環(huán)境的鏡像，也是應用程序變成產(chǎn)品之前的最后一個階段。
敏捷項目和瀑布項目所需的環(huán)境沒太大區(qū)別，其中一個不同之處在于，敏捷項目從項目伊始直至項目結(jié)束，都要用到所有的環(huán)境。在敏捷項目中，保證所有的環(huán)境都一直正常工作也是很重要的。無論因為什么原因讓某個環(huán)境出現(xiàn)故障，都要立刻讓它重新工作起來。在這個話題上，敏捷和瀑布還有另外一點差異，那就是環(huán)境的計劃和資源分配對它們的影響不同，尤其是當各種環(huán)境被項目之外的團隊進行管理的時候，其差異尤為顯著。
開發(fā)集成環(huán)境
開發(fā)者在開發(fā)環(huán)境中集成代碼，開發(fā)應用程序。瀑布項目對開發(fā)環(huán)境的重要性不會考慮太多；開發(fā)環(huán)境中的代碼一直都不能工作，到了開發(fā)者需要彼此集成代碼的時候才想起來使用，而這時項目已經(jīng)臨近尾聲。在敏捷項目中，開發(fā)環(huán)境是整個開發(fā)工作中不可分割的一部分，在開始編碼之前就必須準備就緒。這個環(huán)境會被用來持續(xù)地集成代碼和運行測試套件。無論因為什么原因造成環(huán)境故障，都要立刻修復。
開發(fā)環(huán)境應該考慮以下幾點：
1、集成代碼、構(gòu)建和測試的時間加起來不要超過15分鐘。
2、每個開發(fā)人員所用的環(huán)境跟開發(fā)環(huán)境保持一致（硬件環(huán)境可以不一樣，但軟件環(huán)境一定要一樣）。
3、所用的數(shù)據(jù)要盡可能跟產(chǎn)品數(shù)據(jù)保持一致。如果產(chǎn)品數(shù)據(jù)過于寵大，難以載入，也可以只取一部分。在每個發(fā)布周期的開始階段，這些數(shù)據(jù)要從產(chǎn)品數(shù)據(jù)中重新更新。
4、管理這個環(huán)境的責任應該落在項目團隊身上。
5、向這個環(huán)境中部署的頻率大約是以小時計算。
6、自動部署。
系統(tǒng)集成環(huán)境
系統(tǒng)集成環(huán)境用來將所開發(fā)的應用程序和其他應用程序進行集成。在瀑布項目中，這個環(huán)境只會在項目臨近尾聲的時候才會用到，而且傾向于多個項目共用一個集成環(huán)境。在敏捷項目中，一旦開始編碼，這個環(huán)境就要準備就緒。應用程序會被頻繁部署到這個環(huán)境中，繼而開始執(zhí)行功能測試、集成測試、可用性測試和探索性測試等等。應用程序的演示是在這個環(huán)境中進行。
系統(tǒng)集成環(huán)境應該考慮以下幾點。
1、集成點應該被真正的外部應用程序所代替。外部應用程序應該處于測試狀態(tài)，而非真正的生產(chǎn)版本。
2、把產(chǎn)品環(huán)境的架構(gòu)復制過來。
3、把這個環(huán)境中所使用的數(shù)據(jù)應該是產(chǎn)品環(huán)境數(shù)據(jù)的副本，每個發(fā)布周期的開始階段，都要從產(chǎn)品數(shù)據(jù)中重新更新。
4、建立運行這個環(huán)境中所有測試的系統(tǒng)集成持續(xù)構(gòu)建。
5、管理這個環(huán)境的責任應該落在項目團隊身上。
6、向這個環(huán)境中部署構(gòu)建的頻率大約是以天計算。
7、自動部署應用程序。
試機環(huán)境
試機環(huán)境用來驗證應用程序可以部署為產(chǎn)品，而且工作正常。為了達到這個目的，試機環(huán)境應該完全復制產(chǎn)品環(huán)境，包括網(wǎng)絡配置、路由器、交換機以及計算機性能等等。在瀑布項目中這個環(huán)境往往需要“預訂”也要有一個計劃，計劃在這個環(huán)境中進行多少次部署以及何時進行部署。敏捷項目對這個環(huán)境不像對開發(fā)環(huán)境和集成環(huán)境那樣依賴；不過在項目的整個生命周期中，還是需要常常進行部署。
試機環(huán)境應該考慮以下幾點：
1、這里的數(shù)據(jù)應該是產(chǎn)品數(shù)據(jù)的完整副本，每次應用程序部署前都要更新。
2、用它來驗證UAT， 性能測試和非功能測試（穩(wěn)定性、可靠性等等）
3、向這個環(huán)境中部署構(gòu)建的頻率大約是以迭代計算，如每兩周一次。
4、管理這個環(huán)境的人應該就是管理產(chǎn)品環(huán)境的人，讓他提前接觸應用程序并進行知識傳遞。
5、自動部署應用程序。
產(chǎn)品環(huán)境
產(chǎn)品環(huán)境是應用程序正式上線時的環(huán)境。產(chǎn)品校驗測試就在這個環(huán)境中執(zhí)行，同時會做一些度量以檢驗測試成果。瀑布項目和敏捷項目在這里的區(qū)別不大。在敏捷項目中，發(fā)布過程會盡力做到自動化，為向產(chǎn)品環(huán)境中頻繁發(fā)布提供條件。
產(chǎn)品環(huán)境應該考慮以下幾點：
1、在應用程序正式上線之前，在產(chǎn)品環(huán)境中做回歸測試。
2、要做度量，以檢驗測試成果，例如在前三個月到六個月之前，用戶報告了多少問題，問題的嚴重性如何。
無論是哪種項目，要保證時間期限，就都得做到在需要用到環(huán)境的時候就有一個環(huán)境可供使用。瀑布項目會設法遵守嚴格的計劃，便于對環(huán)境做安排。敏捷項目的靈活性更強。也許有了足夠的功能就可以進入試機環(huán)境了，或者業(yè)務人員會決定產(chǎn)品提前上線。為了做到向試機環(huán)境快速部署，然后進入產(chǎn)品環(huán)境，就要有系統(tǒng)集成環(huán)境以及有關過程的輔助。
問題管理
問題包括缺陷（bug）和變更請求。瀑布項目有著嚴格的缺陷和變更請求管理，而敏捷項目飽含變化，所以就沒有那么嚴格的變更管理。如果需要有變更，就創(chuàng)建一個（或是一些）故事，放到待處理事項里面。高優(yōu)先級的故事會放到下一次迭代中完成。
缺陷管理在敏捷項目中依然適用。如果有人發(fā)現(xiàn)一個正在開發(fā)故事有缺陷，大家就會進行非正式的溝通，發(fā)現(xiàn)缺陷的人把它告訴開發(fā)人員，缺陷立刻被修復。如果某個缺陷并不屬于當前迭代中開發(fā)的故事，或者屬于當前故事，但并不嚴重，那就用缺陷跟蹤工具記錄下來。這個缺陷會被當做故事處理；也就是說，會創(chuàng)建一張故事卡，讓客戶排優(yōu)先級，放待處理故事里面。團隊需要進行權(quán)衡：要找問題所在，為大家理解這個問題并安排優(yōu)先級提供足夠的信息，但又不能在一個對客戶而言優(yōu)先級并不是很高的缺陷上面花太多時間。
瀑布項目和敏捷項目的缺陷內(nèi)容（描述、組件、嚴重程序等）是一樣的，除了一個字段以外：敏捷項目多了一個字段- 業(yè)務價值，如果可能的話就用幣值描述。這個字段表示如果缺陷被解決的話可以帶來多少業(yè)務價值。將業(yè)務價值跟缺陷關聯(lián)以后，客戶就更好地判斷這個缺陷跟新功能相比是不是更有價值，是不是應該有更高的優(yōu)先級。
工具
所有項目都要用到工具，只是程序不同。瀑布項目用工具來強化過程以及提高效率，這有時會造成沖突。敏捷項目用工具輔助提升效率，與過程無關。在敏捷項目中，所有的測試都應該可以在任何團隊成員的個人環(huán)境中運行，也就是說，所有人都可以使用那些自動化測試用例的工具。所以敏捷項目中會經(jīng)常用到開源產(chǎn)品，這又意味著使用這些工具需要不同的技能。開源工具不像商業(yè)工具那樣有齊備的文檔和完善的支持，用這些工具的人要有很強的編碼能力。如果有人編程能力偏弱，就可以通過跟人結(jié)對來提升個人技能。在敏捷項目中也可以使用商業(yè)工具，但是大多數(shù)商業(yè)工具在開發(fā)的時候都沒有考慮敏捷過程，所以敏捷項目匹配起來就不太容易。而且要讓商業(yè)工具跟持續(xù)集成配合，可能要寫很多代碼才行。
項目中應該考慮為下面一些測試任務使用工具
1、持續(xù)集成（如CruiseControl， Tinderbox）
2、單元測試（如JUnit， NUnit）
3、代碼覆蓋率率（如Clover， PureCoverage）
4、功能測試（如：HttpUnit， Selenium， Quick Test professional）
5、用戶驗收測試（如：Fitness， Quick Test Professional）
6、性能測試（如：JMeter， LoadRunner）
7、問題跟蹤（如：BugZilla， JIRA）
8、測試管理（如：Quality Center）
報表與度量
度量數(shù)據(jù)是用來衡量軟件質(zhì)量和測試成果的。在瀑布項目中，有些測試度量指標需要在測試之前就把所有測試用例都寫好，而且僅在應用程序開發(fā)完畢時進行一次測試。這種指標包括：每個測試用例執(zhí)行的時候發(fā)現(xiàn)多少缺陷，每天執(zhí)行的測試用例會發(fā)現(xiàn)多少缺陷。這些度量數(shù)據(jù)收集起來以后，便用來判斷應用程序是否已經(jīng)就緒并可以發(fā)布。在敏捷項目中，功能完成的時候測試用例就已經(jīng)寫好且運行完畢，這就意味著用來度量瀑布項目的一些指標是無法應用在這上面的。
回到收集度量數(shù)據(jù)的原因上來-衡量軟件質(zhì)量和測試成果，你可以看看下面這些概念。
1、用代碼覆蓋率度量測試效果；這對于單元測試尤其有效。
2、在探索性測試階段發(fā)現(xiàn)的缺陷數(shù)量可以說明單元測試和功能測試的效果。
3、在UAT階段發(fā)現(xiàn)的缺陷表示先期的測試并不像UAT一樣充分，我們應該關注業(yè)務過程， 而不是軟件的bug。如果UAT發(fā)現(xiàn)了很多功能性問題，而不是軟件的bug，這就表示團隊對故事或是變化的需求理解不足。
4、故事完成以后所發(fā)現(xiàn)的缺陷數(shù)量能夠作為衡量軟件質(zhì)量的好手段。這些缺陷包括在集成測試、非功能測試、性能測試和UAT測試中發(fā)現(xiàn)的缺陷。
5、缺陷重現(xiàn)率。如果缺陷常常重現(xiàn)，軟件質(zhì)量就很低。
測試角色
測試角色并不是跟單個資源一一對應的。一個資源可以擔任多個測試角色，一個測試角色也可以由多個資源負責。下面列出的這些角色是確保項目測試效果所必需的。一個優(yōu)秀的測試人員應該具備所有這些角色的特征。敏捷項目和瀑布項目都有這些角色，只是扮演這些角色的人不同。在敏捷項目中，所有團隊成員都是怎么扮演各個角色的。這并不是強制性的規(guī)定；每個團隊各有差異，不過這種做法也算得上是不錯的組合。
測試分析人員要了解需求、架構(gòu)、代碼等各個產(chǎn)物，從而判斷哪些需要做測試，哪些是測試要重點關注的地方。
在瀑布項目中一般是有一個（或多個）資深的資源來擔任這個角色。他們檢查相關文檔（需求、設計、架構(gòu)），編寫測試計劃、編寫高層的測試用例描述，然后把所有的東西都交給一個初級員工，讓他填補詳細的測試腳本。敏捷項目鼓勵所有團隊成員一起擔任這個角色。開發(fā)人員的關注點是通過分析代碼和設計來編寫單元測試，但是他們也會協(xié)助業(yè)務分析師或者測試人員編寫功能測試，還會參與非功能測試和性能測試的分析。業(yè)務分析師和測試人員緊密協(xié)作，編寫功能測試和用戶驗收測試，并執(zhí)行探索性測試。客戶/最終用戶會被邀請參與用戶驗收測試。
測試腳本編寫員
該角色就是編寫詳細測試腳本的人。這些腳本可能供手工執(zhí)行，也可能被自動化。瀑布項目中的腳本編寫就是個初級員工，他根據(jù)測試計劃和測試用例描述來編寫手冊，每一步都描述的很詳盡、自動化腳本編寫員就得是更資深的人了，開發(fā)人員也會參與單元測試用例的編寫。敏捷項目會大量使用開發(fā)人員來編寫測試腳本，主要是因為測試腳本是自動化執(zhí)行的。
測試執(zhí)行員
不管是手工測試還是自動化測試都有這個角色，不過在自動化的時候，這個角色的扮演者就是一臺電腦。測試執(zhí)行員會執(zhí)行詳細測試腳本，判斷哪些測試失敗，哪些測試通過。瀑布項目一般都用測試人員來做這件事情，而敏捷項目則鼓勵所有人都來參與，尤其是測試人員、業(yè)務分析量和客戶。
環(huán)境管理人員
這個角色管理測試環(huán)境，包括應用程序運行的環(huán)境以及支持自動化測試的基礎架構(gòu)。他們還會關注外部接口和用作測試的數(shù)據(jù)。這個角色在瀑布項目和敏捷項目中很相似。
問題管理人員
問題出現(xiàn)以后就要解決。這個角色可以幫助篩查問題，確保它們被正確地創(chuàng)建，有各種屬性，如嚴重程度、優(yōu)先級、組件等等。這個角色還要管理問題的生命周期，并提供工具支持。這個角色在瀑布項目和敏捷項目中很相似。
故障檢測人員
這個角色當問題出現(xiàn)的時候就要去做故障檢測工作，判斷是不是軟件缺陷。如果是軟件缺陷，他們就要去找出問題根源、可能的解決方案和變通措施。這個角色在瀑布項目和敏捷項目中很相似。
敏捷團隊所注重的是讓各個角色得到充分發(fā)揮，而比較少關心誰在做什么事情、誰對哪些事情負責。測試人員和其他團隊成員之間沒有界限，他們共同的目標是生產(chǎn)出更高質(zhì)量的軟件，每個成員都要盡一切可能幫助達成這個目標。在敏捷團隊中，測試人員可以從所有人那里得到幫助，而他們又可以幫助其他人提高測試技能。這種方式能夠確保團隊中的每個人都在為交付高質(zhì)量應用程序而付出。