九色国产,午夜在线视频,新黄色网址,九九色综合,天天做夜夜做久久做狠狠,天天躁夜夜躁狠狠躁2021a,久久不卡一区二区三区

第一部分：敏捷軟件開發(fā)簡介

敏捷軟件開發(fā)（Agile SoftwareDevelopment）初起于九十年代中期。最早是為了與傳統(tǒng)的瀑布軟件開發(fā)模式（waterfallmodel）相比較，所以當(dāng)時(shí)的方法叫做輕量級方法（Lightweight methods）。二十世紀(jì)初，17位該方法的倡導(dǎo)者建立了敏捷聯(lián)盟（Agile Alliance），并將該軟件開發(fā)方法命名為敏捷軟件開發(fā)過程。

敏捷聯(lián)盟在成立之初總結(jié)了四條基本的價(jià)值原則：

1. 人員交流重于過程與工具（ Individuals and interactions over processes and tools）
2. 軟件產(chǎn)品重于長篇大論（ Working software over comprehensive documentation）
3. 客戶協(xié)作重于合同談判（ Customer collaboration over contract negotiation）
4. 隨機(jī)應(yīng)變重于循規(guī)蹈矩（ Responding to change over following a plan）

基于這四點(diǎn)原則，敏捷軟件開發(fā)有著自己獨(dú)特的流程（參見圖 1）。

整個(gè)過程中夾雜了很多在敏捷開發(fā)前己經(jīng)出現(xiàn)的軟件開發(fā)方法，包括極限編程（ExtremeProgramming,1996）、Scrum（1986）、特征驅(qū)動(dòng)開發(fā)（Feature DrivenDevelopment），測試驅(qū)動(dòng)開發(fā)（Test DrivenDevelopment）等。這些方法在敏捷軟件開發(fā)流程的各個(gè)階段都有充分的體現(xiàn)和應(yīng)用。

例如，Scrum 主要著重于項(xiàng)目管理，團(tuán)隊(duì)中的項(xiàng)目經(jīng)理（Scrum master）需要在每個(gè)客戶需求到來的時(shí)候制定 Sprint 的周期，定義每個(gè) Sprint 的目標(biāo)、分派任務(wù)、進(jìn)行監(jiān)督、最后總結(jié)得失并開始計(jì)劃新的 Sprint。

相反，特征驅(qū)動(dòng)開發(fā)和測試驅(qū)動(dòng)開發(fā)主要被應(yīng)用于 Sprint周期中。如果項(xiàng)目進(jìn)行于開發(fā)新功能時(shí)期，這個(gè)階段主要推行特征驅(qū)動(dòng)開發(fā)。所有測試和開發(fā)人員都將自己的工作重心放在新的功能上面，從開發(fā)和測試兩個(gè)方面來完成各自的任務(wù)。如果項(xiàng)目進(jìn)行于測試新功能時(shí)期，這個(gè)階段需要將工作的重點(diǎn)挪到測試上來。所有的測試和開發(fā)人員都密切關(guān)注著目前版本的缺陷狀況。測試人員需要在每天的站立會(huì)議（Daily StandupMeeting）上報(bào)告前一個(gè)工作日發(fā)現(xiàn)的新缺陷情況，項(xiàng)目經(jīng)理根據(jù)項(xiàng)目進(jìn)度和缺陷嚴(yán)重性來決定是否修復(fù)這些問題。需要及時(shí)修復(fù)的缺陷是目前Sprint 中的一個(gè)新任務(wù)，將由項(xiàng)目經(jīng)理添加到 Sprint Backlog 上并通知開發(fā)人員去修復(fù)漏洞。

對于敏捷開發(fā)和測試中的審查過程，極限編程中的同行評審（peerreview）思想得到了充分應(yīng)用。代碼和文檔的審查追求簡單而高效。團(tuán)隊(duì)成員兩兩組成一對，互相評審；有時(shí)候，一個(gè)開發(fā)和一個(gè)測試人員也可以組成一對，互相協(xié)作。這樣能夠有助于缺陷和問題在第一時(shí)間被抹殺在萌芽中。

敏捷開發(fā)還有以下幾個(gè)關(guān)鍵概念 (Key Issues)：

1. 迭代過程（Iterative process）
2. 用戶故事（User stories）
3. 任務(wù)（Tasks）
4. 站立會(huì)議（Stand-up meeting）
5. 持續(xù)集成（Continuous integration）
6. 最簡方案（Simplest solutions）
7. 重構(gòu)（Re-factoring）

這些概念是敏捷開發(fā)中經(jīng)常使用到的觀點(diǎn)和方法。下面我們將詳細(xì)論述測試人員在敏捷軟件開發(fā)中扮演的角色和職能。

回頁首

第二部分：敏捷開發(fā)中的測試人員

本部分將簡要介紹敏捷開發(fā)中測試人員所需要具備的素質(zhì)和職責(zé)。

2.1 敏捷開發(fā)團(tuán)隊(duì)介紹

我們的敏捷開發(fā)團(tuán)隊(duì)由四位開發(fā)人員、兩位測試人員、一位產(chǎn)品設(shè)計(jì)，一位項(xiàng)目經(jīng)理和一位產(chǎn)品經(jīng)理組成（參見圖2）。每天早上十點(diǎn)，在固定的時(shí)間和會(huì)議室里面，團(tuán)隊(duì)會(huì)舉行站立會(huì)議。這時(shí)候，團(tuán)隊(duì)成員按照既定的順序向項(xiàng)目經(jīng)理匯報(bào)各自前一天完成的任務(wù)，所遇到的困難和當(dāng)天要完成的任務(wù)。同時(shí)，項(xiàng)目經(jīng)理更新 Sprint Backlog（一張制作精良的 Excel 表格），并及時(shí)解決每個(gè)人所提出的問題。

由于敏捷開發(fā)要求參與人能夠快速而高效得應(yīng)對變化，所以無形中對測試人員提出很高的要求。

2.2 測試人員需要具備的素質(zhì)

測試是軟件開發(fā)中不可或缺的一部分。在敏捷軟件開發(fā)中亦是如此。不同的組織給測試人員以不同的稱號：測試開發(fā) (TestDeveloper)、質(zhì)量分析員 (Quality Analyst)、軟件質(zhì)量工程師 (Software Quality Engineer)等。

每個(gè)稱號隱含有不同的職能。以上的稱號分別對應(yīng)以下的能力要求：

1. 具有質(zhì)量檢測和編寫代碼的能力–> 測試開發(fā)
2. 具有防止缺陷 (Quality Assurance) 和質(zhì)量控制 (Quality Control) 的能力–> 質(zhì)量分析員
3. 具有開發(fā)和執(zhí)行測試程序的能力 -> 軟件質(zhì)量工程師

總結(jié)而言，有三方面的基本素質(zhì)要求：代碼編寫（Coding）、測試 (Testing) 和分析 (Analysis)。

在很多其他的開發(fā)流程中，各個(gè)測試階段對測試人員的能力有所不同；有時(shí)候側(cè)重分析（比如系統(tǒng)配置測試），有時(shí)候側(cè)重代碼編寫 ( 比如功能測試)。但是，在敏捷開發(fā)流程中，測試人員需要結(jié)合這三方面來開展工作，只有這樣才能真正反映敏捷測試的本質(zhì)：簡單而高效得應(yīng)對變化。

2.3 測試人員的主要職責(zé)

在敏捷軟件開發(fā)中，測試人員的職責(zé)有三個(gè)主要方面：

1. 定義質(zhì)量 (Define Quality)：這應(yīng)該是軟件測試人員的基本職責(zé)。敏捷方法鼓勵(lì)測試人員在 Sprint 計(jì)劃的時(shí)候直接與客戶交流，從自己的經(jīng)驗(yàn)出發(fā)，共同為產(chǎn)品功能制定質(zhì)量要求。
2. 交流缺陷（Communication）：敏捷過程強(qiáng)調(diào)團(tuán)隊(duì)中的交流。開發(fā)人員經(jīng)常會(huì)專注于重要而新奇的功能，測試人員應(yīng)該抓住細(xì)節(jié)，尋找設(shè)計(jì)中的 “missing door”；另外，開發(fā)人員使用單元測試來保證產(chǎn)品的基本質(zhì)量，測試人員可以使用驗(yàn)收測試（Acceptance Test）來鑒定客戶需求與實(shí)際成果之間的不一致性。
3. 及時(shí)反饋 (Feedback): 敏捷過程強(qiáng)調(diào)簡單而高效。測試人員需要及時(shí)反饋產(chǎn)品目前的質(zhì)量問題。這樣一來，團(tuán)隊(duì)才可以立刻著手解決。如果傳統(tǒng)的流程是一周匯總一次狀態(tài)的話，敏捷流程 要求每天匯總質(zhì)量問題。在我們的項(xiàng)目中，內(nèi)部的測試報(bào)告會(huì)以網(wǎng)頁的形式顯示在內(nèi)部站點(diǎn)上。每個(gè)團(tuán)隊(duì)成員能夠隨時(shí)獲取。另外，我們的測試框架提供自助測試 (Self-assistant Test)：通過點(diǎn)擊測試用例列表中的某個(gè)具體用例，開發(fā)人員不需要中斷測試人員的工作就可以重現(xiàn)缺陷。

以上總結(jié)了測試人員在敏捷開發(fā)中的需要展現(xiàn)的能力和擔(dān)負(fù)的任務(wù)，下面請跟隨一個(gè)項(xiàng)目實(shí)例來詳細(xì)了解敏捷測試的最佳實(shí)踐。

回頁首

第三部分：敏捷開發(fā)中的測試流程

本部分結(jié)合一個(gè)軟件項(xiàng)目，詳細(xì)介紹項(xiàng)目流程中的主要測試活動(dòng)，每個(gè)活動(dòng)的前提條件和目標(biāo)任務(wù)等。

3.1 介紹項(xiàng)目實(shí)例

項(xiàng)目介紹：根據(jù)一家在線 B2B 公司的要求，我們將為其開發(fā)一款類似于谷歌的搜索服務(wù)。作為 Web Service，該服務(wù)可以內(nèi)嵌于網(wǎng)頁中。當(dāng)用戶輸入關(guān)鍵詞并選擇商戶的類型和位置后，系統(tǒng)會(huì)返回具體商戶的列表（參見圖 3）。

典型的敏捷開發(fā)和測試活動(dòng)參見下表。它主要由三部分構(gòu)成，從最初的用戶故事設(shè)計(jì)和發(fā)布計(jì)劃，到幾次 Sprint周期的迭代開發(fā)和測試，以及最后的產(chǎn)品發(fā)布階段。每個(gè)時(shí)間段都有相應(yīng)的測試活動(dòng)。通常 Sprint 周期被分成兩類：特征周期（FeatureSprint）和發(fā)布周期（ReleaseSprint）。特征周期主要涉及新功能的開發(fā)和各類測試。發(fā)布周期則會(huì)結(jié)合計(jì)劃，確定新版本功能，然后對最新的功能進(jìn)行測試。

在迭代的 Sprint 周期中，開發(fā)部分可以根據(jù)傳統(tǒng)步驟分成編碼和單元測試、重構(gòu)和集成。需要指出的是，重構(gòu)和集成是敏捷開發(fā)的 Sprint 迭代中不可忽視的任務(wù)。如果在新的 Sprint 周期中要對上次的功能加以優(yōu)化和改進(jìn)，必然離不開重構(gòu)和集成。

在每個(gè) Sprint 周期結(jié)束前，測試團(tuán)隊(duì)將提交針對該 Sprint 周期或者上個(gè) Sprint周期中已完成的功能的驗(yàn)收測試（在實(shí)際項(xiàng)目中，測試團(tuán)隊(duì)的進(jìn)度通常會(huì)晚于開發(fā)團(tuán)隊(duì)）。這樣一來，開發(fā)團(tuán)隊(duì)可以運(yùn)行驗(yàn)收測試來驗(yàn)證所開發(fā)的功能目前是否符合預(yù)期。當(dāng)然，這個(gè)預(yù)期也是在迭代中不斷變化和完善的。

當(dāng)產(chǎn)品的所有功能得以實(shí)現(xiàn)，測試工作基本結(jié)束后，就進(jìn)入了發(fā)布周期。此時(shí)，測試團(tuán)隊(duì)的任務(wù)相對較多。

以上，我們概述了敏捷開發(fā)的主要活動(dòng)。下面我們將對各階段相應(yīng)的測試活動(dòng)作詳細(xì)的介紹和分析。首先是用戶故事設(shè)計(jì)和發(fā)布階段。

3.2 用戶故事設(shè)計(jì)和發(fā)布計(jì)劃階段

在用戶故事和發(fā)布計(jì)劃階段，項(xiàng)目經(jīng)理和產(chǎn)品經(jīng)理會(huì)根據(jù)客戶的需求，制定概要的產(chǎn)品發(fā)布日程計(jì)劃。此時(shí)，測試人員可以和開發(fā)人員一起學(xué)習(xí)新的功能，了解客戶的需求。其中，有兩個(gè)主要活動(dòng)：尋找隱藏的假設(shè)和設(shè)計(jì)概要的驗(yàn)收測試用例。

3.2.1 尋找隱藏的假設(shè)

正如前文所述，開發(fā)人員通常關(guān)注一些重要的系統(tǒng)功能而忽視細(xì)節(jié)。此外，敏捷開發(fā)倡導(dǎo)簡單的實(shí)現(xiàn)方案，每個(gè)開發(fā) Sprint周期不可能將功能完美得實(shí)現(xiàn)；相反，每個(gè) Sprint都會(huì)增量得開發(fā)一些功能。所以，測試人員在最初就需要從各種角度來尋找系統(tǒng)需求，探索隱藏的假設(shè)。

項(xiàng)目實(shí)例：

1. 從在線 B2B 公司角度思考

Q：這個(gè)搜索框?qū)镜臉I(yè)務(wù)有什么價(jià)值？

A：搜索框可以為用戶方便得提供商戶的目錄信息。如果越來越多用戶使用這個(gè)搜索框，可以增加我們網(wǎng)站的訪問量。

2. 從用戶角度思考

Q：作為查詢信息、尋找商業(yè)合作伙伴的網(wǎng)站用戶，搜索框?qū)ξ矣惺裁春锰帲?br>
A：壞處：找到一家商戶的地址，過去才發(fā)現(xiàn)已經(jīng)關(guān)門歇業(yè)

好處：查找商戶很簡單，只要輕點(diǎn)鼠標(biāo)

不快：有時(shí)候在尋找一類商戶，卻記不清楚具體名字

3. 從程序員角度思考

Q：一個(gè)搜索框的最簡單實(shí)現(xiàn)方法是什么？

A：一個(gè)有 text input 和 search button 組成的 form；后臺通過 server 程序?qū)⒎项愋秃偷刂返纳虘裘麖臄?shù)據(jù)庫中取出，返回給用戶；每個(gè)返回項(xiàng)包括商戶的名稱、地址和評價(jià)意見。

4. 尋找這些觀點(diǎn)中的問題

Q：搜索框如何在用戶忘記具體名字的時(shí)候提醒用戶？

A：在第一版本中實(shí)現(xiàn)比較困難。可以讓用戶輸入至少一個(gè)類型來提高模糊查找的效果。

5. 最后尋找到隱藏的假設(shè)

以上的思考讓測試人員對系統(tǒng)的隱含假設(shè)更加清晰：

首先，系統(tǒng)應(yīng)該能夠在高峰時(shí)候處理 200 條搜索請求和 1000 個(gè)鼠標(biāo)點(diǎn)擊事件。

其次，用戶可以在已經(jīng)查找到的內(nèi)容中繼續(xù)查找

最后，系統(tǒng)提供一個(gè)商戶類別清單；如果用戶選擇商戶類別而忘記具體名字，系統(tǒng)提供模糊查詢。

在敏捷開發(fā)中，這些假設(shè)可以作為用戶故事記錄下來，從而指導(dǎo)未來系統(tǒng)的開發(fā)和測試。

3.2.2 設(shè)計(jì)概要的驗(yàn)收測試用例

定義完一系列用戶故事后，測試人員就可以著手設(shè)計(jì)概要的驗(yàn)收測試用例。正如我們在前文論述，不同于單元測試，驗(yàn)收測試檢查系統(tǒng)是否滿足客戶的預(yù)期，也就是用戶故事是否能夠?qū)崿F(xiàn)。于是，測試人員可以根據(jù)每條用戶故事來擴(kuò)展，尋找其中的“動(dòng)作”，然后為每條“動(dòng)作”制定正例和反例。

項(xiàng)目實(shí)例：

3.3 迭代 Sprint 階段

當(dāng)一個(gè) Sprint 周期正式開始時(shí)，項(xiàng)目經(jīng)理將制定該周期的具體開發(fā)和測試任務(wù)。在定期的 Sprint 計(jì)劃會(huì)議（PlanningMeeting）上，每位團(tuán)隊(duì)成員都要提供自己在未來一個(gè) Sprint周期中的休假和培訓(xùn)計(jì)劃。另外，每個(gè)團(tuán)隊(duì)可以根據(jù)各自團(tuán)隊(duì)成員的能力和工作經(jīng)驗(yàn)，適當(dāng)設(shè)定一個(gè)工作負(fù)載值（LoadFactor）。比如，我們團(tuán)隊(duì)的工作負(fù)載值為 75%，也就是說每個(gè)人平均每天工作 6 小時(shí)（以 8 小時(shí)計(jì)算）。接著，大家就可以開始分配任務(wù)。

當(dāng)開發(fā)團(tuán)隊(duì)開始編碼和單元測試時(shí)，測試人員的工作重點(diǎn)包括：估算驗(yàn)收測試的時(shí)間、估算測試框架的搭建、詳細(xì)設(shè)計(jì)驗(yàn)收測試和編寫驗(yàn)收測試代碼。第兩個(gè)主要活動(dòng)一般在項(xiàng)目初期的 Sprint 周期中完成。其他的三個(gè)主要活動(dòng)將在接下來的多個(gè) Sprint周期中視情況迭代進(jìn)行。下面我們將具體介紹每個(gè)主要活動(dòng)。

3.3.1 估算驗(yàn)收測試時(shí)間

在軟件開發(fā)初期，需要估算時(shí)間以制定計(jì)劃。這一點(diǎn)在敏捷開發(fā)中應(yīng)用更加廣泛。如果以前的開發(fā)模式需要測試人員估算一個(gè)軟件版本發(fā)行的計(jì)劃（這樣的計(jì)劃通常會(huì)延續(xù)幾個(gè)月），那么現(xiàn)在則要在每個(gè) Sprint機(jī)會(huì)會(huì)議上估算兩周到一個(gè)月的任務(wù)。此外，在每天的站立會(huì)議上，測試人員需要不斷得更新自己的估算時(shí)間，以應(yīng)對變化的需求。所以，每個(gè)測試人員都應(yīng)該具備一定的估算任務(wù)能力。下面我們將介紹兩個(gè)通用的估算測試計(jì)劃的方法：

1. 快速而粗糙的方法

從經(jīng)驗(yàn)而言，測試通常占項(xiàng)目開發(fā)的三分之一時(shí)間。如果一個(gè)項(xiàng)目開發(fā)估計(jì)要 30 天 1 人，那么測試時(shí)間為 10 天 1 人。

項(xiàng)目實(shí)例：

搜索框的開發(fā)估計(jì)需要 78 天 1 人完成。但是，考慮到系統(tǒng)有模糊搜索的功能，所以測試任務(wù)可能會(huì)占 40％左右，大概 31 天 1 人。下面列出了具體的任務(wù)：

2. 細(xì)致而周全的方法

這個(gè)方法從測試任務(wù)的基本步驟出發(fā)，進(jìn)行詳細(xì)分類。其中包括 :

1. 測試的準(zhǔn)備（設(shè)計(jì)測試用例、準(zhǔn)備測試數(shù)據(jù)、編寫自動(dòng)測試代碼并完善代碼）
2. 測試的運(yùn)行（建立環(huán)境、執(zhí)行測試、分析和匯報(bào)結(jié)果）
3. 特殊的考慮

項(xiàng)目實(shí)例：

估算單個(gè)測試任務(wù)的事例參見下表：

估算多個(gè)測試任務(wù)的匯總參見下表：

3.3.2 估算測試框架的搭建

測試框架是自動(dòng)測試必不可少的一部分工作。由于敏捷開發(fā)流程倡導(dǎo)快速而高效得完成任務(wù)，這就要求一定的自動(dòng)測試率。一個(gè)完善的測試框架可以大大提高測試效率，及時(shí)反饋產(chǎn)品的質(zhì)量。

在敏捷開發(fā)流程中，在第一個(gè) Sprint 周期里，需要增加一項(xiàng)建立測試框架的任務(wù)。在隨后的迭代過程中，只有當(dāng)測試框架需要大幅度調(diào)整時(shí)，測試團(tuán)隊(duì)才需要考慮將其單獨(dú)作為任務(wù)，否則可以不用作為主要任務(wù)羅列出來。

項(xiàng)目實(shí)例：

考慮該項(xiàng)目剛剛進(jìn)入測試，需要為此建立一個(gè)測試框架。于是，在原先的估算中多增加一些任務(wù)。

3.3.3 詳細(xì)設(shè)計(jì)驗(yàn)收測試用例

完成對測試任務(wù)的估算，接著就可以著手詳細(xì)設(shè)計(jì)驗(yàn)收測試用例。我們可以對概要設(shè)計(jì)中的測試用例進(jìn)行細(xì)化，根據(jù)不同的測試環(huán)境、測試數(shù)據(jù)以及測試結(jié)果，編寫更詳細(xì)的測試用例。另外，可以結(jié)合幾個(gè)用例，完成一個(gè)復(fù)雜的測試操作。

由于敏捷開發(fā)的流程是不斷迭代的過程，所以很多復(fù)雜的功能可能會(huì)在未來的 Sprint周期中被優(yōu)化。對測試人員而言，一個(gè)有效的方法是盡量將一些驗(yàn)證基本功能的測試用例作為基本驗(yàn)證測試用例（Basic VerificationTest Case）在第一時(shí)間實(shí)現(xiàn)自動(dòng)化；而對一些復(fù)雜的功能測試用例，可以先采用手工的方法測試，直到在未來 Sprint周期中該功能達(dá)到穩(wěn)定時(shí)候再考慮自動(dòng)化。此外，對測試中出現(xiàn)的缺陷可以設(shè)計(jì)回歸測試用例（Regression TestCase），為其編寫自動(dòng)測試代碼，使得此類問題在發(fā)布周期（Release Sprint）時(shí)可以順利而高效得進(jìn)行驗(yàn)證。

項(xiàng)目實(shí)例：

基本驗(yàn)證測試用例：

功能測試用例：

3.3.4 編寫驗(yàn)收測試用例

敏捷開發(fā)不提倡撰寫太多的文檔，提倡直接編寫測試用例。此外，測試人員和客戶應(yīng)取得良好的溝通，將這些需求總結(jié)下來，轉(zhuǎn)化成驗(yàn)收測試用例。如果資源充足，最好對驗(yàn)收測試用例建立版本控制機(jī)制。

考慮到需求在每一輪 Sprint 周期中會(huì)不斷得變化，測試團(tuán)隊(duì)要控制測試的自動(dòng)化率，正確估計(jì)未來功能的增減。自動(dòng)化率過高會(huì)導(dǎo)致后期大量測試代碼需要重構(gòu)，反而增加很多工作量。

3.4 Sprint 結(jié)束和下一個(gè) Sprint 開始

在一個(gè) Sprint 周期結(jié)束時(shí)，團(tuán)隊(duì)要舉行一個(gè)回顧會(huì)議（RetrospectiveMeeting）。團(tuán)隊(duì)成員可以在會(huì)議上暢所欲言，指出在過去一個(gè) Sprint周期中可行的，不可行的和有待改進(jìn)的地方。待改進(jìn)之處將在項(xiàng)目經(jīng)理監(jiān)督下于未來的 Sprint 周期中實(shí)現(xiàn)。

由于敏捷開發(fā)倡導(dǎo)增量開發(fā)，當(dāng)新的 Sprint 開始時(shí)，測試團(tuán)隊(duì)需要根據(jù)新 Sprint 周期的開發(fā)進(jìn)度及時(shí)重構(gòu)驗(yàn)收測試。如果新 Sprint 周期沒有具體的新功能開發(fā)，測試團(tuán)隊(duì)可以將精力集中在執(zhí)行驗(yàn)收測試和尋找缺陷上。

如果下一個(gè) Sprint 周期是發(fā)布周期，那么測試人員需要準(zhǔn)備執(zhí)行回歸測試。下面我們來詳細(xì)了解每個(gè)測試活動(dòng)。

3.4.1 重構(gòu)驗(yàn)收測試

正如上文所提及，敏捷開發(fā)是以迭代方式進(jìn)行的，功能在每次迭代中推陳出新。于是，驗(yàn)收測試用例經(jīng)常需要修改或者添加，相應(yīng)的驗(yàn)收測試代碼也需要?jiǎng)h減。這部分工作如果時(shí)間花銷很大，最好在估算的時(shí)候一并提出。

項(xiàng)目實(shí)例：

在下一個(gè) Sprint 周期中，我們需要實(shí)現(xiàn)之前沒有實(shí)現(xiàn)的“模糊查找”功能。測試人員要在新的 Sprint 周期中更新原來的驗(yàn)收測試用例，在測試“搜索”模塊中添加模糊查找測試。重新估算的測試任務(wù)參加下表：

3.4.2 執(zhí)行驗(yàn)收測試

驗(yàn)收測試可以分為兩大類，基本驗(yàn)證測試和功能測試。如果是基本驗(yàn)證測試，推薦開發(fā)人員在運(yùn)行完單元測試和提交代碼前直接運(yùn)行自動(dòng)測試腳本。如果是功能測試，可以在每個(gè) Sprint 后期，新功能代碼提交后，由測試人員單獨(dú)執(zhí)行。

敏捷開發(fā)的開發(fā)和測試是相輔相成的。一旦基本驗(yàn)證測試出現(xiàn)問題，那就說明開發(fā)人員的實(shí)現(xiàn)違反了最初客戶定義的需求，所以不能夠提交。如果功能測試出現(xiàn)問題，那么測試人員要及時(shí)與開發(fā)人員溝通。如果是缺陷，需及時(shí)上報(bào)給項(xiàng)目經(jīng)理，并在每天站立會(huì)議中提出；如果不是，那么繼續(xù)下一項(xiàng)任務(wù)。這個(gè)過程充分體現(xiàn)了敏捷開發(fā)所提倡的團(tuán)隊(duì)交流機(jī)制。

3.4.3 執(zhí)行回歸測試

在發(fā)布周期中，測試人員所肩負(fù)的任務(wù)非常重要，因?yàn)檫@是產(chǎn)品發(fā)布前的最后質(zhì)量檢驗(yàn)。

首先，要建立一套自動(dòng)生成 build、運(yùn)行自動(dòng)測試代碼、手工執(zhí)行測試用例并匯總測試結(jié)果的框架。估算方法參加上文。

其次，定期執(zhí)行各類測試，包括功能和系統(tǒng)測試。

最后，要整理之前在每個(gè)特征測試周期中出現(xiàn)的問題。如果已經(jīng)整理并歸類為回歸測試用例，那么只要定時(shí)執(zhí)行就可以了；否則，需一一添加。如果用例已經(jīng)被自動(dòng)化，可以直接運(yùn)行；如果是手工測試，測試人員需要按照測試用例進(jìn)行操作，最后匯總測試結(jié)果。這部分測試就是所謂的回歸測試。

回頁首

總結(jié)

以上我們回顧了敏捷測試在整個(gè)項(xiàng)目開發(fā)中的基本流程。詳細(xì)介紹了各階段存在的主要測試活動(dòng)，結(jié)合實(shí)際項(xiàng)目，敘述每個(gè)測試活動(dòng)的最佳實(shí)踐。

最后，我們來探討一下測試中的兩個(gè)問題：手工測試和測試報(bào)告。

手工測試和自動(dòng)測試是兩個(gè)主要的測試類型。考慮到敏捷開發(fā)的高效性，自動(dòng)測試會(huì)優(yōu)于手工測試。手工測試有兩個(gè)主要的缺點(diǎn)：不可靠和容易被遺忘。比如，在文中的搜索實(shí)例中，一旦我們重新建立索引，那么先前在搜索文本中出現(xiàn)的文字錯(cuò)誤就無法重現(xiàn)。另外，當(dāng)測試人員按部就班得手工完成一個(gè)一個(gè)測試用例時(shí)，他們很容易遺忘一些特殊的測試用例，很多缺陷因此而被埋沒。敏捷測試主張一些基本的驗(yàn)收測試可以被自動(dòng)化；對一些涉及系統(tǒng)方面的測試，手工測試比較適合。

測試報(bào)告是反映一個(gè)測試團(tuán)隊(duì)工作的最好成果。為適應(yīng)敏捷開發(fā)的節(jié)奏，測試報(bào)告可以以網(wǎng)頁的形式發(fā)布在內(nèi)部的 web 服務(wù)器上，在一些問題區(qū)域上標(biāo)注鮮明的色彩，用來警示團(tuán)隊(duì)中的每個(gè)人。

綜上所述，本文詳細(xì)談?wù)摿嗣艚蓍_發(fā)中測試的各項(xiàng)任務(wù)。希望本文有助于正在使用敏捷模式或者打算使用敏捷模式的團(tuán)隊(duì)更好得理解敏捷測試。

參考資料

學(xué)習(xí)

• 閱讀 Wikipedia 上有關(guān) 敏捷軟件開發(fā) 的討論。
  
  
• “Agile Software Development with Scrum”（Ken Schwaber and Mike Beedle，2002 年）討論了如何使用 SCRUM 來快速得實(shí)現(xiàn)極限編程，同時(shí)生產(chǎn)出高質(zhì)量的軟件產(chǎn)品。
  
  
• “Testing Extreme Programming”（Lisa Crispin and Tip House，2003 年）討論了極限編程中是測試人員的角色，地位；然后，詳細(xì)敘述了在極限編程周期中的各個(gè)測試任務(wù)。
  
  
• 訪問 IBM developerWorks 中國網(wǎng)站 Rational 專區(qū)，獲得關(guān)于 IBM Rational 軟件交付平臺（Rational Software Delivery Platform）產(chǎn)品的技術(shù)資源和最佳實(shí)踐。
  
  
• 訂閱 Rational Edge 中文版，獲取軟件開發(fā)領(lǐng)域的最佳實(shí)踐。
  
  
• 訂閱 IBM developerWorks 時(shí)事通訊，一份關(guān)于 developerWorks 指南、文章、下載、社區(qū)活動(dòng)、網(wǎng)絡(luò)廣播和技術(shù)講座的電子周刊。
  
  
• 學(xué)習(xí) Hello World 系列教程，這是學(xué)習(xí) IBM 軟件工具的快速通道。在每一篇教程中，都會(huì)有快速入門產(chǎn)品演示動(dòng)畫。您可以通過其中的動(dòng)畫演示快速瀏覽如何使用 IBM 軟件完成開發(fā)任務(wù)。
  
  

獲得產(chǎn)品和技術(shù)

• 訪問 IBM Rational 軟件交付平臺 V7 專題，了解 Rational V7 產(chǎn)品的方方面面。
  
  
• 獲取免費(fèi)的 Rational 軟件工具包系列，了解最新的 IBM Rational 軟件開發(fā)工具技術(shù)文檔和資源。
  
  
• 下載免費(fèi)的 IBM Rational 試用版軟件，了解 IBM Rational 軟件的最新特性。
  
  
• 獲取更多 IBM 試用版軟件，并熟練掌握來自 DB2?、Lotus?、Tivoli?，以及 WebSphere? 的開發(fā)工具和中間件產(chǎn)品，用這些試用版軟件開發(fā)您的下一個(gè)項(xiàng)目。這些試用版軟件可以免費(fèi)直接從 developerWorks 下載。