究竟什么是敏捷測試(2)

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

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

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

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

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

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

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

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

　　2. Scrum的敏捷測試

　　下面就以流行的敏捷框架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”的驗證，但基本的思想和傳統開發是一致的，任何沒有經過驗證的產品特性是不能直接發布出去的。

　　3. 結論

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

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