“測試策略是什麼樣的？”
“測試策略嘛，還不是包括#&~+-=～*-+$這些…”
“你們項目的策略有什麼特別的嗎？”
“我們項目嘛，測試策略的內容有點多，從哪說起呢？”
前面那個場景有沒有似曾相識？你是否清楚目前你們正在使用的測試策略是什麼樣的？
一、常見測試策略
（一）測試策略的內容與形式
我們都知道，測試策略包括以下兩方面的內容：
1. 測什麼（What）？
測什麼是指質量需求是什麼、需要關注質量的哪些方面，比如應用的功能範圍、性能、安全、易用性等非功能需求。
2. 怎麼測（How）？
怎麼測就是採用什麼辦法來幫助系統實現質量需求，而不僅僅是手動和自動化的測試方法，也包括一切為質量保障服務的流程、環境、基礎設施和人員等。
為了描述清楚要測的內容以及如何來測，測試策略通常篇幅較長的文檔，包含多個章節；以文字描述為主，只加上少量的配圖。
圖1 常見策略文檔目錄結構【圖片來源：https://wenku.baidu.com/view/17b9b03067ec102de2bd89ee.html】
（二）測試策略的痛點
長篇大論的文字給人帶來居多不便：
1. 編寫困難
篇幅較長的測試策略文檔要寫好還真不是件容易的事情，尤其是對於理工科出身的不是那麼擅長寫作的測試人員來說，更是比較麻煩，成本較高。
2. 不易閱讀
長篇大論的測試策略文檔，要從中快速找出關鍵信息可沒那麼容易，可能一不小心錯過的細節就是最關鍵的部分，因為篇幅太長，通常不太重要的信息挺多的。
3. 維護、更新痛苦
策略文檔不可能一成不變，這種篇幅較長的文檔要更新和維護簡直是噩夢。往往剛開始還好，隨著時間推移，更新和維護越來越麻煩。
4. 失去了策略的價值
由於不易閱讀，也不易維護和更新，事實上團隊可能有很多人並不是很清楚策略文檔上的內容，這樣的策略文檔形存實亡，不能真正起到策略的指南作用。
5. 反敏捷
工作的軟件高於詳盡的文檔
-- 敏捷宣言
敏捷開發強調的是縮短反饋週期，快速交付高質量的軟件產品。花費太多精力編寫、維護一份不能起到策略作用的長篇幅文檔，顯然是不利於敏捷的。
測試策略的重要性不言而喻，是否可以找到一種更好的表達方式，讓測試策略不那麼痛呢？
Jamie McIndoe在"Testing Stuff - A One-Page Test Strategy"中首次提出可以把測試策略圖視化，用一頁紙來搞定。我們都知道，圖示化的表達方式直觀、清晰，容易識別關鍵信息，並且易於記憶。如果能夠用圖示化的方法將測試策略在一頁紙上搞定，一定非常棒。
下面一起來看看圖示化表達的測試策略是什麼樣的。
二、圖示化測試策略
（一）一頁紙搞定
顧名思義，圖示化就是用圖來描述測試策略的內容，但並不是把原來文字描述的每個章節直接翻譯成圖。我們考慮用圖來表示測試策略的各個關鍵組成部分，並且繪在一頁紙上。
當然，一頁紙的測試策略只是將關鍵信息以圖示化的方式呈現出來，並不是整個測試策略的全部，在一頁紙的背後是團隊的充分溝通和對策略各個方面達成的一致認識，是需要團隊一起來做很多工作的。這種高度簡化的呈現形式，是為了給團隊更多的討論空間，一頁紙也更易於修改，從而更能適應變化，真正滿足需求。
基於Jamie McIndoe的可視化測試策略思想，我建議的測試策略圖包含下列信息：
- 指導性原則：團隊為質量負責
- 測什麼：可能包括功能、性能和安全等
- 如何測：測試左移、精益測試、測試右移，涵蓋測試流程、測試類型、測試方法等
例如，藍鯨項目的測試策略如下圖所示：
圖2 藍鯨項目策略圖
（二）各部分詳細介紹
下面，我們來看看該測試策略各組成部分的具體含義。
1. 指導性原則
藍鯨項目採用的是敏捷開發模式，質量不是某個單一角色的事情，團隊為質量負責是項目質量保障的指導性原則，需要所有團隊成員對此有一致的認識，人人都要有關注質量的意識。更多關於團隊為質量負責的內容，請關注我的另一篇文章《說好的團隊為質量負責呢？》
2. 測試左移與質量內建
敏捷測試最關鍵的兩點就是儘早測試和頻繁測試（Test early, test often），也就是測試左移與質量內建的思想。
測試左移要求在需求分析階段開始對需求本身的合理性進行驗證，不僅要正確的構建產品，更重要的是構建正確的產品，這就需要把好源頭需求這一關。因此，我們可以看到策略裡的流程是從需求分析開始的。
質量內建則是在軟件開發生命週期的每個階段都有質量相關的活動，把質量融入到開發的每一個步驟，通過CI/CD等方式獲取快速反饋，做好軟件缺陷的預防，以減輕缺陷暴露太晚帶來的大量修復成本。藍鯨項目的開發生命週期主要體現在圖示的七個環節，每個環節都有相應測試活動的開展，並且每個活動都有不同角色的參與。
圖3 藍鯨項目生命週期的測試活動
3. 測試精益
測試精益可以理解為以業務價值為目標，以儘量少的成本交付高質量的軟件，也就是說測試要測在能體現價值的點上，要做到有效覆蓋、減少浪費。藍鯨項目的策略圖裡有兩個框架幫我我們更有效的測試，分別是測試象限和測試分層。
（1）測試象限
在Lisa Crispin和Janet Gregory合著的書籍《敏捷軟件測試：測試人員與敏捷團隊的實踐指南》中，我們看到了敏捷測試象限的介紹。由於該象限框架所起到的作用不僅侷限於敏捷的環境，我在這裡稱之為測試象限。
測試象限矩陣一共四個部分，稱為四個象限。下側是面向技術的測試，上側是面向業務的測試；左側是支持團隊的測試，右側則是評價產品的測試。
a. 支持團隊的測試
支持團隊的測試是用來告訴團隊要寫什麼代碼，起到明確需求、輔助設計的作用。其中，第一象限是面向技術的支持團隊的測試，主要是TDD，幫助構建產品的內部質量，也就是代碼質量的保障，比如單元測試和api測試等；第二象限則是面向業務的支持團隊的測試，從更高層次以業務專家可以理解的方式確定系統期望的行為，做到產品外部質量的保障。
這兩個象限的測試能夠快速提供反饋信息，並確保快速的解決問題，既指導了功能的開發，又提供了防止重構和新代碼的引入而導致不期望行為發生的安全網。
b. 評價產品的測試
程序員編寫的代碼可以使得左側面向業務的測試通過，但也可能沒有產生客戶真正想要的東西，因此還需要第三、第四象限的評價產品的測試。
第三象限是面向業務的評價產品的測試，通過模仿真實用戶使用應用的方式，幫助確認是否構建了真正需要的產品；第四象限是面向技術評價產品的測試，主要採用工具和相應的技術來評價產品的性能、健壯性和安全性等非功能特性，並且在開發週期的每一步都要考慮這些測試的開展。
這兩個象限的測試中產生的信息應該反饋到象限矩陣的左側，並用於創建新的測試來驅動下一步開發，形成良性的增強環路。
c. 測試象限的使用
象限的順序跟測試執行的順序無關，敏捷開發往往開始於客戶測試（面向業務的測試）。與測試執行時機相關的因素通常有：
- 產品發佈的風險
- 客戶方對產品目標的要求
- 是基於遺留系統的開發還是從零開始構建的新系統
- 可利用的測試資源等
測試象限提供一種需要哪些測試來保障質量的思考框架，可以根據項目具體情況，結合考慮以開展對應的測試。策略圖所示藍鯨項目的測試象限體現的測試類型跟Lisa書裡介紹的就不太一樣，這是根據項目當前跟客戶的合作方式、業務需求、質量要求等來確定的當下需要執行的測試，比如其中的安全測試就分為業務部分和技術部分。
（2）測試分層
關於測試分層的思想，大家可能比較熟悉的是測試金字塔，主要是針對自動化測試，根據測試所能覆蓋的範圍分成不同的層。金字塔的含義是測試比例的多少，體現為底層單元測試較多，越往上層測試比例越少，呈現為金字塔結構。
越往底層的測試越接近代碼，編寫成本更低、執行速度更快、定位問題也更準確，但是離業務較遠，不能很好的體現業務價值；越往上層的測試越接近業務，更能反應業務價值，但有著不夠穩定、執行速度慢、實現成本較高的不足。因此，需要權衡利弊，根據項目具體情況，真實的目標來確定每層測試的比例。
至於具體的比例是金字塔結構，還是蜂巢結構或其他，並不是一定的，也不會是一成不變的，可能受到價值目標、痛點、質量要求、技術架構、技能水平等因素的影響。
藍鯨項目的策略圖裡的是當前的測試分層結構，類似於蜂巢機構，那是因為基於微服務架構的特點，藍鯨項目更多的自動化測試是保障服務間連通性的API測試部分，而對於單元測試和端到端測試的比例則都有減弱。更多的關於藍鯨項目測試分層策略的詳情，請參考我的博客文章《微服務測試的思考與實踐》。
4. 測試右移
由於軟件系統所處生態環境越來越複雜，技術架構的演進、業務複雜度和數據量的增加、基礎設施的發展帶來更多的不確定性，軟件系統的質量保障在測試環境已經搞不定了，我們需要把目光右移到生產環境。這就是測試右移的思想，其實也就是生產環境下的QA(QA in Production)。
生產環境有著不同於測試環境的特點，生產環境的QA並不是測試環境的QA的直接後延，而是需要利用其特點通過技術手段收集生產環境一切可利用的數據，包括日誌、用戶行為、用戶反饋等，利用這些數據來分析和優化業務以及開發過程的開發和測試工作，形成一個開發過程與生產環境信息分析的良性循環系統。
藍鯨項目在這方面做了不少工作，更多相關的詳細內容，請參考我的另兩篇文章《生產環境下的QA》和《QA與Ops通力合作打造反脆弱的軟件系統》。
5. 測什麼
之所以把這個放到最後介紹，是因為前面介紹“怎麼測”的各個部分都已經涵蓋到要測試的內容，藍鯨項目的測試內容主要有：功能、性能和安全。
這三個方面的測試類似，都是從需求分析到生產環境每個環節都要考慮相關測試，做到質量內建、安全內建和持續的性能測試。
圖4 藍鯨項目的非功能測試
三、測試策略的正確打開方式
一頁紙搞定的測試策略，優勢非常明顯，比傳統策略文檔更加簡潔、清晰，關鍵信息一目瞭然。我們再來看一下測試策略圖示化以後，還有哪些需要注意的方面。
1. 目標驅動
雖然上網搜索能找到很多測試策略模板，但測試策略不應該是千篇一律的，不可以死搬硬套通用的模板。測試策略受到多種因素的影響，比如：業務價值、質量要求、當時痛點、技術架構、技術能力、工作重心、績效要求、項目狀態等等。
制定測試策略需要明確目標，綜合考慮各種因素，權衡利弊，找到最適合自己項目當前狀態的策略。也就是說，測試策略應該是目標驅動的。
2. 演進式
項目處於不同階段會有不同的質量目標，同時隨著架構的演進和業務的發展，對軟件系統的質量保障工作也需要隨之調整。因此，測試策略還應該是演進式的、隨需調整的。
圖示化的測試策略是高度精簡的，具有更大的討論和發揮空間，在防止僵化、保持演進方面的優勢明顯。
四、總結
測試策略舉足輕重，內容很重要，需要以價值目標驅動，持續度量，並根據項目特定情況適時調整、演進。策略文檔不要拘泥於形式，利用圖示化的方法，直觀、清晰的表達，是非常好的組織形式，能有效克服常規文字為主的文檔所帶來的痛，推薦大家使用。
延伸閱讀
1.Jamie McIndoe的一頁紙測試策略：https://making.stuff.co.nz/testing-stuff-a-one-page-test-strategy/
2.說好的團隊為質量負責呢：https://www.jianshu.com/p/f81795a23554
3.QA in Production：https://martinfowler.com/articles/qa-in-production.html
4.生產環境下的QA：https://www.jianshu.com/p/20b454a88bdb
5.QA與Ops通力合作打造反脆弱的軟件系統：https://www.jianshu.com/p/1f456d91c3ab
文/ThoughtWorks 林冰玉
更多精彩洞見，請關注微信公眾號：ThoughtWorks洞見
