字型：大
中敏捷測試
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），以獲取反饋和進一步改進的建議。
在每個迭代結束前，甚至在缺陷達到一定數量的時候，測試人員還需要對新增的缺陷進行分析，找出它們出現的根本原因，召開缺陷改進會議，**改進措施，避免缺陷的再一次出現。缺陷改進會議通常和新一期的迭代啟動會議一起舉行，因為當分析了缺陷產生的原因之後，才能在新的迭代進行修正和避免。
除此之外，測試人員還會不定期地組織缺陷大掃除（
bugbash）和線上問題回顧（post incident review）這樣的團隊活動。缺陷大掃除（不僅能讓團隊其他人員協助測試人員從新的角度發現產品的問題，還可以培養真個團隊的質量意識。而線上問題回顧同樣可以讓團隊了解問題的根本原因，從而更好地構建產品。
測試人員還需要參與**評審（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測試的優秀實踐，並不包含除了測試本身之外別的工作職責，例如開發流程改進和迭代發布計畫管理等，其實這些職責也是測試人員可以承擔並且發揮巨大作用的。
敏捷測試之實踐篇
最近一直在想 敏捷測試 如何實施的事情，敏捷測試在敏捷開發中貫穿始末，涉及到了多種角色的參與 客戶 開發 設計 專職測試等等，每個角色承擔著不同的測試任務，客戶與設計可以進行驗證需求實現的測試，而開發進行 單元測試，專職測試人員進行詳細測試。我們這裡主要是來談談專職測試人員如何開展敏捷測試，其實這個...
敏捷測試的方法和實踐
有一次，當開發人員完成當前sprint 任務的 之後，測試人員 開發人員和產品經理一起來瀏覽產品 從頭到尾走一遍，產品經理發現了問題，認為需要對功能進行比較大的修改。這時開發人員估計需要兩天時間才能完成 但測試人員反對這樣做，我們本來只有5天測試時間，加上這次新做的功能比較多 開發 質量不高，驗收測...
敏捷測試的方法和實踐
有一次，當開發人員完成當前sprint 任務的 之後，測試人員 開發人員和產品經理一起來瀏覽產品 從頭到尾走一遍，產品經理發現了問題，認為需要對功能進行比較大的修改。這時開發人員估計需要兩天時間才能完成 但測試人員反對這樣做，我們本來只有5天測試時間，加上這次新做的功能比較多 開發 質量不高，驗收測...