淺析敏捷測試及其實踐運用
引言
隨著互聯網技術的發展，產品的快速迭代且能適應市場需求已經成為各大公司的痛點。而傳統的開發模式已經不再適用于快速迭代的產品，在這種情況下，敏捷開發模式因其高度迭代、頻繁交付以及適應變化的特點，已經在各個領域得到廣泛應用。與此同時，敏捷開發的發展對軟件測試也提出了更高的要求。因此，敏捷測試對提高測試效率進而提升產品交付質量具有重大意義。
敏捷開發的發展與特點
在2001年2月，Martin Fowler和他的同事提出了敏捷宣言，指出：
- 個體和交互勝過流程和工具;
- 可用的軟件勝過完備的文檔;
- 客戶協作勝過合同談判;
- 響應變化勝過遵循計劃。
無論什么行業或產品，軟件開發的最終目標就是為了能滿足客戶的需求，實現客戶的根本利益。在互聯網行業中，市場需求快速變化，這一特性比傳統行業更為明顯。如何能夠根據客戶提出的需求及時調整開發的內容和進度，從而減少在傳統開發模式下所造成的不必要的浪費?這大概是所有互聯網公司都在思考的問題。敏捷開發是一個不斷累加、迭代增長及時響應的過程。因此，敏捷開發模式已經成為全球范圍最受歡迎的軟件開發模式。
在敏捷開發模式中，Scrum是其中一種增量迭代開發的框架，其以人為核心進行迭代和循序漸進的開發方法已經被廣泛運用。利用這種Scrum敏捷方法，可以將整個開發周期劃分成多個小的迭代周期(Sprint)，每個周期長度一般在2 到4 周之間。在Scrum 框架下，產品需求利用Backlog 進行管理。Backlog 是一個按照商業價值等原則進行排序的列表，根據用戶故事(User Story)進行列表條目的體現。
利用Scrum 敏捷方法進行開發，一般會先開發對客戶具有較高價值的需求。在每個迭代周期中，開發團隊可以從產品中挑選最有價值的需求優先開發。在Sprint 計劃會議上，開發團隊會對需求進行分析討論，并且估算得到一個待辦列表。完成迭代后，Scrum團隊則能夠進行潛在可交付的產品增量的交付。
Scrum這種敏捷開發模式，其特點是在一個極短的發布周期內交付業務價值的一部分，并在開發周期內不斷的迭代和循序漸進。敏捷開發模式不斷接受需求更新，這樣就能做到及時并持續的響應客戶的反饋。
敏捷開發與測試的運用
軟件測試貫穿于軟件的整個生命周期，是保證軟件質量的基礎。測試團隊通過選用合適的軟件測試技術以及測試工具，來不斷改善軟件開發及測試流程。在敏捷開發模式得到迅速發展的同時，敏捷測試也成為了軟件開發與測試團隊共同關注的焦點。
敏捷測試通過持續對軟件進行測試并及時反饋測試結果來提高軟件質量，滿足用戶需求，其強調“持續測試”和“及時反饋”。因此，敏捷測試在一定程度上也可以被認為是遵循敏捷宣言的一種測試實踐。
圖一：敏捷開發與測試流程
從圖一可以看到，在某個Sprint中整個敏捷開發與測試流程被分成了以下幾個步驟：
待辦列表
在待辦列表中會列出所有此Sprint將要開發的功能，這些列表一般是以User Story的形式來進行功能描述，并可能會隨著項目的迭代而更新。
拆分計劃
對待辦列表中的功能進行細化，產生各個子功能，并列明各子功能的具體需求。在拆分計劃階段，開發與測試都需要熟悉各個功能的要求。
迭代開發測試
圖二：迭代開發測試流程
在這個階段，如圖二所示，開發人員對相應功能進行需求分析，制定開發迭代計劃，并進行功能開發與自測。測試人員也要進行需求分析，并列明測試計劃，同時進行測試用例與腳本的編寫。開發人員完成功能開發以及自測后，會產生相應的可測版本。測試人員根據需求執行測試用例，產生的缺陷由開發進行修復，繼而進行持續開發。
圖三：開發與測試階段流程
如圖三所示，在開發與測試階段，開發人員進行模塊開發與單元測試，在TDD(后續章節會有簡單介紹)的驅動下，對模塊進行重構。在模塊開發完成并集成后，由測試人員進行冒煙、驗收測試，其中產生的bug，會繼續由開發人員進行修復。
功能發布
在測試人員完成測試之后，進行測試小結，根據測試結果來評審是否可以交付某功能。
敏捷測試的主要方法及實踐
測試驅動開發(TDD)
測試不僅是測試人員的責任，開發人員也必須通過不斷的單元測試、模塊功能測試等白盒測試來重構自己的代碼，以此提高軟件的交付質量。
TDD要求開發人員在寫代碼前，先寫好測試用例，再編寫代碼，并且代碼能夠通過測試用例。隨著不斷地迭代和重構，測試用例的數量和覆蓋點也會不斷增加，程序所實現的功能也越來越復雜。開發人員需要不斷提高單元測試的覆蓋率，以此來增強代碼的可用性。
不斷地深入溝通
團隊需要密切的溝通，不過多依賴文檔。測試人員通過與不同角色進行溝通，在短時間內對項目的整體需求有充分的了解，才能設計出最適合的測試用例。為了保證產品質量符合客戶預期，在產品不斷的迭代中，測試人員需要不斷地修改測試用例，以達到精益求精的程度。
- 測試人員與開發人員之間的溝通，可以通過閱讀部分源代碼，了解產品的架構，從技術角度探討問題。
- 測試人員與用戶的交流，使測試人員能夠站在客戶的角度去考慮一些問題，必要的時候，還需要對競商的相同類型產品進行比較。
- 測試人員之間的交流，又是一個共享經驗及傳遞問題的過程。通過這種交流，個人經驗轉變成了整個團隊的經驗。
模糊界限
在敏捷模式中，強調團隊的高度協作，測試和開發的角色界限變得模糊。
開發人員不僅要確保開發任務的完成，還要運用單元測試等工作來保證代碼質量。而作為敏捷測試人員，也需要了解項目中客戶的需求、軟件的設計框架、軟件語言等。測試人員可以通過閱讀或編寫一部分產品代碼來熟悉產品的內部邏輯。
在測試人員設計測試用例的過程中，團隊的所有成員都有責任來共同設計符合客戶環境以及使用情景的測試方案。在敏捷模式中，團隊可以通過組織測試用例評審會來確保全員的參與。
自動化運用
在敏捷開發的過程中，項目不斷地以短周期的形式迭代發布。那么，測試人員不僅要保證每次迭代中新功能點的完整實現，還要保證之前迭代版本的功能不受影響。這樣就會造成測試工作量在不斷的增加，而且存在嚴重的重復性。
在敏捷項目中，自動化測試的良好實施會使測試人員乃至整個項目提高效率。一般在項目前期迭代中，測試人員會篩選最基本且使用率較高的測試用例來實現自動化，并且在迭代過程中不斷地完善與優化自動化腳本，增加功能測試的覆蓋面。這樣，在項目后期回歸測試時，只需要將累積的自動化腳本執行一遍就可以基本覆蓋大部分功能，從而縮短測試人員在回歸測試中驗證基本功能所消耗的時間。測試人員也可以將更多的時間投入到一些探索性測試中，以保證 更好的產品質量。
持續集成
在開發過程中，開發人員經常會合入新的代碼。那么，如何檢驗新開發代碼的質量?并保證新代碼合入庫之后不會影響老代碼的功能呢?這就需要通過自動化的持續構建(包括編譯，自動化測試)來保證。持續集成的主要目標是更快發現并解決缺陷，提高軟件質量，并減少驗證和發布軟件更新所需的時間。
如圖四所示，持續集成的過程大致有如下幾個方面：
- 設定一定的觸發條件，如定時、固定周期、手動啟動等;
- 啟動后，持續集成框架從版本管理工具中檢查并下載最新代碼，若沒有則結束集成過程;
- 代碼編譯成功后啟動自動化測試環境開始自動化測試;
- 自動生成測試報告，并通過郵件等形式發送給相應責任人。
圖四：持續集成的過程
敏捷測試該如何開展
在某些項目上，一些團隊已經基本能按照敏捷的方式來進行開發管理，但還是會有一些成員在心理上有一些抵觸，不習慣這樣的模式。就敏捷測試而言，在思想上，推動全員質量意識，項目團隊的所有成員都應該為產品質量負責，保證產品質量不再只是測試人員的職責。開發人員需要通過單元測試的覆蓋率來保證代碼的正確性。
要保證軟件的內建質量，在設計階段就要對需求、設計邏輯等進行全面的分析，提高可測試性。在敏捷測試中，測試人員需要貫穿于軟件的整個生命周期，并要盡早參與測試。在充分了解了計劃中待實現功能的前提下，制定測試計劃，采用迭代的方式完成測試任務。建立持續集成，結合自動化測試，在每次迭代中快速反饋測試結果。并不斷地維護自動化測試框架，用于后期的回歸測試和驗收測試。
