究竟什麼是靈活測試

轉：http://blog.csdn.net/kerryzhu/article/details/8812589

首先，可以明确的是，靈活測試既不是一種方法（如黑盒方法、白盒方法等），也不是一種方式（如探索式測試）。因為在靈活測試中可以采用已有的各種方法，包括白盒方法、黑盒方法；在靈活中也可以采用探索式測試（exploratory test），也可以采用基于腳本的測試（scripted test）。那靈活測試是什麼？靈活測試應該是一套解決方案、一類測試操作與管理的架構、一組實踐或由一定順序的測試活動構成的特定的測試流程。就像Scrum一樣，Scrum可以了解為靈活方法的具體實作的架構、一組實踐或具體的解決方案。簡單地說，靈活測試就是順應靈活開發方法、力求達到品質和效率平衡的一系列的測試實踐。讓我們看看Wikipedia 是如何描述靈活測試的：

先從靈活開發這一方法論層次來讨論什麼是靈活測試，即靈活測試有什麼具體特征，或有哪些主要實踐，然後再就目前非常熱的靈活具體架構Scrum來讨論Scrum中的靈活測試（或稱為Scrum Testing）。先研究一下靈活宣言背後所蘊含的12條原則[5]：

1) 我們最重要的目标，是通過持續不斷地及早傳遞有價值的軟體使客戶滿意。

2) 欣然面對需求變化，即使在開發後期也一樣。為了客戶的競争優勢，靈活過程掌控變化。

3) 經常地傳遞可工作的軟體，相隔幾星期或一兩個月，傾向于采取較短的周期。

4) 業務人員和開發人員必須互相合作，項目中的每一天都不例外。

5) 激發個體的鬥志，以他們為核心搭建項目。提供所需的環境和支援，輔以信任，進而達成目标。

6) 不論團隊内外，傳遞資訊效果最好效率也最高的方式是面對面的交談。

7) 可工作的軟體是進度的首要度量标準。

8) 靈活過程倡導可持續開發。責任人、開發人員和使用者要能夠共同維持其步調穩定延續。

9) 堅持不懈地追求技術卓越和良好設計，靈活能力由此增強。

10) 以簡潔為本，它是極力減少不必要工作量的藝術。

12) 團隊定期地反思如何能提高成效，并依此調整自身的舉止表現。

這12條原則中沒有一條直接談到測試，那是否說明沒有靈活測試呢？有開發就有測試，隻是原來參加靈活宣言的17人，基本是清一色程式員，沒有在原則中單獨闡述一下測試的原則。但其中一些原則和測試的關聯性很強，例如：

1) 軟體測試如何支撐或協助“持續不斷地及早傳遞有價值的軟體”？如何在非常有限的時間内進行充分的測試？這就是我們經常在靈活測試中強調的“自動化測試”，如果沒有自動化測試，就沒有靈活，就不能持續不斷地及早傳遞有價值的軟體，而且還要“使客戶滿意”。

2) “欣然面對需求變化，即使在開發後期也一樣”和傳統的開發原則是不同的，傳統的開發希望有嚴格的需求變更控制，越到後期控制越嚴。而靈活開發擁抱變化，那麼測試如何适應這種變化？如何快速地完成回歸測試？這可能要依賴于開發做好單元測試，或全員參與測試，以及全面支援系統級的、端到端的回歸測試的自動化測試執行。

3) 傳統的開發也要求“業務人員和開發人員必須互相合作”，但存在一定的階段性，例如前期需求評審、期間産品走查（product walk-through）、後期驗收測試等要求有緊密的溝通與協作。但靈活開發更強調“項目中的每一天都不例外”，在這樣的原則下，如何去做靈活測試？這樣可以減少測試文檔，剛開始也沒必要把測試計劃寫得很詳細，而是寫一頁紙測試計劃就可以，将來再持續的完善和調整。

4) “可工作的軟體是進度的首要度量标準”，不再是測試計劃完成情況、完成的測試用例數目、測試腳本量等，而是如何及時驗證每天完成的功能特性。開發的工作量也不能按代碼行來衡量，而是看多少個具體的使用者故事（功能特性）被實作了（done）。某個開發說已完成了某個使用者故事，要麼是通過他自己的驗證，要麼是通過測試人員的驗證，誰做的測試不重要，關鍵是要有準備好的測試，随時驗證已完成的工作。

5) “堅持不懈地追求技術卓越和良好設計”，一方面要求測試的技術要不斷提高，在處理每個測試任務時，都應該找到最有效的辦法；另方面，在前期要更多地參與設計評審，及時發現設計的問題。隻有良好的設計，才能更好地支援系統的功能擴充和不斷的重構。

基于這些原則，我們就可以概括一下靈活測試的一些特點：

1) 靈活測試一定是靈活開發方法的一部分，應符合靈活測試宣言的思想，也遵守上面所列的靈活開發的原則，強調測試人員的個人技能，始終保持與客戶/使用者、其它成員（特别是業務人員、産品設計人員等）的緊密協作，建立良好的測試架構（特别是持續內建測試和自動化回歸測試的基礎設施）以适應需求的變化，更關注被測系統的本身而不是測試文檔（如測試計劃、測試用例等）。

2) 靈活測試具有鮮明的靈活開發的特征，如測試驅動開發（TDD）、驗收測試驅動開發（ATDD），可以見我的另一篇文章《靈活測試的思考和新發展》所讨論的。測試驅動開發的思想是靈活測試的核心，或者說，單元測試是靈活測試的基礎，如果沒有足夠的單元測試就無法應付将來需求的快速變化、也無法實作持續的傳遞。這也說明，在靈活測試中，開發人員承擔更多的測試，這也就是我們說的，在靈活測試中，是整個團隊的共同努力。在靈活測試中，可以沒有專職的測試人員，每個人都可以主動去取設計任務、代碼任務做，也可以去拿測試任務來做。在靈活測試中，也可以像開發人員的結對程式設計那樣，實踐結對測試——一個測試人員對應一個開發人員、或一個測試人員對應另一個測試人員。

3) 靈活測試無處不在、無時不在。在傳統測試裡也提倡盡早測試，包括需求和設計的評審；在傳統測試裡也提倡全過程測試。但在傳統測試裡階段性特征相對突出一些，例如，需求評審，意味着先讓産品人員去寫需求，但需求文檔寫好之後，測試人員再參加評審。而在靈活測試裡，團隊每一天都在一起工作，一起讨論需求、一起評審需求。在靈活測試中，這種持續性更為顯著一些。

4) 靈活測試是基于自動化測試的，自動化測試在靈活測試中占有絕對的主導地位。在傳統測試中也提倡自動化測試，但由于傳統開發的周期比較長（幾個月到幾年），即使沒有自動化測試也是可以應付的，一般來說，回歸測試能夠獲得幾周時間，甚至1-2個月的時間。而靈活測試的持續性迫切要求測試的高度自動化，在1-3天内就有完成整個的驗收測試（包括回歸測試）。沒有自動化，就沒有靈活。

下面就以流行的靈活架構Scrum來讨論靈活測試，會更具體一些，會更具可操作性。我們通過下面圖2再複習一下Scrum的模型，但這裡就不詳細介紹了。

圖2 Scrum過程示意圖

從圖中可以看出，除了最後“驗收測試”階段，其它過程似乎沒有顯著的測試特征，但隐含的測試需求和特征還是存在的。

1) Product Backlog （需求定義階段），在定義使用者需求時測試要做什麼？測試需要考慮客戶的價值大小（優先級）、工作量基本估算之外，需要認真研究與産品相關的使用者的行為模式（如BDD），産品的品質需求，哪些品質特性是我們需要考慮的？有哪些競争産品？這些競争産品有什麼特點（優點、缺點等）？

2) Sprint Backlog（階段性任務劃分和安排），這時候需要明确具體要實作的功能特性和任務，作為測試，這時候要特别關注“Definition of Done”，即每項任務結束的要求——即任務完成的驗收标準，特别是功能特性的設計和代碼實作的驗收标準。ATDD的關鍵一步也展現在這裡，在設計、寫代碼之前，就要将驗收标準确定下來。一方面符合測試驅動開發思想，第一次就要把事情做對，預防缺陷；另方面持續測試和驗收測試的依據也清楚了，可以快速做出測試通過與否的判斷。

3) 在每個疊代（Sprint）實施階段，主要完成Sprint Backlog所定義的任務，這時除了TDD或單元測試之外，應該進行持續內建測試或通常說的BVT（Build Verification Test）。而且開發人員在設計、寫代碼時都會認真考慮每一元件或每一代碼塊都具有可測試性，因為測試任務可能由他們自己來完成。如果有專職的測試人員角色，一方面可以完善單元測試、內建測試架構，協助開發人員進行單元測試；另方面可以按照針對新實作的功能特性進行更多的探索式測試，同時開發驗收測試的腳本。如果沒有專職的測試人員角色，這些事情也是要完成，隻是由整個團隊共同完成。雖沒有工種的分工，但也存在任務的分工。

4) 驗收測試可以由自動化測試工具完成，但一般情況下，不可能做到百分之百的自動化測試。例如易用性測試就很難由工具完成。即使對性能測試，是由工具完成，但還需要人來設計測試場景，包括關鍵業務選擇、負載模式等。靈活的驗收測試，和傳統的驗收測試不同，側重對“Definition of Done”的驗證，但基本的思想和傳統開發是一緻的，任何沒有經過驗證的産品特性是不能直接釋出出去的。

靈活測試就是符合靈活宣言思想，遵守靈活開發原則，在靈活開發環境下能夠很好地和其整體開發流程融合的一系列的測試實踐，這些實踐具有鮮明的靈活開發的特征，如TDD、ATDD、結對程式設計、持續測試等。和傳統測試的區分，可以概括如下：

1) 傳統測試更強調測試的獨立性，将“開發人員”和“測試人員”角色分得比較清楚。而靈活測試可以有專職的測試人員，也可以是全民測試，即在靈活測試中，可以沒有“測試人員”角色，強調整個團隊對測試負責。

2) 傳統測試更具有階段性，從需求評審、設計評審、單元測試到內建測試、系統測試等，從測試計劃、測試設計再到測試執行、測試報告等，但靈活測試更強調持續測試、持續的品質回報，階段性比較模糊。

3) 傳統測試強調測試的計劃性，認為沒有良好的測試計劃和不按計劃執行，測試就難以控制和管理，而靈活測試更強調測試的速度和适應性，側重計劃的不斷調整以适應需求的變化。

4) 傳統測試強調測試是由“驗證”和“确認”兩種活動構成的，而靈活測試沒有這種區分，始終以使用者需求為中心，每時每刻不離使用者需求，将驗證和确認統一起來。

5) 傳統測試強調任何發現的缺陷要記錄下來，以便進行缺陷根本原因分析，達到缺陷預防的目的，并強調缺陷跟蹤和處理的流程，區分測試人員和開發人員的各自不同的責任。而靈活測試強調面對面的溝通、協作，強調團隊的責任，不太關注對缺陷的記錄與跟蹤。

6) 傳統測試更關注缺陷，圍繞缺陷開展一系列的活動，如缺陷跟蹤、缺陷度量、缺陷分析、缺陷報告品質檢查等，而靈活測試更關注産品本身，關注可以傳遞的客戶價值。在快速傳遞的靈活開發模式下，缺陷修複的成本很低。

7) 傳統測試鼓勵自動化測試，但自動化測試的成功與否對測試沒有緻命的影響，但靈活測試的基礎就是自動化測試，靈活測試是具有良好的自動化測試架構支撐的快速測試。

如何聯系我：【萬裡虎】www.bravetiger.cn

【QQ】3396726884 （咨詢問題100元起，幫助解決問題500元起）

【部落格】http://www.cnblogs.com/kenshinobiy/