測試策略的定義
先看下維基百科上關于test strategy的定義

A test strategy is an outline that describes the testing approach of the software development cycle. It is created to inform project managers, testers, and developers about some key issues of the testing process. This includes the testing objective, methods of testing new functions, total time and resources required for the project, and the testing environment.

Test strategies describe how the product risks of the stakeholders are mitigated at the test-level, which types of testing are to be performed, and which entry and exit criteria apply. They are created based on development design documents. System design documents are primarily used and occasionally, conceptual design documents may be referred to. Design documents describe the functionality of the software to be enabled in the upcoming release. For every stage of development design, a corresponding test strategy should be created to test the new feature sets.

歸納上面的定義，我們可以得出測試策略的最終目的是通過定義項目會采用的測試活動，盡可能得暴露和消除產品缺陷，減輕產品風險。除此之外，由于軟件開發時常伴有交付壓力，測試的時間和資源都是無法保證甚至可能被壓縮的，所以測試策略還會從最低成本揭露產品質量風險出發，選擇出最合理的測試方法和測試過程。

測試策略的作用
基于上面的定義，可見測試策略解決了兩個大問題：

“測什么”
“怎么測”
在詳細點就是：

確定了被測對象需要測試范圍
確定了會使用哪些測試技術來達到什么樣的質量標準
確定了項目的測試流程
確定了每一種測試技術的具體使用方式，包括待使用的框架和工具等
探索測試的深度和廣度
探索測試的重點和難點
統一項目內使用的測試相關的術語
確定了質量度量
測試策略和測試計劃的不同
要說不同，先看定義上的不同。

Test strategy Test plan
測試策略詳細描述了QA使用什么樣的具體測試方法來達成測試目標，給測試流程和活動設置了標準，主要關注“測什么”和“怎么測”。 測試計劃的主要目標是包含所有關于測試的信息，比如“為什么測”、測什么”、“什么時候測”、“怎么測”以及由“誰來測”。
由上可見，其實測試策略的內容已經被包含在測試計劃里面了。測試策略定義應該做什么樣的測試而測試計劃包含所有關于測試策略該如何執行的信息，這些信息在測試計劃里面被很好的組織起來。

一個公式可以進一步說明他們的關系 test plan = test strategy + test logistics。所以test strategy可以被看做是test plan的一部分。Test logistics是指測試環境設置以及人力資源等等。

在James Bach的博客A Question About Test Strategy中，他把三者描述如下

Test Plan: the set of ideas that guide a test project

Test Strategy: the set of ideas that guide test design

Test Logistics: the set of ideas that guide the application of resources to fulfill a test strategy

I find these ideas to be a useful jumping off point. Here are some implications:

The test plan is the sum of test strategy and test logistics.

The test plan document does not necessarily contain a test plan. This is because many test plan documents are created by people who are following templates without understanding them, or writing things to please their bosses, without knowing how to fulfill their promises, or simply because it once was a genuine test plan but now is obsolete.

Conversely, a genuine test plan is not necessarily documented. This is because new ideas may occur to you each day that change how you test. In my career, I have mostly operated without written test plans.


敏捷團隊需要測試策略嗎
讓我們先來看下QA在敏捷項目中的主要工作，如下圖所示



iteration.png
那你可能問“咦，怎么沒有測試策略相關內容呢”。其實，整個開發測試流程就體現了測試策略的內容。上圖所示的迭代開發流程里面包含了"Automated Acceptance Tests" & “Story Testing” & “System Testing”這些測試活動，那么為什么項目需要這些測試活動？這些活動如何具體如何開展？分別在哪一個項目階段進行？這些問題都屬于測試策略的范疇，是由測試策略定義和落地的。

敏捷開發模型下，迭代式的開發具有周期短和交付壓力大的特點，對于如何快速響應新需求，保障新需求的質量以及已實現需求的回歸測試都將是測試的挑戰。如果沒有一個匹配項目上下文，合理規劃了測試活動的測試策略，這些挑戰就會持續困擾著團隊，所以標題的答案是當然需要。測試策略在敏捷開發模型下，通過詳細定義項目的測試活動，能夠更加合理地利用測試資源和統一項目對測試的認知。

此外，測試策略也是敏捷項目質量保障體系中重要的一節。

敏捷團隊需要測試計劃嗎
在傳統瀑布開發模式下，測試計劃test plan被認為是項目測試流程的關鍵部分，因為它指導著整個測試活動的開展，既然被認為是項目中的一個must have，于是有人會花很多時間很多精力去把測試計劃給寫好寫完整。那么我們真的在敏捷開發模式的項目里需要一份測試計劃嗎？這真的能給項目質量帶來價值嗎？

敏捷宣言說過：

工作的軟件 高于 詳盡的文檔
響應變化 高于 遵循計劃
盡管右項有其價值，我們更重視左項的價值
在敏捷項目中，產品范圍也就是發布內容在spring進行之前就被討論，所以QA們對于測試對象和測試范圍一直都是清楚的，不需要特別地花時間去寫一個詳細的文檔來闡述。同樣地，agile ceremony會讓QA們清楚地知道測試對象是什么，范圍是什么，重點是什么，測試環境是什么而不需要一個單獨的文檔來進行詳細的描述。甚至，所有關于測試的信息還可以被記錄被故事卡中。在開發進行編碼實現功能的時候，QA們會進行測試用例設計以及自動化測試編寫，因為時間的緊迫，QA除了這兩項測試活動，再去寫一個詳細測試計劃是不經濟的且價值不大，這兩項測試活動才是敏捷項目中價值最高的，況且隨著迭代的進行，測試計劃的維護還需要時間精力。

綜上所述，在敏捷項目中因為時間緊迫和避免重復勞動，價值不高的測試計劃不是一個must have，個人甚至認為也不是一個nice to have。但是這并不是代表我們不需要"planning"，而是不是需要"document planning"，"planning"的實施發生在迭代中的各類活動。

最終我們還是需要一個“計劃”來指導迭代中的測試流程和方法，這就是測試策略是一個must have的原因。在敏捷項目中，“小而精”的測試策略比起“大而全”的測試計劃而言，最大的優勢就是測試策略定義的內容(“怎么測”)是不會輕易受影響改變的，并且在迭代中沒有類似的重復活動。

什么時候著手制定測試策略
具體到項目里，測試策略推薦在項目剛啟動的時候制定。測試策略需要在項目早期就制定下來，用來指導項目的測試活動和方法，從而確定需要的測試資源和保證質量體系的建立。但也不能在產品和技術都還沒有確定的時候就制定，因為只有在產品需求范圍，技術架構和交付計劃大致確認的情況，測試策略才能更加準確，從而減少維護成本。

誰來主導測試策略的編寫
因為測試策略會涉及到很多具體的測試技術和方法，也會要求制定人員具有對質量和測試非常深的理解，所以QA在敏捷團隊中應該承擔制定測試策略的主要責任，但是這并不意味“只有”QA來編寫制定測試策略，測試策略的制定是一個團隊活動，QA需要從不同角色收集到不同的信息

從Business了解到產品愿景，產品發展藍圖和業務流程 - 涉及需求分析和確定測試目標等活動
從Project Manager了解到交付計劃，交付范圍 - 涉及確定測試類型、測試方法、測試階段和測試重點等活動
從Tech Lead了解到技術框架 - 涉及確定集成測試、自動化測試語言、工具和框架選型等活動
從多方收集信息能夠保證業務、技術和質量三者對齊，避免誤解和沖突，共同發揮最大的作用。

當測試策略制定完成以后，還需要給項目團隊進行講解，確保團隊所有相關人員對項目中的測試活動和測試方法有著一致的理解,這樣才能保證實施階段的順利。

在敏捷團隊中制定測試策略的流程
接下來會涉及到QA制定測試策略的具體活動及流程?？偟膩碚f，大體流程可以如下

前期項目信息收集
確立質量目標
確定測試類型
確定測試工具和框架
確定測試階段
確定測試度量
持續改進和風險分析
前期項目信息收集
上面提到了QA可以從不同角色收集到不同的信息，除此之外，使用啟發式測試計劃語境模型 Heuristic Test Planning Context Model和啟發式測試策略模型 Heuristic Test Strategy Model也是一個有效的渠道。具體如何使用這兩個模型，請參考htsm和htcpm。

通過分析htsm中“項目環境”和“產品元素”的關鍵詞和啟發式問題，QA可以了解關于產品和項目的各類信息來幫助制定測試策略。htcpm也提供了大量的關鍵詞來啟發QA去分析了解產品需求、項目環境、測試小組和測試資源。

可以收集的信息大致可分類如下

產品信息
商業目標
產品愿景
相關利益者
業務信息
業務流程
業務范圍
業務數據
技術信息
技術架構
技術棧
交付信息
交付計劃
開發流程
部署架構
持續交付
線上監控
團隊信息
組織結構
測試資源
只有從不同的維度收集到足夠的項目信息并且很好的理解這些信息對項目質量和測試活動的影響，才能幫助我們少走彎路，制定出適合項目和團隊的測試策略。

確定質量目標
在具體思考“怎么測”之前，我們需要確定項目的質量目標。這個質量目標會對齊項目所有相關人員對于項目質量的理解和期望，明確質量范圍也就是測試策略會覆蓋的范圍。同時，質量目標也要與產品目標對齊，因為質量的最終目的也是保證產品的成功。根據產品在不同階段都有不一樣的目標，質量目標有會隨之變化。

那質量目標如何設定？主要是參考軟件質量特征列表和軟件質量模型，建立符合項目上下文的產品質量模型，從而確定項目質量目標

要建立項目產品的質量模型首先就需要先知道一個軟件產品的質量屬性或特征分別有什么，對應的質量模型是什么樣的。幸運的是現在已經有很多可以參考的模型了

軟件質量特征列表
HTSM的Quality Criteria Categories
ISO/IEC_9126
ISO/IEC_25010 中文解析
其他軟件質量模型
ISO/IEC_25010的質量模型大致如下：


iso25010.png
從上面的質量特征列表或是模型可以看出，一個軟件產品的質量由多個質量特征或標準組成，每個質量特征又可以進一步分解為子特征。通過這些已有的質量模型來啟發哪些質量特征是對項目產品重要的，哪些質量標準適用于本項目產品，最后得出符合項目上下文的產品質量模型。

比如 我們創建的產品質量模型可以包含以下粗粒度特征：

功能性
完成度
精準度
互用性
效率
并發
性能
資源利用率
吞吐量
持久力
安全
認證
授權
隱私
兼容性
應用兼容
OS兼容
硬件兼容
向后兼容
可用性
易學性
易操作性
可達性
可靠性
穩定性
健壯性
可恢復性
錯誤處理
數據完整性
可維護性
可擴展性
修復
構建
可移植性
重用
可安裝性
配置
升級卸載
上面的質量模型定義了產品質量特征和標準，而這些特征和標準就是我們應該完成的目標！除了上面說到的質量模型，一些具體的metrics也可以被引入來保證項目質量，成為項目質量目標的一部分。舉個例子

功能性
驗收條件(AC)通過率100%
UI自動化測試覆蓋率30%
API自動化測試覆蓋率90%
單元測試覆蓋率90%
沒有high severity bug
性能
吞吐量定義
資源利用率定義
響應時間定義
安全
OWASP TOP TEN
兼容性
瀏覽器支持
OS支持
可靠性
線上bug響應時間
災難恢復時間
可安裝性
升級時間
卸載時間
內部質量
代碼復雜度
重復代碼
checkstyle
包耦合指數
過多的注釋
未使用的代碼
邏輯錯誤
code convention
Runtime error
上面提到的標準都是可以通過集成到持續集成流水線的質量工具或測試框架來實現。

此外，還有團隊也會使用測試策略目標宣言來打造團隊文化。

“To Constantly Deliver Working Software that Meets Customer’s Requirements”
by means of
“Providing Fast Feedback”
and
“Defect Prevention, rather than Defect Detection”
確定測試類型
有了質量目標，接下來我們要考慮要怎么達成這個目標了！也就是說，我們應該有哪些測試類型來覆蓋每一個質量目標？

測試類型按照不同維度可以有很多種分類，比如說

基于是否考慮軟件內部結構和實現
白盒測試
黑盒測試
灰盒測試
基于是否執行程序
靜態測試
動態測試
基于測試過程
單元測試
集成測試
冒煙測試
功能測試(系統測試)
探索式測試
場景測試
流測試
域測試
兼容性測試
回歸測試
驗收測試
性能測試
壓力測試
負載測試
安全測試
當然，上面只是列出了一部分。

此外，HTSM中的Test Techniques提供了九種通用的九種測試技術來啟發對可應用的測試類型的思考。敏捷測試四象限也提供了敏捷項目可以參考的測試類型,這個測試技術分類系統可以幫助我們快速定位某測試類型在軟件開發中的位置，根據項目產品情況選擇合適的測試類型。

agile testing pyramid
就以我們上面假設的質量目標為例，我們來看看可以應用哪些測試類型

值得注意的是，并不是每一個項目都需要覆蓋上面所列出的測試類型。我們應該根據產品的目標和特點以及其他實際情況選擇與之對應的測試覆蓋類型，也就是說，不同項目根據測試類型的不同，測試廣度是不一樣的。同事，根據測試的難點和重點，測試深度也是不同的。所以，一切都要基于項目的上下文來思考和制定。

對于自動化測試單獨的策略
自動化測試金字塔用來指導敏捷項目中自動化測試的策略。

金字塔底層是自動化測試的基礎，主要包含單元測試和組件測試
金字塔中層是面向業務的自動化測試。調用產品提供的編程接口
金字塔頂層是少量的基于圖形界面的自動化測試
金字塔上方是手工測試


i
根據金字塔理論，項目應該在底層的單元測試和集成測試(API測試)投入更多的精力。

自動化測試項目會被集成在持續集成流水線里面，由上游項目自動觸發。為了減少持續集成的反饋時間，一個普遍的做法是把龐大的自動化測試套件集依據重要性優先級放在不同的流水線里面，可以被上游項目觸發也可以定時觸發，下面描述了一個比較好的實踐：

構建部署流水線，每個構建都要執行的測試，上游項目觸發 --> 單元測試、接口測試、冒煙測試
單獨的測試項目，每日最新穩定版本要執行的測試，定時觸發 --> 部分功能性回歸測試、性能測試
發布候選流水線，每個發布候選構建要執行的測試，定時觸發 --> 全部功能性回歸測試、性能測試
確定測試框架和工具
確定測試類型之后，我們就知道了整個項目的測試活動會有哪些。對于某些測試類型，特別是自動化相關的測試，我們需要對應的測試工具或是框架來支撐我們的測試。所以我們需要對每一個測試類型都去思考下如何進行測試，是否需要相應的測試工具和框架的支持。

拿一個web程序來舉例

兼容性測試工具
browserstack
指定的瀏覽器版本
單元測試框架
Junit
pytest
Jest
Mocha
jasmine
mockup工具
wiremock
moco
mockito
測試數據工具
faker
Lorem Ipsum
集成測試框架
Rest assured
supertest
chakram
Pact
集成測試工具
Postman
Swagger
UI功能測試框架
webdriver
webdriverio
Protractor
codeceptjs
確定測試階段
這個環節我們需要確定在項目開發生命周期的每個階段做什么樣的測試，使得測試類型與項目的開發流程充分結合，這樣就能最大發揮所有測試活動的效果來達到我們的質量目標。因此，我們可以做出類似下面這樣的表格來表現每個階段的測試類型及其實施方法。
 

測試度量
那如何衡量測試策略的有效性呢？質量度量可以告訴我們產品的質量情況和用戶滿意度，從而反應出測試策略是否有效和高效。

軟件質量的度量沒有什么最佳實踐，也沒有最準確和科學的度量，有的只是項目上積累的成功經驗；但是這些成功經驗又由于項目差異化太大而變得復用性很差。所以根據項目的上下文，我們需要制定出自己的質量度量標準。結合本文敏捷項目的背景，我們可以大致使用下面常用的度量：

缺陷統計度量
解決率
解決時間
分布
觸發原因
嚴重性
優先級
數量變化趨勢
覆蓋率
需求覆蓋率
故事卡AC覆蓋率
代碼覆蓋率
函數覆蓋數量
運行使用到的功能覆蓋數量
條件覆蓋數量
path覆蓋數量
自動化測試覆蓋率
運行通過的測試比率
功能穩定程度
不同開發階段的比率
測試執行
測試執行率
測試執行通過率
故事卡返工數量及比例
測試過的系統瀏覽器數量
PO驗收反饋
同時，實例化的質量目標也是很好的項目質量的工具。對于質量模型，我們可以看下每一個質量元素我們是否做到；對于具體的指標metrics，要隨時監控反饋。

持續改進和風險分析
一旦測試策略被確定，一般來講不會經常變化，因為測試策略設置了一些測試標準。如果測試標準頻繁地變動，這會讓具體計劃的執行變得困難，同時帶來更多的資源浪費，最終影響了項目的質量。

在項目中我們會經常遇到“變化”：比如說

feature scope的變化
具體功能細節的變化
測試重點的變化
根據risk assessment來調整的變化
這些變化對測試的影響是被測對象的范圍以及項目資源的調配。對于項目的質量目標、測試類型、測試階段影響不大。所以，測試策略一旦被制定出來，變化不會太大。

不過這不代表測試策略的一成不變和缺乏改進，QA需要在每個迭代中觀察測試策略實施的效果來決定當前的測試類型和實施手段是否滿足項目需求。比如當項目集成測試(API Testing)經常fail，且協調工作耗時費力，QA可以考慮采用契約測試來代替現有的集成測試，提高整個項目組的生產率和質量；比如發現Internet Edge突然用戶量增多且有關于Internet Edge的production bug被raise，QA需要把Internet Edge加到兼容性測試中，并且設置相關的測試環境；比如測試進度落后，交付壓力增大，QA需要及時調整測試范圍和測試重點，進行風險分析。

在實際項目中，往往會出現各種各樣的問題來阻礙測試策略的順利落地和執行。這些問題有些是測試策略自身的問題，但也有項目帶來的問題。這時候，風險分析顯得格外重要。

對于測試策略的風險分析，這個是應該貫穿整個測試策略制定周期里面的，我們需要通過項目風險清單提前識別項目中可能阻塞測試的風險，并通過風險優先級(風險暴露的概率*風險暴露的損失)來評估風險，最終基于風險調整測試策略，把測試重點放到風險高優先級高的地方。

其他影響質量的因素
測試策略是影響質量的重要因素，但不是全部，下面列出了部分會影響質量的因素作為參考，在此文中不會展開來講

風險控制
流程改進
敏捷實踐
團隊組成
項目狀況
寫在最后
上面詳細闡述了我如何理解敏捷項目中的測試策略以及制定測試策略的具體步驟。由于IT項目的多樣性和復雜性，這個總結不可能適用于有著不同上下文的項目，因地制宜地制定測試策略才能保證測試策略在項目中的可用性和合理性。