敏捷軟體開發是目前十分流行，並在業界逐步推廣的軟體開發模式。不同與傳統的軟體開發模式，敏捷開發模式有著自己鮮明的價值和方法。其中，敏捷測試部分也同以往的軟體測試流程有所不同。這對測試人員提出了新的要求，帶來了新的挑戰。本文將結合一個軟體專案例項，基於專案開發的不同階段，詳細介紹每個階段的主要測試活動。文中將分析每個主要測試活動的前提條件和目標任務，並根據例項推薦最佳的解決方案。

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

敏捷軟體開發（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）

基於這四點原則，敏捷軟體開發有著自己獨特的流程（參見圖 1）。

圖 1. 敏捷軟體開發流程

整個過程中夾雜了很多在敏捷開發前己經出現的軟體開發方法，包括極限程式設計（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 週期中要對上次的功能加以優化和改進，必然離不開重構和整合。

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

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

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

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

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

3.2.1 尋找隱藏的假設

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

專案例項：

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

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

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

2. 從使用者角度思考

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

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

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

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

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

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

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

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

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

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

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

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

首先，系統應該能夠在高峰時候處理 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 人。下面列出了具體的任務：

任務	估計時間
設計測試用例，準備測試資料（搜尋資料集）	8
載入資料集	2
編寫自動測試程式碼	18
執行測試和彙報結果	3
總結	31

2. 細緻而周全的方法

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

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

專案例項：

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

測試	準備		執行		特殊考慮	估算
1	設計測試用例	0.5	建立環境	0.1
準備測試資料	0.5	執行測試	0.1
編寫自動測試程式碼	0.5	分析結果	0.1
完善自動測試程式碼	2.5	彙報結果	0.1
總共	4	0.4	0	4.4

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

測試任務編號	準備	執行	特殊考慮	估算
1	4	0.4	0	4.4
2	4	0.4	0	4.4
3	12	4.5	8.5	25
4	4	0.4	0	4.4
5	4	0.4	0	4.4
6	4	0.4	0	4.4
7	4	0.4	0	4.4
總共	51.4

3.3.2 估算測試框架的搭建

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

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

專案例項：

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

任務

估算（小時）

選擇測試工具

相關推薦 從一個例項詳解敏捷測試的最佳實踐 敏捷軟體開發是目前十分流行，並在業界逐步推廣的軟體開發模式。不同與傳統的軟體開發模式，敏捷開發模式有著自己鮮明的價值和方法。其中，敏捷測試部分也同以往的軟體測試流程有所不同。這對測試人員提出了新的要求，帶來了新的挑戰。本文將結合一個軟體專案例項，基於專案開發的不同階段，詳細 python+requests介面自動化測試框架例項詳解教程 前段時間由於公司測試方向的轉型，由原來的web頁面功能測試轉變成介面測試，之前大多都是手工進行，利用postman和jmeter進行的介面測試，後來，組內有人講原先web自動化的測試框架移駕成介面的自動化框架，使用的是java語言，但對於一個學java，卻在學python的我來說，覺得python比起jav SpringBoot 入門教程例項詳解（一） 開發第一個SpringBoot應用程式例項 構建你的第一個Spring Boot應用程式 更多精彩請閱讀 東陸之滇的csdn部落格：http://blog.csdn.net/zixiao217 此教程提供一個入門應用程式例子，來展示Spring Boot是如何幫助快速、敏捷開發新一代應用的。你還可以通 一個應用例項詳解卡爾曼濾波及其演算法實現 為了可以更加容易的理解卡爾曼濾波器，這裡會應用形象的描述方法來講解，而不是像大多數參考書那樣羅列一大堆的數學公式和數學符號。但是，他的5條公式是其核心內容。結合現代的計算機，其實卡爾曼的程式相當的簡單，只要你理解了他的那5條公式。在介紹他的5條公式之前，先讓我們來根據下面的例子一步一步的探索。假設我們要研究的 python+requests介面自動化測試框架例項詳解教程（米兔888） 前段時間由於公司測試方向的轉型，由原來的web頁面功能測試轉變成介面測試，之前大多都是手工進行，利用postman和jmeter進行的介面測試，後來，組內有人講原先web自動化的測試框架移駕成介面的自動化框架，使用的是java語言，但對於一個學java，卻在學python的我 Jenkins+Ant+Android+Robitium 例項詳解（打包app，執行Robotium測試，生成測試結果） Jenkins Ant 打包android app，構建Robotium測試，執行Robotium測試，生成測試結果 例項詳解 前言：       眾所周知，Jenkins提供了強大持續整合功能，本文主要是使用Jenkins 整合Ant構建、打包Android工程，並執行基 [Hibernate]七種關聯關係配置檔案和測試例項詳解 用了一天整理下來。所有關係分為以下七種：單向【1-1】雙向【1-1】單向【1-N】雙向【1-N】單向【N-1】單向【N-N】雙向【N-N】1單向【1-1】基於外來鍵的單向【1-1】是【N-1】的特殊形式，要求【N】方唯一。基於外來鍵的單向1-1只需要在原有的<many- tcl/tk例項詳解——返回一個資料夾下所有檔案的絕對路徑 #所有程式碼如下，使用註釋的方式講解指令碼#修改好資料夾和儲存結果路徑，可以把本檔案直接拷貝進tcl直譯器執行 #指令碼目的：返回一個資料夾下所有的檔案的絕對路徑#主要講述和操作的命令cd、pwd、glob#次要命令：file、open、catch #指令碼思想：使用遞迴返回 Linux 檢視系統硬體資訊(例項詳解) ubuntu的測試環境 linux檢視系統的硬體資訊，並不像windows那麼直觀，這裡我羅列了檢視系統資訊的實用命令，並做了分類，例項解說。 cpu lscpu命令，檢視的是cpu的統計資訊. [email protected]:~$ lscpu Architecture: i686 單元測試實戰（四種覆蓋詳解、測試例項） 理論部分 前言 單元測試，就是對某一段細粒度的Java程式碼的邏輯測試。程式碼塊一般指一個Java 方法本身，所有外部依賴都需要mock掉，僅關注程式碼邏輯本身。   需要注意，單測的一個大前提就是需要清楚的知道自己要測試的程式塊所預期的輸入輸出，然後根據這個預期和程式邏輯來書寫case。 [譯]例項詳解防抖與節流（乾貨！！！） lodash原始碼中推薦的文章，為了學習（英語），翻譯了一下~ 原文連結 作者：DAVID CORBACHO 本文來自一位倫敦前端工程師DAVID CORBACHO的技術投稿。我們在之前討論過這個話題（關於防抖與節流），但這次，DAVID CORBACHO通過生動的演示會將它們講的十分清晰，通俗易懂。 C#資料結構之單鏈表(LinkList)例項詳解 本文例項講述了C#資料結構之單鏈表(LinkList)實現方法。分享給大家供大家參考，具體如下： 這裡我們來看下“單鏈表(LinkList)”。在上一篇《C#資料結構之順序表(SeqList)例項詳解》的最後，我們指出了：順序表要求開闢一組連續的記憶體空間，而且插入/刪除元素時，為了保證元素的順序 android平臺下OpenGL ES 3.0例項詳解頂點屬性、頂點陣列 OpenGL ES 3.0學習實踐 android平臺下OpenGL ES 3.0從零開始 android平臺下OpenGL ES 3.0繪製純色背景 android平臺下OpenGL ES 3.0繪製圓點、直線和三角形 android平臺下OpenGL E android平臺下OpenGL ES 3.0例項詳解頂點緩衝區物件(VBO)和頂點陣列物件(VAO) OpenGL ES 3.0學習實踐 android平臺下OpenGL ES 3.0從零開始 android平臺下OpenGL ES 3.0繪製純色背景 android平臺下OpenGL ES 3.0繪製圓點、直線和三角形 android平臺下OpenGL E expect學習筆記及例項詳解 expect學習筆記及例項詳解 引用自：http://wenku.baidu.com/view/b65e103610661ed9ad51f374.html   1. expect 是基於tcl 演變而來的，所以很多語法和tcl 類似，基本的語法如下 所示： 1.1 首行 例項詳解js閉包（一）閉包基本概念及其作用推導 　　在學習前端的過程中，不可避免的要學習到js閉包這個知識點，很多朋友感到對閉包很難理解，也不清楚它有什麼用。本文就詳細介紹一下閉包，並通過幾個小例子來說明下閉包的用處。  一、閉包的概念       閉包的英文單詞是Closure，我先給閉包可 JavaScript中立即執行函式例項詳解 轉載 作者：李牧羊 javascript和其他程式語言相比比較隨意，所以javascript程式碼中充滿各種奇葩的寫法，有時霧裡看花，當然，能理解各型各色的寫法也是對javascript語言特性更進一步的深入理解。這篇文章主要給大家介紹了關於JavaScript中立即執行函式的相關資料，需要的朋友可以參考下。 前言 javascript中this用法例項詳解 JavaScript中的this含義非常豐富，它可以是全域性物件，當前物件或者是任意物件，這都取決於函式的呼叫方式。函式有以下幾種呼叫方式：作為物件方法呼叫、作為函式呼叫、作為建構函式呼叫、apply或call呼叫。 物件方法呼叫 作為物件方法呼叫的時候，this會被繫結到該物件。 ? js事件監聽器用法例項詳解 本文例項講述了js事件監聽器用法。分享給大家供大家參考。具體分析如下： 1、當同一個物件使用.onclick的寫法觸發多個方法的時候，後一個方法會把前一個方法覆蓋掉，也就是說，在物件的onclick事件發生時，只會執行最後繫結的方法。而用事件監聽則不會有覆蓋的現象，每個繫結的事件都會被執行。 Vue鉤子函式生命週期例項詳解 vue生命週期簡介 Vue例項有一個完整的生命週期，也就是從開始建立、初始化資料、編譯模板、掛載Dom、渲染→更新→渲染、解除安裝等一系列過程，我們稱這是Vue的生命週期。通俗說就是Vue例項從建立到銷燬的過程，就是生命週期。 在Vue的整個生命週期中，它提供了一系列的事件，可以讓我們在事件觸發時註冊js