敏捷測試中的Web測試優秀實踐

說到Web測試的優秀實踐，不得不提到敏捷開發流程。不同於瀑布流程，測試在敏捷開發流程中，涵蓋了從項目啟動到產品上線的各個環節。所以我們對於Web測試的優秀實踐也是基於敏捷開發流程的。

下面我們就從項目全局、迭代和故事卡三個角度出發，向大家介紹Web測試的優秀實踐。

1. 項目全局角度看測試實踐

從整個項目全局的角度來說，測試人員一般會介入如圖A-1所示的兩個階段：

圖A-1 項目全局角度中測試人員的實踐

在項目啟動（Inception）階段，不僅是業務方、業務分析人員、網站設計人員和開發人員需要參加，測試人員也是需要參加項目啟動或者初始會議的。在這一活動中，測試人員從測試的角度出發，分析測試的可行性，以及了解業務需求。通常測試人員會使用行為驅動開發（BDD）和實例化需求（SBE）的方式來理清需求，避免需求歧義或者遺漏需求的情況發生。測試人員還會挖掘除了功能需求外，項目開發過程中需要添加的各項非功能性需求，例如性能指標和產品安全性等。

在項目初始階段，測試人員通過分析產品的架構和開發團隊的技術棧，通過技術選型，選擇適合項目的自動化測試框架及編程語言，以及其他適用於項目並能提高測試效率的工具。同時測試人員還需要根據敏捷測試四象限（如圖A-2）來制定測試策略和計劃，用於下一階段迭代開發中的測試。

圖A-2 敏捷測試四象

2.迭代角度看測試實踐

從每個迭代的角度來看，測試工作會涉及到圖A-3中所示內容：

圖A-3 迭代角度中測試人員的實踐

在迭代開始時，測試人員匯同業務分析人員和開發人員一起舉行迭代啟動會議（Iteration Plan Meeting）。在會議上制定詳細的迭代開發計劃，並對每張故事卡（Story Card）進行工作量的估算（Estimation）。故事卡的估算是基於點數的，而點數是相對於基準故事卡點數的度量，這個值不僅要包含開發這張故事卡所付出的開發人員的工作量，還需要包含測試人員進行測試的工作量，因為沒有測試的故事卡也是不能交付客戶的，也就是沒有客戶價值的。

在每個迭代的後期，測試人員通常還需要準備好類生產環境，設定好涵蓋在上一次演示後新增的所有功能的演示腳本，並給業務團隊進行產品演示（Showcase），以獲取反饋和進一步改進的建議。

在每個迭代結束前，甚至在缺陷達到一定數量的時候，測試人員還需要對新增的缺陷進行分析，找出它們出現的根本原因，召開缺陷改進會議，探討改進措施，避免缺陷的再一次出現。缺陷改進會議通常和新一期的迭代啟動會議一起舉行，因為當分析了缺陷產生的原因之後，才能在新的迭代進行修正和避免。

除此之外，測試人員還會不定期地組織缺陷大掃除（Bug Bash）和線上問題回顧（Post Incident Review）這樣的團隊活動。缺陷大掃除（http://insights.thoughtworkers.org/bug-bash/）不僅能讓團隊其他人員協助測試人員從新的角度發現產品的問題，還可以培養真箇團隊的質量意識。而線上問題回顧同樣可以讓團隊了解問題的根本原因，從而更好地構建產品。

測試人員還需要參與代碼評審（Code Review）。在這一過程中，測試人員不僅需要評審和學習開發人員編寫的產品代碼，也需要演示自己編寫的自動化測試代碼供開發人員評審。這樣測試人員也更容易學習到開發人員的開發技巧，提高編程水平。

3.故事卡角度看測試實踐

在介紹迭代中的優秀測試實踐時，我們並沒有涉及故事卡開發中的測試，那我們現在來看看這一階段中有哪些優秀實踐。

圖A-4 故事卡角度中測試人員的實踐

首先，在業務分析人員完成故事卡的拆分以及分析後，測試人員需要評審故事卡的驗收條件（Acceptance Criteria）並撰寫對應的測試用例／場景。這比測試人員根據業務分析人員發送給開發人員和測試人員的需求文檔來測試使測試前移了很多，而且這個工作也保證了後續活動能順利執行。

其次，測試人員需要和業務分析人員以及開發人員一起參與故事卡的啟動（Kick off）會議。雖然說是會議，可是經常是三方人員聚在卡牆（Story Wall）前進行簡短的討論。通常都會由開發人員來描述故事卡的業務需求、涵蓋的內容以及驗收標準，而測試人員和業務分析人員則進行補充和提問，以便所有人對於故事卡的內容的理解都能達成一致。同時所有人也會對測試人員編寫的測試用例進行評審。

之後在進行故事卡開發時，測試人員會按照測試金字塔（Test Pyramid）的分層原則，和開發人員討論如何把測試用例盡量用更底層的測試來實現，以達到提高測試效率，並同時保證測試覆蓋率的目標。對於可以完全被單元測試和集成測試覆蓋的測試用例，測試人員會交由開發人員實現；對於部分未被覆蓋的測試用例，測試人員會通過手動測試或者端到端自動化測試的方式覆蓋。

在開發人員開發故事卡的同時，測試人員會按照自動化測試的框架以及頁面對象（Page Object）模式編寫故事卡對應的端到端自動化功能測試、集成測試和其他諸如性能測試等非功能性測試。這一工作也可能適合與開發人員進行結對編程（Pair Programming）完成的。在結對編程中，開發人員能學習到測試人員的思維方式，減少自己代碼的出錯幾率；測試人員也能學習到更多的開發技巧。自動化測試編寫完成後，也會提交到代碼庫中，在每次開發人員提交代碼時，都在持續集成環境中不斷運行。團隊所有人員都需要保證每次代碼提交都能通過所有的測試。

當開發人員結束故事卡的開發時，測試人員和業務分析人員會在開發人員的開發機器上驗證代碼是否滿足了故事卡的業務需求，也就是進行故事卡檢查（Desk Check）並且對開發人員編寫的各種測試進行評審，確保測試覆蓋率和測試的準確性。

當故事卡檢查通過之後，測試人員就可以進行探索性測試和系統測試了。這時測試人員可以通過各種探索性測試的技巧，例如快速測試（Rapid Testing）以及基於測程（Session Based）的探索性測試等，進行系統測試。

在測試結束後，測試人員根據和業務團隊的約定，馬上或者定期給業務團隊進行故事卡的演示（Showcase）。如果業務團隊有更新的需求，也是通過測試人員反饋並創建新的故事卡的。只有業務團隊接受故事卡的完成情況時，一張故事卡才算正式的完成了。

在開發機器驗證和正式的測試階段，一旦發現了缺陷，一般來說會直接把故事卡推回開發階段中，從而使的缺陷得到快速修復。但是當測試完成後如果發現任何缺陷，都需要創建新的缺陷卡來記錄和跟蹤缺陷的修復情況。因為此時故事卡的開發已經結束，需要更多時間來修復相應的缺陷。

從這些優秀測試實踐的介紹中可以發現測試人員全面而深入地參與到項目開發的每一個環節，成為項目中不可或缺的重要角色。

細心的讀者會發現我們介紹Web測試的優秀實踐，並不包含除了測試本身之外別的工作職責，例如開發流程改進和迭代發布計劃管理等，其實這些職責也是測試人員可以承擔並且發揮巨大作用的。

相關書籍閱讀：

書名：《Web測試囧事》

ThoughtWorks測試專家聯合撰寫，以73個源自實戰的場景化故事，揭示Bug定位、解決思路與規律，輕鬆、潛移默化地掌握測試技巧與原理，觸類旁通。

ISBN：978-7-111-56940-4

作者：黃勇 徐瀟 楊雪敏

定價：59.00元

出版時間：2017年7月

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！