敏捷團隊中的測試策略

測試 策略的定義

先看下維基百科上關於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制定測試策略的具體活動及流程。總的來說，大體流程可以如下

前期專案資訊收集

確立質量目標

確定測試型別

確定 測試工具 和框架

確定測試階段

確定測試度量

持續改進和風險分析

前期專案資訊收集

上面提到了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

確定測試階段

這個環節我們需要確定在專案開發生命週期的每個階段做什麼樣的測試，使得測試型別與專案的開發流程充分結合，這樣就能最大發揮所有測試活動的效果來達到我們的質量目標。因此，我們可以做出類似下面這樣的表格來表現每個階段的測試型別及其實施方法。