敏捷軟體開發是目前十分流行，並在業界逐步推廣的軟體開發模式。

   不同與傳統的軟體開發模式，敏捷開發模式有著自己鮮明的價值和方法。
   其中，敏捷測試部分也同以往的軟體測試流程有所不同。這對測試人員提出了新的要求，帶來了新的挑戰。

第一部分：敏捷軟體開發簡介

敏捷軟體開發（Agile Software Development）初起於九十年代中期。最早是為了與傳統的瀑布軟體開發模式（waterfall model）相比較，所以當時的方法叫做輕量級方法（Lightweight methods）。二十世紀初，17 位該方法的倡導者建立了敏捷聯盟（Agile Alliance），並將該軟體開發方法命名為敏捷軟體開發過程。

敏捷聯盟在成立之初總結了四條基本的價值原則：

1. 人員交流重於過程與工具（Individuals and interactions over processes and tools）
2. 軟體產品重於長篇大論（Working software over comprehensive documentation）
3. 客戶協作重於合同談判（Customer collaboration over contract negotiation）
4. 隨機應變重於循規蹈矩（Responding to change over following a plan）

基於這四點原則，敏捷軟體開發有著自己獨特的流程

整個過程中夾雜了很多在敏捷開發前己經出現的軟體開發方法，包括極限程式設計（Extreme Programming,1996）、Scrum（1986）、特徵驅動開發（Feature Driven Development），測試驅動開發（Test Driven Development）等。這些方法在敏捷軟體開發流程的各個階段都有充分的體現和應用。

例如，Scrum 主要著重於專案管理，團隊中的專案經理（Scrum master）需要在每個客戶需求到來的時候制定 Sprint 的週期，定義每個 Sprint 的目標、分派任務、進行監督、最後總結得失並開始計劃新的 Sprint。

相反，特徵驅動開發和測試驅動開發主要被應用於 Sprint 週期中。如果專案進行於開發新功能時期，這個階段主要推行特徵驅動開發。所有測試和開發人員都將自己的工作重心放在新的功能上面，從開發和測試兩個方面來完成各自的任務。如果專案進行於測試新功能時期，這個階段需要將工作的重點挪到測試上來。所有的測試和開發人員都密切關注著目前版本的缺陷狀況。測試人員需要在每天的站立會議（Daily Standup Meeting）上報告前一個工作日發現的新缺陷情況，專案經理根據專案進度和缺陷嚴重性來決定是否修復這些問題。需要及時修復的缺陷是目前 Sprint 中的一個新任務，將由專案經理新增到 Sprint Backlog 上並通知開發人員去修復漏洞。

對於敏捷開發和測試中的審查過程，極限程式設計中的同行評審（peer review）思想得到了充分應用。程式碼和文件的審查追求簡單而高效。團隊成員兩兩組成一對，互相評審；有時候，一個開發和一個測試人員也可以組成一對，互相協作。這樣能夠有助於缺陷和問題在第一時間被抹殺在萌芽中。

敏捷開發還有以下幾個關鍵概念 (Key Issues)：

1. 迭代過程（Iterative process）
2. 使用者故事（User stories）
3. 任務（Tasks）
4. 站立會議（Stand-up meeting）
5. 持續整合（Continuous integration）
6. 最簡方案（Simplest solutions）
7. 重構（Re-factoring）

這些概念是敏捷開發中經常使用到的觀點和方法。下面我們將詳細論述測試人員在敏捷軟體開發中扮演的角色和職能。

第二部分：敏捷開發中的測試人員

本部分將簡要介紹敏捷開發中測試人員所需要具備的素質和職責。

2.1 敏捷開發團隊介紹

我們的敏捷開發團隊由四位開發人員、兩位測試人員、一位產品設計，一位專案經理和一位產品經理組成（參見圖 2）。每天早上十點，在固定的時間和會議室裡面，團隊會舉行站立會議。這時候，團隊成員按照既定的順序向專案經理彙報各自前一天完成的任務，所遇到的困難和當天要完成的任務。同時，專案經理更新 Sprint Backlog（一張製作精良的 Excel 表格），並及時解決每個人所提出的問題。

圖 2. 敏捷開發團隊成員

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

2.2 測試人員需要具備的素質

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

每個稱號隱含有不同的職能。以上的稱號分別對應以下的能力要求：

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

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

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

2.3 測試人員的主要職責

在敏捷軟體開發中，測試人員的職責有三個主要方面：

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

以上總結了測試人員在敏捷開發中的需要展現的能力和擔負的任務，下面請跟隨一個專案例項來詳細瞭解敏捷測試的最佳實踐。

第三部分：敏捷開發中的測試流程

本部分結合一個軟體專案，詳細介紹專案流程中的主要測試活動，每個活動的前提條件和目標任務等。

3.1 介紹專案例項

專案介紹：根據一家線上 B2B 公司的要求，我們將為其開發一款類似於谷歌的搜尋服務。作為 Web Service，該服務可以內嵌於網頁中。當用戶輸入關鍵詞並選擇商戶的型別和位置後，系統會返回具體商戶的列表（參見圖 3）。

圖 3. 專案例項圖

典型的敏捷開發和測試活動參見下表。它主要由三部分構成，從最初的使用者故事設計和釋出計劃，到幾次 Sprint 週期的迭代開發和測試，以及最後的產品釋出階段。每個時間段都有相應的測試活動。通常 Sprint 週期被分成兩類：特徵週期（Feature Sprint）和釋出週期（Release Sprint）。特徵週期主要涉及新功能的開發和各類測試。釋出週期則會結合計劃，確定新版本功能，然後對最新的功能進行測試。

在迭代的 Sprint 週期中，開發部分可以根據傳統步驟分成編碼和單元測試、重構和整合。需要指出的是，重構和整合是敏捷開發的 Sprint 迭代中不可忽視的任務。如果在新的 Sprint 週期中要對上次的功能加以優化和改進，必然離不開重構和整合。

在每個 Sprint 週期結束前，測試團隊將提交針對該 Sprint 週期或者上個 Sprint 週期中已完成的功能的驗收測試（在實際專案中，測試團隊的進度通常會晚於開發團隊）。這樣一來，開發團隊可以執行驗收測試來驗證所開發的功能目前是否符合預期。當然，這個預期也是在迭代中不斷變化和完善的。

當產品的所有功能得以實現，測試工作基本結束後，就進入了釋出週期。此時，測試團隊的任務相對較多。

以上，我們概述了敏捷開發的主要活動。下面我們將對各階段相應的測試活動作詳細的介紹和分析。首先是使用者故事設計和釋出階段。

3.2 使用者故事設計和釋出計劃階段

在使用者故事和釋出計劃階段，專案經理和產品經理會根據客戶的需求，制定概要的產品釋出日程計劃。此時，測試人員可以和開發人員一起學習新的功能，瞭解客戶的需求。其中，有兩個主要活動：尋找隱藏的假設和設計概要的驗收測試用例。

3.2.1 尋找隱藏的假設

正如前文所述，開發人員通常關注一些重要的系統功能而忽視細節。此外，敏捷開發倡導簡單的實現方案，每個開發 Sprint 週期不可能將功能完美得實現；相反，每個 Sprint 都會增量得開發一些功能。所以，測試人員在最初就需要從各種角度來尋找系統需求，探索隱藏的假設。

專案例項：

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

Q：這個搜尋框對公司的業務有什麼價值？

A：搜尋框可以為使用者方便得提供商戶的目錄資訊。如果越來越多使用者使用這個搜尋框，可以增加我們網站的訪問量。

1. 從使用者角度思考

Q：作為查詢資訊、尋找商業合作伙伴的網站使用者，搜尋框對我有什麼好處？

A：壞處：找到一家商戶的地址，過去才發現已經關門歇業

好處：查詢商戶很簡單，只要輕點滑鼠

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

1. 從程式設計師角度思考

Q：一個搜尋框的最簡單實現方法是什麼？

A：一個有 text input 和 search button 組成的 form；後臺通過 server 程式將符合型別和地址的商戶名從資料庫中取出，返回給使用者；每個返回項包括商戶的名稱、地址和評價意見。

1. 尋找這些觀點中的問題

Q：搜尋框如何在使用者忘記具體名字的時候提醒使用者？

A：在第一版本中實現比較困難。可以讓使用者輸入至少一個型別來提高模糊查詢的效果。

1. 最後尋找到隱藏的假設

以上的思考讓測試人員對系統的隱含假設更加清晰：

首先，系統應該能夠在高峰時候處理 200 條搜尋請求和 1000 個滑鼠點選事件。

其次，使用者可以在已經查詢到的內容中繼續查詢

最後，系統提供一個商戶類別清單；如果使用者選擇商戶類別而忘記具體名字，系統提供模糊查詢。

在敏捷開發中，這些假設可以作為使用者故事記錄下來，從而指導未來系統的開發和測試。

3.2.2 設計概要的驗收測試用例

定義完一系列使用者故事後，測試人員就可以著手設計概要的驗收測試用例。正如我們在前文論述，不同於單元測試，驗收測試檢查系統是否滿足客戶的預期，也就是使用者故事是否能夠實現。於是，測試人員可以根據每條使用者故事來擴充套件，尋找其中的“動作”，然後為每條“動作”制定正例和反例。

專案例項：

3.3 迭代 Sprint 階段

當一個 Sprint 週期正式開始時，專案經理將制定該週期的具體開發和測試任務。在定期的 Sprint 計劃會議（Planning Meeting）上，每位團隊成員都要提供自己在未來一個 Sprint 週期中的休假和培訓計劃。另外，每個團隊可以根據各自團隊成員的能力和工作經驗，適當設定一個工作負載值（Load Factor）。比如，我們團隊的工作負載值為 75%，也就是說每個人平均每天工作 6 小時（以 8 小時計算）。接著，大家就可以開始分配任務。

當開發團隊開始編碼和單元測試時，測試人員的工作重點包括：估算驗收測試的時間、估算測試框架的搭建、詳細設計驗收測試和編寫驗收測試程式碼。第兩個主要活動一般在專案初期的 Sprint 週期中完成。其他的三個主要活動將在接下來的多個 Sprint 週期中視情況迭代進行。下面我們將具體介紹每個主要活動。

3.3.1 估算驗收測試時間

在軟體開發初期，需要估算時間以制定計劃。這一點在敏捷開發中應用更加廣泛。如果以前的開發模式需要測試人員估算一個軟體版本發行的計劃（這樣的計劃通常會延續幾個月），那麼現在則要在每個 Sprint 機會會議上估算兩週到一個月的任務。此外，在每天的站立會議上，測試人員需要不斷得更新自己的估算時間，以應對變化的需求。所以，每個測試人員都應該具備一定的估算任務能力。下面我們將介紹兩個通用的估算測試計劃的方法：

1. 快速而粗糙的方法

從經驗而言，測試通常佔專案開發的三分之一時間。如果一個專案開發估計要 30 天 1 人，那麼測試時間為 10 天 1 人。

專案例項：

搜尋框的開發估計需要 78 天 1 人完成。但是，考慮到系統有模糊搜尋的功能，所以測試任務可能會佔 40％左右，大概 31 天 1 人。下面列出了具體的任務：

1. 細緻而周全的方法

這個方法從測試任務的基本步驟出發，進行詳細分類。其中包括 :

1. 測試的準備（設計測試用例、準備測試資料、編寫自動測試程式碼並完善程式碼）
2. 測試的執行（建立環境、執行測試、分析和彙報結果）
3. 特殊的考慮

專案例項：

估算單個測試任務的事例參見下表：

估算多個測試任務的彙總參見下表：

3.3.2 估算測試框架的搭建

測試框架是自動測試必不可少的一部分工作。由於敏捷開發流程倡導快速而高效得完成任務，這就要求一定的自動測試率。一個完善的測試框架可以大大提高測試效率，及時反饋產品的質量。

在敏捷開發流程中，在第一個 Sprint 週期裡，需要增加一項建立測試框架的任務。在隨後的迭代過程中，只有當測試框架需要大幅度調整時，測試團隊才需要考慮將其單獨作為任務，否則可以不用作為主要任務羅列出來。

專案例項：

考慮該專案剛剛進入測試，需要為此建立一個測試框架。於是，在原先的估算中多增加一些任務。

3.3.3 詳細設計驗收測試用例

完成對測試任務的估算，接著就可以著手詳細設計驗收測試用例。我們可以對概要設計中的測試用例進行細化，根據不同的測試環境、測試資料以及測試結果，編寫更詳細的測試用例。另外，可以結合幾個用例，完成一個複雜的測試操作。

由於敏捷開發的流程是不斷迭代的過程，所以很多複雜的功能可能會在未來的 Sprint 週期中被優化。對測試人員而言，一個有效的方法是儘量將一些驗證基本功能的測試用例作為基本驗證測試用例（Basic Verification Test Case）在第一時間實現自動化；而對一些複雜的功能測試用例，可以先採用手工的方法測試，直到在未來 Sprint 週期中該功能達到穩定時候再考慮自動化。此外，對測試中出現的缺陷可以設計迴歸測試用例（Regression Test Case），為其編寫自動測試程式碼，使得此類問題在釋出週期（Release Sprint）時可以順利而高效得進行驗證。

專案例項：

基本驗證測試用例：

功能測試用例：

3.3.4 編寫驗收測試用例

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

考慮到需求在每一輪 Sprint 週期中會不斷得變化，測試團隊要控制測試的自動化率，正確估計未來功能的增減。自動化率過高會導致後期大量測試程式碼需要重構，反而增加很多工作量。

3.4 Sprint 結束和下一個 Sprint 開始

在一個 Sprint 週期結束時，團隊要舉行一個回顧會議（Retrospective Meeting）。團隊成員可以在會議上暢所欲言，指出在過去一個 Sprint 週期中可行的，不可行的和有待改進的地方。待改進之處將在專案經理監督下於未來的 Sprint 週期中實現。

由於敏捷開發倡導增量開發，當新的 Sprint 開始時，測試團隊需要根據新 Sprint 週期的開發進度及時重構驗收測試。如果新 Sprint 週期沒有具體的新功能開發，測試團隊可以將精力集中在執行驗收測試和尋找缺陷上。

如果下一個 Sprint 週期是釋出週期，那麼測試人員需要準備執行迴歸測試。下面我們來詳細瞭解每個測試活動。

3.4.1 重構驗收測試

正如上文所提及，敏捷開發是以迭代方式進行的，功能在每次迭代中推陳出新。於是，驗收測試用例經常需要修改或者新增，相應的驗收測試程式碼也需要刪減。這部分工作如果時間花銷很大，最好在估算的時候一併提出。

專案例項：

在下一個 Sprint 週期中，我們需要實現之前沒有實現的“模糊查詢”功能。測試人員要在新的 Sprint 週期中更新原來的驗收測試用例，在測試“搜尋”模組中新增模糊查詢測試。重新估算的測試任務參加下表：

3.4.2 執行驗收測試

驗收測試可以分為兩大類，基本驗證測試和功能測試。如果是基本驗證測試，推薦開發人員在執行完單元測試和提交程式碼前直接執行自動測試指令碼。如果是功能測試，可以在每個 Sprint 後期，新功能程式碼提交後，由測試人員單獨執行。

敏捷開發的開發和測試是相輔相成的。一旦基本驗證測試出現問題，那就說明開發人員的實現違反了最初客戶定義的需求，所以不能夠提交。如果功能測試出現問題，那麼測試人員要及時與開發人員溝通。如果是缺陷，需及時上報給專案經理，並在每天站立會議中提出；如果不是，那麼繼續下一項任務。這個過程充分體現了敏捷開發所提倡的團隊交流機制。

3.4.3 執行迴歸測試

在釋出週期中，測試人員所肩負的任務非常重要，因為這是產品釋出前的最後質量檢驗。

首先，要建立一套自動生成 build、執行自動測試程式碼、手工執行測試用例並彙總測試結果的框架。估算方法參加上文。

其次，定期執行各類測試，包括功能和系統測試。

最後，要整理之前在每個特徵測試周期中出現的問題。如果已經整理並歸類為迴歸測試用例，那麼只要定時執行就可以了；否則，需一一新增。如果用例已經被自動化，可以直接執行；如果是手工測試，測試人員需要按照測試用例進行操作，最後彙總測試結果。這部分測試就是所謂的迴歸測試。

總結

以上我們回顧了敏捷測試在整個專案開發中的基本流程。詳細介紹了各階段存在的主要測試活動，結合實際專案，敘述每個測試活動的最佳實踐。

最後，我們來探討一下測試中的兩個問題：手工測試和測試報告。

手工測試和自動測試是兩個主要的測試型別。考慮到敏捷開發的高效性，自動測試會優於手工測試。手工測試有兩個主要的缺點：不可靠和容易被遺忘。比如，在文中的搜尋例項中，一旦我們重新建立索引，那麼先前在搜尋文字中出現的文字錯誤就無法重現。另外，當測試人員按部就班得手工完成一個一個測試用例時，他們很容易遺忘一些特殊的測試用例，很多缺陷因此而被埋沒。敏捷測試主張一些基本的驗收測試可以被自動化；對一些涉及系統方面的測試，手工測試比較適合。

測試報告是反映一個測試團隊工作的最好成果。為適應敏捷開發的節奏，測試報告可以以網頁的形式釋出在內部的 web 伺服器上，在一些問題區域上標註鮮明的色彩，用來警示團隊中的每個人。

綜上所述，本文詳細談論了敏捷開發中測試的各項任務。希望本文有助於正在使用敏捷模式或者打算使用敏捷模式的團隊更好得理解敏捷測試。

附錄：敏捷開發管理工具

很早以前，就有這麼一個想法：開發一套高效的、用於軟體開發行業進行專案管理的管理型軟體。之所以有這個想法，與我本人的經歷有關。早年，在做**系統的時候，部門的總監就讓我去做那麼一套東西，基於Visual Basic和adodb，當時確實是經驗、眼界、思路都不足，確實帶著嘗試和研究的心態去做了，只是限於以上的侷限性，做出來的東西怎麼說呢？顯得很小家子氣，因為沒有做專門的介面設計，UI設計也不大氣，在部門內部只能實現基於區域網的任務分發、週報編寫和文件的上傳。

1、Leangoo，這個工具是我通過網路搜尋瞭解到的，通過網站，我註冊了一個賬號，新建了一個product backlog並查看了網站現有的部分例項，總體來說，綜合了敏捷開發管理的思路，檢視清晰，感覺不錯。

2、Teambition，這個是之前就瞭解到過的一個軟體，有網路版也有app版本。有任務管理、FAQ管理什麼的，也還不錯，但敏捷性管理的任務卡片、看板、燃盡圖什麼的概念在軟體內好像沒展現。給我印象最深的是FAQ，也許是和我本人的工作性質有關係，個人覺得這個模組比較實用。這些是之前的狀況，不知道現在是否有改版，好久沒有去看了，也許有更新吧。

3、Worktile ， 在Worktile中，我們進入的預設頁面是“訊息”這個IM，這個即時通訊功能正是溝通的體現。而在企業協作場景中，任務又是溝通後的最初成果，也是即將展開的各項工作的核心，而Worktile的核心就是任務這件事。

·