摘要：測試策略描述了測試工程的總體方法和目標。描述目前在進行哪一階段的測試以及每個階段內在進行的測試種類（功能測試、效能測試、覆蓋測試等）以及測試人力安排等。
本文分享自華為雲社群《淺談敏捷開發的測試策略》，作者：敏捷江湖桃花島梅師姐 。
前言
隨著敏捷和 DevOps 的出現，改變了傳統的軟體開發模式，與此同時測試也面臨著不小的挑戰，在敏捷開發模式下，短週期迭代交付模式意味著時間變短，擁抱變化意味著變更頻繁，使用者故事描述需求的方式意味著文件變少，全功能團隊中意味著專門的測試人員變少。基於這樣的情況，如何讓測試也變得敏捷，做好測試工作呢？今天我們就一起聊一下如何做好敏捷開發的測試策略。
敏捷開發測試策略
測試策略描述了測試工程的總體方法和目標。描述目前在進行哪一階段的測試以及每個階段內在進行的測試種類（功能測試、效能測試、覆蓋測試等）以及測試人力安排等。
我們可以按照測試的目的、範圍、起止時間、人員安排、工具，即 5W1H 法來規劃合理的測試策略。
-
why：為什麼要進行測試，測試的目的是什麼?
-
what:測試的內容及範圍，測哪些，確定測試重點（RBT 基於需求的測試等）
-
when：測試的起止時間，考慮影響時間的因素
-
where：相關文件的存放位置、缺陷的存放、環境地質
-
who ：測試人員的安排
-
how：選用何種測試工具及方法進行測試
Why
根據敏捷測試原則，測試的目的是用來預防缺陷，幫助團隊構建最好的系統。可以根據業務和專案的特點，設定一個測試的總體目標。
What
根據測試四象限，從業務和技術的角度、以及程式和產品的角度將測試內容進行類劃分，如下圖所示。
圖 1 測試四象限
依據敏捷的分層計劃原則，測試測試也採用不同級別的測試，可以參考 Epic-Feature-Story-Task 制定策略。下面可以作為制定策略的參考，業務和產品大多是不相同的，可以根據自己業務和產品的特點進行調整。
敏捷開發過程是由迭代組成的，Epic 是由若干個迭代完成，通常為整合測試和端到端的測試；Feature 通常若干迭代來實現，通常會進行特性測試、功能測試、UAT、場景測試；Story 通常在迭代內完成，通常進行功能測試、使用者故事測試；Task 為迭代內的測試，通常進行單元測試、模組測試、程式碼質量測試。其中效能測試會覆蓋到 Story、Feature 和 Epic 層級。
When
在傳統的瀑布開發模式下，測試是一個階段，程式編寫完成後進入測試階段，如下圖所示。
圖 2 瀑布開發模式
在敏捷開發模式下，測試不只是一個階段，而是一個活動，每個 Sprint 都有測試活動。每個迭代都會進行單元測試、程式碼質量測試、使用者故事測試、特性和能力驗收測試；從 Sprint2 開始都要進行一次 Sprint 級別的迴歸測試，以自動化測試的形式實現。累積了幾個迭代之後，在釋出前要進行端到端的整合測試。如下圖所示。
圖 3 Sprint 測試活動
Where
儘管敏捷開發中採用輕文件的形式，但同樣也要做好相關文件的管理。在測試初始要約定相關測試交付物的管理和存放形式，包括不限於測試策略、測試工件、缺陷、測試資料、虛擬服務和自動化指令碼等。通常會在專案管理工具中進行管理，和開發的工作項之間建立關聯，這樣便於後續進行追溯和檢視。以華為雲DevCloud為例，可以將文件上傳到【Wiki】和【文件】中，然後在工作項中建立關聯。
圖 4 華為雲 DevCloud 示例
Who
敏捷開發中，測試活動為團隊的共同工作，而不僅僅是測試人員。其中開發人員做好 TDD、單元測試和程式碼質量測試，同時因為介面測試涉及到介面間的資料交換、傳遞和控制管理等內部邏輯的問題，也建議由開發人員進行。測試人員包括迭代內的測試人員和跨迭代的技術人員。迭代內的測試人員主要負責迭代測試的設計和執行，包括探索性測試和 API、UI 測試自動化指令碼的開發和執行，還有自動化的迴歸冒煙測試。跨迭代的測試人員更多專注在協調測試和制定自動化測試策略。
同時，測試人員為團隊中的一員，不僅僅執行測試工作，還要參與測試計劃、評估和工作安排、回顧及任何其他團隊活動。
How
為了能夠更好的配合敏捷開發的小步快跑、儘早交付的模式，測試就需要具備快速測試和及早反饋的能力。在敏捷方法緊迫時間的框架下，自動化測試能力必不可少，這樣可以極大的緩解測試的壓力。根據 Mike Cohn 的測試金字塔，自動化測試的比例分配為 7：2：1，即單元測試佔 70%，介面測試佔 20%，UI 測試佔 10%，這樣實現分層自動化。在自動化的基礎上還要進行手工的探索性測試。
圖 5 測試金字塔
現在有很多的自動化工具可選，開源工具如 UI 層的 appium、Cucumber、Protractor，API 層的 POSTMAN、資料庫層的 DbFit；商業工具如 UI 層的 IBM RFT、LeanFT, API 層的 SmartBear 等。
在自動化工具選擇上，要從實際情況出發情況，從成本預算、支援平臺、支援語言、可測的應用、技術要求等多方面去考慮。開源工具節省成本，商業工具成本高；在開源工具的選擇上也要結合團隊成員的程式碼能力情況，開源也有技術難易之分；工具的後續支援程度也要考慮進去，在使用的過程中不可避免的會遇到問題。
測試策略示例
一個產品通常是由若干個釋出組成，如下圖所示。
圖 6 敏捷開發
以一個釋出週期為例，按照時間線我們看一下測試的安排：
圖 7 測試策略示例
在制定測試策略的時候，要注意安排合理的測試節奏和週期，同時最好的測試，是全自動化的每天測試。
後記
上面給出了制定測試策略的 5W1H 可以作為參考，最重要的是要牢記測試的目的是為了預防缺陷，幫助團隊構建最好的系統，交付給客戶有價值的產品。因此要把質量左移的測試策略作為最重要的專案管理核心理念之一貫穿到整個軟體生命週期的交付中，通過缺陷預防將質量移向全生命週期的前端，通過制定基於風險的測試策略驅動，儘早發現重大缺陷。