這篇文章主要總結(jié)了我對于敏捷項目中總體測試策略的理解，主要來自于工作上的實踐和思考。

測試策略的定義

先看下維基百科上關(guān)于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.

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

測試策略的作用

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

1. “測什么”
2. “怎么測”

在詳細點就是：

1. 確定了被測對象需要測試范圍
2. 確定了會使用哪些測試技術(shù)來達到什么樣的質(zhì)量標準
3. 確定了項目的測試流程
4. 確定了每一種測試技術(shù)的具體使用方式，包括待使用的框架和工具等
5. 探索測試的深度和廣度
6. 探索測試的重點和難點
7. 統(tǒng)一項目內(nèi)使用的測試相關(guān)的術(shù)語
8. 確定了質(zhì)量度量

測試策略和測試計劃的不同

要說不同，先看定義上的不同。

由上可見，其實測試策略的內(nèi)容已經(jīng)被包含在測試計劃里面了。測試策略定義應(yīng)該做什么樣的測試而測試計劃包含所有關(guān)于測試策略該如何執(zhí)行的信息，這些信息在測試計劃里面被很好的組織起來。

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

在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.

test_strategy.PNG

敏捷團隊需要測試策略嗎

讓我們先來看下QA在敏捷項目中的主要工作，如下圖所示

iteration.png

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

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

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

敏捷團隊需要測試計劃嗎

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

敏捷宣言說過：

• 工作的軟件 高于 詳盡的文檔
• 響應(yīng)變化 高于 遵循計劃
  盡管右項有其價值，我們更重視左項的價值

在敏捷項目中，產(chǎn)品范圍也就是發(fā)布內(nèi)容在spring進行之前就被討論，所以QA們對于測試對象和測試范圍一直都是清楚的，不需要特別地花時間去寫一個詳細的文檔來闡述。同樣地，agile ceremony會讓QA們清楚地知道測試對象是什么，范圍是什么，重點是什么，測試環(huán)境是什么而不需要一個單獨的文檔來進行詳細的描述。甚至，所有關(guān)于測試的信息還可以被記錄被故事卡中。在開發(fā)進行編碼實現(xiàn)功能的時候，QA們會進行測試用例設(shè)計以及自動化測試編寫，因為時間的緊迫，QA除了這兩項測試活動，再去寫一個詳細測試計劃是不經(jīng)濟的且價值不大，這兩項測試活動才是敏捷項目中價值最高的，況且隨著迭代的進行，測試計劃的維護還需要時間精力。

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

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

什么時候著手制定測試策略

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

誰來主導(dǎo)測試策略的編寫

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

1. 從Business了解到產(chǎn)品愿景，產(chǎn)品發(fā)展藍圖和業(yè)務(wù)流程 - 涉及需求分析和確定測試目標等活動
2. 從Project Manager了解到交付計劃，交付范圍 - 涉及確定測試類型、測試方法、測試階段和測試重點等活動
3. 從Tech Lead了解到技術(shù)框架 - 涉及確定集成測試、自動化測試語言、工具和框架選型等活動

從多方收集信息能夠保證業(yè)務(wù)、技術(shù)和質(zhì)量三者對齊，避免誤解和沖突，共同發(fā)揮最大的作用。

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

在敏捷團隊中制定測試策略的流程

接下來會涉及到QA制定測試策略的具體活動及流程。總的來說，大體流程可以如下

1. 前期項目信息收集
2. 確立質(zhì)量目標
3. 確定測試類型
4. 確定測試工具和框架
5. 確定測試階段
6. 確定測試度量
7. 持續(xù)改進和風(fēng)險分析

前期項目信息收集

上面提到了QA可以從不同角色收集到不同的信息，除此之外，使用啟發(fā)式測試計劃語境模型 Heuristic Test Planning Context Model和啟發(fā)式測試策略模型 Heuristic Test Strategy Model也是一個有效的渠道。具體如何使用這兩個模型，請參考htsm和htcpm。

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

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

1. 產(chǎn)品信息
   • 商業(yè)目標
   • 產(chǎn)品愿景
   • 相關(guān)利益者
2. 業(yè)務(wù)信息
   • 業(yè)務(wù)流程
   • 業(yè)務(wù)范圍
   • 業(yè)務(wù)數(shù)據(jù)
3. 技術(shù)信息
   • 技術(shù)架構(gòu)
   • 技術(shù)棧
4. 交付信息
   • 交付計劃
   • 開發(fā)流程
   • 部署架構(gòu)
   • 持續(xù)交付
   • 線上監(jiān)控
5. 團隊信息
   • 組織結(jié)構(gòu)
   • 測試資源

只有從不同的維度收集到足夠的項目信息并且很好的理解這些信息對項目質(zhì)量和測試活動的影響，才能幫助我們少走彎路，制定出適合項目和團隊的測試策略。

確定質(zhì)量目標

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

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

要建立項目產(chǎn)品的質(zhì)量模型首先就需要先知道一個軟件產(chǎn)品的質(zhì)量屬性或特征分別有什么，對應(yīng)的質(zhì)量模型是什么樣的。幸運的是現(xiàn)在已經(jīng)有很多可以參考的模型了

• 軟件質(zhì)量特征列表
• HTSM的Quality Criteria Categories
• ISO/IEC_9126
• ISO/IEC_25010 中文解析
• 其他軟件質(zhì)量模型

ISO/IEC_25010的質(zhì)量模型大致如下：

iso25010.png

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

比如 我們創(chuàng)建的產(chǎn)品質(zhì)量模型可以包含以下粗粒度特征：

1. 功能性
   • 完成度
   • 精準度
   • 互用性
   • 效率
   • 并發(fā)
2. 性能
   • 資源利用率
   • 吞吐量
   • 持久力
3. 安全
   • 認證
   • 授權(quán)
   • 隱私
4. 兼容性
   • 應(yīng)用兼容
   • OS兼容
   • 硬件兼容
   • 向后兼容
5. 可用性
   • 易學(xué)性
   • 易操作性
   • 可達性
6. 可靠性
   • 穩(wěn)定性
   • 健壯性
   • 可恢復(fù)性
   • 錯誤處理
   • 數(shù)據(jù)完整性
7. 可維護性
   • 可擴展性
   • 修復(fù)
   • 構(gòu)建
8. 可移植性
   • 重用
9. 可安裝性
   • 配置
   • 升級卸載

上面的質(zhì)量模型定義了產(chǎn)品質(zhì)量特征和標準，而這些特征和標準就是我們應(yīng)該完成的目標！除了上面說到的質(zhì)量模型，一些具體的metrics也可以被引入來保證項目質(zhì)量，成為項目質(zhì)量目標的一部分。舉個例子

• 功能性
  • 驗收條件(AC)通過率100%
  • UI自動化測試覆蓋率30%
  • API自動化測試覆蓋率90%
  • 單元測試覆蓋率90%
  • 沒有high severity bug
• 性能
  • 吞吐量定義
  • 資源利用率定義
  • 響應(yīng)時間定義
• 安全
  • OWASP TOP TEN
• 兼容性
  • 瀏覽器支持
  • OS支持
• 可靠性
  • 線上bug響應(yīng)時間
  • 災(zāi)難恢復(fù)時間
• 可安裝性
  • 升級時間
  • 卸載時間
• 內(nèi)部質(zhì)量
  • 代碼復(fù)雜度
  • 重復(fù)代碼
  • checkstyle
  • 包耦合指數(shù)
  • 過多的注釋
  • 未使用的代碼
  • 邏輯錯誤
  • code convention
  • Runtime error

上面提到的標準都是可以通過集成到持續(xù)集成流水線的質(zhì)量工具或測試框架來實現(xiàn)。

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

“To Constantly Deliver Working Software that Meets Customer’s Requirements”
by means of
“Providing Fast Feedback”
and
“Defect Prevention, rather than Defect Detection”

確定測試類型

有了質(zhì)量目標，接下來我們要考慮要怎么達成這個目標了！也就是說，我們應(yīng)該有哪些測試類型來覆蓋每一個質(zhì)量目標？

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

1. 基于是否考慮軟件內(nèi)部結(jié)構(gòu)和實現(xiàn)
   • 白盒測試
   • 黑盒測試
   • 灰盒測試
2. 基于是否執(zhí)行程序
   • 靜態(tài)測試
   • 動態(tài)測試
3. 基于測試過程

• 單元測試
• 集成測試
• 冒煙測試
• 功能測試(系統(tǒng)測試)
  • 探索式測試
  • 場景測試
  • 流測試
  • 域測試
• 兼容性測試
• 回歸測試
• 驗收測試
• 性能測試
  • 壓力測試
  • 負載測試
• 安全測試

當然，上面只是列出了一部分。

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

agile testing pyramid

就以我們上面假設(shè)的質(zhì)量目標為例，我們來看看可以應(yīng)用哪些測試類型

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

對于自動化測試單獨的策略

自動化測試金字塔用來指導(dǎo)敏捷項目中自動化測試的策略。

• 金字塔底層是自動化測試的基礎(chǔ)，主要包含單元測試和組件測試
• 金字塔中層是面向業(yè)務(wù)的自動化測試。調(diào)用產(chǎn)品提供的編程接口
• 金字塔頂層是少量的基于圖形界面的自動化測試

• 金字塔上方是手工測試

  
  
  ideal automated testing pyramid

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

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

1. 構(gòu)建部署流水線，每個構(gòu)建都要執(zhí)行的測試，上游項目觸發(fā) --> 單元測試、接口測試、冒煙測試
2. 單獨的測試項目，每日最新穩(wěn)定版本要執(zhí)行的測試，定時觸發(fā) --> 部分功能性回歸測試、性能測試
3. 發(fā)布候選流水線，每個發(fā)布候選構(gòu)建要執(zhí)行的測試，定時觸發(fā) --> 全部功能性回歸測試、性能測試

確定測試框架和工具

確定測試類型之后，我們就知道了整個項目的測試活動會有哪些。對于某些測試類型，特別是自動化相關(guān)的測試，我們需要對應(yīng)的測試工具或是框架來支撐我們的測試。所以我們需要對每一個測試類型都去思考下如何進行測試，是否需要相應(yīng)的測試工具和框架的支持。

拿一個web程序來舉例

1. 兼容性測試工具
   • browserstack
   • 指定的瀏覽器版本
2. 單元測試框架
   • Junit
   • pytest
   • Jest
   • Mocha
   • jasmine
3. mockup工具
   • wiremock
   • moco
   • mockito
4. 測試數(shù)據(jù)工具
   • faker
   • Lorem Ipsum
5. 集成測試框架
   • Rest assured
   • supertest
   • chakram
   • Pact
6. 集成測試工具
   • Postman
   • Swagger
7. UI功能測試框架
   • webdriver
   • webdriverio
   • Protractor
   • codeceptjs

確定測試階段

這個環(huán)節(jié)我們需要確定在項目開發(fā)生命周期的每個階段做什么樣的測試，使得測試類型與項目的開發(fā)流程充分結(jié)合，這樣就能最大發(fā)揮所有測試活動的效果來達到我們的質(zhì)量目標。因此，我們可以做出類似下面這樣的表格來表現(xiàn)每個階段的測試類型及其實施方法。

至此，測試策略解決的兩個問題“測什么”和“怎么測”都可以找到大致答案了。

測試度量

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

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

• 缺陷統(tǒng)計度量
  • 解決率
  • 解決時間
  • 分布
  • 觸發(fā)原因
  • 嚴重性
  • 優(yōu)先級
  • 數(shù)量變化趨勢
• 覆蓋率
  • 需求覆蓋率
  • 故事卡AC覆蓋率
  • 代碼覆蓋率
    • 函數(shù)覆蓋數(shù)量
    • 運行使用到的功能覆蓋數(shù)量
    • 條件覆蓋數(shù)量
    • path覆蓋數(shù)量
  • 自動化測試覆蓋率
    • 運行通過的測試比率
      • 功能穩(wěn)定程度
    • 不同開發(fā)階段的比率
• 測試執(zhí)行
  • 測試執(zhí)行率
  • 測試執(zhí)行通過率
• 故事卡返工數(shù)量及比例
• 測試過的系統(tǒng)瀏覽器數(shù)量
• PO驗收反饋

同時，實例化的質(zhì)量目標也是很好的項目質(zhì)量的工具。對于質(zhì)量模型，我們可以看下每一個質(zhì)量元素我們是否做到；對于具體的指標metrics，要隨時監(jiān)控反饋。

持續(xù)改進和風(fēng)險分析

一旦測試策略被確定，一般來講不會經(jīng)常變化，因為測試策略設(shè)置了一些測試標準。如果測試標準頻繁地變動，這會讓具體計劃的執(zhí)行變得困難，同時帶來更多的資源浪費，最終影響了項目的質(zhì)量。

在項目中我們會經(jīng)常遇到“變化”：比如說

• feature scope的變化
• 具體功能細節(jié)的變化
• 測試重點的變化
• 根據(jù)risk assessment來調(diào)整的變化

這些變化對測試的影響是被測對象的范圍以及項目資源的調(diào)配。對于項目的質(zhì)量目標、測試類型、測試階段影響不大。所以，測試策略一旦被制定出來，變化不會太大。

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

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

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

其他影響質(zhì)量的因素

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

1. 風(fēng)險控制
2. 流程改進
3. 敏捷實踐
4. 團隊組成
5. 項目狀況

寫在最后

上面詳細闡述了我如何理解敏捷項目中的測試策略以及制定測試策略的具體步驟。由于IT項目的多樣性和復(fù)雜性，這個總結(jié)不可能適用于有著不同上下文的項目，因地制宜地制定測試策略才能保證測試策略在項目中的可用性和合理性。

參考資料

• 從測試策略到測試架構(gòu)
• 究竟什么是軟件測試策略
• agile-test-plan-do-we-really-need-one
• A Question About Test Strategy
• 軟件質(zhì)量模型
• 軟件質(zhì)量度量