從一個(gè)實(shí)例敏捷測試的最佳實(shí)踐

1、從一個(gè)實(shí)例詳解敏捷測試的最佳實(shí)踐陳曉穎，是 IBM 中國系統(tǒng)技術(shù)實(shí)驗(yàn)室（CSTL）的一名軟件工程師。簡介： 敏捷軟件開發(fā)是目前十分流行，并在業(yè)界逐步推廣的軟件開發(fā)模式。不同與傳統(tǒng)的軟件開發(fā)模式，敏捷開發(fā)模式有著自己鮮明的價(jià)值和方法。其中，敏捷測試部分也同以往的軟件測試流程有所不同。這對測試人員提出了新的要求，帶來了新的挑戰(zhàn)。本文將結(jié)合一個(gè)軟件項(xiàng)目實(shí)例，基于項(xiàng)目開發(fā)的不同階段，詳細(xì)介紹每個(gè)階段的主要測試活動。文中將分析每個(gè)主要測試活動的前提條件和目標(biāo)任務(wù)，并根據(jù)實(shí)例推薦最佳的解決方案。第一部分：敏捷軟件開發(fā)簡介敏捷軟件開發(fā)（Agile Software Development）初起于九十年代中期

2、。最早是為了與傳統(tǒng)的瀑布軟件開發(fā)模式（waterfall model）相比較，所以當(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é)作重

3、于合同談判（Customer collaboration over contract negotiation）4. 隨機(jī)應(yīng)變重于循規(guī)蹈矩（Responding to change over following a plan）基于這四點(diǎn)原則，敏捷軟件開發(fā)有著自己獨(dú)特的流程（參見圖 1）。圖 1. 敏捷軟件開發(fā)流程整個(gè)過程中夾雜了很多在敏捷開發(fā)前己經(jīng)出現(xiàn)的軟件開發(fā)方法，包括極限編程（Extreme Programming,1996）、Scrum（1986）、特征驅(qū)動開發(fā)（Feature Driven Development），測試驅(qū)動開發(fā)（Test Driven Development）等。這些方

4、法在敏捷軟件開發(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ū)動開發(fā)和測試驅(qū)動開發(fā)主要被應(yīng)用于 Sprint 周期中。如果項(xiàng)目進(jìn)行于開發(fā)新功能時(shí)期，這個(gè)階段主要推行特征驅(qū)動開發(fā)。所有測試和開發(fā)人員都將自己的工作重心放在新的功能上面，從開發(fā)和測試兩個(gè)方面來完成各自的任務(wù)。如果項(xiàng)目進(jìn)行于測試新功能時(shí)期，這個(gè)階段需要將工作的重點(diǎn)挪到測試上來。所有的測試和開發(fā)人員都密切關(guān)

5、注著目前版本的缺陷狀況。測試人員需要在每天的站立會議（Daily Standup Meeting）上報(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ā)和測試中的審查過程，極限編程中的同行評審（peer review）思想得到了充分應(yīng)用。代碼和文檔的審查追求簡單而高效。團(tuán)隊(duì)成員兩兩組成一對，互相評審；有時(shí)候，一個(gè)開發(fā)和一個(gè)測試人員也可以組成一對，互相協(xié)作。這樣能夠有助于缺陷和問題在第一時(shí)間被抹殺在萌芽中。敏捷開發(fā)

6、還有以下幾個(gè)關(guān)鍵概念 (Key Issues)：1. 迭代過程（Iterative process）2. 用戶故事（User stories）3. 任務(wù)（Tasks）4. 站立會議（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ì)介紹我們的敏

7、捷開發(fā)團(tuán)隊(duì)由四位開發(fā)人員、兩位測試人員、一位產(chǎn)品設(shè)計(jì)，一位項(xiàng)目經(jīng)理和一位產(chǎn)品經(jīng)理組成（參見圖 2）。每天早上十點(diǎn)，在固定的時(shí)間和會議室里面，團(tuán)隊(duì)會舉行站立會議。這時(shí)候，團(tuán)隊(duì)成員按照既定的順序向項(xiàng)目經(jīng)理匯報(bào)各自前一天完成的任務(wù)，所遇到的困難和當(dāng)天要完成的任務(wù)。同時(shí)，項(xiàng)目經(jīng)理更新 Sprint Backlog（一張制作精良的 Excel 表格），并及時(shí)解決每個(gè)人所提出的問題。圖 2. 敏捷開發(fā)團(tuán)隊(duì)成員由于敏捷開發(fā)要求參與人能夠快速而高效得應(yīng)對變化，所以無形中對測試人員提出很高的要求。2.2 測試人員需要具備的素質(zhì)測試是軟件開發(fā)中不可或缺的一部分。在敏捷軟件開發(fā)中亦是如此。不同的組織給測試人員以不同

8、的稱號：測試開發(fā) (Test Developer)、質(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)。

9、在很多其他的開發(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é)。敏捷方法鼓勵測試人員在 Sprint 計(jì)劃的時(shí)候直接與客戶交流，從自己的經(jīng)驗(yàn)出發(fā)，共同為產(chǎn)品功能制定質(zhì)量要求。2. 交流缺陷（Communication）：敏捷過程強(qiáng)調(diào)團(tuán)隊(duì)中的交流。開發(fā)

10、人員經(jīng)常會專注于重要而新奇的功能，測試人員應(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)告會以網(wǎng)頁的形式顯示在內(nèi)部站點(diǎn)上。每個(gè)團(tuán)隊(duì)成員能夠隨時(shí)獲取。另外，我們的測試框架提供自助測試 (Self-assistan

11、t 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)目流程中的主要測試活動，每個(gè)活動的前提條件和目標(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)會返回具體商戶的列表（參見圖 3）。圖 3. 項(xiàng)目實(shí)例圖

12、典型的敏捷開發(fā)和測試活動參見下表。它主要由三部分構(gòu)成，從最初的用戶故事設(shè)計(jì)和發(fā)布計(jì)劃，到幾次 Sprint 周期的迭代開發(fā)和測試，以及最后的產(chǎn)品發(fā)布階段。每個(gè)時(shí)間段都有相應(yīng)的測試活動。通常 Sprint 周期被分成兩類：特征周期（Feature Sprint）和發(fā)布周期（Release Sprint）。特征周期主要涉及新功能的開發(fā)和各類測試。發(fā)布周期則會結(jié)合計(jì)劃，確定新版本功能，然后對最新的功能進(jìn)行測試。敏捷開發(fā)的主要活動測試活動用戶故事設(shè)計(jì)尋找隱藏的假設(shè)發(fā)布計(jì)劃設(shè)計(jì)概要的驗(yàn)收測試用例迭代 Sprint 估算驗(yàn)收測試時(shí)間編碼和單元測試估算測試框架的搭建重構(gòu)詳細(xì)設(shè)計(jì)驗(yàn)收測試用例集成編寫驗(yàn)收測試用

13、例執(zhí)行驗(yàn)收測試重構(gòu)驗(yàn)收測試Sprint 結(jié)束執(zhí)行驗(yàn)收測試下一個(gè) Sprint 開始執(zhí)行回歸測試發(fā)布發(fā)布在迭代的 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)度通常會晚于開發(fā)團(tuán)隊(duì)）。這樣一來，開發(fā)團(tuán)隊(duì)可以運(yùn)行驗(yàn)收測試來驗(yàn)證所開發(fā)的功能目前是否符合預(yù)期。當(dāng)然

14、，這個(gè)預(yù)期也是在迭代中不斷變化和完善的。當(dāng)產(chǎn)品的所有功能得以實(shí)現(xiàn)，測試工作基本結(jié)束后，就進(jìn)入了發(fā)布周期。此時(shí)，測試團(tuán)隊(duì)的任務(wù)相對較多。以上，我們概述了敏捷開發(fā)的主要活動。下面我們將對各階段相應(yīng)的測試活動作詳細(xì)的介紹和分析。首先是用戶故事設(shè)計(jì)和發(fā)布階段。3.2 用戶故事設(shè)計(jì)和發(fā)布計(jì)劃階段在用戶故事和發(fā)布計(jì)劃階段，項(xiàng)目經(jīng)理和產(chǎn)品經(jīng)理會根據(jù)客戶的需求，制定概要的產(chǎn)品發(fā)布日程計(jì)劃。此時(shí)，測試人員可以和開發(fā)人員一起學(xué)習(xí)新的功能，了解客戶的需求。其中，有兩個(gè)主要活動：尋找隱藏的假設(shè)和設(shè)計(jì)概要的驗(yàn)收測試用例。3.2.1 尋找隱藏的假設(shè)正如前文所述，開發(fā)人員通常關(guān)注一些重要的系統(tǒng)功能而忽視細(xì)節(jié)。此外，敏捷開發(fā)

15、倡導(dǎo)簡單的實(shí)現(xiàn)方案，每個(gè)開發(fā) Sprint 周期不可能將功能完美得實(shí)現(xiàn)；相反，每個(gè) Sprint 都會增量得開發(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ū)ξ矣惺裁春锰?？A：壞處：找到一家商戶的地址，過去才發(fā)現(xiàn)已經(jīng)關(guān)門歇業(yè)好處：查找商戶很簡單，只要輕點(diǎn)鼠標(biāo)不快：有時(shí)候在尋找一類商戶，卻記不清楚具體名字3.

16、 從程序員角度思考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)容

17、中繼續(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ò)展，尋找其中的“動作”，然后為每條“動作”制定正例和反例。項(xiàng)目實(shí)例：動作數(shù)據(jù)期待的結(jié)果搜索一組能成功搜索到的（類別，位置）數(shù)據(jù)在該類別和位置條件下的一組商戶信息搜索一組不能成功搜索到的（類

18、別，位置）數(shù)據(jù)空列表3.3 迭代 Sprint 階段當(dāng)一個(gè) Sprint 周期正式開始時(shí)，項(xiàng)目經(jīng)理將制定該周期的具體開發(fā)和測試任務(wù)。在定期的 Sprint 計(jì)劃會議（Planning Meeting）上，每位團(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ù)載值（Load Factor）。比如，我們團(tuán)隊(duì)的工作負(fù)載值為 75%，也就是說每個(gè)人平均每天工作 6 小時(shí)（以 8 小時(shí)計(jì)算）。接著，大家就可以開始分配任務(wù)。當(dāng)開發(fā)團(tuán)隊(duì)開始編碼和單元測試時(shí)，測試人員的工作重點(diǎn)包括：估算驗(yàn)收測試的時(shí)間、估算測試框架的搭建

19、、詳細(xì)設(shè)計(jì)驗(yàn)收測試和編寫驗(yàn)收測試代碼。第兩個(gè)主要活動一般在項(xiàng)目初期的 Sprint 周期中完成。其他的三個(gè)主要活動將在接下來的多個(gè) Sprint 周期中視情況迭代進(jìn)行。下面我們將具體介紹每個(gè)主要活動。3.3.1 估算驗(yàn)收測試時(shí)間在軟件開發(fā)初期，需要估算時(shí)間以制定計(jì)劃。這一點(diǎn)在敏捷開發(fā)中應(yīng)用更加廣泛。如果以前的開發(fā)模式需要測試人員估算一個(gè)軟件版本發(fā)行的計(jì)劃（這樣的計(jì)劃通常會延續(xù)幾個(gè)月），那么現(xiàn)在則要在每個(gè) Sprint 機(jī)會會議上估算兩周到一個(gè)月的任務(wù)。此外，在每天的站立會議上，測試人員需要不斷得更新自己的估算時(shí)間，以應(yīng)對變化的需求。所以，每個(gè)測試人員都應(yīng)該具備一定的估算任務(wù)能力。下面我們將介紹

20、兩個(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ù)可能會占 40左右，大概 31 天 1 人。下面列出了具體的任務(wù)：任務(wù)估計(jì)時(shí)間設(shè)計(jì)測試用例，準(zhǔn)備測試數(shù)據(jù)（搜索數(shù)據(jù)集）8加載數(shù)據(jù)集2編寫自動測試代碼18執(zhí)行測試和匯報(bào)結(jié)果3總結(jié)312. 細(xì)致而周全的方法這個(gè)方法從測試任務(wù)的基本步驟出發(fā)，進(jìn)行詳細(xì)分類。其中包括 :a. 測試的準(zhǔn)備（設(shè)計(jì)測試用例、準(zhǔn)備測試數(shù)據(jù)、編寫自動測試代碼并

21、完善代碼）b. 測試的運(yùn)行（建立環(huán)境、執(zhí)行測試、分析和匯報(bào)結(jié)果）c. 特殊的考慮項(xiàng)目實(shí)例：估算單個(gè)測試任務(wù)的事例參見下表：測試準(zhǔn)備運(yùn)行特殊考慮估算1設(shè)計(jì)測試用例0.5建立環(huán)境0.1準(zhǔn)備測試數(shù)據(jù)0.5執(zhí)行測試0.1編寫自動測試代碼0.5分析結(jié)果0.1完善自動測試代碼2.5匯報(bào)結(jié)果0.1總共40.404.4估算多個(gè)測試任務(wù)的匯總參見下表：測試任務(wù)編號準(zhǔn)備運(yùn)行特殊考慮估算140.404.4240.404.43124.58.525440.404.4540.404.4640.404.4740.404.4總共51.43.3.2 估算測試框架的搭建測試框架是自動測試必不可少的一部分工作。由于敏捷開發(fā)流程倡導(dǎo)

22、快速而高效得完成任務(wù)，這就要求一定的自動測試率。一個(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ù)。任務(wù)估算（小時(shí)）選擇測試工具3建立測試系統(tǒng)3編寫下載、存放和恢復(fù)測試數(shù)據(jù)的腳本2尋找或建立測試結(jié)果匯報(bào)工具8設(shè)計(jì)具體的搜索測試用例4準(zhǔn)備搜索測試數(shù)據(jù)4編寫和測試“搜索”模塊3編寫和測試“驗(yàn)證返

23、回列表”的模塊1學(xué)習(xí)“在結(jié)果中搜索”的模塊設(shè)計(jì)4編寫和測試“在結(jié)果中搜索”模塊4第一次執(zhí)行測試4分析第一輪測試結(jié)果4第二次執(zhí)行測試4分析第二輪測試結(jié)果4總共523.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ù)雜的功能可能會在未來的 Sprint 周期中被優(yōu)化。對測試人員而言，一個(gè)有效的方法是盡量將一些驗(yàn)證基本功能的測試用例作為基本驗(yàn)證測試用例（Basic V

24、erification Test Case）在第一時(shí)間實(shí)現(xiàn)自動化；而對一些復(fù)雜的功能測試用例，可以先采用手工的方法測試，直到在未來 Sprint 周期中該功能達(dá)到穩(wěn)定時(shí)候再考慮自動化。此外，對測試中出現(xiàn)的缺陷可以設(shè)計(jì)回歸測試用例（Regression Test Case），為其編寫自動測試代碼，使得此類問題在發(fā)布周期（Release Sprint）時(shí)可以順利而高效得進(jìn)行驗(yàn)證。項(xiàng)目實(shí)例：基本驗(yàn)證測試用例：動作數(shù)據(jù)期待的結(jié)果登錄用戶名：（空）密碼：（空）“用戶名和密碼無效”功能測試用例：動作數(shù)據(jù)期待的結(jié)果登錄正確的用戶名和密碼進(jìn)入系統(tǒng)：請輸入搜索條件并點(diǎn)擊“搜索”按鈕搜索錯誤的類型提示正確的類型搜

25、索使用正確的類型商戶列表3.3.4 編寫驗(yàn)收測試用例敏捷開發(fā)不提倡撰寫太多的文檔，提倡直接編寫測試用例。此外，測試人員和客戶應(yīng)取得良好的溝通，將這些需求總結(jié)下來，轉(zhuǎn)化成驗(yàn)收測試用例。如果資源充足，最好對驗(yàn)收測試用例建立版本控制機(jī)制?？紤]到需求在每一輪 Sprint 周期中會不斷得變化，測試團(tuán)隊(duì)要控制測試的自動化率，正確估計(jì)未來功能的增減。自動化率過高會導(dǎo)致后期大量測試代碼需要重構(gòu)，反而增加很多工作量。3.4 Sprint 結(jié)束和下一個(gè) Sprint 開始在一個(gè) Sprint 周期結(jié)束時(shí)，團(tuán)隊(duì)要舉行一個(gè)回顧會議（Retrospective Meeting）。團(tuán)隊(duì)成員可以在會議上暢所欲言，指出在過

26、去一個(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è)測試活動。3.4.1 重構(gòu)驗(yàn)收測試正如上文所提及，敏捷開發(fā)是以迭代方式進(jìn)行的，功能在每次迭代中推陳出新。于是，驗(yàn)收測試用例經(jīng)常需要修改或者添加，相應(yīng)的驗(yàn)收測

27、試代碼也需要刪減。這部分工作如果時(shí)間花銷很大，最好在估算的時(shí)候一并提出。項(xiàng)目實(shí)例：在下一個(gè) Sprint 周期中，我們需要實(shí)現(xiàn)之前沒有實(shí)現(xiàn)的“模糊查找”功能。測試人員要在新的 Sprint 周期中更新原來的驗(yàn)收測試用例，在測試“搜索”模塊中添加模糊查找測試。重新估算的測試任務(wù)參加下表：任務(wù)估計(jì)時(shí)間設(shè)計(jì)測試用例，準(zhǔn)備測試數(shù)據(jù)（模糊搜索數(shù)據(jù)集）2加載數(shù)據(jù)集1編寫自動測試代碼3執(zhí)行測試和匯報(bào)結(jié)果2總結(jié)83.4.2 執(zhí)行驗(yàn)收測試驗(yàn)收測試可以分為兩大類，基本驗(yàn)證測試和功能測試。如果是基本驗(yàn)證測試，推薦開發(fā)人員在運(yùn)行完單元測試和提交代碼前直接運(yùn)行自動測試腳本。如果是功能測試，可以在每個(gè) Sprint 后期